[Adonthell-devel] New map engine first draft commited

[Alexandre Courbot]

I have a little demo for you guys! :)

Of course, it's just a draft, which means GFXs are powered by myself -
so do not expect anything brilliant to see ;) I've just ripped a few of
Janesta's frames to quickly make a character.

So, how to run it:
checkout the Branch_road_to_0-4 branch:

cvs co -d adonthell_road_to_0-4 -r Branch_road_to_0-4 adonthell

this will create an adonthell_road_to_0-4 directory, containing the
development branch. Now get the following data file:

http://www.gnurou.org/adonthell-stuff/alextest.tgz

and untar it into the source src/ directory. Then ./autoconf,
./configure and make the new source directory. This will produce an
alextest binary in the src directory. Go into the src/ directory and run
./alextest (it's important that you are in this directory and the data
package is unpacked there too).

So, what's interesting there? There are two map_objects placed, one at
pos (5, 5) and the second one at pos (7, 6, 20, 20). As you can see, you
can place objects with a precision of one pixel (the grid is to let you
see that). Use the arrow keys to move Janesta (and admire the work on
the animations! ;)). She moves of course pixel by pixel too now. Wanna
make her run? Just hold 'r' when moving her. There is no walkability
stuff yet, but everything should be correctly rendered. The renderer is
quickly coded in main.cc - so don't waste your time looking at it ;)

So, how does it work? First, every instance that can have gfxs can also
work without them. For example, map_character doesn't contain any gfx,
while map_character_gfx only contains that. map_character_with_gfx
inherits from these two classes and overload map_character's functions
that uses gfxs on the client side. That way, map_character can work on a
server, while map_character_with_gfx will be used on clients (but you
can as well use map_character_with_gfx on a server, of course - it's
just an inheritance stuff). This is for the new gfxs handling. If you
have better names for the classes, feel free! :) The landmap class only
handles content with gfxs, but it'll be fixed soon, don't worry.

Now on stuff on the map. Every square has a list of pointers to objects
that are placed on it. These objects are map_placeable. A map_placeable
is an object that simply can be placed on a map. Having a map_placeable,
you can have information about it's occupation, it's walkability (and
it's gfxs). It doesn't have position information, that's why the
renderer map_placeable needs coordinates to render it - and why you can
also place the same map_placeable at several places on the map.

Going a bit deeper, a map_placeable can have several string named
states. A state includes a grid representing it's occupation (including
walkability), and gfxs for rendering. What's the use of this? Say you
have a door. The state "closed" would make it unwalkable with the closed
door gfx. If you switch it to the "open" state, it becomes walkable and
will be rendered by an opening door animation. This is also mandatory
for map_characters.

A map_object simple inherits from map_placeable and defines a few,
worthless telling here things. Maybe I'll add some (optionnal, of
course) Python sciprting capabilities - for example if you could have a
drawing callback for some water, you could reflect the image of
characters that are near it - see what I mean? Of course, this would be
optionnal so if you don't use it, it won't be slower.

map_characters also inherit from map_placeable, via the map_moving
class. map_moving is a map_placeable with coordinates, and the float
velocity members, so it can actually move on the map, at any speed, in
any direction (even others than the classic 8 directions you can assign
to Janesta in the example). A map_character defines some convenience
functions (not all finished yet :)) to set the good state depending on
the movment. If a character goes left, his state will be "walkwest" or
"runwest", or whatever else fits. This is done automatically, but you
can also have a lower level control, to define special states (dancing,
eating, ...). But on top of that, you will be able to use a
map_character nearly as before.

To render the map, the mapview browses the squares for it's objects,
guess what kind of object it is (via the 'type' member of map_placeable,
which inheritated classes sets to CHARACTER for a map_character, OBJECT
for a map_object, etc...), force the type a bit, and call the right
drawing function. This makes it easy to add new types of map objects,
like pickable items, and so on. The advantage being that you don't need
to handle one list per kind of object at square level like before. Just
make your class inherit from map_placeable, make the renderer know about
your new type, and voila.

Keep in mind this is a *draft* :) There are still plenty of methods that
are only defined in the header files (à la Java, urrk), names aren't
definitive (I'm open to suggestions by the way) and the API needs to be
thought a bit further. In short, improvments are welcome - I just hope I
have been clear. At worst, you can generate the doc with Doxygen and
have a look at the graphical inheritance stuff to have an idea on how it
works.

The rendering will certainly eat a lot of CPU. The new map stuff isn't
much slower than the old one, but rendering a 640x480 screen is,
unfortunately. Still, it's very acceptable on a quite recent machine
under X, but it's time SDL gets a true hardware acceleration support
under Linux. I'd bet money that under Windows with the DirectX it's very
fast. I'll raise the topic on SDL mailing list and see how good for us
is the OpenGL hack I've talked about once.

Voila, hope you like it! Comments now, please! :)

Alex.
-- 
http://www.gnurou.org