Re: Some Documents

[WareWolf@chris2.mayn.de (WareWolf)]

Hi Adrian,


AR> The other document is a license which I think is appropriate
AR> for us.  It is a lot like the LGPL, except there is no
AR> obligation on people who distribute binaries to distribute
AR> the source.
AR>
AR> Since it  is more relaxed than the LGPL, which is more relaxed
AR> than the GPL, there should be no trouble putting [L]GPLed code
AR> under this new license.  What do people think?

I'm not sure about that. Have you checked the Artistic License (somewhere
under www.opensource.org is a link to it)? It ts less restrictive than the
LGPL and it is generally accepted. I think it is easier to integrate
(L)GPLed Code under the Artistic than under some self-made license.


AR> THINGS AND THEIR WORLD
AR> ----------------------

AR> Finally the  world is probably also what takes care of flow control.
AR> i.e it is responsible for giving all the Things and Entities, their
AR> little time slices.

I don't think it's a good idea to include timing here. Perhaps it's better  
to only include information such as speed, paths etc at this point and let  
some seperate layer handle the timing.

I don't know whether this would work, as detailed info about the world is  
needed for it. Just an Idea.


AR> 	* They can be drawn.  They can probably do other things,
AR> 	  like make noises, but I haven't thought about how that
AR> 	  fits in yet.

This is somewhat similar to the point above. I'd love to have the world  
description (including collision detection etc) separate from such things  
as visualization. Perhaps the object descriptions of the world engine can  
be made abstract enough for this.


AR> The idea is that the when a Thing moves, or does anything else which
AR> could cause a collision, world checks these bounding boxes.  If it finds
AR> a collision, then it informs both Things involved, they can decide among
AR> themselves whether they are really colliding or not.

Sounds good.



AR> A special method in the View Manager will be invoked once each frame
AR> which will cause everything that is visible to be drawn.  Why not
AR> make the View Manager part of the World?

I like the "View manager" concept, but including it into the world could  
pose some drawbacks on versatility.


AR> Here is one example: we have _two_ views of the world, one is the
AR> "main" screen, while the other is a "radar".  We could have one
AR> View Manager for each, but they would share the same World.

Here you would have the world to contain several view managers.

And perhaps someone wants to have some view manager accessing several  
worlds simultaneously (e.g. for providing some kind of "diff" or for  
overlaying parallel dimensions ;)


AR> SIGNALS AND SLOTS
AR> -----------------
AR>
AR> Signal/Slots are an event passing mechanism which should be familiar
AR> to users of the Qt GUI Toolkit.  The mechanism here will be similar
AR> but less elaborate.

As I wrote I saw a very good signal/slot mechanism in the GTK-- package.  
It seems to be more powerful than the one of Qt (including type safety  
etc) yet is implemented in only 12k of C++ code (including about 150 lines  
of comments). And it is really simple to use.


AR> either of the objects at either end of the connection.  In fact, the
AR> whole idea is that objects can be made to communicate without having
AR> to even know about each other's existence.

Exactly :)

AR> Why do we have this?  Let our two objects be a door D somewhere in the
AR> game, and a button or switch B which opens that door.  The idea is that
AR> when B is pressed by the player, then it will send a Signal.  D
AR> will have a Slot which is connected to that signal.  When it receives
AR> the signal, the door will open.

And the receiving object doesn't even have to know that it can react to  
the given signal (e.g. Connection of the sigal Button.Pushed to  
Door.ToggleState () ).

AR> Here is one reason we may not use a signal/slot mechanism.  If the
AR> GUI chooses to use an event mechanism which is different, but gives
AR> us the same functionality, we may choose to use that instead, to avoid
AR> duplication.

Yep. We should use some general mechanism for the entire Layer O. And the  
one I mentioned above seems to be fit for this. I'll keep you informed.



AR> 			LISCENSE FOR THE PENGUIN GRAPHICS LIBRARY


Sounds good, but please have a look at the Artistic, too


Cu
        Christian


Christian Reiniger (Germany)
e-mail: warewolf@chris2.mayn.de