geoPBM
commented
3 years ago Further break down of this lead to seeing the that the x-pos is normalized and then divided by 2 and stored into the VIC. So the application can get an exact location if it is using doubling bits, or a very close location if it is using native screen coordinates. In this case it might not be worth the trouble to get this reclassified as global.
But it would still be a welcome change for consistency to in the system.
This variable contains the soft sprite x-position for sprites 0-7. I believe This should be reqXpos0 the first of 8 consecutive soft sprite x-positions.
I am currently creating an updated version of the HitchHiker's Guide to GEOS and believe the omission of this variable from the guide was a mistake. (By far not the only mistake found in the guide).
Argument for this being declared a global variable that has to remain at a fixed address.
You should write the x position to the global variables "reqXpos0, reqXpos1... (reqXpos0 is what scr_mobx should be called).
"Better yet, use the "PosSprite" call in the kernel." (Making reference to the fact that PosSprite sets reqXPos).
At this point I was thinking to just let it be and dont have reqXPos be global even though it should be since you can set the value of it using PosSprite.
Then I read this. "Reading values from the VIC chip... This is also ok for the status values and for the y position. The x position can be useful also, if you use the PosSprite call. In addition to filling the global variables reqXpos0, etc" (This is pointing out you can get all the information from a sprite from the data stored in the VIC except for the x position. Since PosSprite sets that variable that would not be a problem). But it is since it has now been declared as being private.
This is a problem. With that variable being considered as private kernal space the application has no way to check the current x-position of a sprite on the 80 column screen. If the variable is considered as as global this would not be a problem. I could simply document the 887D as the base address for the reqXPos variables and any future applications could then use it.
Last point is the address of this variable is 887D in GEOS 128 1.3 and again in GEOS 128 2.0 it is 887D. I do not think is just happened to not move. Unfortunately Wheels 128 4.4 considered it to be an internal variable and it has moved in that version to 888B. I would assume MP3 also has this same issue. In the long run Wheels 128 4.4 would need an update to fix that problem.
For now I will make a note in the new HHG2G that this variable is not application accessible and because of that it is not possible to retrieve the x-position of a soft-sprite.
Since I see this repository as the most "official" space for GEOS I think we must remain in sync on this issue.