So much to say, so little time...
Is there a reason you can't use SPVAR entries for the associated variables? Technically I think those are stored as floating-point values, but you could just as easily store fixed-point integers since there's enough bit space.
On the other hand, if you use your own arrays then I suppose it would be good for allowing users to use all 8 of those variables for their own purposes. Allocating several 512-entry arrays definitely isn't a terrible idea.
You pretty much got it right. Initially I did intend to use SPVARs, but then I figured "what if the user wants to use all 8 SPVARs?", so I thought up a SBPE_NOSPVARS command, which would switch to using arrays instead of SPVARs. That would mean two modes of operation to accomplish the same thing. Then I realized that I'd just be making things more complicated for me to develop, to debug and to optimize, so it's better to just focus on one method and optimize it to work fastest.
No worries. I'm not making much understanding either.
My criticism is that to do what you're doing, you will always have to have the maximum amount of memory allocated.
I get around having to have a N*512 byte array by pushing the sprite management number (external id) into an array and having a different internal id.
My library does not need to expose its internal id, as the properties are set on the sprite itself, and can be accessed using the external id and the built-in sprite commands.
In my update functions, I can then loop through that array and use only the external IDs that are active with SPOFS etc. Avoiding unnecessary updates on unused sprites.
Do you update all 512 entries when you simulate collision?
The only way I can think of not storing 512*N attributes with only an internal id is doing a lookup for the external id, but for things like getting velocity, without a separate ID, that would be a linear search through your array, which you wouldn't want for speed reasons. So I'm not sure what you can do to save space.
Your choices really are just: allocating all the memory, or returning a new and possibly different management number...
I can see why you wouldn't want to have a new ID, but I think the performance benefits are worth it.
I think what kldck_hul is saying is that you need to keep track of which sprites are currently active in the engine, because you probably don't want to iterate over 512 booleans to check whether each sprite is active or not. But that's probably easy enough to do by just pushing each sprite onto an internal array when registering it.
That's a lot of food for thought! One possible solution is to have one 512-sized array, and 6 dynamic sized arrays:
DIM MANAGEMENT_TO_INTERNAL[512]
DIM INTERNAL_TO_MANAGEMENT[0]
DIM MODE[0]
DIM X[0]
DIM Y[0]
DIM VX[0]
DIM VY[0]
'adding a sprite:
DEF ADD_SPRITE ID%
VAR NEW_ID% = LEN(INTERNAL_TO_MANAGEMENT)
PUSH INTERNAL_TO_MANAGEMENT, ID%
MANAGEMENT_TO_INTERNAL[ID%] = NEW_ID
PUSH X, 0
PUSH Y, 0
PUSH VX, 0
PUSH VY, 0
END
Getting info using either number:
VAR MANAGEMENT_NUMBER% = 17 'for example
VAR INTERNAL_ID% = MANAGEMENT_TO_INTERNAL[MANAGEMENT_NUMBER%]
XX = X[INTERNAL_ID%]
YY = Y[INTERNAL_ID%]
'etc
'Removing a sprite (is there a more efficient way?)
DEF REMOVE_SPRITE ID%
VAR INTERNAL% = MANAGEMENT_TO_INTERNAL[ID%]
MANAGEMENT_TO_INTERNAL[ID%] = -1 ' the "unassigned" value
VAR LENGTH = LEN(X)-2 'can check any of the same-length arrays..
FOR I = INTERNAL% TO LENGTH
' move all sprites above it ahead to fill in the gap
INTERNAL_TO_MANAGEMENT[I] = INTERNAL_TO_MANAGEMENT[I+1]
MODE[I] = MODE[I+1]
X[I] = X[I+1]
Y[I] = Y[I+1]
VX[I] = VX[I+1]
VY[I] = VY[I+1]
MANAGEMENT_TO_INTERNAL[INTERNAL_TO_MANAGEMENT[I]] = I
NEXT
POP(INTERNAL_TO_MANAGEMENT)
POP(MODE)
POP(X)
POP(Y)
POP(VX)
POP(VY)
END
Possible alternative: to adding and removing (maybe more efficient):
DIM MANAGEMENT_TO_INTERNAL[512]
DIM INTERNAL_TO_MANAGEMENT[0]
DIM X[0]
DIM Y[0] 'cba for the rest of them
DIM FREE_INTERNAL[0]
DEF ADD_SPRITE ID%
VAR NEW_ID%
IF LEN(FREE_INTERNAL) == 0 THEN
NEW_ID% = LEN(INTERNAL_TO_MANAGEMENT)
PUSH INTERNAL_TO_MANAGEMENT, ID%
PUSH X, 0
PUSH Y, 0
ELSE
NEW_ID% = SHIFT(FREE_INTERNAL) 'can use POP instead, is there a performance difference?
INTERNAL_TO_MANAGEMENT[NEW_ID%] = ID%
X[NEW_ID%] = 0
Y[NEW_ID%] = 0
ENDIF
MANAGEMENT_TO_INTERNAL[ID%] = NEW_ID%
END
'and removing, much simpler:
DEF REMOVE_SPRITE ID%
VAR INTERNAL% = MANAGEMENT_TO_INTERNAL[ID%]
MANAGEMENT_TO_INTERNAL[ID%] = -1 ' the "unassigned" value
PUSH FREE_INTERNAL, INTERNAL%
INTERNAL_TO_MANAGEMENT[INTERNAL%] = -1
END
A lot less overhead, but if a large number of sprites is removed then it leaves a lot of gaps which will be iterated/skipped over and they'll never be cleaned up.
So you're planning to use a combination of SPCOL, SPCOLVEC, SPHITRC, and SPHITINFO for handling collisions with the background? I haven't tried those out personally yet, but they seem really powerful. Like, I guess you could call SPHITRC for each potential BG tile collision and then use the minimum collision time and associated position from SPHITINFO.
Yup, exactly! However, in Petit Computer, SPHIT commands had one minor flaw - if the sprite was moving too fast, they'd give some slightly-off results. This MAY be a problem if it's still the case (SBPE is intended to work for bullets as well), so if I find that it is, I'll have to implement my own version of SPHITRC. That should be fun..
