Job meter: Difference between revisions
mNo edit summary |
mNo edit summary |
||
Line 17: | Line 17: | ||
*Exit subroutine | *Exit subroutine | ||
< | <syntaxhighlight> | ||
VBlank: | VBlank: | ||
...BIOS calls... | ...BIOS calls... | ||
Line 26: | Line 26: | ||
move.w #GREEN,BACKDROPCOLOR | move.w #GREEN,BACKDROPCOLOR | ||
rts | rts | ||
</ | </syntaxhighlight> | ||
As long as there's no red lines on the top, the code is sure to run fast enough to avoid video glitches. | As long as there's no red lines on the top, the code is sure to run fast enough to avoid video glitches. | ||
[[Category:Code]] | [[Category:Code]] |
Revision as of 13:43, 14 March 2012
The Job meter is the name given by some developers to a mean of knowing how much time (or video lines) some of the CPU calculations take to execute.
For example, this can be useful to know if VRAM updates don't go over the vblank period, or to find what routines are causing slowdowns...
Job meters are made by changing a palette value before and after execution of said code. Multiple routines can be measured by using multiple colors. Some job meters can also consist of a value displayed on the fix layer to indicate how buffers (ennemies, ammo, animation loops...) are filled.
Something as simple as this in the vblank subroutine can be used to monitor time usage by looking at the borders of the screen:
- Do BIOS calls and anything which has to be done right after vblank
- Set "Bad" color
- Update VRAM
- Set "Okay" color
- Update values in RAM, prepare stuff for the next frame...
- Set "Done" color
- Exit subroutine
VBlank:
...BIOS calls...
move.w #RED,BACKDROPCOLOR
...VRAM update code...
move.w #ORANGE,BACKDROPCOLOR
...Sprite position update code...
move.w #GREEN,BACKDROPCOLOR
rts
As long as there's no red lines on the top, the code is sure to run fast enough to avoid video glitches.