headers
Nathan Whitehorn | 1 Mar 2002 01:01
Picon

Re: 3d engine

> In my dictionnary (ok, ok ... we can go far with that :-)  I think a 
> game
> engine is too specialized for a "basic" OS package. We have to 
> concentrate
> on more generic services that can be used for. Like DirectX is a 
> generic API
> for games development, but not an engine itself.
> 
> But if we plan for a huge packaging (like Linux distros), sure we can 
> bundle
> anything else, including this engine...
> 
> I just want for those "extra" to remain extra and not be considered 
> as
> "native" in the heart of the OS...

I agree wholeheartedly. I had not realized at the time I wrote that 
that Crystal Space was a game engine. I thought it was something like 
Mesa.
-Nathan

--
Fortune Cookie Says:

OMNIVERSAL AWARENESS??  Oh, YEH!!  First you need four GALLONS of
JELL-O and a BIG WRENCH!! ... I think you drop th' WRENCH in the JELL-O
as if it was a FLAVOR, or an INGREDIENT ... or ... I ... um ...
WHERE'S the WASHING MACHINES?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Zenja Solaja | 1 Mar 2002 01:36
Picon

RFC archieve and public access

	[Zenja Solaja]  Hi everyone.  I believe that we urgently need to
solve a very serious problem - the archieving of great ideas floating around
GE and OBOS lists.  This issue was brought up in another thread and I'd like
to move it to its own thread.

	What I'm proposing is:

	1. We establish a public repository (the GE or OBOS website) where
we publish a set of RFC documents.

	2. Each RFC would address a certain domain, ie a FileSystem layout
RFC, a Deskbar GUI RFC, Window Border RFC etc.  

	3. Each RFC would be itemised (1.2.3, 1.2.4).

	4. When discussing an item, the email header would reference the
item in question.

	5. We'd limit discussion to one item at a time until a consensus is
met.  We would cycle through the entire RFC twice.

	6. A greater than 2/3 majority is essential (>66%).  Therefore,
quorum is at least 4 people voting.  Here are some illustrative numbers to
accept an item: 3/4 (75%), 4/5 (80%), 5/6 (83%), 5/7 (71%), 6/8 (75%) etc.
Notice how 4/6 doesn't pass the >2/3 barrier.  To loby for an item, simply
get more supporters to vote for it.

	7. Once the community agrees on a RFC, it becomes a SRS (system
requirements specification).  Ambitious developers can now tackle a project
of their choosing.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Bruno G. Albuquerque | 1 Mar 2002 03:58
Picon
Gravatar

select() magic! :)

Ok, firs of all I would like to publically thanks Philippe Houdoin. 
This guy rock! You may be wondering why I am so excited... Well, he 
just got select() support working on plain R5! That's it, you read it 
right! Even some ex-Be engineers I contacted told it was not possible!

So with this one, we managed to overcome two major problems of the BeOS 
net_server:

1 - Sockets will be file descriptors in our implementation.
2 - select(0 will work in sockets and file descriptors.

Bellow you will find his email with an explanation of how this all 
works.

Thanks Philippe!

-Bruno

Okay, you guys were right about R5.0.3 and select() problem!
My code doesn't works under R5.0.3. :-( (beside the need to fix some 
compilation errors...)

Not without some tweaks :-)

Problems are:
- R5.0.3 kernel_intel have a select() call, but is not exported.
- Be Inc' libnet.so export a select() call, but this one don't works 
with file descriptors, only with R5 net_server sockets.

/me thinks this point explain the previous one: name collision, so
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bruno G. Albuquerque | 1 Mar 2002 04:24
Picon
Gravatar

select() again.

Travis brought to my attention that even if select() is working it does 
not mean notifications will be sent. I know one of the reasons is that 
the R5 BFS does not implement the bfs_select() call, but our OpenBFS 
does (since today, I implemented it). So if this would be the problem, 
it will work when OpenBFS is done.

-Bruno

--
Fortune Cookie Says:

Bugs, pl. n.:
	Small living things that small living boys throw on small
living girls.
Permalink | Reply | 0 comments |
headers
Michael Phipps | 1 Mar 2002 03:26
Picon

Re: 3d engine

Of course, Nathan is right in saying that code is required for an API to do something.
What do you define as an "engine"? The definitions that I infer from what is written would
imply that any significant code is an engine. App_server, I think, could be called an "engine".
To say that we should have no "engines" would imply that the OS does nothing, literally.

What to include and not include is almost a philosophical question. 
Certainly, no one would argue that we should not include the kernel. After that, I think that
few people will agree on what an "optimal" package would include. Most people want
networking. Most people want a GUI. Most people want printing. That stuff is all pretty simple.
Every OS out there includes those things. But what about gaming APIs? On a pure business machine,
they may well be wasted. Or ODBC, on a gamer's machine. Or MIDI on a kiosk?

The way that I (personally) see it, the "cost" of including the package should be outweighed by its 
usefulness. Most people will use networking. So the fact that it takes up (with all of the tools and all)
N megabytes of the install are worthwhile. If we did not include networking, a majority of people would
need to install it. On one side of the equation (the DON'T include side), you have size of the package, 
CPU cycles when unused and making the package bigger. On the other side (the DO include side) you have
convenience, utility out of the box, the ability for standardization and increasing the popularity of the API.

So, generally, I would think that packages that are fairly small, fairly good quality and fairly useful should
be installed by default. The bigger, the more unstable, and the more obscure, the less likely that they should
be installed.

>In my dictionnary (ok, ok ... we can go far with that :-)  I think a game
>engine is too specialized for a "basic" OS package. We have to concentrate
>on more generic services that can be used for. Like DirectX is a generic API
>for games development, but not an engine itself.
>
>But if we plan for a huge packaging (like Linux distros), sure we can bundle
>anything else, including this engine...
(Continue reading)

Permalink | Reply | 2 comments |
headers
Michael Phipps | 1 Mar 2002 03:46
Picon

Re: RFC archieve and public access

I want to take this point by point:

>	[Zenja Solaja]  Hi everyone.  I believe that we urgently need to
>solve a very serious problem - the archieving of great ideas floating around
>GE and OBOS lists.  This issue was brought up in another thread and I'd like
>to move it to its own thread.
>
>	What I'm proposing is:
>
>	1. We establish a public repository (the GE or OBOS website) where
>we publish a set of RFC documents.

That is supposed to be what GE is.

>	2. Each RFC would address a certain domain, ie a FileSystem layout
>RFC, a Deskbar GUI RFC, Window Border RFC etc.  

Fine.

>	3. Each RFC would be itemised (1.2.3, 1.2.4).

Good.

>	4. When discussing an item, the email header would reference the
>item in question.

Sensible.

>	5. We'd limit discussion to one item at a time until a consensus is
>met.  We would cycle through the entire RFC twice.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Phipps | 1 Mar 2002 03:50
Picon

Re: select() question.

Select and mmap are, I think, the two key API items that give UNIX people
the biggest headache in dealing with BeOS. I (as kernel guy) am aware of them.
MMap is definate for R1. Select may be trickier, but I will certainly work with the
Networking team to see if we can't hammer something out to fix it. In my opinion, this is
a bug in R5, and not something that we HAVE to replicate. But I can not promise a fix
for select, either. I will try.

>You might want to check here: 
>
>http://mail.gnome.org/archives/mc/2001-November/msg00024.html
>http://www.zope.org/Members/rbickers/Zope_on_BeOS
>
>IIRC this came up as a topic on the old BeDevTalk mailing 
>list too. 
>
>Best Regards, 
>		David
>
>.. *  *      *   .   \|/  *      *     ,   . *   '  *  .
>..   .   *  ,     * --*--    .     `    * ,   .  *  ,  .
>David Sowsy    .    /|\  BeOS Rebel and Coder   .  *  .
>http://dsowsy.nanorevolution.com   .   *   .   *   .  .
>
>
>
Permalink | Reply | 0 comments |
headers
Nathan Whitehorn | 1 Mar 2002 04:09
Picon

Re: RFC archieve and public access

> I want to take this point by point:
> 
> >	[Zenja Solaja]  Hi everyone.  I believe that we urgently need to
> >solve a very serious problem - the archieving of great ideas 
> > floating around
> >GE and OBOS lists.  This issue was brought up in another thread and 
> > I'd like
> >to move it to its own thread.
> >
> >	What I'm proposing is:
> >
> >	1. We establish a public repository (the GE or OBOS website) where
> >we publish a set of RFC documents.
> 
> That is supposed to be what GE is.

And *is* what GE is. In fact, this functionality already exists on the 
GE website and has several RFCs.

> >	2. Each RFC would address a certain domain, ie a FileSystem layout
> >RFC, a Deskbar GUI RFC, Window Border RFC etc.  
> 
> Fine.

I would expect that no RFC would address multiple domains. But 
competing RFCs should certainly be allowed.

> >	5. We'd limit discussion to one item at a time until a consensus is
> >met.  We would cycle through the entire RFC twice.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nathan Whitehorn | 1 Mar 2002 04:11
Picon

Re: select() question.

> Select and mmap are, I think, the two key API items that give UNIX 
> people
> the biggest headache in dealing with BeOS. I (as kernel guy) am aware 
> of them.
> MMap is definate for R1. Select may be trickier, but I will certainly 
> work with the
> Networking team to see if we can't hammer something out to fix it. In 
> my opinion, this is
> a bug in R5, and not something that we HAVE to replicate. But I can 
> not promise a fix
> for select, either. I will try.

We certainly don't have to replicate it. Since the Net Kit docs now say 
that socket tokens have no meaning, old apps won't care if they become 
real fds. They won't know the difference. New apps will, and will get 
appropriate new power. And people porting things from UNIX will kneel 
before you and kiss your feet.
-Nathan

--
Fortune Cookie Says:

Non-sequiturs make me eat lampshades.
Permalink | Reply | 0 comments |
headers
Andrew Edward McCall | 1 Mar 2002 12:03
Picon

Re: RFC archieve and public access

Hi,

>A couple points here. I think we *should* decide things. 
Recomendations 
>should be finalized for coding when the appropriate time comes. *But* 

You can't really do that.

At the moment, al the programmers that are involved with OpenBeOS are 
involved with it because *they* want The Be Operating System. They know 
what their job is - to create an exact replica of the Be Inc, software 
that they are copying, they have chosen to make a copy.

When they have finished, it will just be like any other project : 

If you want something in the OS you have a few choices :

a) Put a request in to the author for him to code *if he wants to*
b) Add it yourself, and send the diffs to the maintainer to add, *if 
they want to*

If they fail you can fork a new version, and hope that its clearly 
better than the original so that it gets included in the original ones 
place.

The GE Project can not dictate what any of the programmers write in 
their own spare time, it can be a forum for ideas - but unless the GE 
Project does the coding, thats all it ever will be.

Just my thoughts.....
(Continue reading)

Permalink | Reply | 0 comments |

Gmane