![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
(Action RPG) Fixed-Point movement
I've changed the way the player moves to make use of fixed-point math. In the rom right now I replaced the castle with a simple square in the middle so I could work on screen clipping with the new movement code. Took me a while to get that right, once again due to my confusing how cmp works with setting the carry flag. I seem to keep testing for the opposite case than what's called for. ^^;
Also, another strange thing I had going was that movement got busted as soon as I swapped in the new code.
If I moved directly down, it worked normally.
If I moved to the right, I ended up moving diagonally down-right until I hit a wall where I'd get stuck. (The collision code is still using the old code, so it no longer works properly just yet. >_>
If I moved left or up however, I instantly got warped either off the screen or to the very top/left of the screen. I have to assume that's what happens in the left case, as the player would vanish under the playfield at the time.
The problem with left/up was mainly with me not specifically setting all the movement variables. I didn't init the ones that should have been 0 figuring they should already be zero after going through the initialization code... There was also the flipped carry branch I was using with the screen clipping. After I corrected those things, those directions didn't cause too much of a problem.
As for the diagonal movement, that was caused because in the original code, I was not using the accumulator for anything but holding the joystick reading as I rol'ed the bits out. Of course, the new code uses the accumulator heavily, and x and y in the math functions. So in the left/right cases, after rol'ing out a bit to test, I saved it to my scratch variable, TempVariable. Then when I would be ready to test the up/down half of the controller, I would reload it again.
This fixed the diagonal problem.
I worked on the diagonal problem first, so I can only assume if I worried about that last, then the up/left would have had a diagonal problem as well once it's reset-to-zero error was fixed...
No rom to show this time. ;) I'm going to start in on changing the collision code to work with the new setup first and post the final version of 0.005 when that's done.
Also, another strange thing I had going was that movement got busted as soon as I swapped in the new code.
If I moved directly down, it worked normally.
If I moved to the right, I ended up moving diagonally down-right until I hit a wall where I'd get stuck. (The collision code is still using the old code, so it no longer works properly just yet. >_>
If I moved left or up however, I instantly got warped either off the screen or to the very top/left of the screen. I have to assume that's what happens in the left case, as the player would vanish under the playfield at the time.
The problem with left/up was mainly with me not specifically setting all the movement variables. I didn't init the ones that should have been 0 figuring they should already be zero after going through the initialization code... There was also the flipped carry branch I was using with the screen clipping. After I corrected those things, those directions didn't cause too much of a problem.
As for the diagonal movement, that was caused because in the original code, I was not using the accumulator for anything but holding the joystick reading as I rol'ed the bits out. Of course, the new code uses the accumulator heavily, and x and y in the math functions. So in the left/right cases, after rol'ing out a bit to test, I saved it to my scratch variable, TempVariable. Then when I would be ready to test the up/down half of the controller, I would reload it again.
This fixed the diagonal problem.
I worked on the diagonal problem first, so I can only assume if I worried about that last, then the up/left would have had a diagonal problem as well once it's reset-to-zero error was fixed...
No rom to show this time. ;) I'm going to start in on changing the collision code to work with the new setup first and post the final version of 0.005 when that's done.
no subject
no subject
I'm writing it in straight assembly. There's not much else you can do for the 2600 as even C is too slow and takes away the much needed timing control for drawing to the screen. You literally need to know where the TV beam is going to be when it's drawing the picture as you'll be updating registers to change the data being sent to it only a few cpu cycles ahead of the beam.
The only other option available would be to use "Batari Basic" which someone developed to help abstract out the writing of the code. The syntax of the code you write for that is much like basic I believe, but I haven't looked at it too much. While it makes writing code a lot easier, it also eats up the majority of the limited resources for it's own workings and limits what you can do. :)