About the 149 vs 360 somethin-like framerates and them not being high enough, they were actually really low. My friend had over 600 for the DDraw sample. The program was very simple. It loaded a bitmap w/ a color key and then drew it bouncing around the screen while clearing the back. It was that simple.
---
My Site-My Tetris Clone w/Source
Come join us on IRC in #directxdev @ irc.afternet.org
Direct3D vs DirectDraw for 2D games
I am writing an engine with DX8.1, too.
But I used untransformed and unlit vertices for both sprites and maps. Now I am capable of rotating and lighting my sprites.
But I used untransformed and unlit vertices for both sprites and maps. Now I am capable of rotating and lighting my sprites.
I am doing the same, but in my case I am using unlit but transformed vertices. I do zoom, rotation and transparence on sprites/map.
I build a first version using many little vertex buffer (one for every tile, map or sprite), but I redo it so I can use only one giant vertex buffer. but it''s still no completly optimized since I didn''t sort the primitives by texture.
I''m asking myself about the effectivness of such on method, since 2d will always use a huge amount of texture. one solution could be to gather many of them in bigger texture, but I still have a vodoo 3 accelerator (arg :/) and I''m limited to 256x256 square textures.
As far as I know, I think it''s the best method, even since it may appear too complex for a "simple" 2d rendering engine...
I build a first version using many little vertex buffer (one for every tile, map or sprite), but I redo it so I can use only one giant vertex buffer. but it''s still no completly optimized since I didn''t sort the primitives by texture.
I''m asking myself about the effectivness of such on method, since 2d will always use a huge amount of texture. one solution could be to gather many of them in bigger texture, but I still have a vodoo 3 accelerator (arg :/) and I''m limited to 256x256 square textures.
As far as I know, I think it''s the best method, even since it may appear too complex for a "simple" 2d rendering engine...
quote:Original post by zilch_
I read a couple of days ago that TV has something like 20 or 30 FPS (it was low!). 149 should be enough
The reason that TVs only run at 30 fps (slightly less, actually) is because every frame is blurred into the next. This fools your brain into thinking that the images are much smoother than they actually are.
Also, I have to disagree with those people saying that using D3D8 for 2D games is harder than DirectDraw. It took me less than 2 days to get my DirectGraphics 2D engine up and running (I used the very easy-to-use IDirect3DSprite interface). With DirectDraw you have to worry about a lot more low-level stuff than you do with a simple D3D app.
-Mike
Don''t forget hardware compatibility. It''s extremely easy to write something in D3D8 that runs on only 2 different graphics cards. DirectDraw is pretty straightforward and runs well on all cards. With Direct3D, you have to do LOADS of testing until you get it right. I tend to think that it''s hardly worth that for a simple 2D engine...
- JQ
Full Speed Games. Period.
- JQ
Full Speed Games. Period.
AFAIK the most dangerrous things are non-supported special effects and cards which seem to be pure devices.
Avoiding those should not be a problem.
Check for support before using effects and keep track of your Transformstates etc. manually.
Avoiding those should not be a problem.
Check for support before using effects and keep track of your Transformstates etc. manually.
quote:Original post by doctorsixstring
Also, I have to disagree with those people saying that using D3D8 for 2D games is harder than DirectDraw. It took me less than 2 days to get my DirectGraphics 2D engine up and running (I used the very easy-to-use IDirect3DSprite interface). With DirectDraw you have to worry about a lot more low-level stuff than you do with a simple D3D app.
-Mike
of course it was simple ! you used this easy interface... and even if you used simple 2-triangles primitive to draw separate tiles, it would have been simple like this... but using D3D8 allow you to use the full power of the render pipeline of your graphic accelerator. that mean, by using separate tiles (and therefore doing the maximum render state/texture change), you lose a lot bandwidth for nothing...
read the post of MrGuest, it explains everything (at least for me) of doing an intelligent and efficient 2D renderer with D3D8 and actual graphic cards.
I think there's a real big difference between D3D8 and DDraw, and that every coder has to make a decision regarding what he aims. using D3DXSprite will only allow you to use simple tiles, but there 're a lot of other things you can do in 2D with D3D8 not allowed with DDraw.
[edited by - Axel5 on September 24, 2002 1:29:16 PM]
Just wanted to address two issues I saw earlier in the posts.
1. From what I hear, and personal experience, some graphics cards are not limited to the power of two textures. I am finishing a game where I have textures anywhere from 8X8 to 500X2100, as well as any imaginable value inbetween.
My game runs fine on my GeForce 4, as well as my 3 year old TNT2 card.
2. The framerate of a game depens on the type of game you are writing. The game I spoke about earlier is a 2D shooter game with total freedom. This means that you control your forward and backward movement. So there could be a speed difference of a couple hundred miles an hour between you and another plane. If my game were to be running at low frame rates, I could have a situation where a bullet would be in front of a plane, and the next frame, behind it, totally missing the plane. This could be solved by checking collisions multiple times per frame drawn, or using vectors, which I don''t know how to do, but as you see, in some 2D games, 30 frames/sec is not enough. My game runs between 60 - 100 fps. Anywhere below 50 is not acceptable in my game due to the accuracy needed.
--Vic--
1. From what I hear, and personal experience, some graphics cards are not limited to the power of two textures. I am finishing a game where I have textures anywhere from 8X8 to 500X2100, as well as any imaginable value inbetween.
My game runs fine on my GeForce 4, as well as my 3 year old TNT2 card.
2. The framerate of a game depens on the type of game you are writing. The game I spoke about earlier is a 2D shooter game with total freedom. This means that you control your forward and backward movement. So there could be a speed difference of a couple hundred miles an hour between you and another plane. If my game were to be running at low frame rates, I could have a situation where a bullet would be in front of a plane, and the next frame, behind it, totally missing the plane. This could be solved by checking collisions multiple times per frame drawn, or using vectors, which I don''t know how to do, but as you see, in some 2D games, 30 frames/sec is not enough. My game runs between 60 - 100 fps. Anywhere below 50 is not acceptable in my game due to the accuracy needed.
--Vic--
quote:1. From what I hear, and personal experience, some graphics cards are not limited to the power of two textures. I am finishing a game where I have textures anywhere from 8X8 to 500X2100, as well as any imaginable value inbetween.
My game runs fine on my GeForce 4, as well as my 3 year old TNT2 card.
This has nothing really to do with the card itself, but with the driver implementation. This is so they make certain optimizations. TNT2 drivers requires power of 2 textures, AFAIK. I have one myself. I''m assuming that you are using D3D and, more importantly, D3DX to load the textures. D3DX will automatically resize non-pow2 textures to the nearest pow2.
quote:2. The framerate of a game depens on the type of game you are writing. The game I spoke about earlier is a 2D shooter game with total freedom. This means that you control your forward and backward movement. So there could be a speed difference of a couple hundred miles an hour between you and another plane. If my game were to be running at low frame rates, I could have a situation where a bullet would be in front of a plane, and the next frame, behind it, totally missing the plane. This could be solved by checking collisions multiple times per frame drawn, or using vectors, which I don''t know how to do, but as you see, in some 2D games, 30 frames/sec is not enough. My game runs between 60 - 100 fps. Anywhere below 50 is not acceptable in my game due to the accuracy needed.
Eh? I don''t quite follow you here. What you describe has no direct correlation to frame rate, but to game mechanics. Yes, this effect could possibly occur at extremely low frame rates - but it shouldn''t be happening at 30 fps! If it does then you need to seriously rethink your collision detection code, because something just ain''t right. Good collison detection code would be able to handle this situation even at 4 fps. It has nothing to do with vectors really. World updates should not be frame rate dependent, but time based. You need to decouple your world loop from your render loop.
quote:Original post by JonnyQuest
Don't forget hardware compatibility. It's extremely easy to write something in D3D8 that runs on only 2 different graphics cards. DirectDraw is pretty straightforward and runs well on all cards. With Direct3D, you have to do LOADS of testing until you get it right. I tend to think that it's hardly worth that for a simple 2D engine...
- JQ
Full Speed Games. Period.
Sorry but I totally disagree with the "DirectDraw is pretty straightforward and runs well on all cards.", it's totally false. Some cards support certain features, some don't.
Two examples:
- Color-Keying + stretching is fucked up on most new cards (which performs algorithmics stretching)
- Mirroring and rotations using DDBLTFX are fucked up on A LOT of video cards.
Only solution: Emulate everything in software.
(My actual 2D engine is DirectDraw and working, but my next 2D engine will certainly be DX9 or OpenGL).
[edited by - Cahaan on September 26, 2002 9:06:03 AM]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement