Jedi-SDL / Recognizing Tiles

[DarknessX]

Well, I'm making a clone of a game called Tower Defense, and my problem at the moment, is I'm making a map editor for it... All fine and dandy, graphics are loading fine and all. I can display them however I want. Now, my problem, is that when I finally get to have actual people walking on the 'roads', I need the people to follow the road and not go off it.

Is there an inbuilt function in Jedi-SDL to do this, or is there a specific way of doing it? I'm not using any tile system currently in Jedi-SDL, I basically made my own... The background, and the roads, are PNG files, the roads are each 64x64. I basically need to be able to tell the characters to move left, or right, or straight, when the opportunity arises. I also plan on having multiple paths to the end of the map... So I will be building a slightly more complex AI.

My coding is quite simple so far, and only framework to display this:
http://i209.photobucket.com/albums/b...464/stage2.png
is in place.

My coding can be seen here:
http://pastebin.ca/659226

So, to recap, my question is, how do I detect the edge of the png files?


Edit: Also, some information which may be useful, when reading the code:

Debugging:

Error 1 is a surface error, where a picture is attached to a surface but the surface is equal to nil.

Error 2 is


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

Naming Conventions:
Roads (for blitting, is a pSDL_Surface):
road_(first letter of vertical direction)(first 3 letters of horizontal direction, ie lef or rig)turn
example: road_drigturn (downwards right turn)
in use: sdl_blitsurface(road_drigturn,nil,screen,nil);

Roads (for assigning gfx, the actual url to the file is contained within):
road_(first letter of vertical direction)(first letter of horizontal direction)turn
example: road_drturn (downwards right turn)
in use: road_drigturn := img_load(road_drturn);

As you can see, I have created a skeleton of a debug system, which I am implementing as I go

[jasonf]

You don't need to detect the edges of the png files. That kind of collision detection is possible, but should only be used as a last resort to see if 2 sprites are physically touching where you have no alternative as it's very slow.

If your game is based on the tower defence games, then your tiles are placed on a grid. As with any grid, detecting your element within that grid is a very easy.

If sprite position 0x0 is the top most left grid location and the grid squares are 64 pixels each, then to find the array element for which the tile is based is easy.

celx := playercentrex div 64;
cely := playercentrey div 64;

then, assuming that your array is an array objects (e.g TGridElement which could have a property for Obstacle ) then you can very easily work out which array elements are the path and which are not.

I've used the centre position here to keep things simple.. but basically, you'd test which cell your creature is about to move to in it's current direction. if it encounters a cell which is deemed to be an obstacle then you rotate 90 degrees to the left and perform the test again. If that one is an obstacle, turn 90 degrees to the right and perform the test again, if there is still a blockage, turn 180 degrees.

This does mean working out the new position based on the angle, but that's not hard.

Basically, you're not using your png's as the indication of whether you've hit something solid, that's far too slow.. instead you use a very very fast grid test and compare it to the array element for the grid position.

Hope this helps.

[DarknessX]

hmmmm, ok. I understood a little of that, but I don't have a grid.. only 64x64 road tiles. I suppose I could manufacture one...Is that what the array is essentially doing, is creating a grid?

And would it be possible for me to create a map file and do, say, this: (I will end up experimenting later.. once I wake up )

mapfile:

| = vertical road
- = horizontal road
o = grass
> = turn left

|oooo
|oooo
>----
ooooo
ooooo

and then, for coding, say...

if &#40;charposition&#91;x&#93; < 65&#41; and &#40;charposition&#91;y&#93; < 65&#41; then currenttile &#58;= 1;
if currenttile = 1 then &#123;read file to see what type of road it is&#125;

The x,y coordinates are simply whatever x,y coordinates are being used for displaying the graphics, IE, for png's,

    dstassign(0,128,0,128); //3rd tile down, turning right
    sdl_blitsurface(road_drigturn,nil,screen,@dst);

the 'x' value is 0 (first one), the 'y' value is 128, and the w/h are the same as the x/y values. so technically...

if &#40;charposition&#91;x&#93; < 129&#41; and &#40;charposition&#91;y&#93; < 1&#41; then currenttile &#58;= 11;

And of course, I would have much better, shorter coding for the x/y location (probably just a simple loop which checks everything).

Would that be too slow?

See, I can't make it choose a road depending on the first open space- there may be multiple paths, and one will break off into another, while still continuing. So, rotating so many degrees won't work, as it will always only find the first available one.

[arthurprs]

Dam my english sucks, i don't undersdant what u want

[DarknessX]

I was trying to detect the edges of the PNG files. Now, I realize that isn't the best way..

So, using JasonF's post, I formulated my own 'theory' for how to make it work.

So, I was asking if it was possible to make a map file, which could then be used, to determine the edges of the roads...

[WILL]

Dam my english sucks, i don't undersdant what u want

Take your time. Look up words if you have to. Or if you like; we have a Localization forum... just ask there what a word or what a 'strange term' means. We'll be kind about it.

...well if not Dom and I will take care of them.

[arthurprs]

I was trying to detect the edges of the PNG files. Now, I realize that isn't the best way..

So, using JasonF's post, I formulated my own 'theory' for how to make it work.

So, I was asking if it was possible to make a map file, which could then be used, to determine the edges of the roads...

Edges :?


TEORY:

w = 64
h = 64

x , y are the block pos
you can also use an double dimensioned array to store it and multiply these values for w and h

topleft = (x , y)
topright = (x + w , y)
bottomleft = (x , y + h)
bottomright = (x + w , y + h)


That what i used on my minesweeper

[DarknessX]

Hmmmm, that is quite interesting... Mind you, I don't think it will work, however, because even though it will give me all 4 corners, it has no way of telling me that the path turns left, or goes straight, or both...

[arthurprs]

Hmmmm, that is quite interesting... Mind you, I don't think it will work, however, because even though it will give me all 4 corners, it has no way of telling me that the path turns left, or goes straight, or both...

of course it can

use types

type
  title = record
   dir : TITLEdirection;
   type : TITLEtype;
  end;

type
 TITLEdirection = (up , down, left, right, lefttop, leftbottom, righttop, rightbottom);
type
 TITLEtype = (grass, vertical, horizontal, turnleft, turnright);

// THIS IS ONLY AN EXAMPLE
// YOU DONT NEED 2 THINGS THAT SAY SAME THING

then makes an 2 dimension array of "title" type, or, if you don't want more things then type then "TITLEdirection"

[DarknessX]

Yes, thats good, but what happens when the road becomes a T-turn, and the person has 2 methods to go? that would make your method extremely complex, because it would add another entire dimension to it.