Need some idea for BOB BG restoration while scrolling

Tigerskunk · 05 November 2016, 16:12

I am currently coding a game for a stock A500.

I have my scrolling running, and after some work on it, I can blit "static looking" BOBs into it, while the background scrolls. Means, they stay in place while the background moves, using a cartesian 2D coordinate for displaying on the screen.

Which wasn't that easy for me, all that scrolling stuff is quite new to me.
Btw, I am using the Aminet scrollingtrick.

But now I have the problem, that if I want to restore the background weird things happen.

What I want to ask is in this thread, is, how do other people generally tackle that issue with blitting, saving and restoring BOBs with a scrolling background?At the moment my game only scrolls into one direction at the same speed. I imagine keeping track of an 8way scroller and doing the blit/save/restore-thing on multiple objects must be a nightmare..

But maybe I just don't have the right idea yet and do stuff overly complicated.

So someone here who can give me an idea how to do this properly and hopefully less complicated than what I am doing at the moment?

Thanks for any help on that issue..

Master484 · 06 November 2016, 11:08

I don't know if this is of any help because I don't code in ASM, but because no one else hasn't posted an answer yet, I thought that I would try.

In Blitz Basic the whole BOB drawing / BG restoration thing is handled by two commands: BBlit and Unbuffer, but I guess that in ASM you have to code all the steps manually.

So, I think that the code steps should look something like this, performed in this order:

---

1. Firstly, when game loop starts, the bitmap should not have any BOBS in it, just the background.

2. Also I assume that hardware scrolling is used, so that only the "View" moves across the bitmap.

3. We now want to blit a 32*32 BOB into the bitmap. If the BOB is a moving object, update it's XY coordinates now.

4. Before blitting the BOB, we save a copy of a 32*32 area of the background, and store it to RAM. This area should be taken from the Bitmap XY coordinate where the BOB XY is currently located.

5. After this we draw the BOB to the bitmap.

6. Then we wait for the frame to end.

7. The second frame now starts, and we want to restore the background and move and draw the BOB to new coordinates.

8. So, before updating the BOB XY, we take the saved 32*32 background area, and blit it to the BOBs current ( =previous frame ) XY coordinates.

9. The background bitmap has now been restored, and we can now draw the BOB to it again. So now we just go back to step 3: update BOB XY, save the BG area, and draw BOB.

---

I think that the above steps are approximately correct; at least that is how I would try to do it if I didn't have the Blitz "BBlit" and "Unbuffer" commands.

Also about BOBs and Sprites: BOBs are always drawn to the Bitmap, unlike Sprites that are always drawn to the screen. So if you're drawing a static BOB to a scrolling screen, so that BOB stays at a certain screen XY while the Bitmap scrolls from right to left, this actually means that the BOB is moving right inside the bitmap. If the BOB wouldn't move inside the bitmap, then it would scroll with the bitmap.

And also, if the above system would be used for drawing and restoring many BOBS, then the BOB areas would need to be restored starting from the BOB that was drawn last. So if BOBs 1 , 2 and 3 were drawn in this order, then they need to be restored in this order: 3 , 2 and 1. This is to avoid problems when they're drawn on top of each other: for example BOB 3's "restore background area" would also include the graphics of BOB 2 and 1. Only BOB 1 restore area contains a clean bitmap, and this is why it needs to be restored last.

---

In my own game project Megaman X I use both BOBs and sprites. A large bitmap is hardware scrolled, and every frame I store the current "View" XY coordinates to variables. And for BOB drawing coordinates I then use a simple correction like "BOB X + ViewX". This way I can use direct Screen coordinates to BOBs, and just add the "ViewX" and "ViewY" scroll variables to them to take care of the bitmap scrolling offset.

And for Sprites I use the same coordinate system as for the BOBS, but before drawing them I have to substract the ViewX and ViewY from their XY to transform the Bitmap coordinates into Screen coordinates.

Hope this helps.

phx · 06 November 2016, 21:06

What Master484 wrote is correct. After you mastered the "scrolltingtrick", there is really no rocket-science behind drawing/restoring BOBs.

BOBs have absolute coordinates, which can be outside the visible display, in which case they are not drawn. The current View of the bitmap also has a coordinate, which specifies the currently visible upper-left edge of the display area. I am usually handling this with BOB structures in three lists:

- Unused BOBs. No processing time needed. Take an object from this list, when a new BOB is activated.
- Invisible BOBs. Active BOBs, which move, but are currently not visible on screen.
- Visible BOBs. Active and currently visible.

BOB positions are checked against the current View region and BOBs can move between Visible and Invisible lists.

When they are visible, their position on the bitmap is calculated relative to the View's current origin.

The BOB's background is saved and the bitmap-pointer of the saved location is remembered together with the buffer, so it can be easily restored. Then draw it.

At the beginning of the next frame the buffer is easily restored using the address (no calculations required).

Also refer to SolidGold/bob.asm. But it's much more complicated than you need for a simple horizontal scroller.

alkis · 06 November 2016, 22:01

A bit off-topic...but how many 32x32x5 can a A500 (with only chip memory) can do?

roondar · 06 November 2016, 23:08

Quote:

Originally Posted by phx

What Master484 wrote is correct. After you mastered the "scrolltingtrick", there is really no rocket-science behind drawing/restoring BOBs.

BOBs have absolute coordinates, which can be outside the visible display, in which case they are not drawn. The current View of the bitmap also has a coordinate, which specifies the currently visible upper-left edge of the display area. I am usually handling this with BOB structures in three lists:

- Unused BOBs. No processing time needed. Take an object from this list, when a new BOB is activated.
- Invisible BOBs. Active BOBs, which move, but are currently not visible on screen.
- Visible BOBs. Active and currently visible.

BOB positions are checked against the current View region and BOBs can move between Visible and Invisible lists.

When they are visible, their position on the bitmap is calculated relative to the View's current origin.

The BOB's background is saved and the bitmap-pointer of the saved location is remembered together with the buffer, so it can be easily restored. Then draw it.

At the beginning of the next frame the buffer is easily restored using the address (no calculations required).

Also refer to SolidGold/bob.asm. But it's much more complicated than you need for a simple horizontal scroller.

This!
The SolidGold source is a great help to see how to use ASM for all sorts of elements in a game

Quote:

Originally Posted by alkis

A bit off-topic...but how many 32x32x5 can a A500 (with only chip memory) can do?

The short answer is: it actually depends on quite a few factors (though screen size and screen depth are the most important). Assuming 50Hz refresh rate, usually more than 10 but less than 15.

The longer answer: see this thread for a calculation example for 320x256x5 and the formula's needed to for calculate different screen sizes.

alkis · 07 November 2016, 02:36

Quote:

Originally Posted by roondar

The longer answer: see this thread for a calculation example for 320x256x5 and the formula's needed to for calculate different screen sizes.

Nice analysis on that thread! Thanks for the pointer!

Tigerskunk · 07 November 2016, 14:11

Quote:

Originally Posted by phx

What Master484 wrote is correct. After you mastered the "scrolltingtrick", there is really no rocket-science behind drawing/restoring BOBs.

BOBs have absolute coordinates, which can be outside the visible display, in which case they are not drawn. The current View of the bitmap also has a coordinate, which specifies the currently visible upper-left edge of the display area. I am usually handling this with BOB structures in three lists:

- Unused BOBs. No processing time needed. Take an object from this list, when a new BOB is activated.
- Invisible BOBs. Active BOBs, which move, but are currently not visible on screen.
- Visible BOBs. Active and currently visible.

BOB positions are checked against the current View region and BOBs can move between Visible and Invisible lists.

When they are visible, their position on the bitmap is calculated relative to the View's current origin.

The BOB's background is saved and the bitmap-pointer of the saved location is remembered together with the buffer, so it can be easily restored. Then draw it.

At the beginning of the next frame the buffer is easily restored using the address (no calculations required).

Also refer to SolidGold/bob.asm. But it's much more complicated than you need for a simple horizontal scroller.

Guess my Problem is, that I am currently using a "static" coordinate system for the Bobs. Means, they are not bound to the world coordinates, but only to screen coordinates. So even if the background scrolls, my Bobs are not moving (little bit like Sprites). Makes a couple of things easier, but I guess in the overall scheme of things, it just complicates stuff tremendously.

Guess I will make some changes to my BOB engine over the next few days, then...

roondar · 07 November 2016, 16:56

Quote:

Originally Posted by Steril707

Guess my Problem is, that I am currently using a "static" coordinate system for the Bobs. Means, they are not bound to the world coordinates, but only to screen coordinates. So even if the background scrolls, my Bobs are not moving (little bit like Sprites). Makes a couple of things easier, but I guess in the overall scheme of things, it just complicates stuff tremendously.

Guess I will make some changes to my BOB engine over the next few days, then...

Be sure not to overcomplicate it - in essence all you ever have to do for restoring a background is to copy back whatever was at the exact spot the bob was drawn 1 frame earlier.

I personally found a very easy way to do this is to store the adress I blit too in a list* and then restore using that adress as the destination pointer a frame later (keeping blitsize/modulo exactly the same as used by the bob).

*) F.ex. as part of the bob structure.

Seems to me phx is suggesting more or less the same thing, but with additional ideas for how to deal with visible/invisible bobs.

Note that doing the restore this way means the restore routine does not need to know anything about coordinates at all, which simplifies things quite a bit

Tigerskunk · 07 November 2016, 19:44

Quote:

Originally Posted by roondar

I personally found a very easy way to do this is to store the adress I blit too in a list* and then restore using that adress as the destination pointer a frame later (keeping blitsize/modulo exactly the same as used by the bob).

That's exactly the kind of simple idea I was searching for!

Just keeping the (already calculated) adress of the last blit in my bob structure instead of the coordinates.

Damn, it's so simple, why didn't I come across this idea myself?

Thanks man...

alkis · 07 November 2016, 20:11

Quote:

Originally Posted by Steril707

Damn, it's so simple, why didn't I come across this idea myself?

I may be totally wrong, but I get a hunch you'll run into trouble when that address is scrolled-out?

roondar · 07 November 2016, 20:55

Quote:

Originally Posted by alkis

I may be totally wrong, but I get a hunch you'll run into trouble when that address is scrolled-out?

Indeed. But there is a solution for that as well: keep a buffer zone around the edges of the bitmap the size of the biggest bob. That way the restore should always fit.

Tigerskunk · 07 November 2016, 20:59

Quote:

Originally Posted by alkis

I may be totally wrong, but I get a hunch you'll run into trouble when that address is scrolled-out?

Might be, but for my simple side scroller thats not much of a problem right now.

But thanks for giving some additional ideas how to properly implement this...

Tigerskunk · 11 November 2016, 20:00

Just wanted to write, that the address saving was the Missing idea, everythings running smooth now.

Thanks again for the help, everybody.

05 November 2016, 16:12	#1
Tigerskunk Inviyya Dude! Join Date: Sep 2016 Location: Amiga Island Posts: 2,797	Need some idea for BOB BG restoration while scrolling I am currently coding a game for a stock A500. I have my scrolling running, and after some work on it, I can blit "static looking" BOBs into it, while the background scrolls. Means, they stay in place while the background moves, using a cartesian 2D coordinate for displaying on the screen. Which wasn't that easy for me, all that scrolling stuff is quite new to me. Btw, I am using the Aminet scrollingtrick. But now I have the problem, that if I want to restore the background weird things happen. What I want to ask is in this thread, is, how do other people generally tackle that issue with blitting, saving and restoring BOBs with a scrolling background?At the moment my game only scrolls into one direction at the same speed. I imagine keeping track of an 8way scroller and doing the blit/save/restore-thing on multiple objects must be a nightmare.. But maybe I just don't have the right idea yet and do stuff overly complicated. So someone here who can give me an idea how to do this properly and hopefully less complicated than what I am doing at the moment? Thanks for any help on that issue.. Last edited by Tigerskunk; 05 November 2016 at 16:18.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
A4000T Restoration!	fitzsteve	Hardware pics	17	17 December 2011 12:28
Bob's Bad Day - ... no Bob.	AB Positive	support.Games	5	16 May 2009 01:45
Mousepointer restoration and varying audio pitch at savestate restoration	NoX1911	support.WinUAE	0	22 January 2007 20:19
Bob's Bad	Twistin'Ghost	Retrogaming General Discussion	3	06 February 2002 13:50
Bomber Bob	Tim Janssen	request.Old Rare Games	2	07 January 2002 16:16

06 November 2016, 11:08	#2
Master484 Registered User Join Date: Nov 2015 Location: Vaasa, Finland Posts: 525	I don't know if this is of any help because I don't code in ASM, but because no one else hasn't posted an answer yet, I thought that I would try. In Blitz Basic the whole BOB drawing / BG restoration thing is handled by two commands: BBlit and Unbuffer, but I guess that in ASM you have to code all the steps manually. So, I think that the code steps should look something like this, performed in this order: --- 1. Firstly, when game loop starts, the bitmap should not have any BOBS in it, just the background. 2. Also I assume that hardware scrolling is used, so that only the "View" moves across the bitmap. 3. We now want to blit a 3232 BOB into the bitmap. If the BOB is a moving object, update it's XY coordinates now. 4. Before blitting the BOB, we save a copy of a 3232 area of the background, and store it to RAM. This area should be taken from the Bitmap XY coordinate where the BOB XY is currently located. 5. After this we draw the BOB to the bitmap. 6. Then we wait for the frame to end. 7. The second frame now starts, and we want to restore the background and move and draw the BOB to new coordinates. 8. So, before updating the BOB XY, we take the saved 32*32 background area, and blit it to the BOBs current ( =previous frame ) XY coordinates. 9. The background bitmap has now been restored, and we can now draw the BOB to it again. So now we just go back to step 3: update BOB XY, save the BG area, and draw BOB. --- I think that the above steps are approximately correct; at least that is how I would try to do it if I didn't have the Blitz "BBlit" and "Unbuffer" commands. Also about BOBs and Sprites: BOBs are always drawn to the Bitmap, unlike Sprites that are always drawn to the screen. So if you're drawing a static BOB to a scrolling screen, so that BOB stays at a certain screen XY while the Bitmap scrolls from right to left, this actually means that the BOB is moving right inside the bitmap. If the BOB wouldn't move inside the bitmap, then it would scroll with the bitmap. And also, if the above system would be used for drawing and restoring many BOBS, then the BOB areas would need to be restored starting from the BOB that was drawn last. So if BOBs 1 , 2 and 3 were drawn in this order, then they need to be restored in this order: 3 , 2 and 1. This is to avoid problems when they're drawn on top of each other: for example BOB 3's "restore background area" would also include the graphics of BOB 2 and 1. Only BOB 1 restore area contains a clean bitmap, and this is why it needs to be restored last. --- In my own game project Megaman X I use both BOBs and sprites. A large bitmap is hardware scrolled, and every frame I store the current "View" XY coordinates to variables. And for BOB drawing coordinates I then use a simple correction like "BOB X + ViewX". This way I can use direct Screen coordinates to BOBs, and just add the "ViewX" and "ViewY" scroll variables to them to take care of the bitmap scrolling offset. And for Sprites I use the same coordinate system as for the BOBS, but before drawing them I have to substract the ViewX and ViewY from their XY to transform the Bitmap coordinates into Screen coordinates. Hope this helps.

06 November 2016, 21:06	#3
phx Natteravn Join Date: Nov 2009 Location: Herford / Germany Posts: 2,545	What Master484 wrote is correct. After you mastered the "scrolltingtrick", there is really no rocket-science behind drawing/restoring BOBs. BOBs have absolute coordinates, which can be outside the visible display, in which case they are not drawn. The current View of the bitmap also has a coordinate, which specifies the currently visible upper-left edge of the display area. I am usually handling this with BOB structures in three lists: - Unused BOBs. No processing time needed. Take an object from this list, when a new BOB is activated. - Invisible BOBs. Active BOBs, which move, but are currently not visible on screen. - Visible BOBs. Active and currently visible. BOB positions are checked against the current View region and BOBs can move between Visible and Invisible lists. When they are visible, their position on the bitmap is calculated relative to the View's current origin. The BOB's background is saved and the bitmap-pointer of the saved location is remembered together with the buffer, so it can be easily restored. Then draw it. At the beginning of the next frame the buffer is easily restored using the address (no calculations required). Also refer to SolidGold/bob.asm. But it's much more complicated than you need for a simple horizontal scroller.

06 November 2016, 22:01	#4
alkis Registered User Join Date: Dec 2010 Location: Athens/Greece Age: 53 Posts: 722	A bit off-topic...but how many 32x32x5 can a A500 (with only chip memory) can do?

11 November 2016, 20:00	#13
Tigerskunk Inviyya Dude! Join Date: Sep 2016 Location: Amiga Island Posts: 2,797	Just wanted to write, that the address saving was the Missing idea, everythings running smooth now. Thanks again for the help, everybody.

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)