![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
(Action RPG) Return to Playfield
Nov. 5th, 2006 07:06 amI'm going to have to admit defeat on attempting to unlink the SP bar from the HP bar for now. There's a lot more to consider than I originally realized about needing the cycle73 routine. Especially when I use a regular hmove routine at the same time at other parts of the screen. (For the player which can be positioned during vertical blank.)
Essentially, since the movement registers don't change unless we reset them to the value 0000 with the hmclr register, or unless we alter them individually ourselves, whenever we hit hmove, anything with a specified offset is going to move. But here's the real problem.
With a regular hmove, the value of 0000 in the movement registers indeed represents "no movement" or "move to the right 0 pixels"... With a cycle 73 hmove, that same 0000 suddenly represents -8. (A shift to the left by 8 pixels). So anything positioned with a regular hmove command will suddenly be affected by this unless we can alter it's movement register first, changing it to "1000" (Which means 0 in the cycle 73 hmove. - it means move by +7 in regular hmove's tho, or something similar)
In addition to this, there's some timing issues involved with the branch used in the HP bar. When it triggers it ends up taking a cycle too long and pushes the cycle 73hmove I try to use to hmove cycle 75+. (Haven't examined it to see exactly how bad the time cost is) So as a result, my hmove73 suddenly changes to a regular hmove at times, which totally throws off timings and positions.
What I'm going to have to do is try to develop my own cycle 73 hmove routine it seems so I can replace the regular hmove routine I currently use. Using two different routines is just going to complicate things.
But before that I want to work on the playfield again for a while. I've been looking at the code supercat posted in the msgs earlier in the blog and while some of it is still greek, I do see how it works. I'm going to see what it'll do to reduce the size of the existing display code I use. I can already see it freeing up a register, so that's good.
So I guess beta 2 was actually the final for Version 0.008. >_>
Essentially, since the movement registers don't change unless we reset them to the value 0000 with the hmclr register, or unless we alter them individually ourselves, whenever we hit hmove, anything with a specified offset is going to move. But here's the real problem.
With a regular hmove, the value of 0000 in the movement registers indeed represents "no movement" or "move to the right 0 pixels"... With a cycle 73 hmove, that same 0000 suddenly represents -8. (A shift to the left by 8 pixels). So anything positioned with a regular hmove command will suddenly be affected by this unless we can alter it's movement register first, changing it to "1000" (Which means 0 in the cycle 73 hmove. - it means move by +7 in regular hmove's tho, or something similar)
In addition to this, there's some timing issues involved with the branch used in the HP bar. When it triggers it ends up taking a cycle too long and pushes the cycle 73hmove I try to use to hmove cycle 75+. (Haven't examined it to see exactly how bad the time cost is) So as a result, my hmove73 suddenly changes to a regular hmove at times, which totally throws off timings and positions.
What I'm going to have to do is try to develop my own cycle 73 hmove routine it seems so I can replace the regular hmove routine I currently use. Using two different routines is just going to complicate things.
But before that I want to work on the playfield again for a while. I've been looking at the code supercat posted in the msgs earlier in the blog and while some of it is still greek, I do see how it works. I'm going to see what it'll do to reduce the size of the existing display code I use. I can already see it freeing up a register, so that's good.
So I guess beta 2 was actually the final for Version 0.008. >_>
