2D vs. 3D
I''ve read a lot of discussion on 2D vs. 3D on many of the boards here. My question is what are the advantages of one or the other if the goal is to write a good RTS game like Command & Conquer or War Craft?
Is 2D less work...faster game play or vice versa?
Thanks in advance.
May 11, 2002 11:31 AM
Depends on what exactly you want to do. 2D is certainly easier than 3D but then you are somewhat limited when it comes to effects. I can tell you this from my own experience though; Don''t do a 2D game soley using 3D because it is too slow. It has to do with the nature of 2D more than anything else actually. 3D functions is designed for mainly 3D use although you certainly can slap a texture on a polygon and hope the fillrate is good enough. To be honest though the best thing is a combination of both. The background should be drawn using 2D functions because they are much faster. I know some believe that nowadays the 2D functions use 3D anyway but don''t believe them, this is not true. A simple test can prove otherwise. Simply fill the screen using polygons with textures compared with a normal 2D tile function and you will see how much faster the 2D functions are. But the 2D functions have another drawback and that is alpha channel, they don''t have it. Which means that either you do software based alpha which I hope you don''t Secondly you use 3D functions which do have alpha for that purpose (which I hope you do use).
A second drawback is the lack of a colorkey. Older versions of DirectDraw had this but with the merger into Direct graphics this was dropped. This is not a bad move because you still have access to the videomemory and can write a faster function yourself using assembler or just c/c++ if this is preferred.
So my best tip to you is use both but only doing the things they are best at. Don''t just go with one and loose the benefits of the other. Now, I don''t know if you are experienced programmer or not but if you want to get started quickly there are some helper libraries out there.
http://cdx.sourceforge.net is quite old but still does a fair good job.
http://www.libsdl.org which is constantly updated and has a lot of good features although it is mainly opengl oriented. The DirectX support is a bit outdated. Lot''s of support and apps to look at though. I recommend this over CDX actually.
http://hem.passagen.se/mithril which is a free for non commercial use game engine that is mainly directed towards DirectX although it has OpenGL support. Much like SDL but faster and easier to use. Currently the webpage is undergoing some work but you can still download the latest version and some tutorials to look at. This is using a combination of both as I told you about but the manual is not finished yet so using all the functions can be not so obvious at the moment. Most functions are self explanatory though.
Hop this is of some help to you.
A second drawback is the lack of a colorkey. Older versions of DirectDraw had this but with the merger into Direct graphics this was dropped. This is not a bad move because you still have access to the videomemory and can write a faster function yourself using assembler or just c/c++ if this is preferred.
So my best tip to you is use both but only doing the things they are best at. Don''t just go with one and loose the benefits of the other. Now, I don''t know if you are experienced programmer or not but if you want to get started quickly there are some helper libraries out there.
http://cdx.sourceforge.net is quite old but still does a fair good job.
http://www.libsdl.org which is constantly updated and has a lot of good features although it is mainly opengl oriented. The DirectX support is a bit outdated. Lot''s of support and apps to look at though. I recommend this over CDX actually.
http://hem.passagen.se/mithril which is a free for non commercial use game engine that is mainly directed towards DirectX although it has OpenGL support. Much like SDL but faster and easier to use. Currently the webpage is undergoing some work but you can still download the latest version and some tutorials to look at. This is using a combination of both as I told you about but the manual is not finished yet so using all the functions can be not so obvious at the moment. Most functions are self explanatory though.
Hop this is of some help to you.
Here is a quick tip.
Will your game REALLY benefit from being 3d?
Are you REALLY sure that 3d is REALLY going to do something that is REALLY worth having in your game?
Otherwise, absolutely most definetively use 2d!
Will your game REALLY benefit from being 3d?
Are you REALLY sure that 3d is REALLY going to do something that is REALLY worth having in your game?
Otherwise, absolutely most definetively use 2d!
Here''s something I''d like to add (it''s an opinion, no flames please!):
2D RTS games are more fun. Simply because the small job of having to sort out the camera angle is taken out. When playing I hate rotating a 3D camera, especially when it can change angle aswell (e.g. Black and White) whereas, Age of empires 2 I can focus on building my armies, managing my resources and crushing my opponents!
Addmitedly in black and white it isn''t that much trouble because there are no fast moving attacks from the enemy that need to be attended to quick. C&C Generals is going to be a stab in the heart of the series.
(If you meant you were going to have a 2D look anyway and the question was 3D API vs. 2D API then I was mistaken, but if it wasn''t there''s my opinion, doesn''t relate to the question, but it''s the players of the game that count in the end, right?)
[ GDNet Start Here | GDNet Search Tool | GDNet FAQ ]
[ MS RTFM [MSDN] | SGI STL Docs | Boost ]
[ Google! | Asking Smart Questions | Jargon File ]
This was Oluseyi''s old .sig
2D RTS games are more fun. Simply because the small job of having to sort out the camera angle is taken out. When playing I hate rotating a 3D camera, especially when it can change angle aswell (e.g. Black and White) whereas, Age of empires 2 I can focus on building my armies, managing my resources and crushing my opponents!
Addmitedly in black and white it isn''t that much trouble because there are no fast moving attacks from the enemy that need to be attended to quick. C&C Generals is going to be a stab in the heart of the series.
(If you meant you were going to have a 2D look anyway and the question was 3D API vs. 2D API then I was mistaken, but if it wasn''t there''s my opinion, doesn''t relate to the question, but it''s the players of the game that count in the end, right?)
[ GDNet Start Here | GDNet Search Tool | GDNet FAQ ]
[ MS RTFM [MSDN] | SGI STL Docs | Boost ]
[ Google! | Asking Smart Questions | Jargon File ]
This was Oluseyi''s old .sig
![](smile.gif)
quote:
Original post by Anonymous Poster
I can tell you this from my own experience though; Don''t do a 2D game soley using 3D because it is too slow. It has to do with the nature of 2D more than anything else actually. 3D functions is designed for mainly 3D use although you certainly can slap a texture on a polygon and hope the fillrate is good enough.
This is a bit misleading. There hasn''t been a card made in the last 4 or 5 years where blitting a 2D background would be faster than rendering 2 triangles to draw the same thing. The fillrate for 3D will be equal or faster unless you did something wrong. The only time I can see it being a problem is if you try to use a texture that is too large for the card, and therefore you end up doing things in software.
[ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost | Asking Questions | Organising code files ]
May 11, 2002 01:27 PM
quote:
----------------------------------------------------------------
Original post by Kylotan
This is a bit misleading. There hasn''t been a card made in the last 4 or 5 years where blitting a 2D background would be faster than rendering 2 triangles to draw the same thing. The fillrate for 3D will be equal or faster unless you did something wrong. The only time I can see it being a problem is if you try to use a texture that is too large for the card, and therefore you end up doing things in software.
----------------------------------------------------------------
I know what you are saying but size does matter i am afraid;
Also some cards have different requirements regarding what width and height is accepted as textures. Agreed that the speed is equal in some circumstances but not all I am afraid. I spent two months testing different approaches on several different cards from ati rage 128 to GeForce 2 and there are many issues regarding performance in 3d unfortunately. Don''t forget about the cpu here either which also have a big importance. What is also important to remember is that you can only write so many polygons at a time before the card chokes and drops and then you need 2d anyway. I know you can get around some of these problems by using lists, vertexbuffers, drawing things in different order etc. but my point was and still is that you should use both 2d and 3d and not solely go 3d because then you are loosing the benefits from using 2D. Finally some cards create serious artifacts when drawing polygons. I have seen terrible examples of option screens in games where performance almost freezes because of the extensive use of 3d. Empire Earth is a perfect example of an application that should have used 2d for it''s interface for instance.
----------------------------------------------------------------
Original post by Kylotan
This is a bit misleading. There hasn''t been a card made in the last 4 or 5 years where blitting a 2D background would be faster than rendering 2 triangles to draw the same thing. The fillrate for 3D will be equal or faster unless you did something wrong. The only time I can see it being a problem is if you try to use a texture that is too large for the card, and therefore you end up doing things in software.
----------------------------------------------------------------
I know what you are saying but size does matter i am afraid;
Also some cards have different requirements regarding what width and height is accepted as textures. Agreed that the speed is equal in some circumstances but not all I am afraid. I spent two months testing different approaches on several different cards from ati rage 128 to GeForce 2 and there are many issues regarding performance in 3d unfortunately. Don''t forget about the cpu here either which also have a big importance. What is also important to remember is that you can only write so many polygons at a time before the card chokes and drops and then you need 2d anyway. I know you can get around some of these problems by using lists, vertexbuffers, drawing things in different order etc. but my point was and still is that you should use both 2d and 3d and not solely go 3d because then you are loosing the benefits from using 2D. Finally some cards create serious artifacts when drawing polygons. I have seen terrible examples of option screens in games where performance almost freezes because of the extensive use of 3d. Empire Earth is a perfect example of an application that should have used 2d for it''s interface for instance.
umm, if you are creating a tile based games using the 3d hardware is generally much faster then a pure 2d approach via directdraw. blaming poor drivers is silly, especially on older cards. most modern cards (even low end ones built on the mother board) can handle simple textured and alpha blended polys. (btw free alpha blending, bilinear filtered bliting, antialiased sprites, and rotation is enough for me to use 3d hardware for 2d tile based games). granted you cant access buffers directly with any hope of speed. though writing to textures each frame for displaying of movies and other effects is possible and quite fast.
the tricks are: squeeze as many tiles onto a single texture as possible. squeeze as many sprites onto a texture as possible. this will reduce texture sqitching and increase the ability to batch draw things. even a 256x256 texture can get 64 32x32 tiles on it perfectly. cpu has almost no bearing since you dont use any much matrices. and movemnet of things is equal to when calculating things with a 2d engine.
ap, play any 2d game on psx, dreamcast, ps2, or other 3d machines. you will find they run acceptable fast and use the same techniques that you would on a pc using a 3d api. heck bangai-o for dreamcast has hundreds (at times over 1400) sprites running simultanously on screen, and still maintains a decent framerate. its using 3d hardware to do its magic.
also ap, what is the highest pixels per second you can achieve blitting sprites in vram to a vram surface? now with alpha blending (which then puts the surfaces in sysmem for quicker access, then also count the blit to vram for display). also with this numbers if you choose to supply them, please give framerates. this helps show how much extranous fillrate usage you require to use alpha blended sprites.
Kylotan, i have no idea what you been reading but a video card simply wont allow you to use a texture larger then it can handle. drivers dont drop to software mode, they return an error code and disallow you to create the texture. though check the caps of the card using the proper api calls you can prevent creating such large textures.
the tricks are: squeeze as many tiles onto a single texture as possible. squeeze as many sprites onto a texture as possible. this will reduce texture sqitching and increase the ability to batch draw things. even a 256x256 texture can get 64 32x32 tiles on it perfectly. cpu has almost no bearing since you dont use any much matrices. and movemnet of things is equal to when calculating things with a 2d engine.
ap, play any 2d game on psx, dreamcast, ps2, or other 3d machines. you will find they run acceptable fast and use the same techniques that you would on a pc using a 3d api. heck bangai-o for dreamcast has hundreds (at times over 1400) sprites running simultanously on screen, and still maintains a decent framerate. its using 3d hardware to do its magic.
also ap, what is the highest pixels per second you can achieve blitting sprites in vram to a vram surface? now with alpha blending (which then puts the surfaces in sysmem for quicker access, then also count the blit to vram for display). also with this numbers if you choose to supply them, please give framerates. this helps show how much extranous fillrate usage you require to use alpha blended sprites.
Kylotan, i have no idea what you been reading but a video card simply wont allow you to use a texture larger then it can handle. drivers dont drop to software mode, they return an error code and disallow you to create the texture. though check the caps of the card using the proper api calls you can prevent creating such large textures.
May 12, 2002 02:19 AM
;-) I was not talking about DirectDraw. DirectDraw does not exist in Direct Graphics. Secondly, I have already tried to batch things up as you mentioned and it is a bad approach for many reasons, mostly because it is meaningless. Understand this, the cards absolutely love polygons, the more the better (up to it''s limits of course) What it abhores are single drawn polygons and this is where it falls down. A tile based game requires many single drawn polygons, especially when it comes to bullets and everything else that moves around. As a little note I manage about 4000 sprites at full frame rate with no problem at all with just using 3d so I am not putting you down here but I get twice the amount using 2D and 3D techniques together. Thirdly, I did not put the blame on bad drivers anywhere, nor did anyone else here for that matter. I propose that most of you who are so zealous in defending the single use of 3D simply have not tried to implement 2D together with whatever you try to do. Maybe because you think 2D is old and dated and should be forgotten about. I say fine, use only 3D then, it is really not a problem. However, you could improve your applications by using everything all that is available to you. A more important point is perhaps that the smaller the graphics on the polygon the better it will peform so by doing larger polygons you are actually making things worse.
Besides, Kylotan never suggested you draw anything the card cannot handle as such, he was referring to textures that are outside the "recommended" size for any particular card. Maybe he thought this was to be understood. Besides you are wrong, DirectX can revert to software if it is possible to do so without asking you(for certain functions).
Only if you request everything to be hardware only will it fail.
Besides, Kylotan never suggested you draw anything the card cannot handle as such, he was referring to textures that are outside the "recommended" size for any particular card. Maybe he thought this was to be understood. Besides you are wrong, DirectX can revert to software if it is possible to do so without asking you(for certain functions).
Only if you request everything to be hardware only will it fail.
May 12, 2002 03:36 AM
quote : "which then puts the surfaces in sysmem for quicker access"
You got to be joking?? Please don''t ever mention this again, this is totally wrong.
You got to be joking?? Please don''t ever mention this again, this is totally wrong.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
Recommended Tutorials
Advertisement