I’m interested in making a 2D game (either RTS or something like SimCity), but it seems like 2D stuff in openGL is kind of a pain - loading a texture, binding it to a quad… Which do you think is best suited for the job, openGL or directX?
PS: If openGL is in fact the best way to go, does anyone have advice on how to efficiently use its 2D features?
OpenGL is great for 3D and 2D, and its ‘perfect’ for 2D games, it all depends on you. For a Simcity/RTS like game, I would try some kind of quad tree data structure. There are some tutorials out there (the truth is out there).
For a 2D game i would coose DirectDraw it is simple enough to learn/use and it is faster on computers without 3D hardware acceleration, OpenGL without a 3d card is veeeery sloooow. But with a 3d card it is more beatiful. It depends on if the game is planned for better or slower computers too.
DX8 doesn’t have direct draw does it? I think you have to use direct graphics that contains D3d.
I would go for OpenGL, you can take a bet that every one (who plays games) will have hardware acceleration.
hey out there.
i was looking at this post and i saw that
Anonymous Coward said there are some tutorials out there. But can you say US where to look. And HOW easy is it to understand directX.
I want to make some kind of a simcity game too. (more like RED ALERT)
I don’t really need 3d but it’s the only good drawing method i know.
thanks anyway
directx is surely better for 2D drawing, but that does not mean it´s any good at all.
DX is such a twisted, crappy, dirty API that you´ll want to smash you forehead on the keyboard if you actually program with it.
you´d better check out www.clanlib.org or www.libsdl.org, both are gamer’s APIs that will make life easier for you.
for the sound, i´d use www.fmod.org as long as your game will be available for free.
the big benefit of those libraries is that they´re completely PORTABLE, so you can make your game work under linux etc without much effort…
I don’t want to get into the Direct3D vs. OpenGL argument. DirectGraphics (in DX8) does have pretty flexible support for 2D sprites (using 3D hardware), but you could probably do everything using OpenGL just as well.
But as for the 2D vs. 3D API, I think that there are advantages to using a 3D API. Even if you plan your game as 2D, you’ll later be able to add 3D features (such as 3D characters over a 2D background), do easier lighting effects, change to a different perspective - overhead vs. isometric (not trivial, but may be easier when your game is already in 3D, esp. if you already did some of the things in true 3D), and so on.
Texture loading, etc., shouldn’t be too much of a problem. A 2D game usually has a number of different tiles, which you could load at the beginning of the game, and later use. You could probably load all (or most) of them into a single texture, and just use texture coordinates to select them.
I believe DX7 does have Direct Draw (not sure if DX8 does). The only possible problem is the uploading of textures… if textures are large, say even 256x256, this could be costly in terms of performance. Most OpenGL programs have some sort of initialization routines that load textures at the beginning (since textures are often static). I’m guessing you’re probably trying to create a video buffer to use as a texture on a quad… I’ve tried it and it can be slow. Also, some cards (at least the 3DFX ones) have a limit on the size of the textures (max is 256x256, I think).
I’d say go with DirectX, or check out other hw-accelerated 2d toolkits like SDL or OpenPTC. You should also check out blitz basic.
Then upload the textures at the start of the game loop.
BTW, you idiots, DirectDraw is in every DirectX since version 2. omg! 
For a game as in what you’re doing, I’d use DirectDraw all the way. Unless, of course, you’re willing to write your own assembly graphics routine… 
) (any other language is pretty much too slow for RA-style graphics)
What I would do with your game is instead of having memory-expensive 2D textures all over the screen is use low-res 3D models with good textures and maybe even specular and bumped lighting.
Tim said “I would go for OpenGL, you can take a bet that every one (who plays games) will have hardware acceleration.” Yeah… right! I know for a fact that many cards don’t have OpenGL HW acceleration, and those that do aren’t decent enough to actually do more than draw flat-shaded polys to teh screen. If the person has an nVidia chip, they’re guaraunteed good OpenGL acceleration, but not enough do. Consumer PCs are just starting to use the TNT2 chips in their machinces, and some still use AIT’s Rage Pro chips!!! They all do, however, have support for DirectDraw, and would thus make it a better choice for games intended for a more generalized public. Since you seem to be new to game programming, however, I would personally suggest that you use whatever you’re proficient with to design the game, and because you’re guaraunteed to want to rewrite your engine later, you can use a different API then, because you’ll have the rest of the work pretty well laid out. You can’t just start out all new again, so work on learning the basics to writing engines, then learn DirectX, and come back to writing engines with it. You’d be much better off, and you wouldn’t be guessing all the way.
To be exact pATChes11, DirectDraw is not part of DirectX 8. It is however part of DirectX 7, which DirectX 8 installs if you don’t have it. You can not use any DirectX 8 interface to instantiate a DirectDraw interface.
also on systems without hardware acceleration directdraw is not the fastest, fastgraph is 
>>Consumer PCs are just starting to use the TNT2 chips in their machinces<<
check the newspaper this is 2001 not 1997
“>>Consumer PCs are just starting to use the TNT2 chips in their machinces<<
check the newspaper this is 2001 not 1997”
oh yeah? well I know a number of people who still have something less than a TNT and i think if you want to play a 2D game you should not be forced to have fancy 3D hardware.
myself, i´ve got a voodoo2 since 98 and i am not willing to upgrade anything for at least another year. most of the new games are crap anyway except for their graphics, it’s like in the music business, the companies release titles that currently ‘just fit in’… racing games sell? fine, we’ll make another uninspired racer with polished gfx (Gran Turismo etc.) Commandos a success? fine, we’ll do the same thing with other characters, etc. blah blah…analogue: the pop music biz, just take any of those britney spears, boygroup or r&b bull****!!
concerning games, i’m just missing any new ideas, stuff gets just done over and over again. when i started becoming interested in computer games, there were groundbreaking games released every 3 or 4 months or so, simply because programmers weren´t controlled by their publishers who only want to cash in lots of money with some dull product.
ok this has drifted way off-topic now, sorry for that 
still, i recommend some open library for your task (see my post above)
regards
eik
heheh this is funny this board actually parses the word s.h.i.t and fills in **** instead
>>myself, i´ve got a voodoo2 since 98<<
yes but the voodoo2 is a 3d hardware accelerated card. just like my vanta
yeah, but it’s kind of crappy nowadays
it doesn’t have a stencil buffer (aaargh, the nasty workarounds i had to do to get halo flares to work nonetheless in my new prog)
it renders 16bit only
it dithers really ugly
it’s fullscreen only
the drivers like to crash sometimes
however, speed’s okay… and although i regret that 3dfx went bust, i must admit that their technology wasn’t really a match for nvidia anymore when they were bought out… 
the point was, there are enough people nowadays who still got a crappy ATI or something like that that doesn’t boast very fast 3D hardware…
ok true not everyone has a 3dcard. my point was the vast majority do (youve had one for 3 years) and the percentage is increasing with each week.
even old slow 3d cards can handle 2d graphics in opengl with ease. 2d is very fast to do . no depthtesting u know exactlly whats on the screen and whats not etc.
btw why do u need stencil to do halo flares?
(im assuming by halos u mean when u look at a light u see a brightened texture around it)
you´re right that the number of accelerators increases, i’m not saying i´ve made a srong point here
is 2D really faster to render than 3D? i haven’t tried it yet, but under linux, with mesa tuned to my crappy ATI card, texturing is sooooo slow…
ah, the halos: you can see this effect in various racing games, for example if the brake lights go on, there´s a little flare/halo around the light. this also looks very cool if you´ve got a dark environment and some bright lights… to determine were there’s such a light on screen and whether it’s not obscured by another object, i would have used the stencil buffer if i only had one
you can check out the effect by watching the screenshots or downloading the game at my project’s website http://possibleworlds.cjb.net (that version is a bit old, i’m releasing the final version in a week or so)
>>is 2D really faster to render than 3D? i haven’t tried it yet, but under linux, with mesa tuned to my crappy ATI card, texturing is sooooo slow<<
perhaps youre not getting hardware acceleration. texturing (+ other per pixel stuff) without hardware acceleration is very slow.
reasons why 2d can be way quicker u know what is on the screen to the pixel making it much easier to do far finer culling than in 3d. u dont see into the distancce like in 3d thus theres far less to draw.
cause everthing is flat (2d) no need to enable depthtesting or clear the depth buffer. polygons will always be front facing etc etc. i remember getting over 100fps in a 640x480x16 3d scene on my riva128 4mb in opengl a few years ago.
about the halo’s to see if a light can be seen its best/quickest to run a ray from the light to the camera + see if it intersects with any of the polys in the world.
this assumes that the lights are points though but it seems to work alright.
sounds pretty cool, looks like using openGL for 2D drawing might be a good idea. useful to me since i want to do a monitoring interface for a realtime system soon, but that’s another story…
about the halos: intersecting with polys works fine as long as you don’t have partially transparent textures applied to them (girders, etc.). for such a situation i do this: draw a single dot where there should be a lightsource, then, wehen everything’s been rendered, check if the dot has actually been rendered/is still not obscured by accessing the stencil buffer at the screen coordinates the dot was drawn. if the stencil value corresponds, draw the halo. i know accessing buffers slows you down a bit but this is the way to go…