Post new topic    
Slice Handle Use Concern/Question? 
 PostWed Oct 14, 2020 11:13 pm
Send private message Reply with quote
I've been using slice collections and a Stack approach for my animations. Basically, a parent 'stack' slice holds the frames 'children' and then after each frame 'child' animation time completes then that frame 'child' is popped off of the parent 'stack' in order to work on the next frame 'new first child'. So, as you could guess my slice handle number is increasing dramatically as the game continues to run.

I was just getting concerned when I started debugging and saw my handles were already in the thousands. I've just started a method to load in map bgs as slices when the sprite layer reveals uncharted x and y positions of the map. This too though will ratchet up the slice handle count as well.

So, is this approach going to crash the engine eventually because slice handles will overflow the engine limit? Any advice on how to proceed would be great. It's just that I find cycling through animation frames this way to be very clean and great for temporary value management.

Does anyone know the highest slice handle number? Will it possibly just wrap back around when it gets to the limit and reuse old handles that were previously freed?
Metal King Slime
Send private message
 PostWed Oct 14, 2020 11:23 pm
Send private message Reply with quote
The only thing that matters is how many slices currently exist, not how many existed previously. You can't run out of slice handles.

The engine will begin to reuse slice handles so that it doesn't run out of handles. It currently does this after you've freed 5000 slices (though I'm planning to soon change how that works). This is the reason that "slice is valid" isn't totally reliable: if you free a slice the handle might get reused and no longer refer to the original slice even if it seems to be valid.
 PostWed Oct 14, 2020 11:40 pm
Send private message Reply with quote
Wow, thanks for the quick reply TMC. This is also great news for how I have everything laid out in my plotscripts so far. I am going very heavy with the slices because I want to use 16x16 tiles instead of the default 20x20. I did see the wiki on various limits on things in the engine but wasn't sure about assigning and freeing handles so rapidly.

Currently I'm repurposing box border spritesets as tileset array templates. I store them in appropriate slice collections based on the current game scene and each child is a row and then every sprite frame from the box border set is a column.
Metal King Slime
Send private message
 PostThu Oct 15, 2020 11:46 am
Send private message Reply with quote
By "tileset array templates" you mean basically a slice-based tileset? Were the stack-based animations you mentioned are for animated tiles?

Using 16x16 sprites as tiles is doable; I think you'll probably start to see some slow-down when you have around 10's to 100 thousand slices, as long as you aren't modifying many each frame with scripts.

Once sprite/slice animations are implemented (hopefully the release after next), it will be far faster than scripting sprite animations.
 PostSat Oct 24, 2020 7:57 pm
Send private message Reply with quote
You are right about my tileset approach. I was going to use the spritesets of box borders to act as map tiles when rendered by the sprite layer. I am using a custom screen size of 256x224 for an authentic NES look. So each time a new area is pulled into view, at most 16 tiles are being drawn when walking up and down or 14 tiles when going left or right in a given frame update. I'm also running at 60 FPS as well. Everything I'm doing is script driven.

Overall though, after I've messed around with this for a bit I've decided to just build maps in the slice collection editor and bring them into the level already assembled. It's not as modular but it will be less of a headache when trying to load in something as large as a 4096x4096 world map.

On a side note, I have to say I really love this engine and I appreciate all of the hard work you guys have put into it over the years. I've learned so much about programming that helped ease me into actual programming languages like C, C++, C#, and python.
Display posts from previous: