Okay, it's become abundantly clear that Mac<->Windows sounds become messed up.

I use Windows, and the sounds in NeoFirst are VERY messed up and have a lot of static.

messed up sounds on windows

A thought occurs: C-Dawg's Windows-made quest that you linked to requires at least beta 15 (possibly 16b, since it's been updated), but there doesn't seem to be a publicly available Mac version since b14...

Yeah, I'll get onto providing the Macintosh public with playable ZC as soon as I figure out why the Mac version of the most recent revision keeps producing Malloc-related errors.

(Ideally, it'd be Takuya who provides the betas... especially since he, unlike I, can compile for OS X > 10.3.9...)

Well, I'm still not sure what's going on here. Why, I wonder, does sfx.dat's sounds work but not quest file-stored sounds?

You know, I could test it on Mac if you made it for OS9...:disgust:

If it works fine in the sfx.dat, perhaps a way, feature wise, to modify the sfx.dat and include your own sounds? That may just be easiest.

Amaster42 wrote:If it works fine in the sfx.dat, perhaps a way, feature wise, to modify the sfx.dat and include your own sounds? That may just be easiest.

Like using the Allegro grabber?

To recap: the point is that quest sounds saved on Mac OS X sound scratchy on Windows machines, and, importantly, vice versa.

Amaster42 wrote:You know, I could test it on Mac if you made it for OS9...:disgust:

Could you please re-post your test quest? The link is down.

For aged topic links, just insert "/forums" at an appropriate place in the URL. Or just click here.

There are some endianess problems in the SFX loading code. Fixing them didn't seem to resolve the problem, but they couldn't have helped.

Worse, I'm getting a quest loading error when loading the above file, when loading custom guys. It's not grave enough to abort quest loading, but dumps a message to allegro.log. This error almost surely indicates a bug in the quest loader. Are you getting any kind of loading error with this quest?

Please do the following for me:
Post some .wav file here.
Make a new quest, and import that identical .wav file. Post this new quest here as well.

Also, are you *sure* that the quest linked to above is a pristine, never-been-edited-in-Windows quest? If the quest had been saved in Windows after the SFX corruption, that would explain a lot of things.

DarkDragon wrote:Worse, I'm getting a quest loading error when loading the above file, when loading custom guys. It's not grave enough to abort quest loading, but dumps a message to allegro.log. This error almost surely indicates a bug in the quest loader. Are you getting any kind of loading error with this quest?

Could you please try the experiment again with the latest build? I think I've fixed the problem - Allegro was doing endian-dependent pointer operations inside their wav loading code, which I've worked around. Bad Allego! Bad!

Old quests using mac-loaded SFX won't retroactively work on PCs. You'll need to reload the SFX using the newest build.

Nope! Zodiac.qst still has static-laden sounds, and my quests still have pristine sounds.

Right. Old quest don't work cross-platform and never will; Allegro loads .wavs differently on Macs and PCs, so quests with SFX already loaded are corrupt in a way that is not recoverable unless there's some way of examining a .wav's data buffer and determining whether or not it was saved under Mac or PC.

What I did was hack around an Allegro bug and convert all new quests' SFX data to PC format before saving, and then convert back from PC format to native format when loading. Thus new quests will have portable SFX. Old quests will need to be re-saved on a platform where the SFX are NOT screwed up, and then will work for everyone.

For instance, if you were to now save Zodiac.qst, I would expect the sound effects to be screwed up for everyone, on both Macs and PCs.

Conversely, please save one of your pristine quests and post it here. I would expect it to now work on PCs.

Very well - here's a newly-saved version of this again.

SFX 2 sounds fine over here now.
I've saved the quest on my PC; try loading it on the Mac.

Test passed. I guess that's the end of this problem!

(Note to self: ask dudes to re-save released 2.5 quests with this forthcoming build.)

"As of version 4.0, programs that use the Allegro library work on DOS, Microsoft Windows, BeOS, Mac OS X, and various Unix-like systems..."

Sure, though it's a bit technical.

First, some background on data types and endianness.
Although computer memory is made up of individual bits, it is not practical for computer programs to only query one bit at a time; instead, on most hardware memory is dealt with in larger chunks of varying sizes:
byte (8 bits) - this is the smallest unit of data addressable; used for ASCII characters and very small numbers.
word (16 bits) - this used to be the standard unit for storing numbers; not frequently used anymore
dword (32 bits) - the new standard unit for numbers.
As you probably know, 64-bit machines exist which can address four words (64 bits) at a time, but they are not yet mainstream.

As you can see, all of these units are some multiple of the byte. In fact, that is how they are manipulated under the hood: if you ask the machine to retrieve a word from memory, it will load two consecutive bytes. One of these bytes contains the bigger binary "decimal places"; this byte is called the most significant byte, or MSB. The other byte is the least significant byte, or LSB. So, for instance, a word representing a small number, say, 100, has an MSB that is completely 0, since 100 fits entirely inside the LSB.

Why do we care? Well, by definition a word is two consecutive bytes - but, back in the computing dark ages when companies first started manufacturing CPUs, nobody bothered forming a consensus about *which order* these two bytes should be stored in!
On Intel chips, words are stored LSB-first; that is, a word in memory looks like
LSB MSB
On the other, Apple's chips, and all network traffic, are stored MSB-first:
MSB LSB
This inconsistency causes nothing but trouble! Suppose, for instance, that the 100 above represents link's starting health in a quest. You save the quest on a PC, and the quest file looks like this:
100 0
L then fires up your quest on his Mac, and reads
100 0
but that 100 is now in the MSB instead of LSB! End result: Link has a huge amount of health (100 * 2^8, or 25600) instead of the intended 100.

Fortunately, it's not too hard to solve this problem: instead of just saving a raw memory dump of words in .qst files, we instead call Allegro methods which detect if we're running on a PC or Mac, and then flips the bytes in each word so that it conforms to PC ordering. Similarly, when a quest is loaded, the bytes are flipped back if you're running on a Mac-like machine.

This extra step during quest loading is the reason Mac quests don't become hopelessly corrupt on PCs, and vice versa. However, .wavs added an extra wrinkle.

When you load a .wav, Allegro, deep under the hood, loads all of the data in the .wav into one giant array of words, which looks like the following on a PC:
LSB MSB LSB MSB LSB MSB LSB MSB ...
Normally, that would be fine; when you saved your quest, the quest saving code would flip the bytes if necessary. But instead, because of a bug in Allegro, Allegro lies to the ZC program and tells it that the .wav data is actually an array of bytes, not of words:
BYTE BYTE BYTE BYTE BYTE BYTE...
since bytes are harmless, nothing special happens during quest saving. Then, when L loads the quest on his Mac, catastrophe strikes! All of the MSBs became LSBs, and the .wav is totally corrupt.

To fix this bug, I added code to ignore Allegro and manually flip and unflip each word in the .wav data, like is done for other quest data.

But for old quests, there's not much that can be done. SFX loaded on PCs look like
LSB MSB LSB MSB...
and SFX loaded on Macs look like
MSB LSB MSB LSB...
and there's no way to tell which format was used just by looking at the raw data.