Public Group

# 2D isometric game image help

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

## Recommended Posts

##### Share on other sites
Oh, yea.. for those wondering why the double layers on images..

I would like to allow you to make objects that truly surround a player, by drawing one image to go behind the player, then another to go in front of the player. Many objects will use one or the other layer, depending on if the object should be drawn in front of or behind the player, and some objects would use both.

The game would draw the view port from the top across the screen row by row. (note: I have yet to figgure out the algorithm for determining drawing order from each of the four view directions.)

Each spot would get the floor tile first layer drawn, then the walls on both upper surfaces (upper right, and upper left), then floor second layer (so that some floor tiles can have built in tables, for example), then object first layer, then any player present, then object second layer, then any walls on lower right and lower left of the map coordinate. I am entertaining the idea of using one wall object per map coordinate, having two layers, one being the upper two walls, and the other being the lower two walls. How these walls will work with walls on adjoining map coordinates is still unclear.)

Also, for determining which image of an object to use, by applying an image number for each image of an object, 0 - 3, and applying the same numbers for the map view directions, add current map view direction to the orientation of the object, and modulo by 4 or by the number of images the object is using, would give the correct image number to use.

See, I told you I had worked out a few details.

[Edited by - Aakanaar on October 24, 2008 11:03:03 PM]

##### Share on other sites
Quote:
 I am thinking of a 2D isometric tile game with some of the following features:1. Multiplayer online world, where people gather on various “maps” to socialize and play the game2. A map editor, to allow people to design their own maps for uploading to the server or possibly hosting on their own server for others to join.3. A basic image editor to allow making various objects, floor tiles, and walls to go into the maps, for true customization.4. A script editor to allow storing variables based on the map and on each player, provide certain animations by swapping objects, and provide interactivity to the map.

That's good. You can dream big, but you must break up the project into small bits. Accomplish each bit; then weave them together. In my opinion, the list of items should be added after you already have a simple game built.
Quote:
 Now, I have written console apps in C++ many times, but have no experience working with windows GUI, or with Direct X. (I had always thought Direct X was for 3D, and that other routines were used in 2D games. From the information I’ve found on this site and others, I believe that to be a bad assumption now.) As such, I have no idea how to properly store this information in the files (I have heard bitmaps are written to file in reverse order?) and how to use that info to build the images in memory so that they can be blitted to the screen.

You can make 2D games in DirectX or OpenGL, but you can also use a 2D API that is much simpler to use. Examples of this include Allegro, SDL, or SFML. I strongly suggest making a basic 2D game first using one of the simpler APIs. If you code things nicely you can always upgrade.

For example, I wrote a 2D scrolling engine in python\pygame. I then rewrote the engine in C++ with SDL. Now I changed it to SDL with OpenGL. The point is that it is not that hard to "upgrade" to a better or more robust API later (other than the fact that you need to learn the more complex API). You just change which functions you call for graphics, but most of the underlying game mechanic code will not change.

So that is why I advise going with a simpler API first and just blit things to the screen. You asked about bitmap images. Basically, these are the building blocks for the graphical portion of the game. Usually you blit in reverse order: Blit the background first, then the middle, then the foreground.

To take the simple example of pacman:
1. Blit the maze.
2. Blit the pellets.
3. Blit the ghosts.
4. Blit Pacman.

If you already know all this you can move on, but if you've never made a simple 2D game you need to. The point is try to make a simple zelda-clone before you make the game you really want. Sorry there is no substitute for experience.

##### Share on other sites
Ok.. well I am using Bloodshed C++, with Rededit for resource files, and MingW compiler (came with Bloodshed). I think Allegro is for DJGPP, I've heard of SDL in passing (am looking the site over more carefully now), and have never heard of SFML..

Which library would you recommend to use with Bloodshed?

And, again it is important to me to see this dream become a reality, so while I can code much of the non-graphical parts, would it be worth my time to try to document all the features and make an account on source forge or some other site to attract other programmers to help? Or would it be better to just put the idea back onto the back burner, to sit another two or three years while I try to get the experience needed?

I am thinking of just trying to do this project step by step, by starting with the object editor, first getting a pcx file that would be the main window to show, then adding in the buttons and other stuff, and the basic image editing controls and functionality.. and hopefully if I can tackle all of that, then be ready to start learning to work with the images in memory and saving them to a file using my own format.

Once I tackle that bit, then making the map editor next would allow me to learn how to work with tiling the images, and using offsets to make sure the images line up correctly.. and a walk around mode for testing.

Then I can start working on the server and client aspect, making it an actual game, then start adding in the scripting ability and script editor.

Each of these steps are ordered to allow me to start with basic steps and build onto each step, in what appears to me to be a progressive order from simple tasks to the more complex tasks. I hope.

##### Share on other sites
Quote:
 Ok.. well I am using Bloodshed C++, with Rededit for resource files, and MingW compiler (came with Bloodshed). I think Allegro is for DJGPP, I've heard of SDL in passing (am looking the site over more carefully now), and have never heard of SFML..

Most people around here recommend either Code::Blocks or MSVC++ since Dev-C++ is no longer supported or actively developed. The 2D libraries that I listed can be used with Dev-C++, Code::Blocks, or MSVC++.

I would recommend SDL since that is what I use. I also use Code::Blocks. In any case if you decide to go the SDL route there is an awesome site for tutorials and how to set it up under pretty much any IDE: Lazy Foo Tutorials. Lesson #1 tells you how to set it up.
Quote:
 And, again it is important to me to see this dream become a reality, so while I can code much of the non-graphical parts, would it be worth my time to try to document all the features and make an account on source forge or some other site to attract other programmers to help? Or would it be better to just put the idea back onto the back burner, to sit another two or three years while I try to get the experience needed?

I don't know the answer to yr question. I think the best way to get help is to get the project going and establish that you are committed to it. Then more people may be willing to join the cause. Also, there is a help wanted forum here that you can solicit help.
Quote:
 I am thinking of just trying to do this project step by step

That is definitely the way to go. To give you a basic example: for one of my early projects I wanted to make donkey kong. First, I just blitted the background. Then I blitted mario to the screen. Then I acquired user input to move mario, then I animated mario, etc, etc. The basic gist is to keep building with small blocks, adding more features and content and functionality.

Also, have you read the Isometric & tile-based game resources for gameDev? If not you should check them out: go up top to resources, then click articles. Scroll to isometric. There is some good info there.

##### Share on other sites
Quote:
 Original post by AakanaarIf the proper use is as it used to be, which is to blit an alpha mask to the surface first, then blit the image, then when reading the file and creating the image objects in the memory, I would just use the RGB values to create the image and the A to create the alpha mask as a separate image. (Note that this has once again doubled the number of images needed for an object.)

There are very few, if any, modern graphics APIs that still require the old-fashioned method of mask-AND-background, image-OR-background.

If you use D3D or OGL (or any API that uses these under the hood), you'll have hardware support for per-pixel alphablending. Even GDI has support for per-pixel alpha now.

In terms of your custom file format, all sounds perfectly plausible to me. I use a similar system for creating my sprite files - the format supports having multiple images in a single file, stored as RGBA bytes - and has worked out well.

1. 1
2. 2
Rutin
23
3. 3
JoeJ
20
4. 4
5. 5

• 28
• 40
• 23
• 13
• 13
• ### Forum Statistics

• Total Topics
631737
• Total Posts
3001945
×