Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

2D All the way! / [STICKY] 2D Principles with DB/DBpro Tutorial Part I

Author
Message
zenassem
14
Years of Service
User Offline
Joined: 10th Mar 2003
Location: Long Island, NY
Posted: 25th Jun 2004 21:54 Edited at: 18th Jul 2004 03:19
Preface
I am starting this thread in my hopes of bringing together the knowledge I have assembled on working with 2D and DarkBasic / & DarkBasic Pro. The methods I plan to include have come to me from various sources including my own observations/experience and the overwhelming willingness of others in the community to share their knowledge and insights with me.

My main goal, is to help users understand how to implement 2D game making with DarkBasic Pro (I'll try to provide DBC code as time allows). Getting 2D code to work properly under Dbpro can be quite confusing and sometimes frustrating. Over the recent months, and perhaps since I have joined, I have seen the same requests for help with regard to 2D: images, sprites, animation, syncing, refresh, tile-maps, transparency, bitmap vs images, game loops, Iso-tiles, platformers, arrays etc. While I fully understand that no one thread can answer all questions, I think that it would be helpful to have a thread that can get people going in the right direction.

The challenge that I have is keeping the code straight-forward enough to be helpful newcomers while avoiding being flamed and appeasing veterans. I would just like to preface by saying that the early parts of the tutorials are designed for beginners. While my tutorial may employ methods that aren't always advanced, keep in mind my original goal. As the threads progress I will eventually move towards more advanced and optimized methods. Eventually I will turn the discoveries and discussions in these threads into full tutorials.

In addition, I'm not an expert on everything DBpro can do, nor am I an expert on 2D theories. My solutions and examples aren't going to be the only solutions nor will they be the best possible solutions. I have certain ways I feel comfortable doing things, and have gone down many dead-ends in my pursuit to understand 2D in DBpro. I think that some of my experiences will help others. I'm always open to suggestions, and I will not take offense to someone disagreeing with my examples. But please don't just post in here to be rude or cut me down. If you have a comment or suggestion post it. It may be helpful. After that let it be, you can always e-mail me if you have to. I just don't want to have the whole thread be an argument over what is the right way to do something. Again keep in mind, that in the beginning I will be trying to make the code as understandable and hassle free as possible, and focus on the principles. In the later parts I will focus more on better techniques and implementation.

Well that concludes the introduction. I'll post the beginning of the tutorial in this thread tonight.

Thanks,
Zenssem


zenassem
14
Years of Service
User Offline
Joined: 10th Mar 2003
Location: Long Island, NY
Posted: 26th Jun 2004 02:07 Edited at: 5th Jul 2004 15:46
Well, It's been very difficult to post the last two days. And I'll edit the post above (garbled text) when things pick up.

Here is a template for our 2D game setup. Many of the examples will be built upon this. I find it to be very reliable.

+ Code Snippet

I will provide a more in depth of the template in the first example.


megamanx
13
Years of Service
User Offline
Joined: 17th Jun 2004
Location: Kentucky, USA
Posted: 26th Jun 2004 02:29
oooh, good stuff ^_^

I'll be looking forward to part 2. I've been toying around and I think I finally figured out how to create a side-scrolling tile map which is effecient but I have yet to figure out how I'm going to do the collision detection and all that juicy stuff
zenassem
14
Years of Service
User Offline
Joined: 10th Mar 2003
Location: Long Island, NY
Posted: 26th Jun 2004 02:51
I'm going to be covering that in part I. You might want to contribute something when I get to that point, It would greatly be appreciated.

Part I is going to cover all the topics (and more)that I outlined above.

Part II will then take the code and optimize it, enhance the coding structure, add more complex types, as well as advanced movement, collision etc... as well as remove some of the uneccessary steps that make the code easier to read but slower to execute.

The idea is that there will be 3 separate threads each with it's own parts. This way people want have to go through all the posts for 2d principles if they are looking for code on ISOhex. Eventually I will pull all the info together, and create a .pdf tutorial from the threads.


megamanx
13
Years of Service
User Offline
Joined: 17th Jun 2004
Location: Kentucky, USA
Posted: 26th Jun 2004 03:53
Alrighty, sounds good. I don't know if I'll be able to contribute since I haven't gotten past the theoretics of the tiling engine yet. I'll be looking forward to how you implement yours, you have more experience with 2D game making than I do.

My current project is a site called Dark Basic Resource, feel free to read about my progress and give suggestions/feedback. Perhaps when you are done with this mega 2D tutorial I could put it up on the site with credit going to you and a link to your website (if applicable). I think it would be a good addition to the site. I might rewrite a little bit of it (such as optimizing it for search engines and making it more understandable if it's needed), so don't get freaked out if it has been changed slightly
zenassem
14
Years of Service
User Offline
Joined: 10th Mar 2003
Location: Long Island, NY
Posted: 28th Jun 2004 04:36 Edited at: 18th Jul 2004 03:42
[Edit 7/13/04]
- Made some corrections pointed out by IanM
- Reorganizing index
- Fixed some typo's

Chapter 1
Index

Bitmaps, Images, & Sprites Oh My!

First Introduction to sprites (No not the Fairy kind!)

On To Arrays

User Defined Types (First Visit)

Some Last Minute Things To Tie-UP

=====================================================================

CHAPTER I

Bitmaps, Images, & Sprites Oh my!

Working with sprites in DBpro is not always as easy as one might expect. Sprite issues are a popular topic in the 2D board. Hopefully, I can address some of the most common problems programmers face; including (load image vs. load bitmap, The Blue Backdrop, backsave, sprite priority, transparency, movement, animation and more).

First I would like to discuss the Load Image and Load Bitmap commands.

Load Image vs. Load Bitmap

I recommend using the Load Image command when developing sprite frames, items in 2D games. I tend to use Load Bitmap for loading, menu screens, textures, and other resources for 3D environments. Try fininding the method that works best for you. You will see me use both commands in this tutorial.

The Load Image command contains an additional optional parameter (Not documented in my reference manual, but mentioned in the html help) that allows mip-mapping to be turned off, by adding a ,1 after the imgnum parameter . This is the syntax we will use for loading images:

Load Image filename, imgnum, 1

I would recommend creating a [media] folder inside your project folder & having a copy of your media reside there.

Grabbing portions of a loaded image
It is important to mention that, unlike the Load Bitmap command, the Load Image command does not automatically become the current bitmap. Therefore, if we need to grab a portion of the loaded image we must paste it first by using the Paste Image command and grab the portion we need using the Get Image command. The Paste Image command has the following syntax:

Paste Image imgnum, x, y, transparency

If the optional transparency flag is set to 1: all colored pixel rgb(0,0,0) (by default) will not be drawn. In {DBPRO} You can change the transparent color by using the command Set Image Colorkey red value,green value, blue value . I usually use either (0,255,0) a bright green or (255,0,255) a bright pink rather than the default black for transparency. It is important to note that the Set Image Colorkey should appear before any Load Image commands. I recommend placing this near the top of your code

The Get Image command has the following syntax:

Get Image imgnum, left, top, right, bottom, texture flag

The Get Image command also has an optional texture flag. (This is not Documented in the reference manual, but is mentioned in the html help.) The help states that setting the texture flag to 1, prevents the image from being stretched and ensures a pure grab of the image. I have also found that setting the flag to 1 ensures that any transparent pixels remain transparent.

After we are done with the original loaded image, we will want to free up the resource by using the Delete Image command

Delete Image imgnum

Other things of note:
I have seen issues occur if you try to load images larger than the current screen size. I try to avoid this as much as possible. The first few examples will not include any type of error checking, later on we will make sure implement code to make sure images exist, display modes available etc...

Here is the code added to our template to sum up loading images & grabbing images. In the next section we will focus on image formats (.bmp, .jpeg, .png, .tga ...)as well as grabbing multiple frames for a sprites. We will then look at the sprite command set , and methods for control animation, & timing. We will also look at arrays, multi-dimensional arrays, & user defined types.
+ Code Snippet[i][/i]


zenassem
14
Years of Service
User Offline
Joined: 10th Mar 2003
Location: Long Island, NY
Posted: 3rd Jul 2004 09:12 Edited at: 5th Jul 2004 15:51
Just In case anyone was wondering. I am going to be contributing more to this thread over the next couple of days. I've been working on a multi-layer tile-map editor "Tile~Forge", that I will be using as the first example of implementing the 2D commands and arrays. It will serve a double purpose. First, I will provide the code as an example in the tutorial, and second it can be used to create maps for 2D games that we will use throughout this tutorial and the 2D tile-map tutorial.

Here is a small scaled Screenshot of Tile~Forge




<The scaled image doesn't show the grid properly>

Tool creation, is a topic that I do not see discussed as much with DB as I have seen in other languages. I believe the reason has something to do with the fact that it's easier to get to the actual game programming faster in DB than say setting up your own engine in C++. This is a good thing, but sometimes it leads people to try to hard-code their games rather than spending time developing tools to make the creation process easier, and also make enhancements, sequels, modifications. There is a lot that can be learned from creating your own tools, especially when working with 2D, and a lot of the code that you use in your dev tools can be used in the actual game design. And b y writing your own tools, you get the functionality that you need rather than trying to learn someone elses program. I will attempt to show how to write a simple tilemap creator, and a sprite animation tool.

~zen


SpecTre1
14
Years of Service
User Offline
Joined: 24th Feb 2003
Location: United Kingdom
Posted: 4th Jul 2004 09:31
Well done Zen, this looks like just what I need, a good tutorial to make a 2D game!!

Looks like you have thought of everything including a map editor, very cool!!!!

Would you also be able to give us a download address of where we can get all the graphic files etc for us to use with the tutorial?

Look forward to your next instalment!

Spec

New to DBPro comin from AMOS on the Amiga!
SpecTre1
14
Years of Service
User Offline
Joined: 24th Feb 2003
Location: United Kingdom
Posted: 4th Jul 2004 09:34
Oh also could someone please make this sticky as I think this is going to be really useful being done in DBPro as others tutorials are based toward DBC, would be great if someone could do that!

Thanks

New to DBPro comin from AMOS on the Amiga!
zenassem
14
Years of Service
User Offline
Joined: 10th Mar 2003
Location: Long Island, NY
Posted: 4th Jul 2004 09:52 Edited at: 4th Jul 2004 10:26
Thanks Spectre,
Yeah I will be providing a link for all and any media that I use. Right now I wil have to clear it with TGC as i am using a lot of their tiles from T.G.C. in the mock-up. If I am not allowed to distribute the media from their I will have to change take out that media and replace it, DBpro doesn't come with as much media as DBC came with. You will also be able to add in your own tiles as well. The first version of the mapEditor will use 32*32 tiles, later versions will include the abiltity to change tile/grid sizes.

What I think will be interesting is I will be improving the Map-Editor while providing the code, so anyone following will be able to see the source code change as it grows in functionality. So the code will be used to showcase the tutorial lessons, as well as the actual product can be used to build 2d tilemap levels for other games.

As an example here is the rough-code I used to start the map-editor obviously a lot of it is just temporary to make sure things work. I'll start removing some of the hard-coded stuff and reading settings from .dat/.ini files down the road.

+ Code Snippet


Rknight
13
Years of Service
User Offline
Joined: 25th Sep 2003
Location: NJ
Posted: 4th Jul 2004 10:19
Ah. Thank you for this tutorial. I'm sure it's very informative for everyone wanting to learn a little more about the subject.

I'll be looking into the provided code soon.
zenassem
14
Years of Service
User Offline
Joined: 10th Mar 2003
Location: Long Island, NY
Posted: 4th Jul 2004 10:52 Edited at: 6th Jul 2004 15:09
Topics to be discussed:
Sprite command
Arrays & Multidimensional arrays
A simple user-defines type example
“Tile~Forge” simple Map Editor


Sprites: (No, not the fairy kind!)
Sprites are a very important part of 2D programming. Simply explained, a sprite is usually a rectangular image that has a transparent color that doesn’t show when blitting the image to the display. Sprites don’t have to have transparency and can be used as a large bitmap if one chooses, but generally when referring to sprites my first simple explanation is what we are apeaking of.

In DBpro (as well as with DirectX 8+) sprites are actually rendered as flat 3D plains. This allows sprites to take advantage of acceleration from 3D graphics cards. This is an advantage to DBpro users, but it does add some elements that can lead to confusion for DBpro programmers. In DBpro when you use the sprite command you are initiating the 3D display, hence you may notice the blue backdrop that appears. This happens regardless of whether or not you have backdrop off at the beginning of your code. The method that I use to rid myself of the blue backdrop is to call cls or cls 0 at the beginning of my loop. This means I have to be sure to redraw everything on the screen each loop. This may sound daunting but it’s actually the best way to handle things IMHO. It also offers us another advantage. Since we are clearing the screen and redrawing it every iteration of the loop, we can eliminate the need to have backsave enabled for our sprites. Backsave on, basically allows dbpro to redraw the pixels that were covered by our sprite when the sprite moves. Though it’s a nice feature, it causes slowdown. I have received better results by setting the backsave to off and handling redrawing the display each refresh.

So lets create a sprite. Our first sprite will be a precise cursor (like those used in drawing applications) , we will then replace the standard mouse cursor with our new image. Here is the image I drew up. You can save this to your project folder if you would like to try out the code snippet that we will be building. Save it as Cursor.bmp or something similar.

figure 1.1


The bright pink color is the transparent color will be using for our sprites and images. It’s rgb value is 255,0,255. So here’s the small code snippet. I’m not going to make a big deal about sprites at this point, we’ll revisit them in depth later when we actually create an animated character. For now I just want to make sure that people who have never used sprites understand what they are.

+ Code Snippet

On to the Arrays!


SpecTre1
14
Years of Service
User Offline
Joined: 24th Feb 2003
Location: United Kingdom
Posted: 4th Jul 2004 22:03
Very good m8 Keep it coming

Someone please make this sticky!

New to DBPro comin from AMOS on the Amiga!
IanM
Moderator
14
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 4th Jul 2004 23:51
Your wish is my command.

I also have some additions and corrections to what has been stated so far


LOAD BITMAP:

Does exactly what it says. It does not apply mipmapping. That is usually applied while grabbing the image using the GET IMAGE command, and can be disabled by adding an extra ,1 to that command.

The reasons to use LOAD IMAGE directly rather than LOAD BITMAP/GET IMAGE are:
- Speed. One command rather than two.
- Ease. Even if loading a multi-image bitmap, you can set it up as an animated sprite rather than split it up into separate images.

In addition, for image types that have built-in transparency (PNG and TGA) the transparency layer is lost when loading to a bitmap, but retained when loading to an image.

GET IMAGE/LOAD IMAGE texture flag:

The extra flag for each of these commands is the 'texture' flag. When not set, the image is assumed to be a texture, and is stretched to fix a power of 2 square image (eg, 24x24 would strect to 32x32). It also causes a set of mipmaps to be generated for the image. This stretching is applied to all parts of the image including transparency, causing some strange effects.

When the flag is set to 1, the image is loaded unchanged, with no stretching taking place and no mipmaps being generated.

Image Sizes:

Graphics cards are limited in the types of images they can hold. You should assume that they have the following restrictions on images, and code accordingly:

1 - Images are square. Some cards allow rectangular images, but they are rare.
2 - Sizes are powers of 2 (1/2/4/8/16/32/64/128/256/512/1024/2048 etc). When you load an image that are not these sizes, the image size is rounded up to the next power of 2, even if you use the texture flag detailed above.
3 - They have a maximum allowable size. My laptop has a maximum size of 1024/1024, while my desktop has a maximum size of 4096x4096. Some slightly older machines have a lower limit.

Getting rid of the Blue screen with sprites:

Using the SET SPRITE command to disable the backsave option on a single sprite disables backsave for all sprites and also disables the blue screen. I use this function to set things up

+ Code Snippet

This does mean that you need to clear the display yourself to remove old sprites from the display.

*** Coming soon - Network Plug-in - Check my site for info ***
For free Plug-ins, source and the Interface library for Visual C++ 6, .NET and now for Dev-C++ http://www.matrix1.demon.co.uk
zenassem
14
Years of Service
User Offline
Joined: 10th Mar 2003
Location: Long Island, NY
Posted: 5th Jul 2004 00:07 Edited at: 6th Jul 2004 15:08
Whoever made this a "sticky" thank-you. And thanks Spectre for the nice feedback.
[edit] Thanks IanM, especially for the corrections. I appreciate it.

Ok, on to arrays
So what is an array? An array is a collection of variables of the same type and name, ordered sequentially in memory. Arrays are very useful for all sorts of things, from look-up tables to bitmaps; you will use arrays throughout your games. (~Andre Lamothe)

Lets say for instance you were writing a program that would calculate the average of test grades for a certain marking period. Lets also assume that the grades need to be stored so that you can call up each individual grade as well. So, here is how one might store the grades in a program without using an array.

grade1#=95.0
grade2#=100.0
grade3#=75.0
grade4#=87.0
grade5#=92.0


Now notice that I used 5 seperate variables. This method would be ok if the ammount of grades to be processed were small. But think about the possibility that there were 20 grades, 80 grades, 200 grades...
If I needed to print out each grade I would have to do something like

print grade1#
print grade2#
print grade3#

etc...

There has to be a better way. That's where arrays come in. Rather than naming seperate variables with numbers, arrays use indexes. This allows us to process them in a loop, and helps us to sort and search and do many other useful things. So great! But how do we use an array?

The first thing we need to do is dimension the array. Dimensioning lets the program know how much memory should be allocated for the array. So, for our example lets say that we need to store 10 grades. We would dimension our array by typing the following:

dim grades#(9)

"9" why 9? Well the answer is DB starts arrays at 0 and allocates space up to n where n is <dim array(n)>. So if you include 0-9 that is 10 elements that can be stored. Which is what we needed for our example. So now we have 10 slots for floats in an array named grades. So, how do we assign values to the 10 slots?

grades#(0)=95.0
grades#(1)=100.0
grades#(2)=75.0
grades#(3)=87.0
grades#(4)=92.0

etc...

Now you might be thinking, "Isn't that the same thing as using 10 different variable names?". No, not exactly. First let me show you how we can now print out these grades using a loop:

for index=0 to 9
print grades#(index)
next index


A much better method! Especially if we needed to print out, say... 100 grades, or 1000 grades (Feel bad for the individual who has that teacher!)

We can also do the same thing to initialize array elements. "What is initialization?" Well it's something that many of us who program in other languages are acustomed to. I'm not sure about DB, but in say C++ for instance, when you create an array you aren't guaranteed that each element is automatically equaled to 0. In fact, it could be anything -100, 32, 500... It all depends on what was in that memory area. So, just to be on the safe side as we would never want an element in our grade program to have an entry of -100 (unless you did really bad) we will want to make sure that all entries begin starting at 0 or for grades to -1 (I'll explain why -1 is best for our example). This will help us to process all the grades that were validly entered. Since we never expect to see a -1 as an actual grade, if we do come across it we can safely assume that the previous grade was the last actual grade entered. So lets initialize our grade array:


for index=0 to 9
grades#(index)=-1
next index


Figure 1.2 Here is a graphic to help understand what the array would look like, if we initialized it first and then used the code above to set some of the element values...


{note: I used floats because I was talking about grades & averages. I'll have to check whether or not the value of -1 will actually be -1 or -1.0 or -1.00. Give me a moment and I'll make sure it's accurate}

So lets see how the -1 could be used to determine how many grades were entered, add them, and finally divide them by the number of grades to get the average.

index=0
while grades#(index)>-1
average#=average#+grades#(index)
inc index
loop
if index>1
average#=average#/(index-1)
endif

if index=1
average#=grades#(0)
endif

if index=0
averge#=0
endif






Next, we'll discuss Multi-Dimensional arrays and how to read in values from data statements.


SpecTre1
14
Years of Service
User Offline
Joined: 24th Feb 2003
Location: United Kingdom
Posted: 5th Jul 2004 00:23
Thanks IanM my m8

New to DBPro comin from AMOS on the Amiga!
zenassem
14
Years of Service
User Offline
Joined: 10th Mar 2003
Location: Long Island, NY
Posted: 5th Jul 2004 02:59 Edited at: 5th Jul 2004 11:07
Ok we are getting close to where I can actually begin to use some of this info and discuss the map-maker. Just a little more info on arrays, types, and data statements should be enought to get us to a more intersting discussion, while not leaving anyone behind.

Multi-Dimesional Arrays (2 dimensions)

Ok, so now that we pretty much have 1-dimensional arrays down we now need to look at a 2-dimensional array, and finally a 3-dimensional array. Sticking with our grades#() example, let's see how we could enhace it with a 2-dimensional array. first of all a 2-dimensional array is dimensioned with the following syntax, for our purposes I am going to make the array typed as integers rather than floats, so stay with me. It will make the discussion easier to understand, and we want to get to a point where the array is used to tile-based games (I mean, who really cares about G.P.A.'s anyway).

dim grades(xelements,yelements)

Why would I use a 2-Dimensional array? Well let's imagine that we not only want to keep a list of grades, but lets say we would also like to keep each quarter (marking period) seperate. Lets further say that we will have 5 grades (xelements) and 4 marking periods (yelements). For this example we would dimension the array as follows...

dim grades(4,3)

note: keep in mind that arrays start at 0 and continue to & include the numder we have in our dim statement. So Dim grades(4,3) acually gives us 5 xelements(0-4) and 4(y-elements) 0-3. Also, it's important to note that we could have just as easily dimensioned the array as dim grades(3,4): We would just have to reverse the way we index and store values. I prefer to look at the dimensions as x,y, because it follows other commands ordering and it makes more sense to me, especially when adding other dimensions.

So now instead of dealing with a single column and one index, we now have columns & rows each with their own index. The possible indexes (elements) for our array are:

grade(0,0) grade(0,2)
grade(1,0) grade(1,2)
grade(2,0) grade(2,2)
grade(3,0) grade(3,2)
grade(4,0) grade(4,2)
grade(0,1) grade(0,3)
grade(1,1) grade(1,3)
grade(2,1) grade(2,3)
grade(3,1) grade(3,3)
grade(4,1) grade(4,3)

I feel that a graphical figure is in order here.

figure 1.3 (2D array)


So in all we have 20 elements. You may have noticed that if we multiply xelements+1*yelements+1=3+1*4+1=20. (we need to ad + 1 because DB counts from 0 to and including the number in the dim statement)

That's how you can determine how many elements are available in a multi-dimensional arrauy. We'll get to 3-dimensional arrays, but just a foreshadow how many elements would there be in a array(3,4,2)?

60 is correct. Just multiply the dimensions number of elements in an array(x,y,z)=(x+1)*(y+1)*(Z+1)=(3+1)*(4+1)*(2+1)=4*5*3=60

How to index a 2D Array
Alright, moving right along... It should come as no surprise that to index elements in a 2D array we will need to have 2 indexes (is indexes or indecies? bah, who cares I'll stay with indexes). 1 indexX and 1 indexY. These will need to be in a nested loop (one loop inside the other.) if we plan on filling our x values first then our y values we will have to be sure to put the indexX loop inside the indexY loop like so (here we are initializing all elements to 0:

for indexY=0 to 3
for indexX=0 to 4
array(indexX,indexY)=0
next indexX
next indexY


if we stepped through the loop and watched the values it would look like this
1st iteration (iteration= Time through the loop)
indexX=0 indexY=0
2nd iteration
indexX=1 indexY=0
3rd iteration
indexX=2 indexY=0
4th iteration
indexX=3 indexY=0
5th iteration
indexX=4 indexY=0
6th iteration
indexX=0 indexY=1
7th iteration
indexX=1 indexY=1
...
20th iteration
indexX=4 indexY=3
then the loop ends and we continue on with our program...


3Dimensional arrays
Now we are getting somewhere. You can picture 3-dimensional arrays like a stack of 2-dimensional arrays. Like boxes stacked in cube. Though, you can get to any boxes contents without haveing to move any other boxes. the third dimension is how many rows (how high) is the stack of boxes. array(x,y,z). So if we were to dimensions a 3-dimensional array like

dim array(3,3,3)

you can picture a stack of boxes 4-long X 4-wide X 4-high. I'll provide a figure.

As you probably guessed we will need three indexes to index our 3-dimensional array. Again, staying with our grade example, how can we use the 3rd dimension of the array. Well lets see. The first dimension was grades on tests, the second dimension was for the quarterly marking period, so the third dimenasion can represent individual students. lets say we have 25 students in the class, each takes 5 tests, in each of 4 marking periods. Each student will have an assigned number from 0 to 24. So here is the array to store all the info. (Again rememeber I changed to integers, to keep the discussion simplified)

dim grades(4,3,24)

To index into the 3-dimensional array we will need to nest the two loops from the 2-dimensional array inside our third loop. So grades(x,y,z) is initialized as follows:

for indexZ=0 to 24
for indexY=0 to 3
for indexX=0 to 4
grades(indexX,indexY,indexZ)=0
next indexX
next indexY
next indexZ


how many elements are in this 3-dimensional array?



well (4+1)*(3+1)*(24+1) = 5*4*25 = 500
So the answer would be 500 elements.


SpecTre1
14
Years of Service
User Offline
Joined: 24th Feb 2003
Location: United Kingdom
Posted: 5th Jul 2004 05:29
This is really doing me good and think will answer my thread for the frogger game,
http://forum.thegamecreators.com/?m=forum_view&t=34449&b=7
might even get on to doin a platform or commando type game! Oh the possiblities!!!

Coding time!!!

New to DBPro comin from AMOS on the Amiga!
zenassem
14
Years of Service
User Offline
Joined: 10th Mar 2003
Location: Long Island, NY
Posted: 5th Jul 2004 11:33 Edited at: 18th Jul 2004 03:32
[edit 7/16/04]
-Added a description on Why build tile based worlds

Spectre, If it would help later on I might make frogger the example game that we will create after disecting how to build our mapmaker, I could also create a commando style game. Let me know if you would like that.

User Defined Types
User defined types are very useful. I will touch upon them here and we will revisit them during the platform game developement portion. I just feel it is necessary to mention them briefly here because I use them in the mapmaker. The main strength of user defined types is that it gives us an abilityt to group variables together. The second stron point is, that we know arrays can only store the same 'type' of data, for example all ints, all floats, all strings; but waht if we need to have an array that contains ints and floats. Well we can create a user defined type that has an int variable and a float variable, and have an array of that user type. I'll show an example of this later on. For now lets just see how a basic user type is defined and used.

In the mapmake program I have buttons for the GUI. To have the buttons respond to clicks I need to check if the mousepointer is over the button. So, I define a type called rect that has four integer variables, one for the top-left-X coordinate, 1 for the top-left-Y coordinate, 1 for the Bottom-right-X coordinate, and 1 for the bottom-right-Y coordinate. I then creat variables of this type for each button on my GUI. So let's see how to define and use our own types so that we can move on to the fun stuff. Geez! I thought we'd never get there!

User Define Type Decleration

type rect
tlx
tly
brx
bry
endtype


note: because i didn't specify the type of the variables (tlx,tly,brx,bry) the compiler assumes them to be ints.

So that's all there is to the definition. Now we can use this type just like you can use a built in type. For example just like you can define a variable to be a string "name as string" you can use our defined type "button1 as rect":

button1 as rect

That was easy. Now let's assume that button 1 is top-left-x coordinate and top-left-Y coordinate is (100,100) and the bottom-right-X and bottom-right-Y coordinate is (140,140); here is how we would place thpose values into button1

button1.trx=100
button1.try=100
button1.brx=140
button1.bry=140


Ok, so you may be asking, "how does this help us?" Well say for instance later on in the program design we decide that we need to move button1 to topleft(90,90) & bottomright(130,130); if we used the defined type, we only need to change the 4 values at the beginning of the program, and we are done. If we just used 100,100,140,140 all throughout our program we would have to search for every instance of it and make sure to change them. It's not as easy as an 'automatic search and replace' because there may be other 100's or 140's that have nothing to do with button1. Don't worry if it doesn't make sense just yet, I believe that it will when we disect the mapmaker program.

Some last minute things to tie-up before we get to the game-stuff

I can almost smell those 2D games cooking...
the last things I want to cover before building our own 2D tile-map editor is:

What are tile-based games and why should I bother?
How do 3-dimensional arrays apply to tile-based games?
Reading-in data to arrays - From data statements
What is this thing called a game loop?

This will complete our crash-course first chapter. Chapter 2 we will start building or tile-mapmaker. Can you feel it?

What are tile-based games and why should I bother?
Well first I will say that many 2D games past and present are built upon tile graphics, especially games for the NES, SNES era's because let's face it, 2D platformers/rpg's/top-down were more prevalent then. Though some games still work better in 2D like R.T.S.'s (Real-Time Strategy) and T.S.R's (No. Not Terminal Stay Resident; rather Turn-Based-Stategy) anyone enjoyed Advanced Wars? Some examples of tile-based games are: Super Mario Bros., early Zeldas, the early Castlevania's, the early Final Fantasy's, The original Metroid, The orignal Mega-Man, as well as numerous games past & present. Some games used tiles that were diamond shape, giving a more 3D feel to them, These are referred to as ISO and ISO/HEX-tile-based games. I'll cover them in another tutorial. In 'top-down' tile-based games, the worlds/levels are made up of numerous tiles of a certain size. Some of the common sizes are (16*16, 32*32, 64*64) usually powers of 2 for graphical reasons.

So now that you may recognize some tile-based games, you might still be thinking, "Isn't it better to just draw my backgrounds as large bitmaps instead of building up the screen out of small tiles?" This question is not always simple to answer, and to be honest - with certain games it may be best to hand-draw all of your backgounds (though you will still likely use some sort of logical collision grid); But the most practical answers for using tiles to build the worlds are:

Why Build a world out of tiles?

When designing levels like this as 2D programmer has a few choices:

1)The first one that comes to mind is to create a large bitmap for the level, scrolling it as the player moves.

2)Another method is to use small tiles (like a mosaic) to build thhe large world. Using tiles to create the world is similar to using pixels to draw a large picture in a paint program, but rather than painting with a single pixel, we are painting with a bitmap usually a size of (32*32, 64*64*, 128*128).

Now between these 2 methods; why is method 2 preferred over method 1?

There are primarily three reasons: Memory conservation, graphic reuse, and dynamic map creation.

Let's take a look at each.
(credited to author Todd Barron)
Memory Conservation

Let's say we we needed a level 100 * 100 tiles; with each tile being 64pixels * 64pixels. That would equal 10,000 tiles total. Lets calculate how much memory this single map would use if we tried to create it using one large bitmap, instead of using tiles. so,

100 tiles * 100 tiles = 10,000 tiles
64pixels * 64 pixels = 4,096 pixels per tile
10,000 tiles * 4,096 pixels * 1 byte(8bits) = 40,960,000 bytes (w.256 colors)
10,000 tiles* 4,096 pixels * 4 bytes(32-bit) = 163,840,000 bytes


So a simple 100 * 100 map would require 163 mb in storage if we used 32-bit color; even if we chose tro use 256 colors it would require 41 mb of storage space - for one map.

Now let's compare how much memory it would take to store the map if we use tiles to create the larger world.

100 tiles * 100 tiles = 10,000 tiles
64 pixels * 64 pixels= 4,096 pixels
100 tiles * 4,096 pixels * 4 bytes= 1,638,400
10,000 tiles * 1 byte per tile = 10,000 bytes
10,000 bytes + 1,638,400 = 1,648,400 bytes total


So, using a set of 100 tiles, you can create the 100 * 100 map using opnly 2 mb of memory. Even if you used a tile set of 1000 tiles it would only use less than 20 mb.

And that's if map had no repeating tiles and each tile was used once.

Graphic reuse
This one is practically a no-brainer. If we chose to make each level from a large bitmap we would have to draw every level by hand, if we want to add a level, we will have to start from scratch and draw the level from scratch. If we want to create a new game, we start over drawing levels.

Now creating your own tiles does take time, it isn't an easy process, but once complete, you can reuse the tiles, over and over again. Yu can create new levels with them, in fact you can even use a good tileset for a completely different game, or for hundreds of completely different games.

[Dynamic Content]
Say you want your game to create random maps or levels on the fly. If your world is built from tiles you can write an algorithm to place tiles in a way to make them appealing. Hence, a random map generator.

To do this with a world that is one large bitmap would be a programming nightmare. You would have to write an algorithm that draws a world pixel byu pixel and creates something playable. I don't even want to think about it.

------

Ok I hope that you are convinced as to why tile-based worlds are the way to go. Now I can answer the Data question

So, lets imagine that we want to draw a Super Mario Brothers level. Let's say we have a tile that looks like bricks and its a bitmap that's 32 pixels by 32 pixels.

This means that our level is going to made up of multiple tiles 32*32 placed into a grid, like working with mosaics. Let's say our screen resolution is 640pixels * 480pixels, and that our world will be two screens wide by one screen high (1280pixels * 480pixels). Since we have tiles that are 32pixels * 32 Pixels in order for us to fill two screens we will need to have a 40 tiles * 15 tiles map.

To Store the 40 * 15 map we will use a 2d Array. (it may help you to keep in mind that a 640 pixel * 480 pixel screen is basically a 2d array. dim Screen640x480(640,480) where each x,y pair refers to a specific pixel. Our map will work the same way but rather than x,y referiing to a single pixel it will refer to a tile that is 32pixels*32pixels.)

dim OurMap(40,15)

So now we have a 2d array that can old our map. But we still have no idea how to get the 32*32 tiles to the screen. That's where our data statement comes in. The idea is we will give each tile a numeric identifier. For example or brick tile will be identified by "1" lets also we have an all blue tile that represents the sky and is identified by "0". Now we have to get these values into our 2d array. later when we want to draw the map we will look at the coordinates in our array, any time we run into a 0 we will draw a 32*32 blue tile; any time we run into a 1 we will draw a 32*32 brick tile. So how do we get our map's data into the array. Well there are a few methods. first we can do this

OurMap(0,0)=0: OurMap(1,0)=0: OurMap(2,0)=0: OurMap(3,0)=1 ....

As you can see this is not a good method. So to make our life easier we can use data statements.

What are data statements. Basically it's a way for us to include directly in our program, as opposed to having to open a .txt file, .ini file, .dat file, or even our own custom .map file. The data can be integers, floats, characters, strings etc. The only thing we need to make sure of is that when we read from the data statement that we have the appropriate variable type to hold the data we are reading.

Keep in mind that for our map data 0=to blue sky (32*32 tile), 1=to a brick (32*32 tile)

so lets create or map with data statements
we need a 40*15 map. So I will write the data statements to coincide with that. We will have 15 data lines; eachline will have 40 values.
I could write it all in one single data statement, but by doing it the other way I can sort of see what the map will look like.

data 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
data 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
data 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
data 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
data 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
data 0,0,0,0,0,0,0,0,0,1,1,1,1,1,1,0,0,0,0,1,1,1,1,1,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0
data 0,0,0,0,0,0,0,0,0,1,1,1,1,1,1,0,0,0,0,1,1,1,1,1,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0
data 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
data 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
data 0,0,0,1,1,1,1,1,1,1,1,1,0,0,0,0,0,1,1,1,1,0,0,0,0,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0
data 0,0,0,1,1,1,1,1,1,1,1,1,0,0,0,0,0,1,1,1,1,0,0,0,0,1,1,0,0,0,0,0,0,0,0,1,1,1,1,0
data 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,1,1,1,0
data 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
data 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1
data 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1

It my be hard to see but these data statements represent a level that looks like this
+ Code Snippet

Now we need to read these intgers into our world array
for y=0 to 14
for x=0 to 39
tile=read number
OurMap(x,y)= tile
next x
next y

How Do 3-dimensional arrays apply to tile-based games

This is the "Meat & Potatoes", the "Nuts 'n' Bolts"; so to speak! This is where we make the leap. I know that so far I described multi-dimensional arrays, and you probably thought "Oh great, another tutorial showing me how to average numbers!" Don't fear, I wouldn't just leave you there. I understand it's not enough to just describe a data structure, I need to show how to implement it - and implement with a game design. That's why we are all here, and that's why we purchased DB/DBpro, not to write a grade averager!

It was important to introduce the structure in a reasonable straight-foward manner, but now we need to step-up a notch and make a conceptual leap. It's one thing to desrcibe a data structure, it's another to put it to use. It's kind of like describing a paintbrush, and then describing how to paint a masterpiece. So without further ado I will try to help you understand how the 3-dimensional array is the heart of tile-based games.

Here is a figure to help us conceptualize.
figure 1.4


Sorry the image is a little small, but I'm trying to keep things to a minimum.

Here's an explantion of the figure. The picture shows a 4*4*3 tile-based cut-away of a tile-based world.

The first layer is layer 0 and is oulined in black. This is the base terrain layer. All tiles placed on this layer the character can walk-over. Although I placed water on this layer (normally not walkable for mortals), I made sure to place water at the edge of the land (on layer 1) to provide a barrier so the character sprite can't move there.

The second layer is layer 1 and is outlined in red. This is the layer that the character is rendered on. Any tiles placed on this layer the character sprite will collide into. eg. water, items (like the Novell computer).

The third layer is layer 2 and is outlined in yellow. This layer would be used for things that the player walks under. eg. tree limbs, bridges, etc..

In our actual games we will usually use 5 layers. It made it easier to shoew the figure with only 3.

You are probably noticing something. This figure looks a lot like the description of a 3-dimensional array. dim world(3,3,2). And that's exactly the point. The logic, and tile-placement of the world, collision, rendering, is all handled by the structure of a 3-dimensional array. Now how do we put in information into an integer array to give it the logic to control tile images. That's our next step, and here is where we will talk about reading in data statements.


zenassem
14
Years of Service
User Offline
Joined: 10th Mar 2003
Location: Long Island, NY
Posted: 5th Jul 2004 15:27 Edited at: 6th Jul 2004 04:02
OK, we are on a roll now

Reading-in Data to Arrays -Using Data Statements

I wanted to cover this topic because I use it quite frequently especially while I begin design of a 2D app. Hopefully, "Tile~Forge" the mapmaker will eliminate the need for me to do this, but it's still a technique that one should be aware of. Plus when we move onto reading the contents into an array from a .txt or .ini or .dat file many of the same principles will be used.

So what are data statements and how do we use them? data statements are a way for us to have a list of values (seperated by a comma) that we can read from value by value and move to variables, arrays, etc...
It's like having a text file in the actual programs code. The reason we use them is so that we can read-in contents to the array in a loop just like we initialized the array to 0 in a previous code example. In other words we do not want to enter each coordinate one at a time like this.
Avoid doing this...
world(0,0,0)=1
world(1,0,0)=2
world(2,0,0)=1

instead we will create data statements that have the values that we wish to move to the array. I should explain now that the integer values will either directly or indirectly relate to a tile image. So lets say we have three tiles water, grass, and dirt and we load them as images. Next we want to create a world array to store the world information, which will be read in from the data statements. Follow me?

Here is a code snippet to do just that
Note at this point I'm leaving out code that would be required for it to actually compile and run. I will finish off this chapter with such an example for DBC/& DBpro. No skimping here. And just think all of this is free! Ok back to work. So here we go again:

load image "water.bmp",1,1
load image "grass.bmp",2,1
load image "dirt.bmp",3,1

`we will dimension a 2-d array to store a 10*10 world. Just remember
`that a 3-d array would be the same except we would have an indexZ,
`and we would have to have a 10*10 data statement for each layer.

dim world(9,9)

restore worlddata:

for indexY=0 to 9
for indexX=0 to 9
tilenum = read values
world(indexX,indexY)=tilenum
next indexX
next indexY

worlddata:
`layer 0
data 0,0,0,1,1,1,1,0,0,0
data 0,0,1,0,0,0,0,1,0,0
data 0,1,0,0,0,0,0,0,1,0
data 1,0,2,2,0,0,2,2,0,1
data 1,0,2,2,0,0,2,2,0,1
data 1,0,0,0,0,0,0,0,0,1
data 1,0,3,0,0,0,0,3,0,1
data 0,1,0,3,3,3,3,0,1,0
data 0,0,1,0,0,0,0,1,0,0
data 0,0,0,1,1,1,1,0,0,0





What Is This Thing Called The Game Loop?
I am going to borrow from Andre Lamothe here, as I like his explanation of a game loop. I'll add the relevant stuff to DB. Most of it holds true regardless of what language you are developing in. Lamothe has already reproduced this part of the book in electronic form and has provided it free on other web-sites, so I believe it wil be ok to reproduce the section here. It's pretty standard and well-known information that is in every Game Programming book I have read, with slight modifications here and there.

"We need to learn a way of programmin that's conductive to real-time applications and simulation, rather than the single-line, event-driven, or sequential logic programs that you may be used to. A video game is basically a continuous loop that performs logic and draws an image on the screen, usually at a rate of 30 [Nowadays we should aime for 60+] per second (fps) or more. This is similar to how a movie is displayed, except that you are creating the movie as you go."

Sections of a Game Loop:
Section 1: Initialization
In this section, you perform the standard operations you would for any program, such as memory alloacation, resource aquisition, loading data from disk, and so forth.

Section 2: Enter Game Loop
In this section, the code execution entr into the main game loop. This is where the action begins and continues until the user exits out of the main loop.

Section 3: Retrieve Player Input
In this section, the players input is processed and/or buffered for later use in the AI and logic section.

Section 4: Perform AI and Game Logic
This section contains the majority of the game code. The artificial intelligence, physics systems, and general game logic are executed, and the results are used to draw the next frame on the screen.

Section 5: Render the Next Frame
In this section, the results of the player's input and the execution of game AI and logic are used to generate the next frame of animation for the game. This image is usually drawn on an off-screen buffer area, so you can't see it being rendered. Then it is copied very quickly to the visible display.

Section 6: Synchronize Display
Many computers will speed up or slow down due to a game's level of coomplexity. For example, if there are 1,00 objects running on the screen, the CPU is going to have a higher load than if there were only 10 objects. The frame rate of the game will vary, which isn't acceptable. Hence, you must synchronize the game to some maximum fram rate and try to hold it there using timing and/or wait functions. Usually 30fps [Nowadays 60 fps] is considered to be optimal.

Section 7: Loop
This section is fairly simple - Just g back to the beginning of the game loop and do it all again.

Section 8: Shutdown
This is the end of the game, meaning that the user has exited the main body or game loop and wants to return to the operating system. However, before the user does this, you must release all resources and clean up the system, just as you would for any other piece of software." Author ~Andre Lamothe "Tricks of the Windows Game Programming Gurus": - Sams Publishing copyright 1999


SpecTre1
14
Years of Service
User Offline
Joined: 24th Feb 2003
Location: United Kingdom
Posted: 5th Jul 2004 22:34
Sounds great to me m8, both of them games would be good to do tutorials on as Frogger is static and Commando would scroll, blend together nicely

Very good tutorial so far, very easy to understand and get to grips with! Keep up the good work m8, much appreciated!

New to DBPro comin from AMOS on the Amiga!
zenassem
14
Years of Service
User Offline
Joined: 10th Mar 2003
Location: Long Island, NY
Posted: 6th Jul 2004 05:18 Edited at: 6th Jul 2004 15:19
Now the last thing I want to do, before we start building a tile-editor/mapmaker is, match the gameloop sections with our 2D code template that I provided in the beginning, as I promised to cover it more in depth. Here is the code template again:

Basic 2D Game Template

+ Code Snippet


======================================================================


Well that's the end of Chapter 1
I believe we have layed the ground-work to actual build the fun stuff.
I will spend time re-reading and fixing errors & mistakes that I have made as I move along. I'm just excited that the alot of the preliminary information is out of the way now, and we can now move on to more interesting code.

It had to be done, and for me it was the most grueling part. It's hard to make the intro information fun. I hope that it wasn't to painfully boring and that people reading it can get something out of it. We will still revisit some of the topics discussed so far in a more in-depth manner (eg. Sprites, Image manipulation, F/X).

At the end of each chapter I will throw out some thanks. So here's the first round...

End of Chapter 1: Special Thanks!!!
At this point I would really like to thank IanM. Withouth him none of this would have been possible. I have been following his posts since I first joined, and it's good that he was able to clear up some of my blunders/ommissions in the first section. I will look to edit the orignal posts and incorporate his insights.So here!!! here!!! IanM!

Thanks also to Spectre for the feedback. I'm not sure if I would have pushed as hard to finish the first chapter if it wasn't for his support. I do hope that others will see this tutorial as useful and informative as I move along. I know hundreds of questions are asked about the upcoming topics.So here!!! here!!! Spectre!

Thanks to Cattlerustler, mainly for keeping me laughing while I break away from this thread to read the other boards; and as well for the mounds of information I have learned from reading his threads. If anyone gets the chance I would suggest checking out his netlib DLL. CR, I promise that I'll do some good things with it. Plus, us New Yorker's need to stick together. So here!!! here!!! Cattlerustler!
Cr's site:
http://www.mod2software.com/dbp/dbp.htm

Thanks to All the TGC staff and mods (now including Jess), it's still amazing to me how much gets done around here. Bug week was a great success IMHO. It really goes to show you how much people care about this community. The improvements to the language, and the board, have renewed my energy in DB. We are the first to complain when things go wrong (which is good to the overall product) so we should be the first when things go right (which I think we do just as well). [b]So here!!! here!!! TGC Staff & MOD'S (now including JESS)!


SpecTre1
14
Years of Service
User Offline
Joined: 24th Feb 2003
Location: United Kingdom
Posted: 6th Jul 2004 08:21

Well that was a great first chapter!
We got to give a big thanks to zenassem for creating this tutorial and for putting in the time and effort that is needed in doing so, thanks again m8y!

Really looking forward to the rest and can't wait for the next steps in the 2D games coding world!!! I know my m8 Octave will be following this tutorial very soon as he is in the same boat as me!
Chapter One is all printed out and filed ready for Chapter Two!!

New to DBPro comin from AMOS on the Amiga!
2DJay
13
Years of Service
User Offline
Joined: 7th Jul 2004
Location:
Posted: 8th Jul 2004 07:36
All of this sounds inspired.

Please bring on the 2D platform collision detection. With a reliable platform collision algorithm (preferably pixel perfect) so many games and ideas can be achieved. I have tried for so long to achieve this, but yet not succeeded.

Cheers

Jay
Skeletor
13
Years of Service
User Offline
Joined: 21st Jun 2004
Location: florida
Posted: 8th Jul 2004 11:28
Question... is any of the code above compatible with DBC or just DBPro?
zenassem
14
Years of Service
User Offline
Joined: 10th Mar 2003
Location: Long Island, NY
Posted: 8th Jul 2004 21:08
I will be posting any changes that are necessary for DBC today! The next chapter will have both the DBpro & the DBC code for evey example.

That's what I have been working on the last two days, as well as waiting to hear whether or not it will alright for me to post 2d media that was included with DBC.

2DJay,
The first examples will be based on simple grid collision, so that everyone can get on board. I have some collision code, that still needs some tuning, for platformers that is Not exactly Pixel Perfect technically speaking, but the results are fairly close. I will be working while I am writing on trying to achieve pixel perfect collision without sacrificing the frame rate.

~Zen


Skeletor
13
Years of Service
User Offline
Joined: 21st Jun 2004
Location: florida
Posted: 9th Jul 2004 02:06
Alright very cool zen!
2DJay
13
Years of Service
User Offline
Joined: 7th Jul 2004
Location:
Posted: 9th Jul 2004 06:53
Excellent Zen. To be fair, I am only looking for good collision detection. You know when you have a character that appears to float next to the platform, this is what I am trying to avoid.

2DJay
zenassem
14
Years of Service
User Offline
Joined: 10th Mar 2003
Location: Long Island, NY
Posted: 14th Jul 2004 07:01 Edited at: 14th Jul 2004 09:47
Sorry for the delay with chapter 2. I was involved in a car accident, and have been nursing some injuries the past few days. Nothing too serious, just some bruising and scrapes. I look to be posting some code tomorrow, and possibly some information tonight. My laptop with my source code is at work, and I should be retuning to work tomorrow. I tmight be possible for me to get my compiler up and running on this stanby computer, so I might be able to test dome snippets. I wil be posting more of the main tile system components tomorrow.

From here on I am going to try to keep indexes better organized and accurate.

Thanks for everybody's patience.

Sincerely,
~Zen


zenassem
14
Years of Service
User Offline
Joined: 10th Mar 2003
Location: Long Island, NY
Posted: 14th Jul 2004 09:15 Edited at: 15th Jul 2004 08:45
Chapter 2
Index

Tile~Forge

First Some Blah, blah!
2.1 Intro Babble!
2.1a Definition of terms (Rectangular tile-maps)


Put On Your Hard-Hat!
2.2 Coding a Tile-map Editor

Playing With Building Blocks
2.3 Tile~Forge (The begining Of our Tile-Editor, An overall design)
2.3a The Map Layer Editor
2.3b Desining The GUI
2.3c The Map View Area & Layer Selector
2.3d The Tile Selector Area


Add some Polish!
2.4e The Fringing Applicator
2.4f The BackDrop Applicator
... (To be decided soon!)


=====================================================================
Blah, Blah!
2.1 Intro Babble!
I am going to be taking a different direction in this tutorial then I have seen in other tutorials or game programming books. Many of the books that I have read generally introduce each aspect of the game followed with code snippets – eventually (hopefully) tying these snippets into a general/basic game. I have rarely seen good examples – if any example at all – about creating tools to aid in the development process. Our approach here will be quite different. I would like to focus on the tool creation first, and later, the code to design a game engine. Many of the principles that we will use in coding the tools will see its way into actual “in-game” code. Creating your own development tools can be rewarding, and they can save you time developing future projects. You may consider including the tools with the release of your programs, allowing users to extend the replay value of your game by allowing them to develop their own custom levels or maps. Many games released today are following this trend.

The first tool that we will be looking at is a tile-map editor. Our first map editor will be designed for use with rectangular tiles, and be capable of genereating levels for various 2D Side Scrollers, Top Down Strategy games, Top Down RPG’s, and Puzzle games. If you haven’t before worked with-tile based games – don’t fret, it isn’t that difficult. There is however some terminology that I have to cover to so that we are all on the same page when it comes to discussing the elements of this genre.


2.1a Definition Of Terms (Recatngular tile-maps)

A Map Editor: This is the first tool we are going to be building in order to help us create our tile-based games. You can think of a map editor as a paint program, but rather than painting with single pixels, we will be painting with rectangular images. We will then save the information that we draw in the Map Editor to a 3dimensional array that weill be loaded into our game. By creating this tool we will be able to draw maps and load them into our games without haveing to type numbers for each tile by hand.

A Tile: Since we are creating a Tile~Map Editor we should define what a tile is. A Tile for our purposes here will be a rectangular bitmap, of a certain size (32*32,64*64,96*96) that will be placed next to eachother to make a picture of a larger world. If you have ever seen a mosaic, it would give you a good idea of what a tile is. We will also be looking at a specific tile which only uses a portion of the rectangular size, that is used for transitioning from one type of tile to another. We will refer to these a fringing tiles.

Tile Selector: This is akin to a color selector in a paint program. Since we are basically painting with tiles we need an area that we can select which tile we are painting with.

*** I'll be adding more definitions as needed.

2.2 Coding a Tile~Map Editor
We are ready to begin coding our Map Editor. I have been using the name "Tile~Forge" for mine but feel free to give yours whatever name you would like. As I said in the definitios earlier, basically we are going to be creating a 2D paint program, whose brushes are tiles rather than pixels and colors. There are many different components that will need to be coded for us to complete our task. We will touch upon every topic that was covered in Chapter 1 and more. The exciting thing is, that once we are done building the Map Editor, you have a pretty good idea on how to code much of the in-game tile engine. So the reward will be two-fold at least. In addition, you will be able to modify and use your map editor for countless games in the future.

2.3 Playing with Building Blocks!
Here is a list of components we will be coding
-Map Editing Window
-Mouse Position code
-The Layer Selector
-The Tile Selector
-Fill tool
-Copy/Paste tool
-Automatic Fringe Tool
-Save Map Utility
-Load Map utility
-Mini Map Viewer
-Backdrop Creator

That Will be enough for Chapter 2. Later on we will look at placing objects, triggers, npc's, events etc...

So let's get Going


Neophyte
14
Years of Service
User Offline
Joined: 23rd Feb 2003
Location: United States
Posted: 15th Jul 2004 03:41
@zenassem

"Our approach here will be quite different. I would like to focus on the tool creation first, and later, the code to design a game engine."

Interesting. I certainly look forward to seeing how this pans out. I have to say that certainly is a unique approach and could prove most usefull.


Oh, and I'm sorry to hear about your accident. I hope you get better soon.
zenassem
14
Years of Service
User Offline
Joined: 10th Mar 2003
Location: Long Island, NY
Posted: 15th Jul 2004 08:50 Edited at: 15th Jul 2004 14:07
Here is what our interface for the Map Editor will look like.
You can download it and all from: ***link in a moment***



Every code example will have both a DBpro Version followed immediately by a DBClassic Version. I will continue this structure thorughout the rest of the tutorial, eventually we will be heading to Isometric & IsoHex maps. The code snippets will be labeled both right before the code snippet and in the code snippet to avoid any confusion. here is an example

[Pro]
+ Code Snippet

[Classic]
+ Code Snippet

Hope that eases anyone concerns, and makes it clear that the title of the thread is exactly what it says!


SpecTre1
14
Years of Service
User Offline
Joined: 24th Feb 2003
Location: United Kingdom
Posted: 16th Jul 2004 01:54
this is great format to use zen, hope you get better soon and look forward to the chapter!!

By the way, did you get permision to use the tiles yet??

New to DBPro comin from AMOS on the Amiga!
mmurray
13
Years of Service
User Offline
Joined: 16th Jul 2004
Location:
Posted: 16th Jul 2004 23:13
Just a quick post (my first) to say this is a wonderful thread. Please keep up the good work. I am brand new to all of this and the information you are providing is great.
zenassem
14
Years of Service
User Offline
Joined: 10th Mar 2003
Location: Long Island, NY
Posted: 17th Jul 2004 06:12
I will be posting the code today!!! Yay!!! and I'll be uploading to dbspot for download. Unfortunately I never recieved a response from both my thread and email to see if I would be allowed to use resized DBC media. So I figure I will have to draw up my own tiles or find some on the net until I can get an official answere as to whether I can provide them. Minor setback but we'll roll with it. I have the first part of the code working in DBpro, just tweaking some of the DBC code.

Also, I have begun testing out 3D maps. This will come after we cover Isometric tile-engines. The 3d maps will still look like the isometric strategy games,
but of course it adds some ability to rotate the camera and such. We have a way to go to get their, but the journey should be exciting. Right now it's 400 pm est usa. I will be adding the code a little at a time, along with the required media.

@mmurray, thanks for the feedback. I hope that this thread helps explain some concepts. As I move foward I will be looking over the other posts making slight corrections, spelling, and formatting.


zenassem
14
Years of Service
User Offline
Joined: 10th Mar 2003
Location: Long Island, NY
Posted: 18th Jul 2004 02:36 Edited at: 18th Jul 2004 05:03
[NEWS FLASH!]

I made some edits to chapter 1. Mostly minor corrections; But I did add a section under "Tile-Based World Why should I Bother?". After reading that section I realized that I didn't really explain the reason to make worlds from tiles, nor did I really tie in arrays/data statements to a tile based world. I hope that the added text does a better job. I will be making minor changes from time to time, and I'll try to keep everyone notified.

If anyone spots an error, (spelling mistake, logic value, coding error etc. Please feel free to email me at "[my username]@hotmail.com". You can also leave me feedback if you believe something was not covered properly or if you think there is something that I should devote more attention to.

In the coming weeks I'll start converting the thread text to an adobe .pdf document that can be downloaded chapter by chapter. I believe this will help people in the future.



----------------------------------------------------------------------

Alright, Thanks to Jimmy & Dbspot for giving me some hosting space to store all the files for the tutorial. I just uploaded the GUI bitmap. It's not compressed. I will probably zip, media on the next upload.

Here is the 1st design of the GUI I drew up for us to use. I might convert to .jpg to get a better compression, but jpeg will add artifacting. I'll need to compress it somewhat. If anyone knows the best method to compress the media. I'll either use .zip or .rar. but more people are porbably familiar with winzip files.

http://zenassem.dbspot.com/CreateMap.bmp

Right now everything is off the root. I'll work on setting up a page when time allows
http://zenassem.dbpsot.com

Everyone who wants to build the mapeditor will need this file. I will be adding tile media and other media today!

The MapEditor will have a Fun look to it, (I purposeley didn't want it too look all serious and drab). But I will do my best to make it has professional as possible. Something that people can actually use as a tool to help them create levels for 2d games. I'm not going to cut corners and spend a lot of time programming an app that doesn't function well. I hope everyone likes the design. Of course you will have all the source, and media so you are free to make any changes after we are done.

Oh btw, I have decided that after we build the editor our first level/game will be a level from Super Mario Bros. And then possibly Frogger! Future examples will be based on RTS and Turn-based Strategy games, But don't be suprised if I through a retro Zelda into the mix.


~zen


zenassem
14
Years of Service
User Offline
Joined: 10th Mar 2003
Location: Long Island, NY
Posted: 18th Jul 2004 05:13 Edited at: 18th Jul 2004 13:52
2.3a The Map Editor

Here is the source code that we will be discussing in this chapter. I remarked some lines that we will unrem when I get the rest of the images loaded. I discuss every section of the code that is presented.

[DBpro Code]
+ Code Snippet

[DBClassic Code]
It's important for me to note that all DBC code will be written and tested in darkedit. I cannot bring myself to work in the original editor without a loaded 9mm near by. Plus dark Edit allows user defined types, syntax highlighting. So if you are going to be following the DBC track, do yourself a favor and download DarkEdit.

+ Code Snippet

O.K. it really wasn't easy reworking the code for DBC, but I pulled it off. I still get flashing while media is being loaded, and during resolution change. If anyone knows how to prevent this in DBC,please let me know, and I'll make the changes. I'll look cleanup the DB code a little better as we move along, but I really needed to get the core out there so we could start talking about it.


Alright so what does this code do. Well it's the beginning of our MapEditor. We will be changing the format of how the actuals tiles are loaded, but I threw them in there just for testing purposes. I'll have the media available for download tomorrow. What the code does so far is:

- Loads a Title screen.
- Loads the main MapEditor GUI.
- Breaks most of the areas into regions
- Breaks the reagons down to specific buttons, tilepicker, editor grid etc...
- Allows you to select a tile for the left mouse button and the right mouse button
- Allows you to draw a map on layer 0 with left and right mouse buttons
- The layer buttons function and either make that layer visible or hidden

Now I'll expalain how it works!


zenassem
14
Years of Service
User Offline
Joined: 10th Mar 2003
Location: Long Island, NY
Posted: 20th Jul 2004 14:07 Edited at: 21st Jul 2004 07:58
Alright so this would be a good place to expain (almost line by line what is going on. I’m not going to go overboard as we will be changing some of the code as we start building it up. But I wanted to get the basics out so that we could get started. I will explain the DBpro code, and at the end I’ll explain the differences in the DBC code. I’ll also make good on my promise to have the media available for download. Sorry if I kept anyone waiting. So let’s look at what is going on here.

<Let me apologize now for possibly explaining the obvious, I don’t plan on doing this throughout the entire tutorial, but I want to do it here to make sure everyone is on the same page.>


set display mode 800,600,32
set image colorkey 255,0,255


This is pretty straight forward. Set the display to 800 pixels by 600 pixels with a color bit depth of 32. Set pink to be the transparent color. (DBclassic doesn’t have this command so black is transparent. I might change our transparent color to black so that I will not need separate media files, I’ll get back to you if I change it.)


TILESIZEX=32
TILESIZEY=32
LAYERS=5
TWORLDSIZEX=20
TWORLDSIZEY=15
PWORLDSIZEX=800
PWORLDSIZEY=600
SCREENSIZEX=800
SCREENSIZEY=600


Here we are just setting up some varianles. This makes it easier to change the code later on. Say for example we need the TileSize to be 64*64, we wouldn’t want to go throught the entire program changing 32’s to 64’s. If we use these variables we can change the value in one place and we are done. (later in the development these values will be set by a file created by user input.) So, we setup our world to have:
32*32 pixel tiles
5 layers (that will be the third dimension in our 3D array)
20 Tiles across by 15 tiles down
and some screen sizes that we will talk more about later


dim ArMAP(TWORLDSIZEX,TWORLDSIZEY,LAYERS)
for indexL=0 to LAYERS
for indexY=0 to WORLDSIZEY
for indexX=0 to WORLDSIZEX
ArMAP(TWORLDSIZEX,TWORLDSIZEY,LAYERS)=0
next indexX
next indexY
next indexL


ArMap(15,20,5) is our 3D array structure that will store the world information, basically the tiles that we draw. Note: be aware that DB arrays start at 0 and go up and “include” the number in our dimension statement. So, in this example we are actually creating an array with the size of 16x21x6. I’m not to concerned about it here, but I didn’t want to throw everyone off by subtracting 1 from or variables. Basically this code sets up storage for our world, and initializes the structure so that we can 100% certain that all indexes contain a value of 0. It fills the array across X values, then Down 1 row Y value, and again all the way across. Kind of like reading a page of a book. The third dimension layers is like flipping to the next page and the process starts all over again, doing this for 5 (+ our additional index so actually 6) pages.


dim ArTSET(3,13,15)


ArTSET is a three dimensional array for our tileset that we will be using to draw our world. This will be changing later, but I needed to have something to test our program out with. Basically this structur would hold 16 4tiles*14tiles (tile sets). These will be displayed in our tile selector/picker area. Kind of like a color selector in any 2d paint program.


CurrLayer=0
TRUE=1
FALSE=0


Currlayer is an integer variable that lets our mapeditor know which layer the user is drawing on. I’ll explain more about layers later, but just keep in mind that we have a map that can have 5 layers (layers are like transparencies lade on top of eachother to create on final image).

The TRUE and FALSE is basically Boolean logic. I know it’s built in, but this is something that I brought over from my C programming days. I got used to doing it this way and it stuck with me. They should really be constants but I’ll take care of that later. Just know that we can now use TRUE to represent 1 and False to represent 0.


dim LayerVis(5)
for index = 0 to 4
LayerVis(index)=TRUE
next index


LayerVis is a 1 dimensional array. It will just keep track of which layers are visible. When we are editing a map we may want to turn off or on certain layers as we progress. The values of the indexes in the array will let the display section know which layers should be rendered. By default we have all layers turned ON =Visible=TRUE=1


Skeletor
13
Years of Service
User Offline
Joined: 21st Jun 2004
Location: florida
Posted: 25th Jul 2004 11:31 Edited at: 25th Jul 2004 11:33
@ Zen
Still Working on the Tutorial? (I hope so)
Anyhow its great so far keep up the good work

Oh by the way I got DBP online edition about a week ago. I would still like to see how much DBP and DBC differs though.

Skeletor
13
Years of Service
User Offline
Joined: 21st Jun 2004
Location: florida
Posted: 27th Jul 2004 07:16 Edited at: 27th Jul 2004 07:16
Hey Zen you should make a Tutorial/(include it in this one) on how to get Pixel perfect collision in DBP. It seems a lot of people run into this problem when they switch over from DBC to DBP.

M00NSHiNE
14
Years of Service
User Offline
Joined: 4th Aug 2003
Location: England, UK
Posted: 29th Jul 2004 01:49
For example: me. I'm less bothered about how to do pixel perfect collision in DBP, but more of how to do pixel perfect collision when the sprite is actually a textured 3d plane a la DX8/9/OpenGL.

Skeletor
13
Years of Service
User Offline
Joined: 21st Jun 2004
Location: florida
Posted: 9th Aug 2004 10:14
lol what the hell happened to zenassem...


http://www.angelfire.com/games5/db_games/
SpecTre1
14
Years of Service
User Offline
Joined: 24th Feb 2003
Location: United Kingdom
Posted: 20th Aug 2004 10:53
Been on holiday for a few weeks keep up the good work m8, following you great there!

New to DBPro comin from AMOS on the Amiga!
Skeletor
13
Years of Service
User Offline
Joined: 21st Jun 2004
Location: florida
Posted: 21st Aug 2004 04:32 Edited at: 27th Aug 2004 07:11
Lol Spectre, Zenassem disapeared and hasnt posted in like 3 weeks if not longer.


http://www.angelfire.com/games5/db_games/
Peter H
13
Years of Service
User Offline
Joined: 20th Feb 2004
Location: Witness Protection Program
Posted: 27th Aug 2004 02:04
maybe he got in another accident

"We make the worst games in the universe."
Skeletor
13
Years of Service
User Offline
Joined: 21st Jun 2004
Location: florida
Posted: 27th Aug 2004 07:11
Errr.... I dont know but I was looking forward to this Post.


http://www.angelfire.com/games5/db_games/
Mr Anderson
13
Years of Service
User Offline
Joined: 14th Oct 2003
Location: NYC
Posted: 27th Aug 2004 14:06
Question:
Since the sprites are basically taking advantage of the 3d hardware and directx 3d features.... is there a way to use the alpha for transparency in the sprites... For example say you render your sprite frames in a 3d program and it outputs png files, or another image file that stores alpha value. Can Sprites take advantage of that piece of data?

<sorry if that was answered. I read through the sprite stuff, but skipped over arrays and stuff>

IDIC (Infinite Diversity Infinite Combinations)
It Wasnt Me
12
Years of Service
User Offline
Joined: 27th Aug 2004
Location: Wherever the fried eggnog pudding is
Posted: 28th Aug 2004 01:42
Where is he?

If it was me, I wouldn't know it.
the_winch
14
Years of Service
User Offline
Joined: 1st Feb 2003
Location: Oxford, UK
Posted: 28th Aug 2004 09:03
Quote: "Since the sprites are basically taking advantage of the 3d hardware and directx 3d features.... is there a way to use the alpha for transparency in the sprites... For example say you render your sprite frames in a 3d program and it outputs png files, or another image file that stores alpha value. Can Sprites take advantage of that piece of data?"


Yes just use them as normal. You can also take advantage of the transparancy info using paste image, just add the transparancy flag eg PASTE IMAGE 1,0,0,1

shrink those dbpro exes
Create patches for your dbpro games
Mr Anderson
13
Years of Service
User Offline
Joined: 14th Oct 2003
Location: NYC
Posted: 28th Aug 2004 15:46
Thanks I'll try something

Crosses fingers...

I'll post something later. I have to build my mother's shuttle PC

IDIC (Infinite Diversity Infinite Combinations)

Login to post a reply

Server time is: 2017-08-20 20:21:52
Your offset time is: 2017-08-20 20:21:52