2D game rendering question

#1

So I’m trying to get back into programming (took a 4-5 month break), and starting off with a game. I don’t think I’ll finish it, it’s a lot of work, but I still want to work on it.

So I have a question about the most efficient way of rendering a 2d tile based game. If you have any insight I’d love to hear your opinions.

For example, for drawing the map, which would be better?

  1. Have the map be one image. Either saved as an image or created as an image when the map file is loaded. To render map, just show a portion of that image.
  2. Create an image for the current viewport of the map every time the map is moved or updated, and draw that
  3. Draw the map tile by tile

Drawing it tile by tile makes it easier to draw entities, but Im not sure if it’s as efficient.

#2

The question is a bit arbitrary, because rendering efficiency is tied strongly to whichever drawing library you’re using. Beyond that, is is also a pretty big memory versus processing dilemma. If you cache the current viewport or the entire map, you’re going to have to store those (possibly massive) images in memory, whereas a tile-based approach is storing a few small images in memory and just instancing them when drawing them individually. As far as memory is concerned, the tile-based approach is significantly superior.

Now, in terms of processing time, it matters significantly on how your drawing library handles clipping in this case. Drawing the viewport image or just a translation of the entire map composite may be close to the same speeds, depending on how it handles image referencing, blitting, and clipping of the final image. If it uses hardware acceleration, it helps to know how it sends the final image being drawn to the graphics card.

If you want a VERY efficient system, you could even implement some sort of “dirty-region” setup that many older games used, as well as most modern GUI environments. This is a nice learning exercise, but I’m not going to go into it too much.

Finally, you need to think about your target hardware (whether or not you’re using software drawing, hardware will refer to the amount of main memory available, speed and availability of the CPU, graphics memory available, GPU capabilities, etc.) This is an extremely easy thing for even a CPU to rasterize, which means all three options are probably thousands of times faster than you would ever need to worry about. As a result, I would personally recommend taking option #3 because it’s the easiest to implement. It may be potentially the slowest (but even that is fairly easy to mitigate if you use a hardware-accelerated rendering library like OpenGL or Direct3D) but you really don’t need to be worried about that, anyway.

#3

Thanks, I guess my main question was whether or not a certain approach would be considered bad practice or extremely inefficient over the others, and you answered that. Currently I’m just using Graphics2D, but if it does eventually get to the point where I may want to push the project out (which is extremely unlikely) I’d probably look into OpenGL

EDIT - What can you tell me about sprites? Specifically referencing them from a sheet. Let’s say I had a spritesheet for X different character animations, and I wanted to pass those animations to my entity object. Is it acceptable/good practice to hardcode it?
Ex:

SpriteLoader { passAnimations() { character.setWalkN(createAnimation(sheet.getSprites(0, 1, 2, 3, 4), delay, etcetc)); character.setWalkS(createAnimation(sheet.getSprites(5, 6, 7, 8, 9), delay, etcetc)); ... That’s probably too specific, so let’s just remove the entity object and have it in general. Let’s say I was just creating animation instances from my spritesheet. Would you have some other way to store the information about each animation, or is just hardcoding it fine?

#4

It’s up to you, really. A more data-driven approach would be to probably create an animation format of some sort, with or without an tool to edit/preview them. That way the hard numbers are somewhere where they make sense, versus just being directly in code like they are now. If you are fine with hardcoding stuff, then I would recommend you at least make an effort to separate core code from implementation code. This can be done in a variety of manners, ranging from using a scripting language to implement the engine to creating a separate project holding actual game code and the other project holding the engine code. Even creating a separate package in Java is perfectly suitable, it’s all up to you. I would definitely recommend you emphasize separating the abstraction layers, though (otherwise it begins to be difficult to maintain and things start getting very ugly looking).