Hi members of Cemetech my name is Mike.(But you can refer to me by my screen name) I recently had to migrate from UnitedTI after the shut-down.

Recently, I've been working on a Physics engine and I feel fairly proud of myself before getting to this point. I've got most of the physics parts done(at least I think I do) but came to a complete stop once I got to collision detection.

Now I wanted to ask about debugging my code. I didn't see any rules against simply posting my code. In any case, if it is against the rules, or this is the wrong place for this topic
I apologize.

My Physics routine has two point/vectors stored in memory. The current position of the object and the previous position of the object represent like this


Code:


Nothing to fancy

The Physics routine first puts the current position in the previous postion and then modifies the current position based on forces and velocity. It then finds the slope of these two points and simply used that slope to see if there is a collision.

Here's the actual code to detect collisions not the physic part.

Code:


I dont think there a problem with the main but I think there a problem with the called routines xslope and yslope

here is the called routine called xslope

Code:


And here is the called routine yslope


Code:


I'm not sure exactly what the error is. I am open to suggestion or even complete a completely different algorithm, even an already written routine. Any help is appreciated.

Welcome to Cemetech, Mike. Please Introduce Yourself in that thread, and be sure to say hi over on SAX and/or IRC. You've provided some code, which is always a good thing, but I'm afraid you're missing one component of a good request for programming help: you didn't describe what's wrong. You say you're not sure what the error is, but you didn't describe what happens (or doesn't), and what should (or shouldn't) happen instead.

Hmm.... fair enough

Ok the problem is the collision detection code won't detect collisions and as a result an object goes through tiles. sense gravity is a constant force the object simply goes down through floors instead of stopping(i.e apply the normal force and friction) when the position encounters floors/tiles.

Basically my collision detection works as if it wasn't there, as taking it out does not change how the program works.

Thanks for the clarification, now it makes sense. May I ask what debug steps you have taken thus far to try to track down the issue, if any? It sounded from your first post as though you're not sure if you have a fundamental math error or a coding/implementation error, is that correct?

Okay well after writing my routine I made sure it did one thing. Preserve the state of the registers. So this is what i assembled and ran to make sure it worked


Code:


I did this for each register (with the exception of ix) and as expected e was the only one that changed.

the same was also done with yslope and a respectively.

Next I essentially did the same thing only this time I made sure ix pointed to the tilemap. Next I set a(PREV_YPOS) to row were I knew there was a tile, particularly 40 but set e(PREV_XPOS) such that the coordinates (a,e) in the form of (y,x) would point to an empty tile in the tilemap, which is pointed to by ix, e was set to 48.

I then set b(X-component of the slope) to be something small like 2 to see if e would simply increase by 2 which worked

next I set b to a big number(96) to see if it would not increment the entire 96 to e, but stop once (a,e) pointed to a Clear tile. But to my luck it added the entire 96. And that's what I have been trying to figure out.

Does CheckClearTile work properly? Try putting a jr $ after jr c,SkipIncX to make sure that the code properly detects a collision, then follow the code with a debugger. And what exactly are slope X/Y? Are they essentially velocity values? What are their normal values?

Also, jumping around a lot can waste a bit of space/clocks, you could try something like this, it's not gonna fix your issue but it looks a little neater:

Code:
Or depending on what the value of slope X is, you could even just add slopeX to e (ld a,b \ add a,e). But anyway, why are you updating the X position if you hit an object? If you hit an object, shouldn't you stop and not continue moving?

I don't know if you want to give us something more to work with, i don't really know what is going on in your subroutines.

I'm pretty sure CheckClearTile works. A clear tile, as I defined it, is just a tile whose pointer is 0. Any other number means that it is a solid tile.

Anyways heres CheckClearTile. It fairly simple.


Code:


So if FindTile Works then this block of code from routine xslope should detect a tile (At least I think so)


Code:


As for FindTile It finds a tile in a tilemap who data is stored like this

Code:


And FindTile code

Code:




I'll try that



Y slope is simply (YPOS - PREV_YPOS) and X slope is (XPOS - PREV_XPOS). In essence there just Δy/Δx or slope.

At chickendude: thanks for the suggestion I'll try implementing them right away.

Do you have an emulator? You should check out WabbitEmu for Windows or TilEm2 for Linux, try taking a screenshot of what happens, as well as following it in the debuggers.

I can comment on your code, but i honestly don't know where the problem is. To me it looks like you update the x and y values even when there is a collision. And a lot of the code is unnecessary. For example, cp 0 will always reset the carry flag (so you don't need scf \ ccf), and "or a" (or "and a", but "or a" seems to be the standard) is actually a faster and smaller way of doing the same thing. And instead of scf \ ccf, you can use or a or and a, which won't change the value of a but will reset the carry. And all the jumps in SlopeLoop are making me a little dizzy

I don't know if you don't want to post a full zip of your source, but it would help (me) to be able to see what your code is doing

Anyway, it's always nice to see another z80 programmer

While we're on the topic of emulators, hopefully without self-advertising too much, we have an online emulator here at Cemetech, called jsTIfied:

http://www.cemetech.net/projects/jstified

I don't know if this is right but hear me out
The code checks to see if a position between the 2 positions(current postion and previous position) has a tile there.(at least thats what it is supposed to do)

If (a,e) in the form of (y,x) points to a tile in tilemap ix, then the code won't know it hit something until (a,e) actually points to a solid tile. If the position is actually on a solid tile I would want it to "back up" so that its not on the solid tile anymore.

Now the term "back up" is relative so I'll explain
if the difference in the x positions is negative and you "hit" something solid, then you want to increment the xpos once and the opposite is also true.

Likewise if the difference in y positions in negative then you want to decrement the ypos because that actually is moving in the positive direction so that the position isn't on the tile but just outside of it.



Thanks, I've use some of these little "tricks" and rewrote my routine.



Simply put, it just not that organized to give out yet. I lot of old version of the code and numerous other things. Until it gets more organized, I feel that I can only throw out pieces of code. Not to say I won't but....



I do have emulator as and I've taken a screenshot, but I'm having a little trouble with picasaweb.google.com to get my image up

I'm working on it


At KermMartian: Online huh, I'll try it

Will the object ever be able to move more than one tile at a time? I mean, if your tiles are 8 pixels by 8 pixels, will you ever be able to move 9 or more pixels at a time? I don't know if it's normal to use two variables (for old and new position). I think your slope variables are what i've been calling velocity. What i do is take the player's current position then add the X and Y velocity ("slope") to the X/Y coordinates, and pass these values to the collision detection routine. Check if there is a nonpassable tile, and if there is, block the player's movement (usually set the player's coordinates so that they are aligned against that tile). If the tile is free, then just store those coordinates back to the player's coordinates and continue.
For example:
http://www.mirari.fr/hBcx?.gif

Also, srl a uses 2 bytes and 8 t-states. It's not a huge deal, but rra is one byte and 4 t-states. It'd be quicker to do something like:
and %11111000 ;clear out bottom three bits
rra
rra
rra ;rotate 3 times/divide by 8

And looking through again, you might have reversed your dec e/inc e statements. If the value is negative (meaning the player is going up), you dec e, when maybe you should inc e. Again, i'm not sure how everything's set up, but usually a negative value means going up or left, and positive means going down or right.

EDIT: I don't know why the image isn't showing up, but it's not really that important.

Yes that was the plan to be able to move any amount of bit per frame (however I'm starting to see that maybe a little over my head)

Anyway I tried your method and I went from

this https://lh3.googleusercontent.com/-iq1h8TnkduI/T-EX-LOlQyI/AAAAAAAAAA4/RnFIUCwP2CU/s192/test.gif

to this https://lh4.googleusercontent.com/-qECauVbXDio/T-JCIQhwkoI/AAAAAAAAABI/JU6e5WsVYpw/s192/test2.gif

Thanks, this is better but I guess I had to do something wrong
The basic algorithm that I thought of was this

Add the velocity to the position
Check to see if there is a tile in that position
If there is
then set the position to the smallest/closest multiple of 8 (if the position is 41 then 40, but if its 39 then 32)
Zero the velocity in that direction

here is the actual code for detecting collisions in the y direction


Code:


May I ask how you would do it, or anybody. appreciate the help.

http://www.mirari.fr/hBcx?.gif
Did you make that, if so fairly impressive.

Velocity+1 is velocityY? Why do you negate it (2's complement it)?
Btw, the "jr YcollisionDone" can be replaced by a ret.

Instead of:

Code:
Try:

Code:
I also wouldn't store the result back into YPOS, if you want you can push af and pop it later, store the result in an unused register, or switch to the shadow registers. Then if you can pass, store the result. Otherwise, and %11111000 and store that back (at least, for going down). For going up, you could do that then add 8.

After many, many rewrites I finally got it working (mostly)

Notably, I still have 2 problems.
The first is fairly simple I have to make sure that the position doesn't go below zero
I tried this code when I am adding the Velocity to the postion...


Code:


But not working. I'm sure it's simple but haven't figured it out (yet)

Now at first glance this appears to work flawlessly. just simple.


Gravity working. It fall on the first platform and then fall to the ground
Normal Force is working. It stops once it hits a ground
Friction working.

The problem is that it only falls off of platform one way not the other
Here's a screenshot of what I mean



It code let you fall off the right but not the left. It think it might be a bug in the physics code and not the collision detection.

Here another demonstration with the platform moved



This code is the updated collision detection


Code:




Yes Velocity+1 is veloctityY. I negate it because I calculate the velocity based on the more used x,y plane rather than a computer plane.[/img]

So a negative velocity means the player falls down?

Also, keep in mind that if you are going to be using smooth (pixel by pixel) scrolling, you will need to test TWO tiles if the sprite is not aligned (or only check for collisions when the sprite is aligned, which might be a little complicated if your sprite can move more than 1 pixel at a time). For example, if your sprite is at X position 4, then you have 4 pixels in the first tile and 4 pixels overlapping into the second tile.

Try adding something like:

Code:

after the call FindTile (and before CheckClearTile) in the x detection routine to see if it's checking the right tile (you should see the tile number blinking up at the top somewhere).

I seemed to have created some sort of pseudo-physics

In the x-collision part, by changing this

Code:


by dec a after ld a,(YPOS) and before call FindTile, and changing the jump instruction to jr c,SkipCollision I get this...



This appears to be working even better but it is not working as originally intended.
If you look closely whenever it jumps and descends it only moving in increments of 8, when it should be moving based on acceleration.

and if the add a,8 is changed to add a,7 (or any number smaller than 8 ) then it won't move. This has led me to believe that the acceleration nor the velocity is responsible for its movement (going down) but the add a,8 is.

chickendude, I used what you said but I think it is checking the tile to the left and not the right (at least that what I see) so.. anyway heres what it looks like (with the original code and no changes besides yours)

based on this (and from my own tiledata) the standard floor is 9, the left and right edges of the the platforms are 22 and 25 respectively and blank space is 0. And from what I can tell, it checks the tile right below the bottom of the block.

Lastly when it is on the right platform, on its left edge, the number is zero and not 9 or 22, indicating that it is checking tile immediately to the left of the right platform.

What would it mean if it was checking the right tile? I'm slightly confused.

I gonna try post something later today.

When you're on the platform and it shows 0, is that when you are pressing left? It looks like the x detection is testing the row below the character. You might try also putting a block (with a different id, maybe 26 or 23) on the floor to see if it detects that or if it detects what's below it. When pressing left/right, it should tell you the id of the tile the sprite wants to enter.

And in FindTile, what is the "ld e,(ix+1)" for? Why +1?

Another thing to keep in mind is that ix (and iy) is much slower than the other registers, if you want to use it it's often a good idea to do as much as you can with the other registers before storing the value into ix. Like in your FindTile routine, you could save a couple bytes/clocks by adding de to hl first then pushing hl and popping it into ix.

Yes it is

I do that because tile data is stored like this...

Code:

basically, it's just indexing, multiply the number of columns by the y-coordinate (or de*a) to get the row the tile in and then add the x-coordinate to get the exact tile. ix+1 simply points to the number of columns. I know this is just the screen size map so it could be

Code:

or something along those lines to do quick multiplication by 12 but I want it to work for any tilemap



I tried that this is what happened

which make me conclude that it is looking at the tile to the left and not the right. Notice that if you going fast enough you do fall off.

I Think I figured out the problem. I wanted to say that there is something wrong with FindTile but apperently not as it show me the correct tile. I think it has something to do with AND %11111000.
Actually I think I'm on to something. If you notice when the block jumps It get aligned somehow.

and with this screenshot I've made it display hl display if a collision happens or

Code:


and again if you'll notice, It only says theres a collision while in the air, which is werid so maybe theres something wrong with CheckClearTlie

Well, you want it to be aligned if there is a collision, i think it's just checking the wrong tile for a collision. If you put the tile that is beside the platform on the ground, will the block stop? Also, remember that if the X velocity is negative, you need to check the tile to the left. Dividing by 8 should be fine. But if the X vel is positive, you'll need to add 8 (before dividing) or 1 (after dividing) to check the tile to the right.

Where is the player at YPOS=0? At the top or at the bottom?

It should. This screen shot is taken using my modified code of the x-collision(dec a,jr c instead of jr nc) and this is what happens

When it displays zero then it means that I'm pressing left but the object can't go left because of a collision. While the screenshot doesn't do a good job showing it, the object will do the same if coming from the left but it will let 7/8 of the sprite through. This is due to the fact that the sprite is drawn from the bottom up, left to right, so the code needs to check 8 from the sprite position in x and y direction when it checks movement (obviously I knew that I was just trying to solve the gravity problem first) but I think it might be time to just go ahead and do those changes now anyway.

So a basic algorithm for this would be..

Do y collision
Find the tile the position is located it
check to see if that tile is clear
if theres a collision, align it
subtract 8 from the y position (since the ypostion is at the bottom of the sprite
Do y collision again
repeat all steps for x

Or is there a different way to think about it.

Although I'm pretty sure I'm not the first I Also figured out the simple zero problem
if you add 8(or the width of the sprite) to the xpos and the number isn't bigger than 8 then set it to zero

and you can do the same with the ypos to with no changes other than your dealing with the y and not the x

chickendude though I haven't quoted you I belive I've answered your question, and I tried to post this as early as I could.

I'm going to try to Implement the changes and post something today