Put files into one file

[torangan]

I don't think adding or removing images would be a huge problem. If need be, you could simply split the image remove a part or add a dummy part and combine them again using the scripts.
I also intend to find out how much space can be saved in the zipped case - I think it'll be more then a few kb. Don't forget, if you combine different frames which are very similiar, compressibility should increase quite a bit. Maybe I'm wrong but I'm curious in general and I never coded something like that before. If it doesn't work out, I've learned something and know that it isn't worthwile. Nothing to loose if I wait until I've got some time to spare with doing it.

[Jetrel]

I don't understand why we would want a 2D data structure to store records where every field is optional. This kind of kludge usually requires placeholders or a fixed, predetermined placement semantics within the grid. Seems very complex, and if we had had such a rigid data structure to start with, this may have stopped for instance death animations from being added.

If the code settles down, it may make sense to impose a rigid data structure. But in the absence of any compelling reason to do so (eg. a hardware sprite renderer that needs a specific grid format) this just seems like a lot of complexity for no discernible gain.

What he said.

Or, what francisco said.

In response to freim's comments, the reason that it works fine for Civilization/FreeCiv is that Civ's animation system is fairly stable, and has few optional parts, with few cases where they have an optional number of frames.

In my own projects, there is no way in hell I am ever going back to doing "sprite sheets". I wasted a lot of time in coding for that in my "project 0," and will never repeat that mistake if I can help it.

[freim]

In response to freim's comments, the reason that it works fine for Civilization/FreeCiv is that Civ's animation system is fairly stable, and has few optional parts, with few cases where they have an optional number of frames.

Fair enough, I didn't fully consider the fact that Wesnoth has so many cases with a variable number of frames/tiles. It would probably outweight the benefits.

I guess I just have to put up with the mess I don't really enjoy working with dirs filled with thousands of files. We should divide it up more imo.

Also having individual files seems to make it easier for cruft to build up. I just cleaned out almost 100 obsolete tiles a couple of days ago myself (Admittingly many of them was tiles I had obsoleted myself )

[js138]

Well that sounds like me an argument for a directory for each unit with that unit's graphics in it. Simple, effective, modular.

[freim]

Well that sounds like me an argument for a directory for each unit with that unit's graphics in it. Simple, effective, modular.

Thats a bit more fine grained than what I had in mind, but I wouldn't mind if fx buildings/structures (villages, castle, encampment, etc) where moved out of the terrain dir.

[Invisible Philosopher]

Well that sounds like me an argument for a directory for each unit with that unit's graphics in it. Simple, effective, modular.

I agree with turning some parts of the name into directories. For example,

Code: Select all

images/human-bowman.png

could turn into

Code: Select all

images/human/bowman.png

and

Code: Select all

images/elvish-ranger+female-attack2.png

could turn into

Code: Select all

images/elf/ranger/female/attack/2.png

Maybe not have separate directories for "female" or for different attack frames if that is considered too much structure, but at least for different races and different units within those races. That would really help to reduce the number of files in any one directory, making it much easier to find what is desired. Maybe if we restructure the unit images we can even get fid of such abominable names as "neutral-footpad.png" -- the Footpad is not neutral, and it's a human so it should be named as such. It could go in a subdirectory of human though (because "human" would probably get pretty crowded), for example

Code: Select all

images/human/chaotic/footpad.png

or better, as it doesn't depend on the units' statistics,

Code: Select all

images/human/outlaw/footpad.png

If that was done perhaps the bowman example should become

Code: Select all

images/human/lawful/bowman.png

or (though I think the name Loyalist is too specific for these units)

Code: Select all

images/human/loyalist/bowman.png

P.S. having "Code:" appear on a line before all those boxes is quite a nuisance/waste of space, but

is no better, and I don't have any control over it. I think lining them up in boxes like I did is beneficial for comparing the differences visually though, so I'm not changing it.

[scott]

I don't want to be negative, but it seems using directories would be changing it for the sake of changing, besides the addition of more "overhead" (a concept as nebulous as global warming).
It would be a good system had the game originally been coded that way, but it wouldn't be a good idea to take good code and potentially add bugs, right?

[Invisible Philosopher]

I don't want to be negative, but it seems using directories would be changing it for the sake of changing

Merely "changing" is not the reason I would prefer that. In fact I understand the difficulties of changing, and certainly do not desire it (whyever would I want a change for no reason???) but also that sooner is better than later if changes are going to be made. It would be easier to navigate and find the unit I want if they were organized in such a way.

, besides the addition of more "overhead" (a concept as nebulous as global warming).

What overhead are you talking about? Does the reference to nebulousness mean that you're just speculating that using more directories might cause overhead?

It would be a good system had the game originally been coded that way, but it wouldn't be a good idea to take good code and potentially add bugs, right?

This would only involve changing the WML in the unit files to refer to the new image paths. That would hardly introduce significant or subtle bugs. However you are right, doing it would increase the immediate likelihood of incorrectly-referred-to images.

How about some feedback from other people who use the images directory -- would you benefit from such a change?

[scott]

Yes, I was speculating that more directories would increase overhead. I was wrong with the code changing - I had something else in mind that was dumb. When I work on images I just type the name stem into the finder's search box and only the images I want appear, which is why it doesn't seem like a big deal to me. But, the same would be true with lots of directories.

It just seems like something else you have to remember when referring to images. If it leads to identically-named images I think that would be a disaster. It wouldn't be bad if each unit had a single subdirectory (so ~230 in all) and the naming stayed the same as now.

[js138]

I confess I was looking at the problem from a OO programmers point of view (while I don't do C++ I've done a resonable amount of other OO programing - mainly in perl recently).

The difference between a function which constructs the name of the animation image it wants from the various facts it knows and one which creates a path and a name is small, and it was my assumption that would be the method used.

References to WML make me suspect that may not be the case.

However I was indeed invisioning the ~230 subdirs - one for each unit - in which all their images (static, death frame, attack animations etc etc) would live. For someone working on a given unit's images this wouldn't be any more inconvenient I would have suspected, and from a coding point of view ought to be a trivial change. The only difficult bit would be where WML references images by their current name/location - but how prevalant that is I'm unsure.

I'm not sure how a more complex structure (splitting by race, neutral/chaotic etc) would be a significant improvement unless there are plans to add 100s more units. A dir with 230 subdirs isn't particularly unmanagable.

[Invisible Philosopher]

It just seems like something else you have to remember when referring to images. If it leads to identically-named images I think that would be a disaster. It wouldn't be bad if each unit had a single subdirectory (so ~230 in all) and the naming stayed the same as now.

As it is you usually have to look up the image name anyway, since the naming convention is not entirely consistent. I don't understand how identically-named things are any more likely/worse than now. There is no way "elf/fighter.png" "dwarf/fighter.png" can be mixed up any more than the current "elvish-fighter.png" and "dwarf-fighter.png". (Actually, thinking about it, it might make more sense to use "elf/fighter/base.png" or some such.) There are not going to be two units of the same race and usage-name(e.g. Ranger) that are differently named overall, except by mistake (which gets fixed).

About searching with Finder -- not everyone can do the same thing, obviously, on their different OS's, and even though I use OS X, the search box tends to often be slow/unreliable for me. (yet another reason I am coming to dislike this OS... not that there necessarily exists a better one at the moment)

I'm not sure how a more complex structure (splitting by race, neutral/chaotic etc) would be a significant improvement unless there are plans to add 100s more units. A dir with 230 subdirs isn't particularly unmanagable.

My compulsion to organize everything that can be. A sometimes-unnecessary habit reinforced by frequent programming.

[ott]

the search box tends to often be slow/unreliable for me

On my OS X box I usually use

Code: Select all

find images/ -name '*yada*-yada.png' -print

from a command line. It seems pretty instant. Ditto for searching for stuff inside the unit files:

Code: Select all

fgrep -r somestring data/

Of course these also work on Linux and any other Unix-like systems.

[Simons Mith]

A slightly tangential observation: ZIPs, PAKs, WADs and other similar files really are little more than glorified directories with a proprietary format. Indeed, I have a program called WadFS that lets me read WAD files as if they were inside a normal directory, and another, SparkFS which gives me read/write/delete access to ZIP files and several other formats. I can run programs and even applications from inside ZIP files without unzipping them. Win2000/3 onwards gives a rather feeble imitation of this, but as is Microsoft's wont their implementation sucks awesomely.

If we were to store Wesnoth files in a consolidated format, I'd suggest plain old Zip - perhaps distribute it with units.zip, campaigns.zip, maps.zip etc. inside the current data directory. This would require the ability to extract these data files at run-time, but that might be a nice feature to have in version 1.0

[fmunoz]

IIRC Wesnoth can use zipped folders now if compiled with libzipios
So you can zip whole sets of images and the game just use them transparently..
But the point is ... Do we really need to save lets say 3 kb per image per 1600 images ... 5 Mb of hard disk space?
Adding another bug source, another required lib (currently is optional) and wasting effort on things like that when there are still too many other things to fix...

[dms]

I don't understand how identically-named things are any more likely/worse than now. There is no way "elf/fighter.png" "dwarf/fighter.png" can be mixed up any more than the current "elvish-fighter.png" and "dwarf-fighter.png".

I suspect there are probably plenty of situations where only the filename is available.
Here's a quick example. GIMP provides (tiny) thumbnails, but other programs might not...