Sign in to follow this  

Need guidance

This topic is 4320 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello everyone Im crazy about isometric games and I want to build them. The thing is that Im not good at DirectX and furthermore I only know Visual Basic 6. Ive created some 2D terrain models that can generate uneven land and the algorithms that detect the mouse movement/click on them. But my major problem right now is the algorithm to determine which tiles to show on screen (visibility testing) Anyways Ive gone through a LOT of threads on many website and I think if I get a book about it, it would make things more easy and understandable. So.. Im looking for a begginer's book on 2D isometric games (Ive heard a lot about TANSTAAFL) I was thinking of starting from DirectX 8 because Ive already done quite a few experimentation with it. And I only know Visual Basic 6 (not .NET). Is there any such good book? Ok ok I am willing to switch over to C/C++ just for isometric games, but Im not ready for .NET yet. Please recommend me some good book keeping above things in mind, and also tell me where to get it from. Thank you very much!

Share this post


Link to post
Share on other sites
Articles and Resources:
http://www.gamedev.net/reference/list.asp?categoryid=44

Recommended Books:
http://www.gamedev.net/columns/books/books.asp?CategoryID=11

You can find this information by looking in the menu under names like 'Articles' or 'Books'.

Share this post


Link to post
Share on other sites
Personally, I am not a fan of learning game programming/design from a book. I feel that it is just something you have to do yourself before you understand. The game I've been working on since June 2004 has come a long way (and is still a long way from completion as well) and I just learned things as they came up. I did buy one game programming book, but it was not very much help to me at all, and didn't really answer anything that I could find in online API documentation.

Share this post


Link to post
Share on other sites

You should get TANSTAALF's, it's really worth the price.

You should move to C/C++, too. No reason to learn .NET if you don't want to. But by sitting just in VB you're limiting your options.

And note that almost any game programming book you can find will be oriented to C/C++

I also recommend you to leave DX (for now) and go to a simpler API such as SDL. The idea is to learn the basics of isometric programming in 2D before making the leap. By using DX you'll have to pay attention to many other important details inherent to that API, that could overwhelm you if (1. it's your first C/C++ project, and 2. it's your first isometric game)

Of course, this all depends on your own skills. If you feel like making an isometric engine in DX, you can do it. You're the one who knows your own limitations.


Quote:

Personally, I am not a fan of learning game programming/design from a book. I feel that it is just something you have to do yourself before you understand.


I disagree. Self-learning is important, but you shouldn't discard any good resource you have access to. A good learner will get any article / tutorial /book they can find, read them, and then start from there moving on his own.

Anyways, that would be a matter for another discussion.

Share this post


Link to post
Share on other sites
Quote:
Original post by Sante05
I also recommend you to leave DX (for now) and go to a simpler API such as SDL. The idea is to learn the basics of isometric programming in 2D before making the leap. By using DX you'll have to pay attention to many other important details inherent to that API, that could overwhelm you if (1. it's your first C/C++ project, and 2. it's your first isometric game)
I disagree with this. He already has some experience with DX. Moving to SDL (a somewhat outdated 2D API with manifest gotchas of its own) will just waste time.

Share this post


Link to post
Share on other sites
Quote:
Original post by Sneftel
Quote:
Original post by Sante05
I also recommend you to leave DX (for now) and go to a simpler API such as SDL. The idea is to learn the basics of isometric programming in 2D before making the leap. By using DX you'll have to pay attention to many other important details inherent to that API, that could overwhelm you if (1. it's your first C/C++ project, and 2. it's your first isometric game)
I disagree with this. He already has some experience with DX. Moving to SDL (a somewhat outdated 2D API with manifest gotchas of its own) will just waste time.



I mentioned turning down DX just because of what he said:

Quote:

The thing is that Im not good at DirectX


Of course the decision is his. I was just pointing the alternatives.

About SDL being outdated, it's true. However, it's way easier to learn, and it should be considered when starting in this (as opposed to the complexity of more powerful APIs)

You could say it's similar to learning Pascal before jumping into C/C++. Yes, Pascal is outdated, and you wouldn't use it in any real project. But it's easier to use, and allows you to learn the basics of imperative programming without having to deal with complex features.

Share this post


Link to post
Share on other sites
Ok lets break it down.. I KNOW DirectSound, DirectMusic, etc. but when it comes to Direct3D, I know which function does what but I faced severe performance issues when I was building a 3D isometric game (with an orthographic camera projection) That sounds intense doesnt it? :) Especially when it was my first time using DX.

So I was able to create the whole landscape, manage textures, etc. but my game was too slow and my engine totally got beat when I tried to implement the mouse detection code (ie. to know which tile my mouse was currently on). My game was a lot similar to SimCity4.

So I think I can create stuff in DX but I always face performance problems. Im not that smart DX coder who manage their game in such a way that it gets optimum performance.

Share this post


Link to post
Share on other sites
I have faced somewhat similar issues, and have seemingly overcome them.

The important thing to realize, is that coding in a 3D API, is VERY different that coding in a 2D one, let me lay some things out for starters.


In a 2D API
- I can load images of any size (basically), only restricted by memory
- I can draw my images in whatever order I please


In Direct3D
- Your textures must comply with the graphic's driver's capabilities (power of 2, square, 256x256, worst case (larger min size nowadays))
- Your scene geometry (vertex,index buffers) should be as constant as possible (few to none real-time locks)
- Your scene should be drawn first and foremost to reduce texture and state changes
-- draw all things using tex0 draw all things using tex1 ...
- DrawIndexedPrimitive should be used in almost all cases

As you can see, to get performance out of Direct3D you need to adheare to a couple of important restrictions that at first sound hard to do.



So, I'm going to give you a few tips.


Your terrain, should probably be stored in a single, static vertex buffer, if your terrain is too large however, it may need to be broken up into multiple vertex buffers.

When drawing your terrain it should be rendered based on what textures it uses,
and the data would be best arranged to allow for contiguous rendering of the geometry.

so wherein 2D your rendering code might look like:

for each tile
set texture
draw tile
end each


in 3D it should look somthing like:

for each texture
set texture
draw all tiles using this texture
end each

this reduces texture switches.

Hope that helps.

Share this post


Link to post
Share on other sites
Depending on the type of game you are making, the rules enforced by the 3d API's can sometimes be bent. For instance, using texture coordinates with tile sets will greatly reduce the number of texture switches increasing your performance. With a little fore thought, this can be used in much the same way as source rectangles in 2d API's.

And again, depending on the type of game and the complexity of it, you can still have a performance increase using a 3d API and the same 2d drawing techniques you would use with something like SDL.

The biggest problem I have with using a 3d API is the complexity of rendering to an offscreen texture. This tends to be a pain and causes performance issues if overly used (at least for me). For the most part though, you can get away with drawing 3000-5000+ textured quads with scaling, blending and rotation in less time than 2000-4000 in something like SDL without scaling, blending and rotation.

Try looking into something like PnP Bios's hxRender library (SDL/OpneGL under the hood) or HGE's game library/engine if you don't want to do the low-low level stuff yourself. Even Irrlicht has 2d functions along with a built in GUI library. Irrlicht may be overkill for anything small but who knows what your game might grow into.

Good luck

Share this post


Link to post
Share on other sites
I would like to add to these since they are pretty signifigant gotchas in certain cases.

Quote:
Original post by evillive2
... For instance, using texture coordinates with tile sets will greatly reduce the number of texture switches increasing your performance.



This CAN be used in certain cases but one must be aware of potential issues.

Unlike our old friend the Image Blitter, mapping part of a texture onto a quad is not nearly so precise. unless you do a direct mapping of Texels to Pixels (which means the quad cannot be scaled up) you are likely to see part of your neighboring tile 'bleeding' into your drawn image, this is ususaly due to the filtering process, the only effective way to get around this is to use a 1 (or more) translucence pixel 'gutter' around all of the images in a packed tile set, which is a large large pain.


For a little bit of perspective, I found that doing a game as image-heavy as morning's wrath was enourmously hard to make performant in a 3D API, and even now it is not very performant versus a 2D api.

Quote:
Original post by evillive2
The biggest problem I have with using a 3d API is the complexity of rendering to an offscreen texture. This tends to be a pain and causes performance issues if overly used (at least for me). For the most part though, you can get away with drawing 3000-5000+ textured quads with scaling, blending and rotation in less time than 2000-4000 in something like SDL without scaling, blending and rotation.

Try looking into something like PnP Bios's hxRender library (SDL/OpneGL under the hood) or HGE's game library/engine if you don't want to do the low-low level stuff yourself. Even Irrlicht has 2d functions along with a built in GUI library. Irrlicht may be overkill for anything small but who knows what your game might grow into.

Good luck


The large issues come not when you draw 5000 textured quads, the card is very happy about doing that. The issue comes when you draw 5000 textured quads with about 50 different textures. Non-grouped renderings will cause tons of texture switches, and if you happen to be using more textures than can fit on your card, prepare to drop some serious frame-rate.

my current advice would be to keep your tile images as squares, 64x64 or whatever, and utilize a view transform to put your view into isometric.

if you can guarentee that the tiles will be 64x64 (or whatever size you choose) then you can have a number of atlases (which you might have to gutter if you need to scale) these can be generated programatically or by an artist. in this way, 64x64 tiles, a single 1024x1024 image map will give you 16x16 64x64 tiles
for your needs this may be enough and each map can have it's own 'atlas' or you can use multiple atlases, that get swaped out during map changes.

just some food for thought =D

Share this post


Link to post
Share on other sites
Thats all very informative; thank you. A little problem:

Quote:

my current advice would be to keep your tile images as squares, 64x64 or whatever, and utilize a view transform to put your view into isometric.

if you can guarentee that the tiles will be 64x64 (or whatever size you choose) then you can have a number of atlases (which you might have to gutter if you need to scale) these can be generated programatically or by an artist. in this way, 64x64 tiles, a single 1024x1024 image map will give you 16x16 64x64 tiles
for your needs this may be enough and each map can have it's own 'atlas' or you can use multiple atlases, that get swaped out during map changes.


Doesnt "64x64" sound as 2D drawing? If so, how can the view transform be utilized? I think view transform is only for 3D space where x,y,z values are in relative terms not exact pixels.

I was able to setup a nice 3D terrain with no performance issues and I had also implemented all the nice tips that you guys gave; such as single index buffer, least texture switches, using the transformation view to appear like isometric, etc., but my major problem was mouse detection. Since I was using a single index buffer, I had to use ray-picking technique (transform the current mouse cordinate into 3D and check each triangle one-by-one if mouse lies within it; using Pythagoras theorm!). You can see it was very yucky!

If I checked each tile one-by-one in ascending order (top-left of terrain to bottom-right) then if my mouse was on the top edges, it would detect/calculate very fast. But if it was near the bottom edges, my algorithm would bring down the FPS from 65 to 5!! So my poor-lil code brought my system down to its knees.

Thats why I decided to revert back to 2D and get my head absorb it completely first. I can create varying-height terrains in 2D, mouse detection is a peice of cake as it is simple calculation in 2D, now comes new problem: visibility test >> ie. to decide which tiles to draw and which not to draw. For that I used the same rotten technique; checking each quad if its visible on the screen. That again brought the speed down.

..... and THATS why Im looking for a book that shows some examples+explanations to overcome the basic terrain engine problems :)

my 3D terrain

[Edited by - itz_faraz on February 13, 2006 1:50:18 PM]

Share this post


Link to post
Share on other sites
I keep track of fine offset and the top left tile. When it comes down to drawing, I know that my tiles are 64x64 (as an example) and my screen is 640x480. I can now run 10x8 (or 10x16 if iso) I pre-calculate, and only re-calculated when screen resolution changes. This way their is no need to test a tile. Setting up a view port (region, whatever) can also help quite a bit if your map only takes up a section of your screen. The last thing I do, is while I'm drawing down my 1st layer of tiles I check each "Room" for what other layers exist (objects, top tiles, splat layers, etc) and que them up for drawing. Once I complete the initial draw, go back and run my que, thus eliminating the need to run the entire screen space again.

- Jeremy

Share this post


Link to post
Share on other sites
Quote:
Original post by itz_faraz
my 3D terrain


Okay, clearly you have a pretty firm grasp on using D3D... the earlier suggestions of using SDL are inappropriate... nice screenshot, BTW!

While EDI recommends using non-isometric tiles and then allowing the hardware to orient them into "diamond" tiles, I'd tend to argue against this depending on what your end goal is. If you're wanting to do a "classic" isometric game that's pixel-perfect, then you'll want to avoid have the 3D hardware shear your tiles to make them isometric. You'll lose some detail due to filtering and generally not be getting the most bang for your buck. Of course, if you're wanting to have 3D terrain (like EDI's Project2) then going the texturing route is the way to go.

Share this post


Link to post
Share on other sites
When you say you tested against every triangle.

Does this mean you locked the vertex buffer and read triangles from it?

if so, that is _very bad_ you should _never_ read data from hardware resources.

an alternative to this is to keep a software memory equivilent to be used in hit testing.

you can keep this data in object space, and you can take your mouse coord and transform it (using similar matrixes of what you are using to display with) from screen space back to object space, and do your test there.

Share this post


Link to post
Share on other sites
Quote:
Original post by EDI
When you say you tested against every triangle.

Does this mean you locked the vertex buffer and read triangles from it?

if so, that is _very bad_ you should _never_ read data from hardware resources.

an alternative to this is to keep a software memory equivilent to be used in hit testing.

you can keep this data in object space, and you can take your mouse coord and transform it (using similar matrixes of what you are using to display with) from screen space back to object space, and do your test there.


Ok here's how I create my terrain:

1. I load heightmap (a grayscale bitmap picture) into an array
2. Then I setup traingles' xyz points in a D3D_LIT_VERTEX array
3. Create a vertex buffer from the above vertex array
4. I setup indices in an indices' array
5. Create an index buffer using the indices' array

And in 'each' frame render, I perform the following:

1. Set the vertex shader type (I use different types for different geometry thats why I have to reset it in everytime to draw terrain)
2. Set the texture for the terrain (D3DDev.SetTexture 0, t_grass)
3. If user wants the grids to appear on terrain (grids can be turned off) then I setup another texture at stage 1 ((D3DDev.SetTexture 1, t_grid)
4. Use SetStreamSource to set the vertex buffer stream
5. Set indices
6. DrawIndexedPrimitive using the indices' array as D3DPT_TRIANGLELIST

Since I have an array of vertices and indices, I use that array (not the buffers) to test if my mouse is within that triangle. I dont need to lock/unlock because Im not using the buffers.

Anyways folks, Ive spent about 1.5 yrs trying to accomplish a simple 3D terrain engine but Im not able to make any good out of it so Im planning to revert back to 2D drawing and get a good grip on it first; learn a few more tricks before I get on to 3D. [smile] Ive done some work in 2D, but only on flat terrain engine. I was making a variable-height-2D-terrain engine a few months back but got disasterious performance because my visibility-test code was not working well. I was testing each tile to check if it was visible, thats why I wanted a book which could show me a few tricks on how to implement a variable-height engine in 2D (or 3D even, but 2D just for now [smile]). Here's my 2D game:



PS. In my 3D terrain engine, you all can see that my whole terrain is drawn by a single buffer. It raises a problem, it will draw the whole terrain even if only a small part of the terrain is being viewed/infocus. So impossible to perform visibility-test here to reduce the rendering load. My terrain can be zoomed-in as well. Actually the screenshot is taken from the farthest away zoom. In the closest zoom only 16 tiles are visible (4 rows, 4 cols) and even in that the cpu/gpu is wasted by drawing the whole terrain. No idea what to do here [rolleyes]

[Edited by - itz_faraz on February 12, 2006 1:43:41 PM]

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
There is a very simple trick for mouse click detection for isometric, tile and height map based games. Determine the column where the mouse is positioned, this selects one or two strips of terrain. Then iterate through each entry in the selected column(s), from front to back and check the height of each tile. (terrain height + object height) When the mouse cursor is below the currently checked height then the tile is selected. (i count with the origo in the bottom-left corner) The front to back ordering ensures that the closest objects, that occlude others get selected first. This selection is accurate to the bounding box of the enclosed terrain and objects. A better algorithm might check the alpha map of each tile hit and on a miss continue with the next tile.

For fast tile clipping, the programmer should determine the area visible on the maximal and minimal zoom factors and interpolate between these two sizes for other zoom positions. (the general rule is if you zoom in 2x, you have to draw an erea half the width)

Viktor

Share this post


Link to post
Share on other sites
With what you explained there you should be getting very good performance, unless of course you have some very very sad hardware.

if you are indeed having bad performance feel free to post the code that does what you described and I can look it over.

Share this post


Link to post
Share on other sites
You can also post up a Test app for others to download and run. This will give you a much better idea of where you stand on different hardware and software configs.

- Jeremy

Share this post


Link to post
Share on other sites
Maybe I'm just missing something, but it sounds to me like you need to look up visibility culling, like hierarchical trees (BSP, octree, quadtree is probably most appropriate for a 2D playing field). You should probably take your vertex buffer and split it into "chunks" and use a tree to test whether or not each chunk is visible (actually, you work the other way around).

Bottom-line: do some googling on quadtrees and BSP trees.

BTW: the game looks pretty cool. Any other info on it?

Share this post


Link to post
Share on other sites
Ok .. I shall upload my code for others to test. Thank you for all your valuable advises!! I think I will also get TANSTAFL's book too.

Quote:
Original post by Simagery
BTW: the game looks pretty cool. Any other info on it?


Thats the thing, what you see in the pic is what there is :S My game became so overloaded and so heavy buy the time I came to something near that screenshot. If I can get my engine to work properly in severe conditions, I think I can come up with a good game design. Lets see.... :/

Share this post


Link to post
Share on other sites

This topic is 4320 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this