Can anyone else test/confirm this for me that I'm not doing anything stupid?
If you use SPHOME to set the offset on a sprite, then use SPCHR to change the sprite image, it resets the offset (which doesn't appear to be documented)
This means if you use SPHOME to, say, set a character sprite offset at their feet, the animate using SPCHR, you need to remember to set SPHOME again each frame.
The sprite definitions have data for SPHOME, meaning you'd have to adjust the definitions with SPDEF.
Or, you can give SPCHR the offsets of the texture (SPCHR ID, X offset, Y offset, width, height)
For the record, SB already comes with sprite definitions with SPHOME at the feet. Just add 2048 to the definition number.
Yes, that mostly works - especially if I set the screen to 2D.
WIth 3D on, I notice a weirdness in that not all sprites at the same Y value seem to have the same depth (i.e. some sprites seem to stick out further than others). That might be a result of me using floating point values, I guess - so a sprite at Y:100.1 and Y:100.9 would have the same vertical screen position, but may end up with Z values that put them on different depth layers when it hits the 3D hardware.
I have tried building "Sprite Management Number Swapping Algorithm" to reduce the weirdness you have felt.
Could you download V3EKQXN1 and refer to EX_SPPRIO in the downloaded folder?
Please download it asap because I'll keep it on the cloud server temporarily.
Got it - thanks!
Ooh, clever, so you're detecting collision and switching based on Y - that's pretty nifty. Any idea how much slowdown that causes if you've got lots of sprites on the go?
I guess that it depends on frequency of sprite collision (density of sprite crowd).
Normally, the probability that sprite collision will occur must be low.
(In my program, all sprites share a X position.)
By the way, I've built EX_SPPRIO2, a little bit improved from EX_SPPRIO.
Could you download N3234PCP?
I've modified the key. The new one is XELE38HE.
