Rendering 2D tile-maps with 2D api's ...

[Jamie W]

Hello,

I've been checking out the major 2D game API's, or at least the one's I've found, which are:

PTK
Haaf's Game Engine
Popcap Framework
SpriteCraft
Tourque 2D game builder

Are there any more?


I'm now wondering how best to go about rendering a tile-map, my current thoughts are:

Load a bitmap to a texture in video ram. This will contain a lot of tiles (eg: a 512 * 512 bitmap containing 256, 32 * 32 pixel tiles).

Then in the draw phase of my game loop, something like:

DrawMapLayer1();
DrawSomeSprites();
DrawMapLayer2();
DrawSomeMoreSprites();
DrawMapLayer3();
DrawPanelOverlaysEtc();

I'm planning for multi-layered maps.

Am I barking up the right tree here?

The "load a tile-set in to video ram as a texture, then blit each individual tile that's currently in view" approach seems to be the way things are done (and seems very well suited to the API's I've researched so far).

Are there any other approaches I may consider?

Thanks. :)

[Gnatinator]

Sounds good! That is pretty much exactly how I did maps in Outer-Rim Pod Digger.

My only difference is that I had seperate 32x32 images for each tile. This is something I kind of regret now (longer load times, difficult to do post-render touchups so many seperate files).

Which brings me to the question, can anyone recommend a good program that will take all of your sprites and combine them into one big image for your game?

[jankoM]

Which brings me to the question, can anyone recommend a good program that will take all of your sprites and combine them into one big image for your game?

this would be it http://phelios.net/supersprites.html

[Jamie W]

I'm thinking that sprites are quite a different animal to tiles.

Tiles normally would all be the same size (e.g. 32*32), sprites could be any size (or should be, not withstanding technical limitations).



I keep reading that textures in video ram, must have width and height, of a power of 2. Is this correct?

So my questions are:

1) Legit texture sizes would be 256*256, 512*512, 1024*1024 etc ?

2) Can I have 256*1024 ?

3) For PC casual games, what amount of video ram can I assume a customer will have?

4) Do I just put 'needs 8 meg video ram' in my minimum specs?

5) What happens if they try to play and don't they don't have the minimum video ram?

6) Can I query the amount of available video ram from my game (and abort if there's not enough)?

[princec]

I'm thinking that sprites are quite a different animal to tiles.

Tiles normally would all be the same size (e.g. 32*32), sprites could be any size (or should be, not withstanding technical limitations).
This is a red herring. Sprites == tiles == sprites. Tiles aren't even necessarily the same size either. One special optimisation with tiles is that if you've got an entirely opaque tile you can blit it without any blending turned on which is a tad faster. Same's true for sprites of course. They're just the same thing used in two different ways.

I keep reading that textures in video ram, must have width and height, of a power of 2. Is this correct?If you're using a 3D API then usually this is the case. In fact just do this anyway, it'll save you some bother one day.


1) Legit texture sizes would be 256*256, 512*512, 1024*1024 etc ?

Yes.
2) Can I have 256*1024 ?
Yes.

3) For PC casual games, what amount of video ram can I assume a customer will have?0mb. Get it?

4) Do I just put 'needs 8 meg video ram' in my minimum specs?My advice is to say nothing about specs. 95% of consumers don't have a clue what a megabyte even is, let alone how many videos are in their rams.

5) What happens if they try to play and don't they don't have the minimum video ram?Just put up a dialog and tell them their computer's not powerful enough, end of story.

6) Can I query the amount of available video ram from my game (and abort if there's not enough)?Yes. Or use OpenGL, and don't worry about it.

Cas :)

[Jamie W]

This is a red herring. Sprites == tiles == sprites. Tiles aren't even necessarily the same size either. One special optimisation with tiles is that if you've got an entirely opaque tile you can blit it without any blending turned on which is a tad faster. Same's true for sprites of course. They're just the same thing used in two different ways.

Thanks for your answers Cas, my eyes are slowly being opened!

:)

I get the sprites == tiles == sprites; in that technically its the same thing, you're doing the same operation to get them on the screen.

My tiles will all be a uniform size, however, my sprites will be any size. I render them from MAX, and then have my own tool, to scan the output (of the 32bit tga's) and compile a single table and data file. The table contains and entry for each sprite/frame, with items such as width / height / x_offset / y_offset.

Using this scheme, I may need to create textures of any size (or at least best fit, using a power of 2) and then dynamically upload sprites to video ram as required. I'll prob need to review and adapt how I'm doing things though.

A lot of the API's seem to allow you to effortlessy switch between DirectX / OpenGL. With OpenGL, there are no video ram issues?

[princec]

What you plan to do is exactly how all my games have worked for the last 3 years so I'd say you're on the right track :) When packing my sprites I output an XML file with all the offsets. Also I trim off any transparent pixels before packing them - useful when rendering from Max as that generally produces a lot of wasted space around the edges of the images.

OpenGL manages VRAM for you. The first you'll know that you've not got enough of it is when the game slows to a crawl. Older DirectX's don't manage VRAM for you, and generally just crash in my experience when people don't take this into account :) I believe the latest DirectX's have some sort of automatic management.

Cas :)

[Jamie W]

What you plan to do is exactly how all my games have worked for the last 3 years so I'd say you're on the right track :) When packing my sprites I output an XML file with all the offsets. Also I trim off any transparent pixels before packing them - useful when rendering from Max as that generally produces a lot of wasted space around the edges of the images.

Yeah :)

What I did was to get the 32bit .TGA's from max, and process them with my own tool. I assume the centre of the sprite is the centre of the .TGA image (very useful if you have rotating iso-view sprites), I then get rid of wasted space around the sprite, and can also calculate x and y hotspots (offsets from centre).

If I use this for PC stuff, I'll prob want to encode the alpha channel too, so should look quite yummy.

I'm not entirely sure what I'm doing with the techy side of things on the PC as yet, so my grand plans may well be flawed!

OpenGL manages VRAM for you. The first you'll know that you've not got enough of it is when the game slows to a crawl. Older DirectX's don't manage VRAM for you, and generally just crash in my experience when people don't take this into account :) I believe the latest DirectX's have some sort of automatic management.

Cas :)

I may end up just using one of these API's, PTK looks nice, and you can switch from OpenGL to DX easily.

What's your opinion of these API's, any drawbacks?

Thanks.

[Mike Wiering]

You might be interested in my program Tile Studio (http://tilestudio.sourceforge.net/). You can import your tile sets into it and create maps and the output is programmable. Tile Studio generates new tile sets based on the tiles / tile combinations you actually use in your maps. For sprites I usually make separate tile sets for each group of sprites that are the same size.

The way you plan to draw the layers seems fine. What I do in my newest engine is give each layer and object a Z cooridnate and sort them before drawing a frame.

[illume]

Pygame with PGU can do tile maps. PGU has a level editor and a tile editor too.

pygame: http://www.pygame.org/
pgu: http://www.imitationpickles.org/pgu/wiki/screenshots

[Huge]

I think we all agree that your approach is pretty sound.
Just pick a framework and start coding !

I've used the Popcap Framework for doing pretty much what you want, and no problems. If you pack all your tiles/sprites into a single image, then your concerns about powers-of-two is not really a problem. Just fix your width of packing at, say, 512, and let the height take care of itsself.
Again, popcap does this for you - easiest to just "load from png".
Popcap also has an option to turn off 3D acceleration - I tried this and my frame rate only dropped from 100 to 80 so no problems there (800x600 res).
Bottom line is that if the engine/framework you use is good enough, you should not have to care particularly about the implementation. Gone are the days when games have to be mega-efficient. Do some coding now, and optimise only if you have a performance problem.

[Jamie W]

I think we all agree that your approach is pretty sound.
Just pick a framework and start coding !

I've used the Popcap Framework for doing pretty much what you want, and no problems. If you pack all your tiles/sprites into a single image, then your concerns about powers-of-two is not really a problem. Just fix your width of packing at, say, 512, and let the height take care of itsself.
Again, popcap does this for you - easiest to just "load from png".
Popcap also has an option to turn off 3D acceleration - I tried this and my frame rate only dropped from 100 to 80 so no problems there (800x600 res).
Bottom line is that if the engine/framework you use is good enough, you should not have to care particularly about the implementation. Gone are the days when games have to be mega-efficient. Do some coding now, and optimise only if you have a performance problem.

So say I'm using 32*32 tiles, if I have a load of bitmaps that are 512*32 pixels wide, each containing on strip of (16) tiles, that I can then upload in to video RAM, that'd be quite an efficient way of doing things?

If I have 8 bit (256 colour) tiles that I then load in to video RAM, will they be stored as 32 bit (ARGB) in video RAM? So in effect, there's no saving in video RAM.

I think my mindset is tending towards GBA development, where resources are mega-scarce (compared to PC).

[jankoM]

I think you worry too much about this. I newer thougth about this things and it all worked - (I probably worry to little though).

[Huge]

OpenGL swaps yout textures in and out of vram, so you say "Bind image 1" and it will get transferred into vram if it's not aready there. For DX, i'm not exactly sure but any framework worth its name should take care of this for you. 512x32 strips seems like a very reasonable way to go. Popcap has a "Palattize" function that will convert 32bit RGBA to 8bit RGBA (as stored in vram), thus giving you the efficiency you desire. But for 2D stuff you are being way to pessimistic about saving every byte. Do it the easy way first, then thing about how to make a 4k demo out of it !

[DanDanger]

Hello,

Load a bitmap to a texture in video ram. This will contain a lot of tiles (eg: a 512 * 512 bitmap containing 256, 32 * 32 pixel tiles).

Then in the draw phase of my game loop, something like:

DrawMapLayer1();
DrawSomeSprites();
DrawMapLayer2();
DrawSomeMoreSprites();
DrawMapLayer3();
DrawPanelOverlaysEtc();

Thanks. :)


Hellos!

That loop pretty much describes how I render me game "Keith Goes Painting" www.wolfysgames.com. I had 4 layers: 2 opaque layers and 2 shadow layers. I also used 32x32 tiles on 1 large 1024x1024 texture map. All my object "sprites" were on another 1024x1024 texture.

I used the wonderful LWJGL for creating that game, using the opengl functionality to render everything.

If you're interested I can send you the code if you want to have a butchers.

[Jamie W]

Thanks Guys.

I feel pretty much OK, and happy, about how to do tiles / maps.

I'm thinking more about how to handle sprites now.

My sprite system (as well as my map / tiles) system, will sandwich between whatever API I use (or DirectX / OpenGL), and my game code. Then if I decide to swith API's or use DirectX directly, the only code I will need to change will be in my sprite_system and map_tile_system modules etc. In effect I'll be divorcing my game code from the API, with another layer of abstraction between game and API.

jankoM:

I feel it's important for me to worry about all this stuff now, rather than later down the line when I've started implimenting stuff (and maybe discovered I've gone a long way down the wrong track!). I just want to get educated on the best way to do do things with the PC. :) (of course, an appropriate amount of worrying is a good thing, not too much, not too little).

Huge:

I'm just considering the impilcations of VRAM usage, so that whatever system I use makes the best use of VRAM. I prob am worrying too much about it, but I've always liked to know what's going on 'under the hood' (of course, while my head is under the hood, it's not somewhere else, like on making the game itself!).

DanDanger:

I love the 'screenshots' of your game, I can almost see the reflection of you holding a camera!? Thanks for offering to show me your source, I will be coding this in C++ though, I'm pretty confident how to do the coding part, I'm just wondering about best way to handle my sprites.

For my sprite system, I'm thinking of doing something along the following lines:

1) Using a sprite grabber tool, I will pack a load of individual bitmaps in to a single data file (with a table).

2) I can then load this data file in to memory, and then dynamically load parts of it (i.e. as and when I need to display a sprite) from PC memory in to VRAM.

3) I will have a class to handle all management of this system.


It will be really easy to access my sprites from game code, once I've got this system running. Things I'm cautious about are:

1) It will mean each sprite I'm displaying at any moment, will need it's own texture in VRAM. So potential waste of space (say my sprite is 33*34 pixels, it will need a 64*64 texture).

2) Processing time it will take to load bitmaps (from PC memory, not file) in to VRAM for an individual sprite.


Does such a system sound feasable? What problems do you think it would throw up? How about issues 1) and 2) above?

[Sharpfish]

OpenGL swaps yout textures in and out of vram, so you say "Bind image 1" and it will get transferred into vram if it's not aready there. For DX, i'm not exactly sure


If the dx engine uses a resource pool type of "Managed" then it will swap it about for you as best it can. (Dx8+)

To Jamie> We sometimes get this lower level of coding discussion on here but I think you will get better feedback and a lot more info at a more game coding dedicated site like gamedev.net. Personally I feel you are worrying about low level details too much at this stage when there is plenty out there to ease this for you. Pick a framework to use and learn that framework ,generally the sprite handling and what have you will be wrapped and taken care of. Have you tried the blitzmax demo? Your code will compile on mac,pc and linux versions and it does Ogl and DX7. There are also many useful tools for it and more each day which give you more than enough to get on with and make games. Don't be put of by it's connections to basic either. It is somewhat object oriented and has some of the best features found in C++ but with a lot of hassle taken out. I still use straight C++ with my own stuff for 3D but for 2D stuff I would use BlitzMax for downloadable games and Flash for Webgames.

[electronicStar]

It will be really easy to access my sprites from game code, once I've got this system running. Things I'm cautious about are:

1) It will mean each sprite I'm displaying at any moment, will need it's own texture in VRAM. So potential waste of space (say my sprite is 33*34 pixels, it will need a 64*64 texture).


1)in this case you should use a 32X32 sprite and scale it if your engine manages that

[Jamie W]

To Jamie> We sometimes get this lower level of coding discussion on here but I think you will get better feedback and a lot more info at a more game coding dedicated site like gamedev.net. Personally I feel you are worrying about low level details too much at this stage when there is plenty out there to ease this for you. Pick a framework to use and learn that framework ,generally the sprite handling and what have you will be wrapped and taken care of. Have you tried the blitzmax demo? Your code will compile on mac,pc and linux versions and it does Ogl and DX7. There are also many useful tools for it and more each day which give you more than enough to get on with and make games. Don't be put of by it's connections to basic either. It is somewhat object oriented and has some of the best features found in C++ but with a lot of hassle taken out. I still use straight C++ with my own stuff for 3D but for 2D stuff I would use BlitzMax for downloadable games and Flash for Webgames.

Yeah, you're probably right with a lot of what you're saying there Paul.

:)

Maybe it's better (and simpler) to just have simular sprites grouped on to a single bitmap texture, and then just index the animation frame by multiplying the source x / y position.

Someone did mention a tool that would take several sprites with names like frame000.tga, frame001.tga, frame002.tga etc, and create a single bitmap from those images. I'll defo have a look at that.

I'll carry on checking out all the API's ...

I did think Blitz Max was only for use with Basic? Does it work with C++ too?

[Sharpfish]

I did think Blitz Max was only for use with Basic? Does it work with C++ too?

BlitzMax is self contained. It is a hybrid language built with advanced BASIC like syntax (oxymoron?) and many of the features of more modern/flexible languages. It is very similar to C++ etc but has certain constraints and keyword differences. Took me a couple of days to get used to it.

Where it is different is that it totally abstracts all the the APIs so it is not merely a language. You write the code in "blitzmax" syntax and compile in the provided IDE (or a better one like blide). This makes the .exe and you are good to go. YOu can hook up C++ stuff to it but you don't have to.

It has a full library of graphics calls and even network etc. I suggest you go downlod the free demo and spend an hour with and see what it can do. It is literally a blank canvas of robust code waiting to build games with.

Oh and there are plenty of sprite packers etc around for blitz.

Hope this helps :)

edit . to put it another way it's like a really advanced version of "AMOS" (amiga) and has dropped the "basic" tag for a reason. ;)

[TJM]

Moved post.