Proposal: split the drake sprites directory

Production of artwork for the game by regular contributors takes place here.

Moderator: Forum Moderators

Post Reply
User avatar
thespaceinvader
Retired Art Director
Posts: 8414
Joined: August 25th, 2007, 10:12 am
Location: Oxford, UK
Contact:

Proposal: split the drake sprites directory

Post by thespaceinvader »

Our new drakes are shaping up well, but one thing I'm noticing is that they have a LOT of frames.

For each flying drake by the end of the summer there will be 7 flight frames, 4 takeoff/landing frames, 10 fire frames, a minimum of 5 or 6 melee frames, and 2 defend frames, and leadership for the Flare/Flameheart. So 30 plus frames per unit. For 11 units. 330+ frames.

And then the Clashers, 5 units, probably 20 to 30 frames each, another 100 frames.

When we finally add north animations, this will nearly double, and idle animations wioll increase it still further.

Is nearly 500 even without the north frames too many for a single directory? It strikes me that splitting the drakes into drakes-clashers, drakes-gliders, drakes-fighters and drakes-burners might make sense. What does everyone think? I'll raise this on IRC as well, when I get back from work.
http://thespaceinvader.co.uk | http://thespaceinvader.deviantart.com
Back to work. Current projects: Catching up on commits. Picking Meridia back up. Sprite animations, many and varied.
Blarumyrran
Art Contributor
Posts: 1700
Joined: December 7th, 2006, 8:08 pm

Re: Proposal: split the drake sprites directory

Post by Blarumyrran »

If that were to be done, organizing all the other folders by their trees should be done too - but that will be unnecessary once the number of unit sprite files will lessen dozens of times after implementing spritesheets; so no.

On a related note, Wesnoth172\data\core\images\terrain is a mess tho - all those images that arent in subdirectories atm should be sorted too.
User avatar
Jetrel
Posts: 7242
Joined: February 23rd, 2004, 3:36 am
Location: Midwest US

Re: Proposal: split the drake sprites directory

Post by Jetrel »

Yes, the real issue will be spritesheets. Spritesheets not only will solve this problem, but will also collapse our data size for sprite images by about 90%, so they should be done for a number of reasons.

500 images is a lot, but it's not the end of the world (well, winXP actually does choke a little with that high of a number of files in a folder, on certain operations, but we don't need to accomodate the fact that some butthead at MS put a schliemel-the-painter algorithm in there. I can't remember what it was ... deletion?). This is probably not a big deal, though, and I for one don't think we should waste the effort, because I think it should instead be spent on spritesheets.
Play Frogatto & Friends - a finished, open-source adventure game!
User avatar
thespaceinvader
Retired Art Director
Posts: 8414
Joined: August 25th, 2007, 10:12 am
Location: Oxford, UK
Contact:

Re: Proposal: split the drake sprites directory

Post by thespaceinvader »

Hang on... sprite sheets? Have I missed something major here?
http://thespaceinvader.co.uk | http://thespaceinvader.deviantart.com
Back to work. Current projects: Catching up on commits. Picking Meridia back up. Sprite animations, many and varied.
User avatar
Iris
Site Administrator
Posts: 6798
Joined: November 14th, 2006, 5:54 pm
Location: Chile
Contact:

Re: Proposal: split the drake sprites directory

Post by Iris »

Spritesheets can already be used thanks to the ~CROP(x, y, width, height) image functor as I implemented it in 1.5.4 per Jetryl's request. I remember talking with alink about possible caching issues (e.g. degrading performance) with Wesnoth's own run-time image cache, but I don't remember what was the conclusion to it. :(
Author of the unofficial UtBS sequels Invasion from the Unknown and After the Storm.
User avatar
Jetrel
Posts: 7242
Joined: February 23rd, 2004, 3:36 am
Location: Midwest US

Re: Proposal: split the drake sprites directory

Post by Jetrel »

shadowmaster wrote:Spritesheets can already be used thanks to the ~CROP(x, y, width, height) image functor as I implemented it in 1.5.4 per Jetryl's request. I remember talking with alink about possible caching issues (e.g. degrading performance) with Wesnoth's own run-time image cache, but I don't remember what was the conclusion to it. :(
:augh: Wait, you actually implemented that?

Wow, I though we were still waiting on that. Talk about a lapse in communications.

:hmm: I seem to remember some concern about caching, but the only thing I can think of as being valid would be that if we needed to flush a cache, it'd take longer to refresh it immediately (we'd have to load the entire PNG, then copy the little subsection into our buffer, versus just loading a small PNG), but other than that I can't see it causing any issues as an image-path function, because we couldn't cache the entire loaded image; at least not as what the image functor returns, because that just expects to receive the 72x72 image.

I don't know; then again, the act of loading might cache the entire file, but I really don't know a lot about our code structure.
Play Frogatto & Friends - a finished, open-source adventure game!
User avatar
Iris
Site Administrator
Posts: 6798
Joined: November 14th, 2006, 5:54 pm
Location: Chile
Contact:

Re: Proposal: split the drake sprites directory

Post by Iris »

Jetrel wrote: :augh: Wait, you actually implemented that?
Of course I did! You should have even received four emails from the bug tracker back then. :p
Author of the unofficial UtBS sequels Invasion from the Unknown and After the Storm.
Post Reply