Log in

View Full Version : 2D vs 3D (In terms of implementation)


pangyan
07-01-2003, 06:53 PM
I am about to start a new project and I am torn between using 2D And 3D for various reasons. I know how to make a 2D game, 3D is totally new. Can I make a 3D game look 2D just by having rectangular polygons and texture mapping them to show a flat display? Is that how some 2D looking games actually use a 3D engine? (For example Retro64 games). There is a reason why I need a few 3D only features (Smooth scaling and rotation, alpha blending etc.)

Chandler
07-01-2003, 07:29 PM
Yup! You just fix the z-coordinate. Look at Crimsonland here (http://crimsonland.reflexive.com/crimsonland/). This game is basically all quads with textures on them :)

Carrot
07-01-2003, 11:56 PM
There's usually also the difference that the 2D version has orthographic projection instead of perspective projection.

This just means that the depth is ignored and bending at the edges of the view volume are avoided.

If you really want to see the projection matrices check both out here (http://www.sgi.com/software/opengl/advanced96/node61.html)

LordKronos
07-02-2003, 02:12 AM
Another issue to consider with trying to replicate 2D in 3D is that
you have texture size limitations. Every texture has to be power-of-2 in size. This means you can't have a part of your HUD be 102x195. You'll have to enlarge that to 128x256 and just use a subsection of that texture. Not much of a problem, except it uses more memory. And then I think some card drivers will resample that texture to be 256x256 (some drivers don't like non-square textures). Then you can end up with sampling errors, where things don't look pixel perfect. So your best off trying to pack multiple images into a single texture to make things work without wasting memory.

Then on top of this, if you want to support older systems, you run into more problems. If you want to display your 800x600 background, then you have to enlarge it to 1024x1024...except some cards don't support more than 256x256, so you have to write code to detect that and split your background into chunks of 256x256, and draw your background as a 4x3 grid of quads (or just plan to draw it that way on all systems). On top of that, you also have memory limitations. A 4MB card running 640x480x16bit with double buffering leave you less than 3MB for textures (less than 2.5 if you want to support depth buffering). An 8MB card running 800x600x16 bit leaves you just over 6MB for textures (or 5MB with depth buffering).

So memory limitations are just something you have to keep in mind if you want to support older hardware. Whereas standard DirectDraw can be done in system memory and you can speedily deal with lots of bitmaps. It's easier too, because with DirectDraw you can have a 1000x1000 bitmap and then only access small 50x50 pixel sections of it quite quickly. However, in 3D, anytime you need to access that texture, the entire 1024x1024 block would need to be uploaded into video memory if it's not already there (which is a performance killer on most systems).

To work around these problems while still being compatible with older hardware, you can resort to doing tricky things like breaking your GUI elements up into sections, and then compressing them into stretchable quads. For instance, look at the border around your browser window. You have a section of pixels that is like 10x300 pixels, and all 300 rows (of 10 pixels each) are identical. So you can just store a 10x1 section in your texture, and stretch that over a 10x300 quad. I've done a lot of this type of stuff trying to optimize Miko & Molly to run best on old systems.

On the other hand, you then have the advantages of being able to do stuff you can't do fast in DirectDraw (like rotation), or even at all (depth buffering). So it's a trade-off, and you just need to be aware of what problems you might face.

pawelt
07-02-2003, 02:13 AM
It's quite easy to simulate 2D in 3D (so easy that MS decided to remove DirectDraw from DX 8). The "real 3D" is a totally different world however. There are no sprites (maybe except for GUI), but everything is just... 3D :). There are also tons of mathematics stuff, but this is not very hard (and not so much on the basic level), it's just something new if your're coming from 2D games.

3D features that you mentioned are easy to achieve in 3D. You could also consider using ID3DXSprite interface (part of DX since ver. 8). It provides simple routines for scaling, rotating, translating, it's also quie efficient. Go to msdn.microsoft.com/directx for more details.

svero
07-02-2003, 02:33 AM
It's quite common to use 3D to do a 2D engine. We do it for one of our new games and in fact we can now run any game either using direct3d as the low level image blitter or DirectDraw. The main advantage for us using Direct3D is that we can do hardware alpha blitting which lets us display flashier effects and eye candy. The downside is that using 3D tends to up the system specs.

There's a good article on gamasutra about programming a 2D engine using Direct3D. It's called..

"2D Programming in a 3D World"

Just use the search feature. You need to be a gamasutra member to read it though.

There are advantages to using pure 3d for a 2d game though, like crimsonland or spacretripper or bugatron. Even though bugatron is essentially a 2d shooter you have some nice effects where the ships fly into or out of the playfield. Same with space tripper. Even though the game is 2d there are hills and so on that add a little dimension and flash to the game.