-Thom
Attached Files
-
T06PLMOT.zip 4.79K
68 downloads
Edited by tschak909, Sun Jul 2, 2006 10:06 AM.
1
skips when using VBI?
Started by tschak909, Jul 2 2006 10:04 AM
1 reply to this topic
#1 OFFLINE
tschak909
-
-
- 161 posts
Chopper Commander
- Location:USA
Posted Sun Jul 2, 2006 10:04 AM
Whenever I use the VBI, I read the RTCLOK, AND how many cycles I want to trigger an appropriate event (such as updating a counter), for example, I am using it to update a set of counters for fine/coarse scrolling of playfield objects, and when the event triggers, it triggers several times.. am I using the VBI wrong? or am I going to have to create an inner loop of some sort to filter out the additional times the timer returns the same value? I thought that the VBI increments the RTCLOK each vertical blank?
-Thom
-Thom
#2 ONLINE
Rybags
-
-
- 10,323 posts
Quadrunner
- Location:Australia
Posted Sun Jul 2, 2006 10:44 AM
I just had a quick look (nice display).
Why are you doing ATTRACT mode calculations on the colours? Especially in your DLIs. You'll fairly quickly come to find that you'll run short on time at critical points. Many games/demos just dispense with attract completely - store a zero in $4D each VBI to ensure it never happens.
With RTCLOCK+2, if you AND #1, you have a zero condition every 2nd frame.
AND #2, you have a zero condition every 4th frame, AND #4 every 8th frame, etc.
As long as you perform that test inline in your VBI routine you should be fine.
If you want to do the test in the main loop, you would want to have the test in conjunction with logic that ensures that the code doesn't execute again until the next update of RTCLOCK.
To ensure that, it's fairly simple - just keep a copy of RTCLOCK+2. At the start of your main loop, just have a CMP, BEQ loop which waits for it to be inequal to RTCLOCK+2 - in the event that you had a lot of processing and it updated already, then execution resumes immediately.
e.g.
MAIN_START LDA RTCLOCK+2
CMP RTCOPY
BEQ MAIN
STA RTCOPY ; save current value
... processing stuff here
JMP MAIN_START
alternatively, you can just wait for RTCLOCK to change
LDA RTCLOCK+2
WAIT CMP RTCLOCK+2
BEQ WAIT
The disadvantage of the 2nd method is that if your main loop went for just a fraction over 1 frame, then it will sit idle for the entirety of the next frame.
Disadvantage of the 1st method is that if the main loop went somewhat more than 1 frame, then it starts again mid-frame and if screen updates are done, glitches can occur.
But, the methods you use can depend on your expected CPU utilization.
I don't expect you'll run short, but there's always the early VBlank option (just have a DLI near bottom of screen and base your timing from there).
Why are you doing ATTRACT mode calculations on the colours? Especially in your DLIs. You'll fairly quickly come to find that you'll run short on time at critical points. Many games/demos just dispense with attract completely - store a zero in $4D each VBI to ensure it never happens.
With RTCLOCK+2, if you AND #1, you have a zero condition every 2nd frame.
AND #2, you have a zero condition every 4th frame, AND #4 every 8th frame, etc.
As long as you perform that test inline in your VBI routine you should be fine.
If you want to do the test in the main loop, you would want to have the test in conjunction with logic that ensures that the code doesn't execute again until the next update of RTCLOCK.
To ensure that, it's fairly simple - just keep a copy of RTCLOCK+2. At the start of your main loop, just have a CMP, BEQ loop which waits for it to be inequal to RTCLOCK+2 - in the event that you had a lot of processing and it updated already, then execution resumes immediately.
e.g.
MAIN_START LDA RTCLOCK+2
CMP RTCOPY
BEQ MAIN
STA RTCOPY ; save current value
... processing stuff here
JMP MAIN_START
alternatively, you can just wait for RTCLOCK to change
LDA RTCLOCK+2
WAIT CMP RTCLOCK+2
BEQ WAIT
The disadvantage of the 2nd method is that if your main loop went for just a fraction over 1 frame, then it will sit idle for the entirety of the next frame.
Disadvantage of the 1st method is that if the main loop went somewhat more than 1 frame, then it starts again mid-frame and if screen updates are done, glitches can occur.
But, the methods you use can depend on your expected CPU utilization.
I don't expect you'll run short, but there's always the early VBlank option (just have a DLI near bottom of screen and base your timing from there).
Edited by Rybags, Sun Jul 2, 2006 10:56 AM.
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users
