a True 3D iso engine
Author
Since everyone has been talking about 3D iso engines, I though I would post mine here. Its got a nice feature in that you can switch between perspective and orthographic viewing with a single key press. It also blends the edges of tiles together to make them more seemless.
http://www.tc.umn.edu/~pull0017/3D%20ISO.zip
Use arrow keys/mouse to scroll
Use + and - on the number-keypad to zoom in/out.
Possibility
Edited by - Possibility on June 25, 2001 10:00:52 PM
Nice work 
I picked up about 18.5 FPS on a 32bpp desktop, RIVA TNT2 model 64, PIII 600 mhz.
I didn''t notice a difference with alpha blending on/off, though.
Question, are you rendering each tile individually in seperate vertex buffers, with state changes for each tile? Or have you grouped all tiles with like textures into a few VB''s? I''m assuming the former.
I picked up about 18.5 FPS on a 32bpp desktop, RIVA TNT2 model 64, PIII 600 mhz.I didn''t notice a difference with alpha blending on/off, though.
Question, are you rendering each tile individually in seperate vertex buffers, with state changes for each tile? Or have you grouped all tiles with like textures into a few VB''s? I''m assuming the former.
Author
Oh I forgot, use the arrow keys to scroll, along with mouse at the edge of the window. Use the + and - keys on the number-keypad to zoom in and out. You dont need to tell me the frame rate or anything because the one you guys got is a slow version, its rendering alot more tiles then are need for whats visible on the screen. The actual frame rate for the initial zoom level is about 3 times higher.
The way I have it set is that each tile has its very own VertexBuffer, and I have a single IndexBuffer thats used when rendering all the tiles. Checkout the wireframe mode to see what the tiles look like. I dont do any state changes between tiles, I just change the stream source and the texture if its different from the previous tile. I tried it once with using a single vertex buffer for all tiles that are the same texture, but that wasnt any faster at all, and its to much work as those vertex buffer would have to be regenerated each frame - which is super slow. Plus you when you start having hundreds of tile textures, it wont help any anyways, so its generaly best to have a vertex buffer per tile that is generated when the program is started, IMHO.
Possibility
Edited by - Possibility on June 25, 2001 9:54:11 PM
The way I have it set is that each tile has its very own VertexBuffer, and I have a single IndexBuffer thats used when rendering all the tiles. Checkout the wireframe mode to see what the tiles look like. I dont do any state changes between tiles, I just change the stream source and the texture if its different from the previous tile. I tried it once with using a single vertex buffer for all tiles that are the same texture, but that wasnt any faster at all, and its to much work as those vertex buffer would have to be regenerated each frame - which is super slow. Plus you when you start having hundreds of tile textures, it wont help any anyways, so its generaly best to have a vertex buffer per tile that is generated when the program is started, IMHO.
Possibility
Edited by - Possibility on June 25, 2001 9:54:11 PM
I don''t quite get why you would need to regenerate the VB''s each frame. I mean, the tile coords don''t change, right? You would still only have to generate the VB''s once then forget about them. You would also save tremendously on the number of calls you make to set the current texture. I''ve read several times that the more verts you have per VB the better your performance will be (up to a certain sweet spot, that is).
Author
Oops, I meant to say you have to generate a new IndexBuffer cause you only want to draw the triangles that are on the screen, so you have to create a new each frame. Generating any kind of buffer will take alot time. Plus, if you have a map of 256x256 tiles x 8 vertices per tile, you get vertex buffers that are too large. Plus, if you were to change a tile from one texture to another, then you would have regenerate 2 new vertex buffers (regenerate the one of the previous and for the new type). From what I have seen its just faster to do it per tile.
Possibility
The faster version is one at the link now.
Possibility
The faster version is one at the link now.
Possibility, I haven''t got a chance to look at your engine as I''m at work, but I thought I''d touch on something.
Now, I''m fairly new to D3D, so I could be a bit off, but here''s how I understand it:
You''d want one large VertexBuffer, around 2000 vertices. Your individual tiles wouldn''t keep their own VB''s, but rather just the data that would go in them. When it''s time for a tile to render you lock the large VB, using the lock flag that tells D3D to KEEP the old contents, and starting at position 0 copy the vertices from the tile, update your position variable, then unlock and render. Keep doing this until your position variable + number of vertices you want to render next would be higher than your VertexBuffer vertices (2000), in which case you''d lock with the discard contents flag and reset the position to 0 and do everything all over again.
Also, you''d want to draw all of your tiles that use the same texture at the same time.
According to NVidia''s site the 3 things that slow down D3D most is 1) Switching VB''s, 2) Locking VB (with discard flag), and 3) Changing current texture.
Of course, I''ve never tried the above, so I don''t know how well it would work in your case. It would definately be easier to just draw it like you are doing now, but I just thought I''d mention it.
- Houdini
Now, I''m fairly new to D3D, so I could be a bit off, but here''s how I understand it:
You''d want one large VertexBuffer, around 2000 vertices. Your individual tiles wouldn''t keep their own VB''s, but rather just the data that would go in them. When it''s time for a tile to render you lock the large VB, using the lock flag that tells D3D to KEEP the old contents, and starting at position 0 copy the vertices from the tile, update your position variable, then unlock and render. Keep doing this until your position variable + number of vertices you want to render next would be higher than your VertexBuffer vertices (2000), in which case you''d lock with the discard contents flag and reset the position to 0 and do everything all over again.
Also, you''d want to draw all of your tiles that use the same texture at the same time.
According to NVidia''s site the 3 things that slow down D3D most is 1) Switching VB''s, 2) Locking VB (with discard flag), and 3) Changing current texture.
Of course, I''ve never tried the above, so I don''t know how well it would work in your case. It would definately be easier to just draw it like you are doing now, but I just thought I''d mention it.
- Houdini
Author
Hmmm, I am running a 650 Athlon classic w/ 256PC133 ram with a voodoo3 and I get about 46fps. 14fps is pretty low for a geforce2.
Possibility
Possibility
Using 800x600x16 in windowed mode I got 25FPS on my Voodoo3 3000 on a 500mhz Windows 2000 machine with 96mb''s of RAM. It''s looks pretty nice and unlike that one person I did see a difference between alpha blending on and off. It looks pretty ugly with it off. I really didn''t see much of a speed problem with it like the other people did so I don''t really see anything wrong with it. Good job -Kyle
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
