sprite limite :(

Is there a way? http://sbapi.me/get/QRNPX3V3/SUPER_BASIC/code so for every sprite I set I also set information

spset type,anumber
Array[anumber]=something

I can only set 510 sprites. (also 1 for cursor,1 for logo) With matching info. BC. The limite any advice?

I suck at ingrish

possible solution: set sprites as they come on screen (keep track of sprites offscreen and replace those with ones that come on screen)

link should be http://sbapi.me/get/QRNPX3V3/TSUPER_BASIC/code (internally, smilebasic stores filenames starting with T or B depending on if it's a TXT or DAT/GRP file)

If you're using user-set variables for your sprites, I would recommend not even using SPSET (assuming you have x/y data arrays for your sprites) but using GCOPY to display them.

If you're using user-set variables for your sprites, I would recommend not even using SPSET (assuming you have x/y data arrays for your sprites) but using GCOPY to display them.

Don't do this.

If you're using user-set variables for your sprites, I would recommend not even using SPSET (assuming you have x/y data arrays for your sprites) but using GCOPY to display them.

Don't do this.

Why not?

If you're using user-set variables for your sprites, I would recommend not even using SPSET (assuming you have x/y data arrays for your sprites) but using GCOPY to display them.

Don't do this.

please never do this, your performance will go in the toilet

If you're using user-set variables for your sprites, I would recommend not even using SPSET (assuming you have x/y data arrays for your sprites) but using GCOPY to display them.

Don't do this.

Why not?

GCOPY is too slow to call many/multiple times per frame, e.g. used for static objects only by calling once. The SPSET system is incredibly fast (at least in comparison).

Can confirm. I once built a tile rendering system with GCOPY and entered a whole new dimension of lag.

I made the tests and calling GCOPY 512 times in a sprite-rendering fashion (16x16 blocks) gives an average 90-92ms overhead in every loop iteration where rendering is required. Of course a more elaborated system can be done to only re-render objects whose position/graphics have been modified but it just adds more code and complexity to your program.

I made the tests and calling GCOPY 512 times in a sprite-rendering fashion (16x16 blocks) gives an average 90-92ms overhead in every loop iteration where rendering is required. Of course a more elaborated system can be done to only re-render objects whose position/graphics have been modified but it just adds more code and complexity to your program.

That, piled on top of a physics engine and lighting engine and a and a ... Using sprites is basically the only viable way to go about it, I think. Although, I'm recalling that when I had exported my engine to SB4, I was able to pull off 60 fps running like 60 x 40 on-screen tiles in graphics, no sprites, on top of the physics and lighting engine. ( SB4 is nuts, man.)

I was able to pull off 60 fps running like 60 x 40 on-screen tiles in graphics, no sprites, on top of the physics and lighting engine. ( SB4 is nuts, man.)

I think this has more to do with the more powerful Switch hardware than any optimization done in SB4.

I think I'll do this: 1) look which blocks are offscreen ( bc. I remove sprites of the offscreen blocks. So those sprites are usable.) 2) If a block should be onscreen (I get this from the coords.) then use a available sprite. 3) Rewright code for scrolling, zooming and other sprite related stuff. (should not be to hard I just use a function to look for which sprites I need to move/scale etc.) little thing that would still mess it up: having more then 510 blocks on screen. (hope no one does that bc. that will take about an hour to do manualy+ it would be pretty useless)

If you're using user-set variables for your sprites, I would recommend not even using SPSET (assuming you have x/y data arrays for your sprites) but using GCOPY to display them.

Don't do this.

Why not?

GCOPY is too slow to call many/multiple times per frame, e.g. used for static objects only by calling once. The SPSET system is incredibly fast (at least in comparison).

Thank you for explaining

Thank you for explaining instead of just telling me what not to do (sorry if I'm coming off as rude you've helped a ton 12me21)

Sorry if I'm getting the wrong idea of the tone of your comment, but if you don't want to sound rude, you could just say something like "Thanks for explaining this in detail, good to know." If you're going to take a dig at 12Me21 and then say you're not trying to sound rude and that he's helpful, you might as well say nothing rude at all.

Thank you for explaining instead of just telling me what not to do (sorry if I'm coming off as rude you've helped a ton 12me21)

Sorry if I'm getting the wrong idea of the tone of your comment, but if you don't want to sound rude, you could just say something like "Thanks for explaining this in detail, good to know." If you're going to take a dig at 12Me21 and then say you're not trying to sound rude and that he's helpful, you might as well say nothing rude at all.

Ok good to know srry

Ok good to know srry

It's fine, no worries. Again, sorry if I took the wrong tone of your comment. Don't take what I said the wrong way.

I actually tested it and using GCOPY on a 16x16 sprite from GRP4 to GRP0 takes a hundredth of a millisecond to copy the image. Code I used:

MS=MILLISEC
FOR I=0 TO 100
 GCOPY 4,0,0,15,15,0,0,0
NEXT
MS=(MILLISEC-MS)/100
?MS

I'm pretty sure that this is reliable, but I may be wrong. EDIT: It starts getting noticably worse in quality past 900 sprites with the same conditions above; it starts flickering at that point. Speed also gets noticeably worse there. EDIT2: Speed only actually gets noticeably worse past 1000. When you pass 900 it drops from 59 to 58 and 57. But at 1024 it drops to 54. As long as you have flicker protection, I think that you'll be fine until about there. (This is still only using positioning and not anything else.)

I actually tested it and using GCOPY on a 16x16 sprite from GRP4 to GRP0 takes a hundredth of a millisecond to copy the image. Code I used:

MS=MILLISEC
FOR I=0 TO 100
 GCOPY 4,0,0,15,15,0,0,0
NEXT
MS=(MILLISEC-MS)/100
?MS

I'm pretty sure that this is reliable, but I may be wrong. EDIT: It starts getting noticably worse in quality past 900 sprites with the same conditions above; it starts flickering at that point. Speed also gets noticeably worse there. EDIT2: Speed only actually gets noticeably worse past 1000. When you pass 900 it drops from 59 to 58 and 57. But at 1024 it drops to 54. As long as you have flicker protection, I think that you'll be fine until about there. (This is still only using positioning and not anything else.)

Lag is no prob. Off-screen things will not be rendered. Thank you also what do you mean with flicker protection and how do I do it?