I think we could really use a standard built in tracker of sprite IDs. Everyone has the issue of needing to keep track of sprite IDs so you don't accidentally reuse an existing ID. Currently what I'm doing is creating a global and incrementing every time I add a sprite. For now I'm using a small enough amount of sprites I don't need to worry about getting back IDs so this isn't an issue.
The real problem I see though as as we start to include other users code more and more. Right now I'm trying to pull the SpriteZ particle system into my game. He is using something similar to track sprite IDs, but now I have to change my code or his to match up so we aren't conflicting with each other. This problem grows as GLBasic matures and gets more users. I think it would be better to address it early on. Could probably just reuse the existing LOADSPRITE bmp$, num% and default num% to a negative number; then if user calls the old way LOADSPRITE "img.png", 3; it would still work as today, but if user calls LOADSPRITE "img.png" it can automatically return first available index. Then a corresponding UNLOADSPRITE function could exist UNLOADSPRITE num% which will free up a used index.
This would help us standardize our code and more easily integrate our projects with each other.
That's what GENSPRITE() is for. It allows you to load new sprites but ensures that you don;t over-write existing ones.
Very useful in examples such as yours where you are indeed using other people's libs and functions which use sprite numbers that you may have assigned already.
FUNCTION LoadSprite2: name$
LOCAL id% = GENSPRITE()
LOADSPRITE name$, id
RETURN id
ENDFUNCTION
FUNCTION FreeSprite: id
LOADSPRITE "",id //delete the sprite
ENDFUNCTION
I was not familiar with GENSPRITE, but I see much code that is not using it in the shared code, so I'm not the only one who is unaware and doing this improperly. Building this directly into LOADSPRITE could be done in such a way as to not break backwards compatibility. I believe this still is a good idea.
GENSPRITE() is one of the younger commands, thats why some older codes dont use it (and maybe some new code from older members too^^).
But i think you couldnt change LOADSPRITE, without breaking compatibility with older code, at least i dont see it.
LOADSPRITE don't use () !
All functions with () return something.
If Gernot change LOADSPRITE file$, id% to LOADSPRITE(file$) all programms crashes, and thats :puke:
Hmm. How about if Gernot created LOADSPRITE$? So can still use LOADSPRITE as current functionality, but also have MYID=LOADSPRITE$("bob.png") for simpler code and avoiding GENSPRITE.
Only thing is would still have to alter old code to use that method as you would anyway to use GENSPRITE.
Cheers
LOADSPRITE$ assumes that a string value is returned by the function. Not a big problem though, as it will be converted automatically to a number. But this looks very ugly imho.
Alternatively:
make the second parameter of LOADSPRITE optional
LOADSPRITE file$, id% = 0
Thus old code will still work.
Yeah but that method won't return an autogenerated ID making a single nice command. Ok, what about LOADSPRITE%? So something like : local MYID=LOADSPRITE%("bob.png")
Cheers
What is wrong with just writing:
MYID=GENSPRITE()
LOADSPRITE "bob.png", MYID?
Its not really much more code and if you want you can pack this to your own function like Schranz0r did... I cant really see the problem.
Nothing really. Think we were just batting around the idea of streamlining things. You do realise we are at work right now and it's either this or more boring programmey things right? :)
Cheers
personally i like to see the "Pappnase = loadsprite("pappnase.png")" syntax ,but gensprite is ok.
Here's a function from my library that does this, plus checks if the sprite file exists:
FUNCTION SpriteLoad%: fn$
LOCAL id%
IF DOESFILEEXIST(fn$)
id = GENSPRITE()
DEBUG "SpriteLoad() >> fn:[" + fn$ + "] | id:[" + id + "]\n"
LOADSPRITE fn$, id
RETURN id
ELSE
DEBUG "SpriteLoad() >> *** File NOT FOUND!: [" + fn$ + "] ***\n"
RETURN -1
ENDIF
ENDFUNCTIONYou could change the error return code '-1' to a safer value, such as '1'.
At least then it will return a valid sprite and not cause any unforeseen problems.
QuoteYou do realise we are at work right now and it's either this or more boring programmey things right? :)
Ha, so it's not just me!
[Edit] Oops, I see Schranz0r already posted a similar function!
Nope. This nicely cuts into the extremely "house of cards" type code I am deeply looking into for the first time since 1996 when I first wrote it (95 hour weeks) in Dubai and has since been modded by at least 5 sets of people since (who were probably in school at the time and no-one has heard of the programmers sent there upto 2 years after me, but raise the one after that to a level of Godlike stature even though he was the new support guy we chucked out there at the time because no-one wanted to go...).
Ahhhh.... beer is calling to me... big style...
Cheers