Re: [Adonthell-devel] New map engine first draft commited

[cirrus]

Alexandre Courbot wrote:
> 
> 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! :)
> 

Wheee.. I've seen the future!
It seems to run smooth on my machine (but then again if it didn't I'd be
worried!) so when it's finished and tuned and SDL uses OpenGL it will
RULE!!

        -James
-- 
   ___    ___  ___       ___ 
  /    / /__/ /__/ /  / /__                 Reg. Linux User #148821
 /___ / / \  / \  /__/ ___/@linuxgames.com  www.twiddles.com
                                            adonthell.linuxgames.com