Just to let you all know. Site has been neglected for last few years.
I'm planning on reviving site. So it may be up and down over next few days.

Quote from: DarkN3mo on 24 Dec, 2024, 06:26 AM

Quote from: FOL on 22 Jul, 2024, 08:43 AM

Quote from: DarkN3mo on 02 Jul, 2024, 03:03 AM
hello

any news ?

MadAngus has not been online for atleast 7 years. I can only assume the worst.
I have no way of contacting him, I have tried emailing numerous times.

I know,

Quote from: FOL on 22 Jul, 2024, 08:43 AM

Quote from: DarkN3mo on 02 Jul, 2024, 03:03 AM
hello

any news ?

MadAngus has not been online for atleast 7 years. I can only assume the worst.
I have no way of contacting him, I have tried emailing numerous times.

great!

what's the status of this project?

yes, it's a shame, a website is much more practical than facebook.

Quote from: DarkN3mo on 09 Aug, 2024, 11:29 AM
The aim is to have several bob data in fast, and copy on bank 1 of bob 1.

The procedure to accomplish this is a bit complicated

However, what needs to be known about the data structures is readily found on this page in the manual
https://www.ultimateamiga.co.uk/HostedProjects/AMOSFactory/AMOSProManual/14/1430.html
and on the top of the next page (next-button is located in bottom right corner).

So to create a custom sprite bank, the manual says you can do this:
IMAGES=1
Reserve As Work 1,2+8*IMAGES
Doke Start(1)-12,5

Then you need to reserve some chip memory for the image data, and loke the address of this memory block into
Start(1)+2+8*(IMAGE-1)

This chip memory block can be larger than required for a given bob image, which means you may theoretically use the same memory block for images of different sizes. All that remains to be done is then to copy the image data from fast ram into this memory block (you should use the Copy instruction for this).

Things to keep in mind:

• It will get hard to avoid memory leak problems if you let amos compute masks for your images. Either set the mask address to -1 OR keep a precomputed mask in fast ram for each bob image (which you copy to chip ram the same way as with the ordinary image data).
• You must always do Doke Start(1)-12,0 before erasing bank 1.
• It is probably a good idea to make sure the value of Deek(Start(1)) is always the same as the highest-numbered image in the bank.

Hello DarkN3mo!

Yes, I was able to access the internal data structure of the bobs. Which means data like x,y-position, image number, the values used in Set Bob, a pointer to the stored background image, etc.

So first and foremost the bobs forms a linked list: the first four bytes in the bob is a pointer to the next bob (zero if there are no more bobs). The order in which the bobs appear in the list is the same as the order they are drawn on the screen - usually this means in ascending order with respect to bob number, unless Priority On has been used. The bob data itself it could vary a bit depending on the version of amos being used, so to find a particular piece of data one should consult the appropriate version of the amos source code, or one could try to figure it out experimentally in amos.

I've found only one use for this though. However, it's a pretty powerful one: It's based on the fact that the address Areg(5)-6172 contains a zero if and only if all bobs are off. This means that if we have some bobs defined then Areg(5)-6172 will contain a non-zero value. Suppose we store this value in a variable BBGROUPA and loke zero into Areg(5)-6172. Now amos will think that there are no bobs, so nothing will happen if we do for instance Bob Clear. Moreover, if we use Bob N,X,Y,IMG with one of the previously defined bob numbers, instead of moving the existing bob, a new one will be created. Future bob drawing commands will affect only these new bobs, never the old ones. We can switch back to the old bobs by first saving the new contents of Areg(5)-6172 into a second variable BBGROUPB and then loke the value of BBGROUPA into Areg(5)-6172. Now only the bobs from the first group will be rendered, and none from the second. Thus this method makes it possible to create units of bobs which can be rendered separately, which can be a very useful resource for speeding up the rendering in programs that rely on bobs.

Quote from: adrazar on 14 Oct, 2017, 02:19 PM
Does anyone know where I can find a pointer to the data structure of a given Bob?

Good morning.

have you found the solution?

because i'm also looking...

Has anyone ever tried copying from a BOB to a fast bank and vice versa?
The aim is to have several bob data in fast, and copy on bank 1 of bob 1.

the bob data must be in CHIP at the TIME you use it.
But it's perfectly possible to manually copy blocks of data between chip and fast, which is commonly done in commercial games.
The problem with Amos is finding where the bob data is stored and then making a copy using peek and poke.

Quote from: DarkN3mo on 02 Jul, 2024, 03:06 AM
yes, this site seems to be dead... it's a shame.

Blame Facebook. I believe they all use that instead. I hate Facebook.