Create sprites beforehand or at runtime?

[hosch]

Hey guys,

I am messing around with AGK for a couple of weeks now and I really enjoy it. For my current 2D project, I've created all sprites beforehand, hid them and show them whenever neccessary. Are you doing it the same? Because, if you have a very large project this might be not the way to go. Since I didn't create a large project in AGK yet, I don't have any experience considering this topic. Does it make more sense to create them at runtime and delete them when not needed anymore (which means I'd have to create them every time)?

I've also seen some people defining a sprite custom type and handle them that way. How are you guys doing this? Thanks!

[Steve Elliott]

I've always hid them because the author said it produces faster code.  But it's a real pain and can lead to bugs. From now on I think I'll do what Qube does - by using DrawSprite and Swap() instead of Sync()

[hosch]

Yup, that's what I am experiencing as well. I see a sprite is still visible and have to go all over the code where I forgot to hide it.

Could you elaborate on Qube's method? From my understanding, I could create one sprite, then use SetSpritePosition() to put it where I need it, render it to the backbuffer with DrawSprite() and use Swap() to show it? This actually seems more straightforward to me coming from BlitzBasic, where I used loops to draw my tilemaps etc.

[blinkok]

Remember that DrawSprite() means you cannot use the collision commands with that instance
If it's say, background tiles, a good idea might be to "burn" those tiles into a single image using GetImage() or RenderToScreen()

[3DzForMe]

This is interesting, as I've sprites littering my UI due to back of a fag packet coding, in fact, it's not even that. Straight from the old suede, probably explains a lot!

[hosch]

Remember that DrawSprite() means you cannot use the collision commands with that instance
If it's say, background tiles, a good idea might be to "burn" those tiles into a single image using GetImage() or RenderToScreen()

That's some good advice, I didn't know that!