Talk:Plan for bigger walkabouts

The Mad Cacti (talk): Since this has been requested for the HotOHR...

I don't agree that "this plan would be super-easy to implement, and would only add a very small additional backcompat burden (no worse than what already exists for enemy graphics)". Different enemy sprite sizes will create a mess when we replace the current lumps, and having a similar situation for hero sprites would create a second mess (that's twice the mess!), unless someone manages to find a clever solution.

But I've changed my tune since we last discussed this; I don't think complaining about proper ways to implementation things is a good enough reason to hold back what is a badly needed feature, for prehaps a very long time (it's been 3 years since this was proposed!! I feel like a jerk for ever complaining about it).

So instead I'm proposing an alternative stop-gap solution which won't result in a mess (but it a little more work):

For each walkabout set, store in some new lump whether it is a normal or large walkabout set. Normal ones go in PT1, large ones in the new PT9 lump. Just waste a record in either lump if the spriteset is the other size; the waste will insiginificant and virtually zero when zipped.

A little bit of special case logic will be needed in frame_load (at least I think that's the simplest place to put it). The spriteset picker menu will need to be able to display spritesets of variable sizes, and have the ability to switch the size of a sprite set, copying data from one lump to another (that'll be easy using the frame_* functions).

To be honest, the code for the spriteset picker menu is so bad that the only practical way to implement this is to rewrite it from scratch. But that's not such a bad thing; it has to happen anyway, and that menu not complex; I expect the hardest part will interfacing with the rest of the sprite editor code.

Another downsize is that after this is implemented, every user will demand that the same workaround be implemented for every other sprite type (including all three enemy sprite sizes of course)!

Bob the Hamster (talk): Oh! I didn't read through this plan when I linked it to Fenrir's request. I was actually thinking of something like Plan for raising sprite frame limits for implementing this (not that I have read that one recently either)

I don't understand your suggestion above. It sounds pretty much exactly the same as what I wrote in this plan. I must me missing the difference.

Don't worry, I don't plan on cutting any corners to fulfill HotOHR requests :) If somebody requests something too complicated for me to do according to plan within the alloted time period, they will just win the failure bounty money instead.

The Mad Cacti (talk): Oh, wow, Plan for raising sprite frame limits is hundreds of times more work than this plan (the original, not my alternative). Looking back, Fenrir was only requesting this plan, not the new sprite formats one.

The difference between my alternative and the current plan is that the current plan would add a 'sprite size' field to every hero and NPC definition, like the enemy sprite size, and a "load large walkabout sprite" command, and mine would not.

Bob the Hamster (talk): Oh! Now I see. The toggle for which size sprite frame would be in the sprite set list, not in the hero or NPC data. That make sense.