LoginLogin

Weirdness with SPHOME

Root / Programming Questions / [.]

benjymousCreated:
benjymous#1
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.
Perska#2
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)
niconii#3
For the record, SB already comes with sprite definitions with SPHOME at the feet. Just add 2048 to the definition number.
benjymous#4
For the record, SB already comes with sprite definitions with SPHOME at the feet. Just add 2048 to the definition number.
Ahh, thanks - I totally managed to miss that On a semi-related issue, is there any way to change the sprite draw order so that they draw ordered by Y position, rather than management order?
hanzo#5
For the record, SB already comes with sprite definitions with SPHOME at the feet. Just add 2048 to the definition number.
Ahh, thanks - I totally managed to miss that On a semi-related issue, is there any way to change the sprite draw order so that they draw ordered by Y position, rather than management order?
Does it match your purpose to gear Z position to Y position?
benjymous#6
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.
hanzo#7
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.
benjymous#8
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?
hanzo#9
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?
hanzo#10
I've modified the key. The new one is XELE38HE.