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]=somethingI can only set 510 sprites. (also 1 for cursor,1 for logo) With matching info. BC. The limite any advice?
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)
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).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.
Can confirm. I once built a tile rendering system with GCOPY and entered a whole new dimension of lag.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).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.
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 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)
Thank you for explainingGCOPY 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).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.
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 srryThank 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.
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 ?MSI'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: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?MS=MILLISEC FOR I=0 TO 100 GCOPY 4,0,0,15,15,0,0,0 NEXT MS=(MILLISEC-MS)/100 ?MSI'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.)