I was told by a fellow classmate (the few that aren't terrified to talk to a "girl programmer", that is) that the few tile-based games I've been working on could be optimized if I were to rethink the entire tilemap idea.

He said that I'm doing a lot of my own routines (from scratch) that redraw several layers of tiles, and that I must have not done something right because there's a lot of flickering, etc. when the map scrolls to follow the player.

He suggested that I use some 3D implementation (like OpenGL) to do basically the same layout (2D tiles, etc.) but have OpenGL be in charge of all the redraws, scrolling, etc. Since others have already spent countless hours optimizing the redraw routines for 3D to be "incredibly fast", that would be the best thing for me to do. Then, simply tell the camera to look "straight down" onto the map to get the 2D feel.

Has anyone else here done this, or is this just a lot of hot air from someone who doesn't know what he's talking about?

Flickering indeed means something's wrong. What kind of buffering do you use?

Bit of both. The reason it's going to be a lot faster in OpenGL isn't because someone's "spent countless hours optimizing the redraw routines for 3D" - it's because you're using hardware acceleration.
(Plus, you get stuff like texturing, coloring, lighting, and general blending more or less for free)

And... the concept of "having OpenGL be in charge of scrolling" is just... wrong. Yes, I suppose you could brute-force draw the entire map and just translate it, but why oh God why?

Probably what you need to smooth your scroll is a high resolution timer.
There are a lot of Side Scroller games featuring smoothly scrolls without 3D hardware acceleration.

You mean the right tool?

Okay, so due to the hardware acceleration and all the other fancy stuff built into OpenGL, it would be a lot more computer-friendly to take the simple side-scrolling (or top-down) tile-based game and reduce flickering, movement jumpiness, etc.?

There shouldn't be any flickering, no matter what method is used.

Well, OpenLayer seems to be quite nice for doing 2D stuff. You can also get a lot more eyecandy with it compared to using CPU-only

I dunno, one of those nice (and yet annoying, in some cases) things with openGL is that, by design, any and all features can be implemented in hardware or software transparently (AFAIK). If only some of the API can be implemented on the hardware, so be it; the software end can take care of the gap. Granted, this isn't great for performance, but just because you don't have a 3d graphics card doesn't mean you will get zero hardware acceleration for ANY of the opengl calls. (You likely won't get any acceleration, but if you do have an older 2d-acceleration-only card, in theory, it is possible for some of the routines used by OpenGL are mapped to a hardware implementation).

Besides, the software implementations of the OpenGL spec are not THAT slow (they are no where near hardware speed, but if you are careful in what features you use, you should get playable performance from it with a decent CPU. Of course, if you have a decent CPU, you probably have 3d acceleration anyway, so it is a moot point.)

In theory. Have you ever tried using the software implementation that comes with windows (I know there are libraries out there, but unless you distribute them with you game they don't count)? In the games software renderer i think I hit like 20-30fps.

With the OpenGL renderer I hit 1 or 2 every few seconds. I'm not actually joking either.

This is Counterstrike on a 400mhz celeron. Before you comment keep in mind:
a)Half life before the patches ran playable. After patches it got considerably slower. But I could still play with the software renderer.
b)This particular Celeron generation was actually pretty good as far as Celerons go. It was basically the Pentium 2 chip with a little less cache, but it STILL had some.
c)This is the type of computer that wont have a 3d accelerator. The generation of integrated Intel afterwards(possibly 2 afterwards, I know my Dell has it) included bare bones 3d acceleration. But once again, any and all effects that needed to run in software will drop the game to 1 to 2 fps.(I could run Max Payne 2 up until the part where they had stairs. It took me a good 5 minutes to get to the top :S)

Oh, it's not like that. The Atari 2600/etc all have specific graphics hardware, and if you went something like Atari 2600 -> C64 -> Amiga -> PlayStation -> now then you'd never have had a platform that just used a CPU to write to a dumb framebuffer. It just so happens that the algorithms used by todays graphics hardware allow for 3d visuals as well as 2d visuals.
</quote>
What I had in mind was that gfx-card manufacturers were spending so much time working on 3D accelleration that they were neglecting to improve 2D accelleration (for sprite-based games), and in order to keep costs down, the quality of 2D accelleration even got worse as time went on (this was probably the case in 1999, not sure about today). Around 1999, I even came accross a bitmap font-renderer that actually worked by drawing two textured 3D-triangles for each glyph it was meant to render. While there's nothing inherently wrong with coming up with an outside-the-box solution to obtain the fastest-possible performance, the fact that you need to draw two 3D-triangles to render a font-glyph in the first place makes part of me want to scream. Perhaps it's just me being upset that an attempt was made to kill off the 2D game.

AE.

Would a highly optimised pipeline be able to take special cases into account in order to save GPU-cycles?

Even if we turn off things like lighting, multi-texturing, mip-mapping, bi/tri-linear filtering, perspective-correct texture-mapping, Z and S buffers, we'd end up with the minimum requirements for drawing a diffuse texture-mapped polygon. Even that is a bit overkill if we want to do a simple 2D sprite-game. A point-sampling function for texture-mapping a 3D polygon also has to take the depth into account. Also, for each scanline, the direction of texture-sampling is different (whereas for a rotated 2D sprite, it's the same). And if we don't want to use sprite-rotation, the point-sampling functions only need to work in one dimension, and then if we're not even zooming, the point-sampling function is just a one-to-one mapping between texels and pixels.

Unless the hardware takes into account special cases for things such as the polygon-plane being perpendicular to the camera/screen, or the texture-space as defined by the texture-coordinates mapping to screen-space coordinates by purely using a displacement (that is, one texel maps to one pixel and no rotation is required), the hardware will be doing a lot of extra work unnescescarily. Even if the hardware is optimised enough to be able to do all the lighting, transformation and perspective-correction etc. within the time it takes to fetch the texture from texture-ram, it will mean that using the entire pipeline will use up more energy than is needed and therefore produce more heat.

But by all means, if this is the fastest way of drawing a 2D sprite, then go for it. Game-players want the fastest possible graphics, and don't care about heat-generation. I just think it's a pity that the hardware-designers didn't take 2D sprites as a special case into account (if they haven't).

AE.

I would have thought so too, but I've seen at least one implementation of a 2D font-renderer that turns the texture into two triangles and renders them as 3D polygons. Maybe this was just a one-off, but who knows...

Actually, texturing a 3D polygon is a much more involved process than drawing a 2D bitmap. Even a single-textured (diffuse-mapped) polygon that is textured without perspective correction can take more effort to render than a 2D scaled and rotated object. Once perspective-correction is taken into account, the processing-time becomes even greater.

I agree. I was just commenting from the perspective of a low-level programmer. Anyone who uses a rendering engine does not need to worry about what goes on inside the black box and just have faith that it does it's thing in the best possible way. However, I've been around a few engines in my time, and my faith has become a bit wobbly.

AE.

With using opengl you get a lot of effects and capabilities for free. One that hasn't been mentioned is resolution independance and camera capabilities.

I'd say go ahead and learn opengl because I feel its worth knowing.

Sometimes its also a good idea to take a look at how other people implement things. Opengl is pretty well thought out and designed. There are probably ideas you can take from it to improve your own design.