.VGM Music format

[Cutmanmike]

Ah, I was hoping this would surface. I didn't want to be the one to suggest it though, as I didn't know too much about the format other than it was a gazillion times better than gym.

[HotWax]

No. The codec method would only be FMod-exclusive.

The obvious answer would be to implement it as a generic sound stream available to both FMOD and OpenAL, if possible. Naturally it's going to depend more on how difficult each method is to implement it and how much time the developer who does it cares to devote to it. If it went in as an FMOD-only feature, I don't think too many people would care, TBH.

[Xaser]

Chris would care.

Though I'm completely not involved in the development or the discussion thereof, I'd personally rather see it done the OpenAL-compatible method, "just in case" if for no other reason. Although I like FMod very much and I know Randy has his points against OpenAL, the idea of a GPL G/ZDoom, as far off as it may be, is still a wonderful prospect.

I'd say that if both options are equally feasible, it would be best to go with the less-limiting of the two. As for the other part, at least we can dream.

[Gez]

As far as I'm concerned, I would be completely fine with a ZDoom which has two "sound renderers", one which has more features than the other (MP3 floors, VGM lights, etc.) than the other, as long as both have at least all the features needed to run correctly the standard games (which did not feature dynlights or 3D floors any more than they featured MP3s or console sound formats). Those who can't use the most feature-rich renderer could still use the other, kinda like for a while GZDoom on Linux only had the software renderer working.

[StrikerMan780]

Any news on this?

[randi]

Using the full GME library increases the executable size by 136K. The current snes_spc footprint, in comparison, is only 20K. Is it worthwhile to use the entire library? If I do so, will people use it? Or is VGM/SPC enough? I'm a bit hesitant to use the entire library when doing so increases the executable size so much all at once, and there is a good chance that most of those formats will go unused.

[Graf Zahl]

136k? You are seriously worried about that when you added stuff like additonal Zip compression algorithms or 7z support (which will most likely go unused to a large degree as well?)
For the record, the executable's size increased by 290k between 2.2.0 and 2.3.0, and that's despite all actor definitions having been externalized since then - and 82 more k from 2.3.0 to now. What's another 136k?

If you are that concerned about distribution size why don't you just change Zipdir to make zdoom.pk3 a 7z file? That alone saves much more space than the addition of this library would cost (120k zipped to be precise.)

[Xaser]

For the record, I (a dialup user) wouldn't complain if the filesize went up a little. Though I fully understand the concern of not wanting to bloat the executable to avoid iTunes syndrome.

Of course, I wouldn't likely use the new format myself, but that's just me.

[Rachael]

I think it would be a good idea to find a way to avoid bloating the executable too much. I won't explain why here, in too much detail, though.

I'm sure VGM can be implemented in a little bit more of a streamlined fashion.

"What's another 136k?" Keep saying that, and it all adds up - eventually, ZDoom's executable will be like 3 megs in size, with about half of the code never even being used.

[Graf Zahl]

That's already the case. There's a tremendous amount of bloat just from using 'convenient' C++ code. That stuff can inflate code size faster than any real code that actually does something.

Of course in this case a little research should go into availability of the various music formats so that the ones that have no real use can be stripped.

But strange, nobody complained about DUMB supporting a shitload of obsure module formats that have no practical use whatsoever. Why was that ok and this is not?

[Rachael]

I am not arguing that it's not okay, I'm just stating a preference.

To be honest with you, I don't truly care if this gets in or not - and if it does, so much the better, I suppose. I just think Randy's concern is something which I have a concern with too - the executable just keeps getting bigger and bigger, and sooner or later, we might be faced with the task of weeding through the code and seeing what, if ever, gets executed, and what does not.

[Graf Zahl]

Yes, it's getting bigger - with or without this code. If download size is such a concern one option would be to externalize some code that won't change any further into DLLs and have those an extra package that only needs to be downloaded once. But that would greatly reduce the ease of installation.

Or use 7z where possible. It can be used to reduce the size of zdoom.pk3 by >150k and it also can be used to reduce the final binary package by 200k.

And what shall I say about GZDoom then? Its binary package grew from 1.3 MB to 2.3 MB from 0.9.1 until now.

[randi]

Oh, very well. I can throw in the whole kit and kaboodle if it pleases you lot. Call me old-fashioned if you will, but I can't help but be alarmed when the executable grows by more than the entire memory of a Commodore 128 or more than half the memory of the original Amiga 1000. Once upon a time, that used to be a lot of memory. Now people are like, "128k? Pfft. Who cares! There's plenty more where that came from!"

nobody complained about DUMB supporting a shitload of obsure module formats that have no practical use whatsoever. Why was that ok and this is not?

That's different because the bulk of DUMB is not the loaders. It only has one replay routine that everything gets converted to, and the bulkiest loaders are also the most commonly-used, so stripping out the other formats would have produced little gain. (And I did do some retooling to the resampler to shrink it significantly.) GME, on the other hand, has several different players and CPU emulators with little crossover, so removing one format should have a larger impact. It is after all, essentially just a collection of related libraries unified by a common interface.

[StrikerMan780]

VGM/VGZ, GYM, SPC, and NSF, are the one that would probably be used most. Dunno about HES, but there were some good tunes on that system..

[Graf Zahl]

Oh, very well. I can throw in the whole kit and kaboodle if it pleases you lot. Call me old-fashioned if you will, but I can't help but be alarmed when the executable grows by more than the entire memory of a Commodore 128 or more than half the memory of the original Amiga 1000. Once upon a time, that used to be a lot of memory. Now people are like, "128k? Pfft. Who cares! There's plenty more where that came from!"

Times sure have changed!


Seriously though, there's so much bloat in ZDoom that it hardly matters.

For example, the templated CopyColors functions in bitmap.cpp create >64k of code in order to support any imaginable combination of bitmap format with all color transformations - but optimizing this for size will certainly have a speed impact on texture creation.
Or the new expression evaluator I wrote last year. It's 20k larger than the old one but that's the price of not having a rigid monolithic block of code that is non expandable.
Or polymost: Granted, it's not that much but the code is effectively dead and has no use at all in its current state.

Or hey, better let's stop using C++ exceptions! The handler code and data alone is 100k! And that doesn't even include the overhead to the main code which is necessary to manage exceptions. And aside from a handful of controlled situations, what is this code used for? To ensure that all allocated resources are deleted in case the engine terminates anyway!

The list can go on and on.