20 October 2019, 21:09 | #1 |
Registered User
Join Date: Oct 2019
Location: Eydelstedt / Germany
Age: 44
Posts: 114
|
Vertical blank and Bobs
Hi,
Up to now, I used a wait for vertical blank like wait: cmpi.b #$ff,dff006 bne.s wait which worked just fine if i only used sprites. When using bobs, the bobs disappear somewhere near the bottom of the screen. I tried different methods which now work for the Bobs, but movements of the Sprites are not that smooth anymore. E.g. I use wait: move.l $dff004,d0 and.l #1ff00,d0 cmp.l #303<<8,d0 bne.s wait Can someone explain this? Greetings Christian |
20 October 2019, 22:29 | #2 |
OCS forever!
Join Date: Mar 2019
Location: Birmingham, UK
Posts: 418
|
Your first test was testing for vertical position 255. On a pal screen starting at the usual 44 ($2c) address in DIWSTRT that means you were waiting for a line that was actually about line 211 (in visible pixel terms) so still quite a way from the bottom of the screen. So would expect weirdness and disappearing BOBs, especially if you are clearing the screen.
The 2nd test is similar to one I've used and waits for 303 which is 259 pixel line which should work ok unless something else is amiss (your code could have passed line 303 before you make the test for example). Edit: lots of variations here: http://eab.abime.net/showthread.php?t=51928 |
20 October 2019, 23:00 | #3 |
Registered User
Join Date: Jun 2016
Location: europe
Posts: 1,063
|
BNE generally works OK, but you have to be sure you won't miss the sync raster line. If you are using interrupts that can happen around sync line, or your code is very tight and also takes some variable amount of time and can leak out of a frame for a few raster lines, you might miss the sync and you will drop from 50fps to 25fps. So perhaps BLO/BLT would work better.
About the sprites, it depends what you are doing with them... Assuming auto-DMA mode, maybe in some frames, due to variable nature of your code, you are updating them too late, since your sync is now delayed by 303-255=48 raster lines, and the sprites best work when updated before the end of vertical blanking. Again, just speculating, depends on the rest of the code. |
21 October 2019, 00:00 | #4 |
Registered User
Join Date: Oct 2019
Location: Eydelstedt / Germany
Age: 44
Posts: 114
|
But why do the sprites work perfectly using the wait for line 211? They do not disappear below line 211 as the bobs do.
|
21 October 2019, 10:04 | #5 | |
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,437
|
Quote:
The main difference is that sprites are (normally) drawn automatically. That is, you simply tell the sprite hardware where you want to draw a sprite and what it has to contain and it will automatically get the correct parts of the sprite image from memory at the correct time to display it. Sprites are also never cleared on the screen, they simply show only at the position they are programmed (as if they're tiny movable layers on top of the screen). This means that changing a sprite's position or contents will (normally) never cause the sprite to not display or only display partially*. Bobs meanwhile, are always drawn at whatever time during the screen update (beam position) the program says they need to be drawn. They also, unlike sprites, require you to clear/restore the old part of the screen first. These two things combined mean that drawing bobs is much more time sensitive. When you wait for the screen to hit a certain raster position and then start drawing you'll probably clear/restore the old bobs first. If this is done to a bob that overlaps the raster position you are waiting for, you can see the update process happen in real time. I.E. you might see the bob disappear because the clear/restore is (partly) done, but the drawing of the new bobs hasn't started yet. You might also see the bob display (partly) in the wrong colours if this happens to occur while the new bob is partly drawn. Hope this helps explain it *) Note that there are exceptions here: if you change a sprite's position or image data while the screen update is at the exact time part of the sprite is showing you will get part of the sprite at the old postion/with the old data and part of the sprite at the new position/with the new data. However, even then you won't remove the sprite, merely cause it to display in a glitched way. |
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
ASM: Wait for Vertical Blank | Asman | Coders. Tutorials | 75 | 01 October 2019 12:11 |
New tutorial on BOBs | Yragael | Coders. Tutorials | 9 | 15 August 2018 00:00 |
Clipping bobs | roondar | Coders. General | 18 | 24 September 2015 09:54 |
FS: Various bits n bobs | jujasi | MarketPlace | 0 | 12 July 2009 19:13 |
Bobs Garden | Big-Byte | Amiga scene | 7 | 26 October 2002 11:24 |
|
|