[blitz] - "bblit" sometimes destroys background

[peceha]

Hi,
maybe it doesn't destroy it but "forgets" what was under.
It can be seen on the following video (14 second, letter "q", when going North and then when going NE) - the first "bblit" doesn't remove "q" so it looks like "dragging" (or maybe "ghosting" - don't know how to name it).


[ Show youtube player ]

It happens rarely and I have no idea why. I tried unflash command but didn't help. Tried unbuffer in different places - no luck. Increased buffer size - still nada.

Any ideas what else I can try?
Thanks

ps:
ignore the background tiles "flashing" beyond/around the edge of FOV - this has nothing to do with main problem and I know how to fix it anyway.

[roondar]

There's several things that could be going wrong here, but without looking at the code for the loop you use to unbuffer/blit it's hard to be certain.

Now, I'm not really into Blitz Basic programming, but I can give a few pointers on things that tend to go wrong often when blitting and restoring. There's two main things that go wrong when blitting and restoring graphics.

Problem one: restore bobs (this is Blitz's unbuffer command) is in the wrong place.
The order should always be unbuffer first, then draw bobs.

Problem two: restore the wrong bobs when using double buffering. When double buffering, your restore command needs to be one step behind. Kind of like this:

Starting frame: (some games hide this first frame from the player, showing nothing instead)
Show: buffer 1 (which as yet has no bobs on it)
Unbuffer: nothing at all
Draw: to buffer 2

Now the main loop starts

Frame 2:
Show: buffer 2
Unbuffer: bobs drawn to buffer one (which is no bobs at all the first time you get here)
Draw: buffer 1

Frame 3:
Show: buffer 1
Unbuffer: bobs drawn to buffer 2
Draw: buffer 2

Repeat steps 2&3 for all time.
Note this means that double buffering generally requires two restore (=bob) buffers.

[peceha]

Thanks for the tips roondar. I looked how my code is working and looks like unbuffer is in correct place (and there is no double buffering for bobs)

I'm not going to post here all the code responsible for drawing since its quite messy at the moment and will be difficult to understand what is what.

Short, step by step explanation follows (which is quite long, sorry)
but there is no need to read it since I think I see the problem - am I allowed to do blitting and bblitting alternatively (blitting FOV tiles and bblitting entities)? - maybe that is breaking everything...



1. at the very beginning, the FOV is calculated for main hero and is drawn on one of the bitmaps. IMPORTANT: all entities within FOV are just blitted there (not bblitted)

2. when ready, that bitmap is shown on the screen

main loop starts here
------------------------
3. program now waits for me to pick a direction of movement

4. now, the "speed table" is being processed meaning that it calculates new positions for faster entities (in front of me) and remembers the route of such entities (they can be twice or even more faster then me, so they can move several times before my move comes)

5. when finally the speed table points to me all the mess starts:

bblitting LOOP starts here (8 loops)
-----------------------------
6. me (sprite) is being moved by 2 pixels per frame (tot. 16 pxl=8 frames)

7. one FOV octane is calculated for my destination position (entities within that octane will be blitted there as well) - all that blitting goes to HIDDEN bitmap (that is standard "blit"/"block" command)

8. unbuffer

9. loop through entities list

. if this is first frame of movement:
. program checks if the entity on visible bitmap should be moved (if not than
. such entity remains untached for the remainign 7 frames)

. - If entity must be moved than I blit background tile on top of it and then
. BBLIT entity (so it looks the same as before but now there is BBLIT already
. in game) - this happens on VISIBLE background

. if it is not the 1st frame:
. BBLIT all entities that were prepared in frame one

looping through entities list is finished

10. if this is 8th frame of movement than display hidden bitmap and clear the last active
The new bitmap will have all FOV drawn and all visible entities (but they will be blitted not bblitted)

----------------------------
bblitting LOOP loops here

----------------------
main loop ends here

[roondar]

It's quite possible that mixing blit and bblit to the same bitmap can lead to unexpected results, especially if they are 'randomly' mixed. It's usually best to do blitting in a strictly defined order. In this case, I'd suggest to unbuffer first, then do all non-bblit blits, then do all bblit blits. This should help prevent oddities.

Another potential source of issues is the switch between the hidden and visible buffer you do every 8 frames. The unbuffer command will always unbuffer to whatever bitmap was used to blit to, not the one currently shown. That might cause glitches if the unbuffer happens after you clear the buffer in step 10.

To fix that potential source of issues make sure to unbuffer first and then clear the hidden buffer.