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?

You can do it that way if you want. The benefit of doing it in 3D is you get lighting, blending effects etc which make it look prettier in general. Plus all textures are filtered so they look nicely stretched and it will run nice on all computers with a 3D graphics cards since it won't be that intensive.

The down side is it wont run on a computer lacking a 3D graphics card... so realistically there aren't many .

Now keep in mind there is no reason Allegro shouldn't be able to handle a few layers. Even on a 400mhz Celeron I was able to get the engine to pump out a ridiculous frame rate (several hundred fps) with translucency, several layers etc etc. This was in 8 bit colour. At 16 bits and 640x480 then some more careful optimization would be needed on the Celeron, but on other computers there was no issue.

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?

I have done a tile map like that a few times before with DirectX. The D3D sprites made it very simple and the speed difference was definitely noticeable. Like gnolam said you definitely don't want to draw all the tiles then just scroll them, I was only drawing the tiles that were in the view of the camera.

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.

Its mostly hot air. Theres a small hint of a good idea in there (using OpenGL) but his reasoning for it makes absolutely no sense.

Just ignore the guy.

Besides, OpenGL isn't always the answer anyways. Use the right tool for the right job^TM

You mean the right tool?

For example, if you're doing graphics work then use the graphics processing unit. Your laptop users and users of OSs with modern compositing engines (i.e. Vista, OS X, etc) will thank you forever.

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.?

yes.
If you would do it on CPU using software routines you'd be basically emulating what GPU does. That means you'll waste a lot more power than needed.

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

Every time I hear about someone using 3D acceleration for a strictly 2D task, part of my childhood dies.

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

but if your main coding computer lacks a 3d graphix card then your in trouble;D;D

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.)

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.

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)

You mean you were programming the gameplay

Besides I don't see anything wrong on having the camera fixed at 90° to a surface, having orthographic projection and making a 2d game. It's what you use OpenGL for too. I know a lot of games done this way.

Unless you don't have gfx accelerator, in that case it sucks.

That's why I had to buy new laptop, because my old one had 8MB ATI card which didn't supported OpenGL and I think HW acceleration at all.

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.

3D acceleration still is mostly really 2D. The graphics card doesn't have a 3-dimensional frame buffer, but rather a 2D frame buffer that holds 5 or 6 dimensional values (R, G, B, A, Z, Stencil). This is not the same. For the GPU, the triangles (after all transforms) are 2D, with an additional vertex parameter that controls texture mapping.
And if using the highly optimized rendering pipeline that is already in place to render 2D graphics; what's the problem? As long as it produces the expected results and works fast and reliably, by all means use it.

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 think they probably HAVE taken 2D sprites into account. For example, most 3D games have some sort of on-screen menu, or names of other players walking around, or something else that is drawn onto the screen that should not be rotated by any 3D calculations.

Since 3D objects always have textures overlaying their polygons, I'm sure they have all SORTS of 2D functions (software and hardware both) that have been optimized and loops unrolled.

I agree, though, that for a top-down, or even side-scroller, you probably won't be doing very much sprite rotation, zooming, change of depth, or all those other things you mentioned. And since they're not being used, there's no reason for the GPU to have to heat up calculating anything unnecessary.

I'm just thinking that someone else who has worked on OpenGL (or DirectX or whatever) and has already done all the math. I just come along and use what they've already optimized. Like Allegro: I wrote my game for Windows, with 2GB RAM, 256MB graphics card, etc. However, I used the Allegro libraries. Now, anyone who has Allegro compiled for their machine can play the game. I didn't have to do any of the math or #ifdef __MACINTOSH__'s.

So if I use a 3D library to render the 2D game, I take advantage of all the hardware acceleration and code optimizations that I have never had to think about: I simply tell it, "You! Shift all the tiles over by 8 pixels!" and it does it however it feels happiest.

TT

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.

You know I think for a simple side-scroller OpenGL is a bad idea. You're hurting your user-base.

It wont work on half the computers you wish it did.

This is the sort of thing Allegro was made for. Remember to Use the right tool for the right job^TM

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.

Who cares? User-base is more important.

Besides lets be honest, shes probably not a professional game developer (yet) and hence she probably wont need or use all that extra fancy stuff OpenGL lets you do.

And using OpenGL for a smaller project hurts your user-base. For a smaller project like this one user-base is probably more important.

Weird. I never really thought about "my user-base". Sometimes i give them to friends, or just myself. I run mac, linux, some of my friends use windows. Opengl is really well supported and i'd be hard pressed to find a friend's computer that couldn't handle the level of graphics that my artistic skills currently consume

Ha! Thats funny... Really well supported by whose computers?

I guess his every friends computer supports it.

Even my ancient P1 from '97 did. For some reason I don't think there are a lot of PCs out there that can'd do some basic OpenGL, at least I don't have any friends or relatives whose computer doesn't support it. Perhaps I'm kind of special or something

Most computers support OpenGL. On the other side, some of the OpenGL implemenations are buggy, so programs using OpenGL may not work (display) correctly: My work-in-progress game does not work correctly on my laptop, but everywhere else (where I can test, and some other people can test), so even if OpenGL is supported, you can't always assume that your game will work. The more advanced features and effects of OpenGL you use, the more of potential users may have problems...

Yep, I had the same problem with my old laptop - the card didn't support more than untextured polygons. Though I think that most, even all, of the modern cards support OpenGL. But as mentioned. Some implemenatations are buggy. Though I'd go the accelerated way, if I'd want to use heavy blending and lot's of flashy particles.

D3D is far more supported then OpenGL, which is exactly why I made the Thing Library support D3D.

If you want a bit more solid proof, just look at the early Intel chipsets. Those things are rampant...

On the contrary, both D3D and OpenGL are supported by Intel, Nvidia and ATI. Intel has a 37.4% share of the market, Nvidia has 28.5% of the market, and ATI has 23% of the market (source). So in total, OpenGL is supported by 88.9% of the PC market. So it isn't far more, no matter what the manufacturers of the other 10.1% of cards are doing. As it is, I doubt if many of them support D3D.

Ya now try actually running your app on those Intel driver sets and then tell me how well OpenGL is supported...

Amongst other things, I found that a circa 1999 Intel chipset was more than able to run Half-Life. I would therefore be surprised if it failed to handle "a 2D tile-based map".

Well prepare to be surprised

Of course you have no evidence, but I don't suppose that bothers you. Sites like extremetech seem to get 16 fps from an Intel GMA 950 for Doom 3. To me, that sounds quite sufficient for (a) any game at least 6 months older than Doom 3; (b) any 2d tilemap anything.

EDIT: ahem I was missing the point. At 1024x768, the tests also show that a GeForce 6200 TC runs Flight Sim 2004, a DirectX game, at almost twice the framerate of an Intel GMA 950. In Doom 3, an OpenGL game, it gets about twice as many frames per second.

Screw evidence, not working is evidence enough for me. The earlier* intel chipsets' "support" of OpenGL is buggy at best.
_{* and by earlier I mean very recently.}

I think that concludes this conversation.

Yeah I agree, we're not going to get anywhere. We're just talking on different levels.

Why limit your game to only one API, if you can offer support for both?

Because OpenGL is really portable and generally the code in DX is 6 times longer than in OpenGL - even John Carmarck said this.

1) I don't know DirectX
2) I don't know OpenGL
3) I don't know D3D

Since all 3 of these (or is D3D a 'DirectX' something-or-other?) are different, I would have to assume that I cannot simply say, "render_stuff()" and all of them would understand it the same way. I would have to write code specific for one, then the other, and possibly the third (and fourth, and fifth) different kinds of 3D implementations out there, and all I want to do is write a single game. It would take more time to make all the different APIs as it would to write the game itself.

If I limit myself to DirectX, no one using anything but Windows can use the game. That limits my game more than if I simply used OpenGL; some people couldn't handle it, but a lot more people using Linux/Mac/BSD/non-Windows could, and isn't that more important? Getting your game out to as many people as possible?

Now, if I wanted to do something like Planeshift and had a million people all working on my project, then sure, I don't see a reason NOT to support as many APIs as justifiable.

In OpenGL you typically do something like this:

glBegin(GL_POLYGON);
  glVertex3f(x1, y1, z1);
  glVertex3f(x2, y2, z2);
  glVertex3f(x3, y3, z3);
  glVertex3f(x4, y4, z4);
glEnd();

Usually preceeded by OGL initialization and opening the window, which is platform dependent - done some way on WinAPI - where actual drawing code is way shorter than that one managing the window. Some other way under xorg etc. Either way, you can even use AllegroGL (which merges Allegro and OGL) and then it's plain simple, you just use one line to open up window.

Anyway if you want really abstract API and high level programming, just grab OpenLayer. It's hardware accelerated addon for Allegro. Its API is really easy.

C++ polymorphism and wrapper designs can help, however it all depends on how you have designed your project.

Use Allegro.

Use AllegroGL and OpenLayer.

Dustin's OGL/D3D wrapper could be the solution to that.

Yes! as an allegro user, when I see D3D code I vomit, however I can't deny the importance of a D3D support.

Paul: for me it was enough to see OpenGL initialization under WinAPI. The things you have to do in order to get window opened resulted in acute headache. Then I showed my "minimalistic" code in AllegroGL which has done the same in just one line of code

You're saying Directx is more supported than opengl!? Tell that to my linux boxen.. or my mac.

D3D isn't like OpenGL. OpenGL has had a version of the same API (i.e. it's evolved, but you can still recognise is) for at least 15 years. Conversely Microsoft make no bones about the fact that they frequently completely redesign significant parts of DirectX. Though I have no direct experience, I believe the D3D interface has become quite a bit nicer with age.

I'm typing this on a Mac but nonetheless I don't think Linux & Mac OpenGL support really amounts to much on a total supported scale.

From memory, Macs were about 5% of sales last December so if we genersously give Mac + Linux say 7% of the market, accept 88.9% as the figure for OpenGL on PC and give Direct3D 95% then total computer Direct3D support is 0.95 * 0.93 = 0.8835, i.e. about 88.35% of all computers. Windows/OpenGL makes 0.889 * 0.93 = 0.8277, i.e. 82.77%.

All Macs since about 1999 have hardware OpenGL, so we'll just call that all Macs. That gives 82.77% + 5% = 87.77% market support for OpenGL. Give hardware OpenGL to 75% of the 2% of the market I arbitrarily gave to Linux and that's another 0.75 * 0.02 = 0.015 = 1.5% of all the computers. Giving OpenGL 87.77 + 1.5 = 89.27% of the market.

It'd be more impressive if I hadn't made the Linux & Direct3d numbers up! But the point is, DirectX is fractionally more supported on Windows. If you account for the entire market, OpenGL may be fractionally more suported. But the differences are tiny.

My OpenGL advocacy arguments would be simply:

• AllegroGL, SDL, OpenLayer all give you a tried and tested OpenGL interface that is popular amongst hobbyist programmers

• OpenGL is not only easy but, on account of its historic API stability, very well documented by free resources

• games are less common on Mac/Linux, so OpenGL may equal more recognition for you due to proportionally fewer competitors

One point to back this up is threading safety (OpenGL provides none while D3D appears to support it fully).

Oh even CAD aplications use OGL.

Using 3D acceleration to render a 2D scene is a good idea. Since you don't know D3D or OpenGL and it is a good idea to support both, I would suggest getting your hands on a 3D graphics engine that supports both. For ease of use, you can't go past Irrlicht. It supports Direct3D 8 and 9, and OpenGL.

EDIT: An advantage of using Irrlicht is that it is a scene manager. You can simply use a flat 3D model to represent each map layer and let Irrlicht do the rest. Of course, you'll need to actually move the models at different speeds to get the parallax scrolling effect.