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! / 2D Tile-based SLOPES question... Help needed!

Author
Message
TLOZ
20
Years of Service
User Offline
Joined: 7th May 2005
Location: Enfield, NC
Posted: 7th May 2007 09:57 Edited at: 7th May 2007 10:00
I've been having a lot of trouble dealing with tile-based slopes and what I need to know is "How to have sprites collide with slopes correctly?"

I want to know how to get a sprite to jump, move up & down, and collide with tile slopes correctly.(45 degree tile slopes)

Can someone explain what is being done and how to calculate the math involved? thanks

btw, I'm using DBpro.
zenassem
22
Years of Service
User Offline
Joined: 10th Mar 2003
Location: Long Island, NY
Posted: 7th May 2007 10:51
It really depends on how you code your tile mapper. And is this a straght down 2D tile map game? Isometric? please elaborate.

I can explain the basics of the method(s) I've used.

method 1:
I would use 2 layers of my multidimensional array (or a seperate array) that would have a value depending on the tiles slope, or other facter (eg. Speed, like swamps, forest, deep water etc...).
As the player moved my tile-engine processing routines would look to those values (in the same way I would look at other values to decide which tile to draw)

So depending on how many different angle slopes you have:
The first layer
A value of...
0 = mean no slope
45 = a 45 degree slope this would trigger me to call my routine to slow character speed, and adjust the character Y position accordingly

The second Layer:
was used to indicate which direction the angle going up was
1 = Up to the north
2 = Up to the south
3 = Up to the east
4 = Up to the west


same would go for other angles.

I would use other values in the first array to determine speed of tiles
0 = Normal speed
1 = Faster speed
2 = Slower speed
3 = Extremely fast
4 = Extremely slow

etc...

Method 2:
I used something similar to a height map in 3D games. Pretty much each pixel of the image represented a tile on the map. Each color or shade (depending on what I needed I either used a gray scale image and other times I would use colors) of the image refrenced the same values in method 1.

For instance a white pixel meant 0 slope and normal speed
a green pixel meant extemely fast speed.

etc...

TLOZ
20
Years of Service
User Offline
Joined: 7th May 2005
Location: Enfield, NC
Posted: 7th May 2007 11:08 Edited at: 7th May 2007 20:38
Well, my tile code comes from pizzaman's tile code and it is a straight down tile map.

I understand using arrays to setup the tile info, but what I really need to know is how to code "how much into the tile the sprite is" so I can position the sprite correctly on the slope after moving along it or jumping on it. I'm completely lost up to figuring this out.
zenassem
22
Years of Service
User Offline
Joined: 10th Mar 2003
Location: Long Island, NY
Posted: 9th May 2007 13:58 Edited at: 9th May 2007 13:58
Can you illustrate an example? Even if it's just a collage of said tiles in paint. It would help me to understand and help with your problem.

TLOZ
20
Years of Service
User Offline
Joined: 7th May 2005
Location: Enfield, NC
Posted: 11th May 2007 09:12
I found somewhat of a tutorial on another site that helped out a lot with the slopes! Here is the site: http://oos.moxiecode.com/tut_11/index.html

The thing I need help with now is getting the collision with slopes for jumping done correctly. I can get the sprite to land on the regular square tiles correctly, but I can't get the player sprite to land on the slope tiles right.

***I've attached all media and code to this post.***
zenassem
22
Years of Service
User Offline
Joined: 10th Mar 2003
Location: Long Island, NY
Posted: 11th May 2007 09:20
Great, i will download and have a look at it in the morning. I can say for now, that you will need to have some look ahead code and jump zones (especially if NPC's will need to do this). It really becomes a matter of steering the character to the predertimined (not to far in advance) landing spot.

The one thing that can add to the code, is if you allow for mid air redirection of your characters (kind of like the drift from mario games). If so, it will be more important that your look ahead code gets called more often so that it's landing prediction can be updated quick enough to respond properly. If not, the landing of the jump could appear like a magnet that's sucking the character back in, which is not really desireable. I'll piece together the code tomorrow.

TLOZ
20
Years of Service
User Offline
Joined: 7th May 2005
Location: Enfield, NC
Posted: 11th May 2007 09:39 Edited at: 11th May 2007 09:39
Hey thanks! Understanding tiles has been(at my current level) the hardest thing to deal with. Hopefully I'll understand everything better after this.
zenassem
22
Years of Service
User Offline
Joined: 10th Mar 2003
Location: Long Island, NY
Posted: 11th May 2007 09:53
2D tile based games are actually more difficult than a lot of the 3D stuff. Because you actually have to code all your own collision routines, especially on topdown maps.

Iso maps, are a head trip. But I think the hardest part of tile based is the question your asking.

After that, it's more or less creating all the graphics, tile animations and timers, transitions, effects... or coding your own Map Trigger/Quest Editor. Becuase sripting the quest, and keeping track of player progression, and having NPC's follow story boards, can also be a headache when hard coding them..

TLOZ
20
Years of Service
User Offline
Joined: 7th May 2005
Location: Enfield, NC
Posted: 11th May 2007 10:16
Didn't know that dealing with tiles was on par or harder than 3D programming. If I can get this down, I'm pretty sure I'll be able to finally make a game that plays like the newer castlevanias.

How long have you been programming 2D?

btw, What are NPC's? :p
zenassem
22
Years of Service
User Offline
Joined: 10th Mar 2003
Location: Long Island, NY
Posted: 11th May 2007 10:33 Edited at: 11th May 2007 10:41
[EDIT] As I was re-reading posts in this thread. I somehow missed or misread at the time that you were saying the original problem was figuring out how far into the tile the "active" area of the sprite is. Glad you found the info you needed.

started in 1986 Commodore64. Didn't know what I was doing for a long time. But that's when it started.

And yep 2d tiles are harder. Now if your using 3D plains and viewing them with a camera from above (making it look 2d), a lot easier. Especially in Dbpro. To keep yourself on the tile you assign gravity. The slope detection is built in.

TLOZ
20
Years of Service
User Offline
Joined: 7th May 2005
Location: Enfield, NC
Posted: 11th May 2007 10:40 Edited at: 11th May 2007 10:41
Man thats a long time ago. I've only been doing this for about 2 1/2 years. Are you talking about my current code?
zenassem
22
Years of Service
User Offline
Joined: 10th Mar 2003
Location: Long Island, NY
Posted: 11th May 2007 10:44
No, not the current code. I was just reading the thread from the beiginning and I realized that I must have misread your question (the one right before I asked you to illustrate it). I could have answered that right then and there had I read it properly.

TLOZ
20
Years of Service
User Offline
Joined: 7th May 2005
Location: Enfield, NC
Posted: 11th May 2007 10:52 Edited at: 11th May 2007 11:03
Did you learn how to program tile-based games from other people, school, or tutorials? What did you take to learn what maths to use to figure out the things needed to program tiles(particularly on finding how far a position is into a certain tile.). I know I just looked at that website I posted early to find out how far a position is into a tile and other things dealing with tiles, but I don't know exactly what it would take to find out that info. I asked because I just finished my 1st year in college and I'm majoring in computer science.
zenassem
22
Years of Service
User Offline
Joined: 10th Mar 2003
Location: Long Island, NY
Posted: 11th May 2007 11:18
It's funny. At first I learned it on my own, and from books or tutorials from and old magazine COMPUTE! that was out during the commodore64 AppleIIe hay-days. I understood multidimensional arrays, and a lot of brute force methods of solving problems. Of course it seemed OK, as these computers were slow no matter what you did, and you were basically coding in Machine Language. At least any graphic routines. Basic was too slow to even draw characters on the screen and refresh them, without the help of Simon's Basic (which was a basic language extension with machine language on cartridge)

Once I learned the basic concepts, i pretty much stayed with them all the way through my first IBM's and Gwbasic. I didn't really change my programming and thinking style till much later when I was a freshman in Computer Science. Especially my second semester when I was taking advanced C++ and data structures. It was being forced to learn data structures, algorithms, Big O notation, that I really starting making new leaps in design. Especially with Object Oriented rather than procedural, and templates, inheritance polymorphism. blah blah. But really it was learning how to code those data structures on my own (as opposed to MFC) that was the best gift. I understood arrays, but never tried sorting algorithms until then.

I worked with the stack in assembly, but never thought that it could be a programming structure. It didn't exist in basic back then and I never saw an article on anyone coding one.

then

Queues, Binary Search Trees, Linked Lists, Doubley Linked Lists.

I also never even thought about recursion and how many problems could be solved so elegantly.


So anyway it was around that time that I shifted most of what I had self taught, and went back to those ideas and started making improvements. My math skills were sharper, and processing power of today's computers unchained all the hoops I used to have to jump through to blit a darn pixel to the screen.


Unfortunately, I was so comfortable with 2D that it took me a long time to start working in 3D. Which is now. I've read tons about 3D. I've studied models, and looked at modeling programs. Read almost every thread here on 3D. But out of not knowing what I was doing, I never tried it for myself until 2 weeks ago. LOL. I picked back up on DBpro after being away fro more than a year and a half.

TLOZ
20
Years of Service
User Offline
Joined: 7th May 2005
Location: Enfield, NC
Posted: 25th May 2007 07:44 Edited at: 25th May 2007 07:45
Could someone take a look at my code and let me know how I could solve this problem? :

1. When the player moves down the slope, the player sprite blinks for 1 frame inside the sloped tile and is then repositioned on the slope to the correct position. How can I get the sprite to move down the slope without the blinking inside tile???

All media is included with this post.

***NOTE: You may have to adjust the "sync rate" command to get the program to run at a playable speed.***
zenassem
22
Years of Service
User Offline
Joined: 10th Mar 2003
Location: Long Island, NY
Posted: 25th May 2007 08:13 Edited at: 25th May 2007 08:50
I'll take a look now. Sorry, I got off of doing anything for this!


I need some time to take it all in. At glance, it looks like the function to place the player 1 pixel above, must not be getting called before the sprite positioning line.

I need to slow it down and output the values for player(1).y & player(1)main_y.

I am currently tracing through what happens for one condition, when the tilenum=8 which is your slope going up from the left side. Obviously it works, but it's one frame behind positioning properly.

Your code, like mine, got big real fast. And there are a lot of conditions and function calls. So it may take a little bit of time.



Progress:
-Witnessed situation you describe - looking over code
-Noticed that something is also not right with moving left. If you do, position on the map is lost
-Tracing through the source, familiarizing myself with the values.

..

TLOZ
20
Years of Service
User Offline
Joined: 7th May 2005
Location: Enfield, NC
Posted: 25th May 2007 08:33
What is it I'm doing wrong?
zenassem
22
Years of Service
User Offline
Joined: 10th Mar 2003
Location: Long Island, NY
Posted: 25th May 2007 08:53
Not sure just yet. I just started to slow it down. I can see the frame you are talking about. should have it in a sec. I can also see that when jumping, the landing goes too far into the tile and then repositions. It's not so much as being wrong, as handling many conditions. I know the feeling, and ran into this in trying to recreate marios jump.

TLOZ
20
Years of Service
User Offline
Joined: 7th May 2005
Location: Enfield, NC
Posted: 25th May 2007 09:01 Edited at: 25th May 2007 09:02
As for the sprite going into the tile when jumping, that was the only way I could get the player to land and get to the right position. The sprite also lands a little inside of the floor tiles, but I push him out by a float until he's back on top of the tile. This is also done before repositioning him on the slope to make sure he is always at the same position.

I noticed in tutorials that they have the sprite collide with the slope tile when falling and when there is a collision, the person just resets the sprite into the tile. Thats how its supposed to be right?

BTW, is that mario tutorial up or have you stopped working on it?
zenassem
22
Years of Service
User Offline
Joined: 10th Mar 2003
Location: Long Island, NY
Posted: 25th May 2007 09:08
I stopped working on it, but I have it around somewhere.

There may be better ways to handle the collision, but it's not a major problem. You are doing it right. My DBpro code, starts to look the same. Your theories are correct, but the implementation can definately be cleared up a bit, and made easier to read and follow. Not a big deal, but we can work on that part later.

I notice that he drops into the tile, has nothing to do with animation, or what i first suspected. It obvious that it is happening, between two tiles. So regardless of your code, the frame that gets messed up, is the moment that the character is passing from one slope tile to the next. That's where the error is. I am still trying to locate it in the code though.

TLOZ
20
Years of Service
User Offline
Joined: 7th May 2005
Location: Enfield, NC
Posted: 25th May 2007 09:13
Okay, you should probably look in "COLLISION_TILE_SLOPE_TO_SLOPE()" function. Thats where I check if the sprite is over a slope and if so, I move them down by the height of the slope.

I think thats where it is.
zenassem
22
Years of Service
User Offline
Joined: 10th Mar 2003
Location: Long Island, NY
Posted: 25th May 2007 09:20 Edited at: 25th May 2007 09:26
something must be happening to player(1).center_x inbetween tiles.

This line might be the culprit
player(1).center_x = int( player(1).main_x / 16 )

I have to test what center_x is equal to in tile transition periods.

TLOZ
20
Years of Service
User Offline
Joined: 7th May 2005
Location: Enfield, NC
Posted: 25th May 2007 09:25
Do you think I should check for the slope using a bigger boundary below the sprite? ( ex. tilemap(center_x, bottom+1) = 2 )
zenassem
22
Years of Service
User Offline
Joined: 10th Mar 2003
Location: Long Island, NY
Posted: 25th May 2007 09:28 Edited at: 25th May 2007 09:38
I was wrong. that's not the problem. I'm close though!

The problem is happening to Player(1).main_y during tile transitions.

Upon moving up slopes player(1).y isn't changing, but rather player(1).main_y is. at tile transitions it get's rounded to 48,64, etc... just need to find out where!

tiles(1).tile_altering goes to 0 at the same point!

TLOZ
20
Years of Service
User Offline
Joined: 7th May 2005
Location: Enfield, NC
Posted: 25th May 2007 09:33
Maybe I could have 2 arrays that hold the value of how much to subtract from the y position depending on the sprite's direction and I would use a bigger boundary for the collision points. If this worked, I could get rid of the function COLLISION_TILE_SLOPE_TO_SLOPE().
zenassem
22
Years of Service
User Offline
Joined: 10th Mar 2003
Location: Long Island, NY
Posted: 25th May 2007 09:43
I've searched thorugh the code, and I believe the only time that tile_altering could go to 0 while the tile below the player is 2 is in this function

FUNCTION UPDATE_PLAYER_POSITION_Y():
if tiles(1).tile_altering > 0
player(1).y = player(1).main_y
player(1).main_y = player(1).y
tiles(1).tile_altering = 0
endif
ENDFUNCTION

I am still testing, but I am about to print "GOTCHA!" from within this function
if i see it during the drop, I am on to something!

TLOZ
20
Years of Service
User Offline
Joined: 7th May 2005
Location: Enfield, NC
Posted: 25th May 2007 09:45
Hope that works!
zenassem
22
Years of Service
User Offline
Joined: 10th Mar 2003
Location: Long Island, NY
Posted: 25th May 2007 09:52
grr!! it wasn't that exactly. That code gets called only when you jump.

But I did find the problem

it's here
if Castle_Forest( player(1).center_x, player(1).bottom, 0 ) <> 2 and Castle_Forest( player(1).center_x, player(1).bottom, 0 ) <> 4 and Castle_Forest( player(1).center_x, player(1).bottom, 0 ) <> 5

`UPDATE_PLAYER_POSITION_Y()
print "gotcha1"
sync
tiles(1).tile_altering = 0
player(1).main_y = player(1).y
exitfunction

This code runs inbetween transitions of tiles, even though it shouldn't. For some reason which I'll find out
player(1).center_x,Player(1).bottom,0 is not equal to 2 inbetween tiles. Hence the above code gets called, messing up the character position for 1 frame.

TLOZ
20
Years of Service
User Offline
Joined: 7th May 2005
Location: Enfield, NC
Posted: 25th May 2007 09:55
Okay, that makes sense.
zenassem
22
Years of Service
User Offline
Joined: 10th Mar 2003
Location: Long Island, NY
Posted: 25th May 2007 10:08 Edited at: 25th May 2007 10:11
Ok, in between tiles the code is looking at the wrong array location.

edit
player(1).bottom is the culprit. it's not being updated until the next pass through the loop. It's what is causing the faulty look-up. Now how to fix it???


Castle_Forest( player(1).center_x, player(1).bottom, 0 )

is equal to 1, in between tiles and on the next pass through the loop it updates to 2. I am trying to pin-point it. But I can tell you what is happening.

As we are going up or down a slope, center_x & bottom are being updated. At the point of tile transition, for 1 pass through the loop, the values are incorrect and pointing towards the wrong array value, causing a value of 1 to be returned from Castle_Forest(). So for that 1 frame, the player Y's value - I believe player(1).main_y is messed up. It gets updated and fixed on the next pass through the loop, and moves the character up (dec in y value) to the right spot.

It's 3:00am , so I'm not exaclty at my best! lol

TLOZ
20
Years of Service
User Offline
Joined: 7th May 2005
Location: Enfield, NC
Posted: 25th May 2007 10:15
lol!, I get what you're saying. So one thing I should do is probably take the "player(1).main_y = player(1).y - tiles(1).tile_altering" out of the main loop and only update the y position directly after changing the value?
zenassem
22
Years of Service
User Offline
Joined: 10th Mar 2003
Location: Long Island, NY
Posted: 25th May 2007 10:49
yes something along those lines. I am trying something similar myself.

Another weird finding...

player(1).bottom = int( ( player(1).main_y + ( player(1).offset_y - 1 ) ) / 16 )

the second part of that equation:
player(1).offset_y-1 / 16

never changes. Even the float value. So It's really not doing anything except always adding 1 I believe.

BTW, I gave up on my code, becasuse I ran into the same issue. LOL. No joke. And I realized that I was testing the same conditions over and over, depending on direction. I also had the same jumping issue, except I was also trying to account for directional drift as the player was falling. Your code looks a lot like mine did. I got really frustrated with it. DBpro can be unforgiving when it comes to hardcoding logic. People make it sound real easy in example, but you find out how different it is to get it into your code, and not stall the main loop. So jumping cannot just be in a FOR loop. It needs to be updated 1 per game loop. You have to keep track of lots of flags. And check the same things for running as Is jumping. Lots of IF Ands & Or's.

I started thinking of an easier way to control these processes. And then I scrapped my code. I did find a cleaner way. One was creating states for the player (isRunning, IsJumping, IsFalling etc...) the other was calling cleaner routines. The subroutine should be the same for numerous conditions. Your code, like mine, has lots of repitition. You should have a subroutine that can handle different values being passed to it. Rather than having all of the duplicate code. I can work on a example tomorrow. It will help to illustrate what I mean.

It's interesting because I have been exactly where you are at. So I know exactly what is happening. Not knocking you or anything. Your logic is intelligent, but it took me getting to the same place to think, there has to be a better way to do this. The code grows real fast. And the next thing you know, it's hard to contain.
I will try to clean up some of the routines, from what I have learned.

TLOZ
20
Years of Service
User Offline
Joined: 7th May 2005
Location: Enfield, NC
Posted: 25th May 2007 10:52 Edited at: 25th May 2007 10:54
EDIT: don't worry about this post, didn't know if you had left to go to sleep or if you were still working on it.

Kind of confused here? In the post above, are you telling me how to fix it or are you still working on it?
zenassem
22
Years of Service
User Offline
Joined: 10th Mar 2003
Location: Long Island, NY
Posted: 25th May 2007 10:58
Probably both.

I'm not sure how to fix it just yet. I was agreeing with your suggestion. The value can't fall behind like that. My brain is not wanting to cooperate with me right now. I' going to break for now, and look at solving it exactly tomorrow. I'm just too tired to think straight at this point

then I go on a long babble of how I have been exactly where you are.

A litttle bit of the sleep stupids!

TLOZ
20
Years of Service
User Offline
Joined: 7th May 2005
Location: Enfield, NC
Posted: 25th May 2007 11:00
Thanks Zenassem, I really appreciate it. I hope cleaning up the code helps in solving the problem.
zenassem
22
Years of Service
User Offline
Joined: 10th Mar 2003
Location: Long Island, NY
Posted: 25th May 2007 13:26
I still haven't slept yet...

The problem will definately be solved today. Here's what I see we can do

- Solve the logic problem
- Clean up some of the code
- If you aren't going to have that many different angles in your map, you can really simplify your current code.

then

- Wait till you see how trivial all of this is, if you used Pseudo 2-D, and actually used 3d. Whether for the tiles, or in keeping everything the way you have it, except the collision is done 3d against an invisible terrain.

You might want to have a camera ready to take a picture of your face. Because if it looks anything like mine did, it will be nice to have a picture of yourself after vommiting for 30 minutes.

TLOZ
20
Years of Service
User Offline
Joined: 7th May 2005
Location: Enfield, NC
Posted: 26th May 2007 00:23
LOL! I'm pretty sure I'm going to be stunned at how simple I could have everything. However, I did solve the problem with the player showing up in the tile for one frame. The code is attached to this post. Its a .txt file and you'll need to copy and paste it into the editor. What do you think?

The thing I'm trying to change now is the landing on the slopes when jumping. Theres nothing wrong with how I have it setup right now, but as of now, I'd like to have the sprite land directly on the slope instead the sprite blinking into the tile below it.

I can't wait to see what you will do to code I gave you and how it SHOULD look.
TLOZ
20
Years of Service
User Offline
Joined: 7th May 2005
Location: Enfield, NC
Posted: 26th May 2007 09:25
Well, I just solved my problem with the jumping. The sprite now actually stops falling when it comes in contact with the slope image.

The code is attached to this post. Its also a .txt file.

Is there anyway I could turn my code into functions so I can call them for NPCs? Basically just simplify the code?
Roxas
19
Years of Service
User Offline
Joined: 11th Nov 2005
Location: http://forum.thegamecreators.com
Posted: 26th May 2007 15:08
Why not just use line collision?


[B] - LINKIN PARK - [/B]
TLOZ
20
Years of Service
User Offline
Joined: 7th May 2005
Location: Enfield, NC
Posted: 26th May 2007 20:04
Could you show me what you mean?
Roxas
19
Years of Service
User Offline
Joined: 11th Nov 2005
Location: http://forum.thegamecreators.com
Posted: 26th May 2007 22:37

Pic of 'our' project It uses line collision the lines are where u are walking on..


[B] - LINKIN PARK - [/B]
zenassem
22
Years of Service
User Offline
Joined: 10th Mar 2003
Location: Long Island, NY
Posted: 27th May 2007 04:47
Good job TLOZ... I'm going to shower, and pump some coffee into the tank. I'll be working on the translation of a text adventure tonight, but I'll try to look at your code as well. I wound up not sleeping for 2 days, and crashed a bit yesterday. Today I had to remove dead squirrels from my pool, and set up the filter. So my weekend is going fast. It will be an all =night coding session tonight.

zenassem
22
Years of Service
User Offline
Joined: 10th Mar 2003
Location: Long Island, NY
Posted: 27th May 2007 04:53 Edited at: 27th May 2007 04:57
@TFMCR-That looks alot like maple story. In fact it looks too much like maple story. Did you rip the graphics?????



@Tloz, not sure of it's in this thread or the other person that was asking a similar question on angles. But I posted about using line collision, either by code, or by having an image that is not displayed be checked for collisions.

But being that you have a tiling system, the collision is built in. It's just that your code kind of grew real quick, and it's a bit harder to reign it in. A lot of your code I would have broken down into simpler functions, and I would have generalized the subroutines, and passed into the routine tha array values and such.

TLOZ
20
Years of Service
User Offline
Joined: 7th May 2005
Location: Enfield, NC
Posted: 27th May 2007 08:55
@The Full Metal Coder Roxas, The graphics are really nice! It looks just like Maple Story. Now, Using lines for the collision seems like it would make checking for collision very easy. One question though, how would you get accurate collision if the lines for the collision checking are so small??? To me it seems like they would need to be a tad bit larger.

@Zenassem, right now, I don't know how I would go about simplifying my code, but I'm sure if I looked at it long enough I'd get it. I really appreciate your help and I do hope you get a chance to look at my code and see what I should do to get rid of the repeating code. If not, its cool. I'll probably start trying to shorten the code myself. I'll make sure to post anymore questions if they come up. BTW, I hope the translation of text works out.

Login to post a reply

Server time is: 2025-08-09 02:15:36
Your offset time is: 2025-08-09 02:15:36