Jump to content
  • Advertisement
Sign in to follow this  
itz_faraz

Need guidance

This topic is 4692 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
Advertisement
common guys that wasnt such a hard question. just name any good book to me and also please tell me how I can order it. Thank you!

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
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!