Tile Engine

edited May 2012 in Help request
Well, my next game will be a top-down game (in the line of Zelda, Chrono Trigger, etc) and I need to load tilemaps... I've searched the forum and the tutorials but didn't find good info on how to achieve this with ORX.
I'll keep doing some reasearch and testing, because currently I'm just loading lots and lots of tiles manually and I'm afraid that it can be a performance issue on really big maps...

any tips on this? does anyone worked with tile maps and ORX?

Thanks in advance!

Comments

  • edited May 2012
    Hi there Antaka,

    I assume by 'tile maps' you mean something like... this:
    ground.png

    to build something like this:
    SpaceMatter_10.png

    If so, you can do this rather easily :)
    [TileGraphic]
    Texture			= ../data/image/ground.png
    TextureSize		= ( 64, 64, 0 )
    
    [Grass@TileGraphic]
    TextureCorner	= ( 256, 704, 0 )
    
    [Wall@TileGraphic]
    TextureCorner	= ( 0, 320, 0 )
    

    the [TileGraphic] object defines the bas texture atlas/tile sheet/sprite map/ whatever you want to call it :)
    the 'texture' is the actual file, and the 'texture size' is the size of the image within that file that you want to show.

    the secondary objects [Grass] and [Wall] inherit from the base object (thus the @TileGraphic) and then define the 'texture corner' or the top-left pixel within the file, where your image is stored.

    If you have different sized images, you can re-define the TextureSize inside the child objects to overwrite the parent when needed too!

    Good luck! :)
  • edited May 2012
    That just what I want to do. Thanks a lot Gray!

    After setting that in the .ini file, I can create "Grass" and "Wall" objects wherever I need them? How do I build the map using the then? Drawing them one by one wouldn't lower the FPS?

    This brings another question to my mind... does ORX do any type of culling for the graphics outside the Viewport?
  • edited May 2012
    Yes, you can create as many instances of those objects as you need; (up to something like 32000 objects I think :D)

    As for building your map, this depends on what you need/want to do. in my screenshot above, I build that map dynamically something like this:
    for( each x in mapWidth )
    {
      for( each y in mapHeight )
      {
        tileIndex = y*mapWidth + x;
    
        orxOBJECT* newTile = orxObject_CreateFromConfig("Grass");
    
        // this calculates the isometric position of the tile! :)
        orxFLOAT tX = (x*32) + (-y*32);
        orxFLOAT tY = (x*16) + ( y*16);
        orxVECTOR pos = { tX, tY, 0.0f};
        orxObject_SetPosition( newTile, &pos );
    
        map[tileIndex] = newTile;
      }
    }
    

    edit: and because I forgot to answer it (sorry)

    There is only the most basic culling in orx right now (per-object, checked every frame, visibility culling against the viewport) -- for systems like mine (many MANY objects) this is a problem that I'm working on fixing in my own code.
  • edited May 2012
    Yes, that was the first thing that came to my mind... I don't know how ORX handles the objects and I was affraid that drawing too many tiles whill kill the performance... I guess I'll have to test it and see for myself :P

    I'll try this as soon as I have some free time hehe...

    Thanks a lot Grey!
  • edited May 2012
    You are most welcome :) oh and before I forget - Welcome to the orx community :)
  • edited May 2012
    I see that I'm late again, but here are some precisions:

    - Sausage wrote a tutorial showing a similar approach to Grey's one: http://orx-project.org/wiki/en/orx/tutorials/community/sausage/semi-dynamic_objects_and_level_mapping
    - the render plugin will do culling (first eliminating objects based on their Z component, then checking bounding box intersection with the camera).
    - drawing many objects won't be slow by itself if you keep all your tile objects within the same render context (ie. if they have the same Z value, using the same texture atlas, using the same shader if any, using the same blending and smoothing parameter). If those conditions are filled, orx will batch draw calls, up to 2048 objects within the same batch on computers (1024 on iOS/Android).

    Unfortunately if you create 10 000+ objects, things will get laggy even if they're not displayed on screen. It's because there's no partitioning in orx yet. I'll try to make a smarter render plpugin in the short term to try to work around that issue until a partitioner is added to orx. That being said, in the case of tile maps, there's a very easy way to have something rendered very fast no matter how many tiles you have.

    This approach is a bit advanced in the sense you need to create a single dummy object that will always be in front of the camera, in the background with a graphic using any dummy texture.
    Orx sends events when objects are about to get rendered and whentheir rendering has been done. You simply have to listen to these events and handle the orxEVENT_TYPE_RENDER/orxRENDER_EVENT_OBJECT_START for your map object.
    When you get it you can then draw the tiles yourself using the orxDisplay API. As you know the camera position thta should be pretty simple. When you're done, your event handler should return orxSTATUS_FAILURE which will tell the render plugin that he shouldn't render this object himself.
    And voilà, only one object and you can cover virtually infinite maps. ;)
    Of course, you can then do that work with a shader if you feel like it.

    As for storing your map, I'd use the config system myself, this way you can easily modify the map and interpret it in code. Something like:
    [MyMap]
    Map = Tile1 # Tile1 # Tile5 #
          Tile3 # Tile2 # Tile6 ; Etc...
    

    To finish, you can use the profiler to diagnostic in which oart of the code you spend too much time and how maby objects are rendered, how many batches are drawn, ... There's a thread on this topic on this forum. :)

    Hope this helps!
  • edited May 2012
    Hi iarwain!
    Thanks for that great explanation =) It's good to know a bit about how orx handles this things without reading the whole source code :lol:
    I cant believe I missed that tutorial hehe Thanks for the link.

    I did not had the time to get back to orx these days, I guess by the end of the week I'll be back with a working tilemap, and lots of new questions :P
  • edited May 2012
    No worries! :)

    I keep calling orx a small game engine but in the facts it's becoming bigger and bigger everyday with currently ~160k lines of code. So feel free to ask as many questions as you need, I don't expect anyone to read all that code! :P
Sign In or Register to comment.