15 users online: Agatha,  Anorakun, buggy789, BUX88, GhostSnow, Green Jerry,  K.T.B., LiamBLOL, name_6969, PuffleDreemurr, Saela, SAMYR DUTRA ARAUJO, Sarcose, TheMURAmatsu, Tiroler - Guests: 64 - Bots: 296
Users: 66,007 (2,161 active)
Latest user: GhostSnow

Counting sprites in LM

I feel like this might be a stupid question, but I was wondering if there's an option in LM to count sprites while taking the extra bits and extra bytes into account?

I can think of two ways, depending on what you want:

- if you Ctrl-A while in sprite editing mode, it says at the bottom of the window how many sprites were selected. Note that that seems to include all level entrances.
- "File --> Levels --> Analyze Resources in Levels" generate a txt file listing which sprites (and other resources) are used in which levels. It doesn't count them though.

Not sure what you mean by taking extra bits/bytes into account - if you want to count all the sprites in a level grouped by sprite number/extra bits/etc., I don't think there's a nice way to do that. (unless LM got a new feature that I haven't heard of, I'm pretty rusty at this point #tb{'U'})

Ah yes, I could explained it a little better. Sorry about that. #ab{^^;;;}

For what it''s worth, I'm aware of the methods you mentioned, and I used Ctrl-A myself for counting so far.

The thing is, from what I understand, it's possible to have about 255 sprites in a level (in an SA-1-Rom at least) before things are supposed to glitch up in some way and I assume this is what LM counts.
Some while ago I ran into glitches - while using your NPCs, incidentally (no complaint, though - the're fantastic) and while trying to figure out what's going on I read something about that with custom sprites, the extra bits and bytes count extra, meaning a regular custom sprite with an extra bit of 2 counts as two sprites, and when it has 3, than it's three, and if there are extra bytes, they also get added.

With that in mind, it didn't surprised me much I ran into trouble, considering an NPC is quite big in that regard with 12 extra bytes, so one NPC would count as 14 or 15 sprites depending on the extra bit. I also had a level area where I pretty much could easily confirm that, because I had a room with 17 NPCs in it and counting the sprites along with all the bits and bytes they did add up to 249, and rest assured, things glitched up with adding number 18.

Of course, that isn't all much of an issue.
It's just that more recently I was working on a level, which was getting bigger than I expected (or wanted), and by the time I noticed that I did that Ctrl-A-thing, counting 160 sprites already #ab{<_<} - lots of them were custom sprites, and a bunch of them had an extra byte as well. There weren't any glitches, which surprised me a bit but then again, I was a bit too lazy to do the proper math.

So, it got me thinking about an easy way to count the sprites, while taking extra bits and bytes into account, because I figured while using custom sprites it might be potentially much easier to exceed the limit because of that?

Unless again, I mixed up some stuff I've read and I'm all wrong... which is of course possible. #ab{@_@}
LM's help file does mention the 255 sprite limit, but doesn't mention anything about the bits and bytes about custom sprites in that regard.

That sounds like a slightly garbled version of pre-LM3 info. #ab{;)} The original game used 8 bit indexing when parsing the sprite list, which meant it couldn't deal with more than 256 bytes. Subtracting 1 byte for the header and another for the end marker and dividing by 3 bytes per sprite gave you about 84 sprites max, which was reduced further if the sprites had extra bytes.

But that limit went away back in LM3, as Vitor had to change sprite parsing to work with ExLevel anyway. It goes purely by sprite count now rather than byte count, assuming the VRAM patch is installed (as that also installs ExLevel).

For what it's worth, the proper limit on actual sprites is normally 128, mainly due to $1938 which only has that many bytes allocated. More than that could cause some unexpected results (which LM warns you about if you do go over). PIXI automatically fixes that issue by moving the table elsewhere, though, and LM even appears to be smart enough to stop showing the warning if its fix has been applied.

Professional frame-by-frame time wizard. YouTube - Twitter - SMW Glitch List - SMW Randomizer
That sounds fantastic. 8>
And yes, the topics were I found that outdated info were indeed a few years old, but I wasn't able to find anything newer which might have stated this was not longer a thing.
But still, this is the best possble answer to that, as I was suspiously looking at some of my levels, wondering if I might have a problem. #ab{<_<}

It's odd then, that the NPCs glitched up, which was the reason I seeked out info about potential reasons in the first place, but on the other hand, it's not a big deal.
Very happy to have that cleared up, that's for sure.
Thank you both! #ab{^^;;;}