HELP ! ISO TILE ENGINE ? HOW TO CREATE..
Author
I have programmed a Tile-Engine. Each Tile has a size of
32x32 Pixel. I use an resolution of 640x480x16 !
I use a P1 166 MMX and I get with this Tile-Engine
75 Frames per second! For this Engine I use a
tilemap like this.
int TileMap[100][100]
Each integervalue represent a tilegraphic.
Now, I have heard from multi-layer maps, which
look like this.
int TileMap[3][100][100]
Question 1: Why I should need multi-layer maps. what
are the advantages ??
Question 2: If I blit 3 maps instead of 1 then my Framerate
is decreased to 37 FPS! If I will use multi-layerd
maps, how can I programm it , that it is
faster than only 37 FPS ??
Question 3 (Main Question):
How can I programm an ISO-Tile-engine ??
Can I use my homogenous Tile-Engine for that ??
But how can I draw 45 degree viewed Grafiks in a
32x32 sized Tile ??
Do you know a good ISO-Tutorial or a good ISO-Page
on the net ??
Can somebody send me his source-code of a ISO-Tile
engine ??
HELP,HELP ... I really need help.
thank you very much
MFG
MisterByte (Germany)
(1) You would have a base layer, that represents the ground, and anything that the player may walk upon. The middle layer would represent anything (including monsters, walls, characters, and so on) that can block traversal. And the final layer would be anything that can obscure the other 2 layers, like tree canopies or roofs. There's no set design pattern for these, it's whatever works best in your case.
(2) You're probably not using an optimized rendering loop. Try removing divides or heavy mathematics inside a loop, that can be precalculated outside of the loop. Also use static data for things that are only ever calculated once when the game engine starts, that only NEED to be calculated once. Post your code here, I'm sure you'll get optimization tips.
(3) More info please... are you programming this using OpenGL, DirectDraw, Direct3D, your own custom library?
I suggest this link for any isometric game engineer: http://www.geocities.com/SiliconValley/Vista/6774/, only because it covers a LOT of things for iso engines, and uses Ultima as the example
What I'm doing for my isometric tile engine is drawing each tile row by row, which I think fixes an obscurement artifact found in other games. Check out screenshots below:
Screenshot 1, Screenshot 2
Before asking for source code to something, try learning how to do it on your own first ... you'll be more satisfied with the results, and you will actually learn what is necessary to move your game forward, rather than copy/paste your way to the finish line.
Good luck
MatrixCubed
http://MatrixCubed.org
Edited by - MatrixCubed on March 15, 2001 8:22:25 AM
(2) You're probably not using an optimized rendering loop. Try removing divides or heavy mathematics inside a loop, that can be precalculated outside of the loop. Also use static data for things that are only ever calculated once when the game engine starts, that only NEED to be calculated once. Post your code here, I'm sure you'll get optimization tips.
(3) More info please... are you programming this using OpenGL, DirectDraw, Direct3D, your own custom library?
I suggest this link for any isometric game engineer: http://www.geocities.com/SiliconValley/Vista/6774/, only because it covers a LOT of things for iso engines, and uses Ultima as the example
What I'm doing for my isometric tile engine is drawing each tile row by row, which I think fixes an obscurement artifact found in other games. Check out screenshots below:
Screenshot 1, Screenshot 2
Before asking for source code to something, try learning how to do it on your own first ... you'll be more satisfied with the results, and you will actually learn what is necessary to move your game forward, rather than copy/paste your way to the finish line.
Good luck
MatrixCubed
http://MatrixCubed.org
Edited by - MatrixCubed on March 15, 2001 8:22:25 AM
Howdy MB,
1) I am using a structure, then defining it as a two dimentional array. Within the structure are the variables that are in effect the layers - like this (this is not the actual structure, but will give you the idea)
The tileid is loaded in from data, the landform is always the same. But, the boogeymen and the botany is random. Things can happen to them ... new plants can grow, old plants can die. Boogeymen can wander off.
So tileid, the base geographical layer, is layer one. The plants and boogeymen are layer two. When the actual blit is going on there is not a lot of overhead to doing a second pass (as opposed to doing everything in one pass). Yes you''ll need another loop but the things to check are still the same, and it saves the hassle of potentially overwriting portions of your second layer with portions of your first, especially with rhombus tiles.
On the second pass, unless things are very busy, it is usually a fast pass. No plants ? No boogeymen ? Next ! On the other hand it can be a slow pass if the tiles are chokas, especially since then you''ll need to sort the order of blitting out so things behind are blitted first.
The bottom line is the good thing about having two layers is the second layer can slide around on the first ... it does add depth ... Of course, more layers is more processing, and fps will go down. That is the price you pay.
2) It does not follow that every layer will require the same amount of processing, as I pointed out previously. Anyhow, 37 fps is not tragic.
3) Check out Ironblayde''s tutorial, here ... it is a good one. The main difference between a rectangle tile engine and an iso one is you need to treat the odd and even rows differently for an iso engine. Apart from that, not a *lot* of difference. Hmm I use a 126 * 63 tile, which overlaps two pixels (everytile has two pixel overlap with its neighbour, if visible) ... not suggesting it at all !!! But 32 * 32, I''m not so sure how that would go either. Sounds like a square to me.
*Disclaimer* - I''m no way saying this is the best way, or even a good way, but it might give you some insight into, a way.
El Duderino
1) I am using a structure, then defining it as a two dimentional array. Within the structure are the variables that are in effect the layers - like this (this is not the actual structure, but will give you the idea)
struct stIsland{int tileid;int numofplants;int numofboogeymen;int boogeymen[30];int plants[30];int xoffset[60];int yoffset[60];}; The tileid is loaded in from data, the landform is always the same. But, the boogeymen and the botany is random. Things can happen to them ... new plants can grow, old plants can die. Boogeymen can wander off.
So tileid, the base geographical layer, is layer one. The plants and boogeymen are layer two. When the actual blit is going on there is not a lot of overhead to doing a second pass (as opposed to doing everything in one pass). Yes you''ll need another loop but the things to check are still the same, and it saves the hassle of potentially overwriting portions of your second layer with portions of your first, especially with rhombus tiles.
On the second pass, unless things are very busy, it is usually a fast pass. No plants ? No boogeymen ? Next ! On the other hand it can be a slow pass if the tiles are chokas, especially since then you''ll need to sort the order of blitting out so things behind are blitted first.
The bottom line is the good thing about having two layers is the second layer can slide around on the first ... it does add depth ... Of course, more layers is more processing, and fps will go down. That is the price you pay.
2) It does not follow that every layer will require the same amount of processing, as I pointed out previously. Anyhow, 37 fps is not tragic.
3) Check out Ironblayde''s tutorial, here ... it is a good one. The main difference between a rectangle tile engine and an iso one is you need to treat the odd and even rows differently for an iso engine. Apart from that, not a *lot* of difference. Hmm I use a 126 * 63 tile, which overlaps two pixels (everytile has two pixel overlap with its neighbour, if visible) ... not suggesting it at all !!! But 32 * 32, I''m not so sure how that would go either. Sounds like a square to me.
*Disclaimer* - I''m no way saying this is the best way, or even a good way, but it might give you some insight into, a way.
El Duderino
You can learn a lot from taking a look to other Iso-engine source codes:
http://www.isometrix.org
(free sources from IsoTest and BlackFish)
good luck
.-/303\-.
http://www.isometrix.org
(free sources from IsoTest and BlackFish)
good luck
.-/303\-.
Also notice there is a link to a book called "Isometric Game Programming" on the front of the www.gamedev.net page. It was written by one of the people who run the site and from what I hear covers all you need to know.
Joseph Fernald
Software Engineer
Red Storm Entertainment.
------------------------
The opinions expressed are that of the person posting
and not that of Red Storm Entertainment.
Joseph Fernald
Software Engineer
Red Storm Entertainment.
------------------------
The opinions expressed are that of the person posting
and not that of Red Storm Entertainment.
(2) You are probably only getting 75 fps because of vertical sync. If you use DirectDraw, you''d be using something like
lpdds->Flip(DDFLIP_WAIT, NULL);
This DDFLIP_WAIT tells your DX to wait for the screeen redraw to finish, before performing the flip. That means the fastest frame rate you can get is the refresh rate of your monitor, and 75 Hz is a common frequency. Try using DDFLIP_DONTWAIT to get the actual fps.
- Sleepwalker
lpdds->Flip(DDFLIP_WAIT, NULL);
This DDFLIP_WAIT tells your DX to wait for the screeen redraw to finish, before performing the flip. That means the fastest frame rate you can get is the refresh rate of your monitor, and 75 Hz is a common frequency. Try using DDFLIP_DONTWAIT to get the actual fps.
- Sleepwalker
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
