natt

There are two different "Doom graphics format"s. One is for patches and sprites, and the other is for flats. You have to specifically import to flat format, not the other one.

The screenshot shows some sort of graphics format mismatch, not specifically having anything at all to do with palettes. Describe your workflow in more detail.

Composed as "NES- style chiptunes" on impulse tracker instead of a setup actually enforced to the NES's capabilities. It probably sounds nice, I don't dispute that, but does it sound NES? Meh. (Also, the pitch bends in D_E1M1 are missing.)

its 32. (or in a more sensible form, 4 mapunits per tic)

320x240 probably means square pixels, but because the end result was an analog video output, you can't be absolutely sure unless you know deep timing information about the N64 graphics hardware. If you wanted to get incredibly anal, the thing to do would be get a video capture card with known timing parameters (note that off-the-shelf stuff running stock software is often slightly wrong in this respect!), and then capture the output of an actual N64 on it and do some quick math. But what would you get in the end? That the PAR is actually 1.03487:1 instead of 1.00000:1? Doesn't seem worth the trouble.

That reminds me: The Doom wiki lists under "limitations and bugs" for DsDoom that it doesn't use the Nintendo DS's hardware 3d rendering capabilities. While the DS doesn't need to use any of its VRAM for a framebuffer, when you only have 512KB at most... I guess hardware rendering DsDoom would be "interesting" to see.

Regular arse doors open at 2 map units per tick Fast doors open at 8 map units per tick Doors stay at full open before reclosing for 150 ticks I dunno what units ZDOOM uses though...

So who owns this computer, you or Norton?

From the Doom Wiki: Wikipedia's Jaguar entry suggests the same thing (that all sound processing is done by the general purpose DSP), as does this discussion: http://www.atariage.com/forums/topic/179872-jag-sound-capabilities/ Finally, the Atari Doom source is freely available, and a quick survey reveals quite a bit of maths calculation code in assembly format for the DSP, not the main CPU. So uhh... no. As far as the original question goes: The crushers appear to be implemented in p_ceiling.c; you could always add one to a level and find out. My bet is on this though:

Unless Audacity can save natively in doom format, that doesn't solve the problem; you need to convert to doom format, not just save as 8 bit PCM.

Don't get an alternate editor; get a converter that works. The converter should be able to handle the 16->8, and then you can keep on authoring in the tools your comfortable with. (Offhand, I don't know what converter would be best: maybe SLADE? Deutex can't do it.) As an aside, I wouldn't be against coding WAV support for prboom-plus, except that the riff-wave format has been "extended" so many times that reading it is a very non-trivial exercise (and even if you use someone else's wav loading library, then you're stuck with the ups and downs of that library).

That's a great idea, and I will do it if I get around to it. ==== Real life is making me a bit busy at the moment. Anyone who's technically inclined, here are some programs and documents I've made. http://www.mediafire.com/?dvw69jt8vafbrov If you have questions I'll answer them. If your questions are of the type "I double clicked on the program and the box came up but it went away immediately", I won't.

I'm not abandoning anything, but you can only stare at a hex editor for so long until your eyes bleed. These sorts of things, you either "see" it or you don't. I'll release everything I've done so far, and see if anyone else comes up with anything, or maybe take another look at it in while when my brain's fresh again.

The LCD files are a rather simple DPCM format. The mathematics of it is not terribly intuitive; but you don't need to understand the formulas, just to use them. I wrote a small utility that turns them into .wav ADSR = Attack - the increase from 0 volume to max volume when the note is first sounded Decay - the decrease in volume right after attack Sustain - volume is held still while the note plays Release - after note off is requested, the decrease in volume to 0. In the PSX sound system, there are parameters for these; and the length of time for Attack and Release are the ones I primarily need to get the fadein-fadeout working right.

I'm just using a regular end-user soundfont editor. Load the samples in, set the parameters, poof. Nothing automated. It's trivial in such a thing to enter in ADSR envelopes that would make it sound better, but I haven't done that because my goal is to get the original ADSR envelope data from DOOMSND.WMD

ok the PVL files are compressed archives. i don't know how to open them, but simple hex editor view shows file name lists at the end of them. i guessed what was important by filename, used google to find the individual files, and downloaded them and peered through them with a hexeditor. midimap.cfg: contains midi instrument remapping tables. ie, "if using device x and a midi file requests instrument y, use instrument z instead". the data looks relatively straightforward, but you'd have to figure out which remapping table is in use (there are a lot of them), and even then, you only have the midi instrument remappings. this might be useful as a secondary guide, but I doubt it. ctmidi.drv: jackpot. contains 128 32 byte records followed immediately by 47 16 byte records. 128 is EXACTLY the number of instruments in the general midi selection, and 47 is EXACTLY the number of drums in the general midi perc selection (note that the GENMIDI lump in doom has exactly 128+47 records). the first 128 records are dual voice opl records, and the next 47 are single voice ones; the information might not correspond exactly 1-1 to what's in the GENMIDI file, but they're both programming the same target device (opl2/3), so the idea is the same. i have extracted just the above data from ctmidi.drv. anyone who is proficient with a hex editor, understands the registers of an opl2 (adlib.doc and whatnot), and understands the doom GENMIDI format, take a look. http://www.mediafire.com/?4ec20ywzpqi0kok

I've been scratching my head a bunch over voice selection. I can't seem to quite figure out how it is determined which voice is played on which track... the fact that some tracks sound ok on the mid+sf2 I posted before seems to be the combination of multiple bugs working against eachother. Maybe this sounds better? http://www.mediafire.com/?cpkwhyxxxp6l6y5 (Note that if a staff uses program 0 here, it means I have no idea what program to assign it.) I'm going to clean up what I've done a bit and then release it for others to look at, because quite frankly, everything I haven't figured out yet, I'm stumped on. Most importantly, there are bunches of tables and headers in DOOMSND.WMD that I don't understand.

If you want to just try out random GENMIDI lumps, Freedoom has one, derived from the openbsd opl2 drivers. Dunno what it sounds like. If you want to accurately replicate a SoundBlaster 16 when used under Win3.1, then I'll give it a brief look, if you help me out. First of all, find for me the exact drivers you installed (for the SB16 on Win3.1 in the dosbox) to produce the MP3 in the original post.

It was more of a joke really. If you're good with a hex editor, you know what you're looking for, and you get lucky, you could look through the files related to the driver and hope you find a table of OPL2 register data.

Ahh, an OPL. Welp, the windows driver used voice definitions not unlike the GENMIDI lump to program midi voices. If you found that data, then massaged it a bit, and turned it into a GENMIDI lump... presto gizmo! Not for the faint of heart. Presumably someone somewhere did it before though, right?

Sounds funny. Well, with a soundfont based midi synthesizer and the right soundfont, you can make anything sound like anything. I'm not sure what that's supposed to sound like though. Did you record that? What sound card did that machine have?

Nothing should be missing, I'll have to double check some stuff... As far as the cutoffs go, yeah, I know what the problem is. I've watched the sound debug output on PSX emulator and it extensively uses large ADSR envelopes to provide fade in and fade out effects. I just haven't found where in the .WMD the ADSR coefficients are stored yet.

So did you listen to any of them? Do they sound alright?

I've decided to drop the mod conversion idea entirely. Not because I think it's bad, but because such a creation would have 80% of the complexity of a full-fledged midi->mod converter and 2% of the utility. I'd rather write a full-fledged midi->mod converter (which takes arbitrary midi files as input) than write something specifically for this task. ==== I installed myself a soundfont editor (Vienna), imported the wav samples in, and manually typed in the loop points. Quicker than making a program that writes the behemoth that is the sf2 format. There's still some stuff missing; a few unknown midi events, and envelope parameters (attack/decay/sustain/release) aren't set up yet (I can't find them in the WMD =/), and probably bugs ahoy, but some of it sounds ok. I've been listening to a few of em on my emu 10k1. http://www.mediafire.com/?pyd5a4xw0avur1x If you have no hardware soundfont-based midi capability, something like fluidsynth can play them.

If it's written in portable-ish C, easy to compile on different platforms, then that's cross-platform enough for me honestly. Of course, you'll never really reach that with GUI apps, because GUIs are always complicated. But tools like deutex and nodebuilding (of which there are multiple open source nodebuilders which are simple cross-plaform console apps), I don't think much would be gained by adding a java version.