Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[adrazar]

Does anyone know where I can find a pointer to the data structure of a given Bob?

[Volvo_0ne]

In the manual, there is a section entitled "Memory Bank Structures"
which seems to have useful info on the whereabouts of the Bob Images.

If you don't have the manual do a web search for "AmosPro.pdf"

Hope this helps.

also

Code: [Select]

AMOS:Sprite and Icon bank formats
A sprite bank and an icon bank share very similar attributes. They define graphic data which can be drawn onscreen.
4 bytes: "AmSp" for sprites (bank 1) or "AmIc" for icons (bank 2)
2 bytes: the number of sprites or icons to follow
many bytes: the above-counted sprites or icons
64 bytes: a 32-entry colour palette. Each entry has the Amiga COLORx hardware register format, which is 0x0RGB, where R, G and B represent red, green and blue colour components and are between 0x0 (minimum) and 0xF (maximum).

Each sprite or icon has this format:
2 bytes: width, in 16-bit words
2 bytes: height, in raster lines
2 bytes: depth, in bitplanes (1 to 5)
2 bytes: hot-spot X co-ordinate
2 bytes: hot-spot Y co-ordinate
many bytes: width*height*depth*2 bytes of planar graphic data(taken from http://www.amigacoding.com/index.php/AMOS:Sprite_and_Icon_bank_formats

[adrazar]

Sorry, no I was talking about a pointer to the entity created by the Bob instruction. I think (after reading about system tasks, library functions and that sort of things) a proper answer requires having had a look at the Amos-source found on this site.

[SamuraiCrow]

I don't think AmosPro uses OS structures for its bobs.  It would probably be faster if it did.

What were you hoping to get a pointer to?

Sent from my Prism II using Tapatalk

[adrazar]

There exists certain blocks in memory which corresponds to previously defined Bobs. These blocks contains information about the Bob's x and y position for instance (the ones returned by X Bob() and Y Bob()). I also expect them to contain the information associated with the Set Bob instruction. Since Set Bob fails to have any effect on already defined Bobs, direct manipulation of the data structure seems like the only way to simulate Set Bob on defined Bobs.

I can't find any trace of the pointers to these Bob structures using pointers provided by Amos, like Sceen Base. But they ought to be somewhere in the computer However finding them seems to require looking at Amos from the outside, and not from within. (and that's how I got into reading about the OS).

[KevG]

Not sure this will help you but just type in Listbank in direct mode to return the base address of bank 1 (sprite and bob images).

1. Create a bob then use listbank
2. Create another bob then use listbank

Doing this should give you the offsets and size of the data for each bob image.
However, it would require some work to identify the structure for the bob images.
If your images are say 16x16 pixels and ONE colour then that would give you something to work with.

Kev G.

p.s. Just read your post again and realized that you wanted 'pointers' and not the data structures themselves. How about...   Pointer=Start(1)

[adrazar]

@KevG: This is the same misunderstanding as with Volvo_0ne. I want pointers to Blitter Objects. Start(1) is only a pointer to the set of images that a Blitter Object may use.

[adrazar]

It just hit me that I would like access to the Bobs also in a compiled version of the program. This might narrow down where its feasible to look... or not. It depends how much the compiled version differ from the interpreted - a subject in which I find myself to be completely blank.

I believed the pointer could be be dug up from one of the following three locations: tc_UserData, tc_MemEntry or tc_SPReg, in the "task structure" (http://amigadev.elowar.com/read/ADCD_2.1/Includes_and_Autodocs_3._guide/node064B.html)
Could some of them be ruled out?

[Volvo_0ne]

I would think that there are more ways than one to write bob code, so I think (as you say) a detailed inspection of the AMOS system coding is probably the only way forward for your answer.

I like to (try) code in AMOS, but I know little about how it work internally.

Hope you find your answer.

V1

[adrazar]

I would think that there are more ways than one to write bob code, so I think (as you say) a detailed inspection of the AMOS system coding is probably the only way forward for your answer.

I like to (try) code in AMOS, but I know little about how it work internally.

Hope you find your answer.

V1

Thanks for the kind words It appears a bit of encouragement worked miracles this time, as I seem to have found the solution It really did help to examine the sources (which I actually couldn't find online before yesterday...)

Here are the ingredients I needed:

• AMOSPro V2.0 sources ( +w.s being the most interesting file)
• AP20 Resource Symbols (contains lots of offset definitions)
• An assembly crash course

Now, in +w.s the register a5 is generally used with the offsets defined in the file "AP20_Vect.s". Among the bob-related names contained in this file we find T_BbDeb = -6172 (likely short for Bob Debut). When checking its content in AMOS

Code: [Select]

BB=Leek(Areg(5)-6172) : Rem Areg(5) contains the value in register a5it turns out BB contains precisely the pointer I have been looking for!

There is one thing that worries me with this method though, and that is how much it can be trusted that Areg(5) will contain the right address at any given time while the program is running.

A simple way to verify the address runtime is by comparing Leek(Areg(5)-476) with Screen Base, as these should be equal when Areg(5) is correct. (-476 is one of the offsets listed in AP20_Vect.s).

However *should* the register Areg(5) happen to contain the wrong address, there does exist a way to recover the right one either way. That's because the address normally found in Areg(5) really is tc_UserData (see my previous post). This address is obtained through the following not-so-simple piece of code:

Code: [Select]

Set Equate Bank 12 : Rem (arbitrary bank number)
Areg(1)=0
TASKBASE=Execall(Lvo("FindTask"))
A5=Leek(TASKBASE+$58)
' Now proceed using A5 instead of Areg(5)

The reason I hesitate to recommend this over using Areg(5) is that it didn't compile very well last time I tried.

[DarkN3mo]

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...

[adrazar]

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.