VB.Net - DX9/DirectDraw - Isometric Binary Tile arrays..

[nem33]

The more I search, the more lost I become.
I am brand spanking new to Direct X of any kind.
I have a couple questions I can not find any answers to..
1.) DirectDraw is still technically DirectDraw7? Examples I find in DD7 would apply to DX9 DirectDraw?
2.) Im currently working on a *gasp* isometric RPG....that sounds so...generic. Anyway..Reading some tutorials for DD on map tiling and such..I read that using a simple 2D array and a plain ol .txt file 'could' work for storing map/tile data...But the tutorial says using that method would limit me to only 9 or so different kinds of tiles. The best way...it said..was to store map data in a binary file and load bits of data into the array in the program vs. loading simple tile identity numbers.."1 for water..2 for dirt..etc." The text file I can do..but binary?? How exactly would this work? I'm not asking for someone to write my code for me..but the lack of examples is frightening.
3.) All amateur game programmers seem to have written a tile scrolling rpg at some point..But not once have I seen a true isometric example. Take Ultima Online for instance..Predrawn( I think) diamond shaped 32x32 tiles...Then you have the buildings and such. These buildings allow the character sprite to move behind them. Using DirectDraw, is this just another surface blitted on top of the base tile surface? If so would I create a seperate binary map file for storing the locations of these 'buildings' taking a 'z' coordinate into consideration (to allow artifical height)
4.) Ive seen two different methods for drawing animated sprites in DirectDraw. First method is to create a bitmap with all your frames of animation drawn. Load the entire BMP into memory and tell DX to draw every 100ms, (ala stupid timer) ,a different rectangle on that bitmap. Seems to work okay, but timers are evil. The 2nd method I've seen is to have seperate bitmaps for each frame of animation, then load all those bitmaps into an array, then create a loop to shoot through the array. Which method is faster/better?

I've been studying DirectX9 for about a week now and I can create a fixed centerscreen sprite (animated) and have it follow the mouse in 4 different directions using a predrawn bitmap to simulate a running character (animated only on right click down). Next goal is to now create the scrolling tile map complete with 'raised' buildings. Another question I have deals with strecthing a tile. Flat tiles are okay for grassy plains or whatever, but what about mountains/rugged terrain? It seems, in games I've seen, They use a texture map of some kind and stretch the textures over......over what I don't know..completely lost on that one.
Anyway..Im a newbie, but I learn fast. I might be jumping into things far too advanced for my level of experience, but that's the best way to learn imo. Any help is super appreciated, I can find no good examples on the net. Any help here could be extremely benificial to anyone researching this topic. (and there seem to be alot of em) I plan to write a completely in depth tutorial directly relating to DX9 and VB.NET when I become confident in my code enough to do so, as there seems to be a need for such a guide. Thank you in advance.
-J

 

[Nerseus]

1. Yes, DirectDraw in DX9 is the "same" as it was in DX7. While you'll obviously have to port the code from VB6 to VB.NET, the DX functions names should *mostly* be the same.
2. There are MANY ways to store map data. If you wanted to easily load and save a map, I'd stick with plain text for now. The idea of using numbers to represent tiles can easily be extended to include letters. For example:

Map File - assume 1 is a wall, 2 is grass:
111111
122221
121121
122221
111111

From the above, you could easily use a combination of letters AND numbers - between lower/upper case and digits, you would have (quick math in head...) 62 tile types. If you went with binary you could get 255 but it's more of a headache for this early stage of your game. If you design it right, loading a map should have no impact on the game. Meaning, you can easily change how map files are stored/loaded without affecting everything else in the game.
3. There's at least one book that covers isometric programming. I would guess that you would need some extra "z" type information stored with each tile in order to know when to draw it (in front of a player or not). For the record, amateur programmers don't start with an RPG - they start with Tic-Tac-Toe or Connect Four, then move on to a card game (maybe blackjack), then a simple 2D game like pacman, then move onto more difficult projects. Well, I should say smart amateur programmers don't jump right into an RPG
4. Why is everyone worried about faster all the time? Anyway... I would use whatever is easier to understand for now. If that means a timer, then use one. If you've already got the know-how to create a game loop inside of an event-driven programming model (like .NET), then you can use your own timing-based code to animate the sprites.
Regardless of whether you choose a timer or if you have a game loop that gets the elapsed time, I'd suggest using one bitmap with all the images. Just my preference - using separate bitmaps won't have much affect on performance unless you load every single tile as a separate DirectDraw surface (that could consume extra memory - but only potentially).

<mindless_blather, only read/pay attention if you want>
Since you're just beginning, I'd make the following suggestion:
Do NOT confuse your sample code with a game.
Keep your samples simple - you've got one that loads a sprite and has it move on a right click. Don't think you can expand on that program to add tiles, then add score, then add a "player" class, etc. etc. and you'll eventually end up with a game. A game is MUCH more work than it first seems and it's better to start with a good idea of what data needs to be stored, in what objects, etc. Once you've got the samples working right, start a new project and design your game - you can always copy code snippets that work into the final game. But if you just keep expanding on one program, you're bound to end up re-writing a LOT more than if you'd just started fresh.
</mindless_blather>

-Nerseus

 

[steved]

Gotta agree with Ner on this: Take your time, explore things in small chunks, and throw away code.

Your first experiences with DirectX will be like a poet's first scribbles - almost everything you write is written purely for the trash.

It's a hard thing to swallow sometimes, believe me. In high school (grade 10) I wrote a massive -and disgusting- online RPG in VB6/Dx5 (using Type Libraries, long before DirectX ever had VB support). It turned out to be a huge, unmanagable mess. But one I remember fondly, of course.

Seriously, though. If you're not interested in writing Pac-man and Tetris, I don't blame you. But be perfectly willing to throw out everything you've done and start clean every once in a while.

.steve

 

[nem33]

I agree with not jumping into an rpg right away. I have done the pacman/tetris thing but that was all using bitblip. Maybe I should make a pacman game in DX? =) I hadn't planned on using the code I have now for the actual game. I throw away more code than I keep.
I make small examples of every aspect of the eventual game I want to create. Then when done I review the code from start to finish and take what Ive learned to start the main project.
I've got a couple guys coding with me and learning on this as of today. Eventually it would be great to do a project. Although I may be of more help in the graphics and music dept than coding. =) Thanks for the replies..I understand most of wha I was asking now.

 

[steved]

If you have the patience to write a PacMan-style game in DirectX, I would highly recommend it before you move on. Programming in DirectDraw means programming more RECTs and calls to BltFast than you could ever possibly want.

I found that doing stuff in DirectDraw led me to writing a bunch of wrappers that simplified most DDraw functions. Since you started with GDI, you may find yourself in the same boat.

Good luck.

.steve

PS: You should post your progress once you think it to be publishable! We'd love to see it.