natt

In my travels, I've noticed that there are a lot of maps out there that claim that they are made for boom or compatible ports that use the self referencing sidedef trick (deep water, invisible floor). This doesn't make sense to me because linedef type 242 can accomplish all of that without relying on any rendering quirks. Even BOOMEDIT.WAD, a showcase of boom features, while it demos the "242 as invisible floor" effect, in a different part of the same map uses self referencing sidedefs as invisible floor instead. It's a bit depressing at times, as such effects invariably look wrong in prboom gl mode, and I was wondering if anyone has any insight as to why people did it.

Fair enough. Makes sense that people would just continue to use what they already know. I'm guilty of this too; in my lifetime I've released one map and one tech demo (both of which suck horribly, so don't go looking for them), and both of which use "classic" tricks in a situation where 242 would have worked. I don't remember at all why I did it though.

I loaded europe into prboom-plus and gzdoom, and in both cases I observed what appeared to be massive blockmap glitching in the area around (3000, 15000). (North end, big pit with the boat in it, try taking the stairs back up). Either there's some shared engine bug (possible, but not terribly likely; the two ports are much different codebases), or there's something wrong with the map even after you correctify it.

Wut, a compiler? There must be an awful lot of virii out there...

I don't have vista/7 to test on, but if you find any bugs I'll see what I can do to fix them.

That's exactly what's happening. Not the entire, W, just some pixels of it though. That's something different; the second "Quit Game" is actually the "End Game" message. For whatever reason, that's the way the pl2 menus are.

Never say a map is boom compatible if you haven't at least checked it with prboom at the least, or more ideally boom in dosbox. There are too many isms out there.

the bars on the red key door don't appear to work.

If you want to make "rust and green colors stand out more", just edit PLAYPAL to make rust and green colors stand out more. Editing 10MB of graphics instead of 768 bytes of palette is just silly.

Your question reads as if there's someone working on a console for PrBoom who has overlooked the existence of Eternity. But that's all wrong: the reason there's no PrBoom console is because there's no one interested in making a PrBoom console.

Same way you've been doing it for 17 years? IDCLEVnn

Heh. Pretty pathetic if you ask me; a wad with nothing but one lump in it can't get it right. SigVart's ega does change the palette for item pickups though; check it out in slade. Unlike EGADOOM.WAD, which has a "tint red" for damage taken, it does its palette changes within the constraints of the EGA palette, so it's harder to spot the difference.

Perhaps macdoom has a 640x400 mode, I don't know; but that isn't it. That's 320x200 doubled in both directions. It's a nice goal, but a release of the DoomEd source wouldn't help much towards it. DoomEd was a primitive tool compared to any half-modern editor. You'd be better off starting with a windows editor as your baseline and porting the gooey to <whatever>.

CRRED[0x43] != 0x43 Don't ask me why.

Well, I freely admit that I do not understand much of the internals of audio compression formats. I do my work mostly by lucky guesses; I use a hex editor and look for file structure that I do understand. In the case of vadpcm, the discovery process went like this: 1. Mupen64plus 1.99 emulated the sound of doom64 more or less successfully while using an HLE audio plugin. This is good because HLE sucks; it isn't actually emulating anything, it's just using high level code that knows what is supposed to happen. But since it got it right, I can just look at the high level code and see what's going on. 2. Looking at the source for the audio plugin, it's invoking a VADPCM decoder that it claims is for "mario 64". The source is otherwise pretty much a mess, so I download an open source N64 sound rip tool which claims to support mario 64. 3. The tool doesn't work. Examining its source, I note that the structures its looking for don't resemble what I've seen in the hex editor at all. But one thing does look familiar: VADPCM custom predictor sets. It's a simple format, and I've seen them already in the doom rom. So I guess that while the overall structures are different, the audio data itself is VADPCM. 4. I look through the source of the tool for any identifying marks I should expect to find in the actual audio data. There is one: every 9th byte contains predictor and scalar selections, instead of raw audio data. I look at the portion of the Doom rom which I think contains compressed audio data, and every 9th byte looks like that. 5. I combine what I've already figured out (tables and offsets) with this VADPCM decoder, and done. (You can forget the part where I spent half an hour with garbage spewing out of my speakers because one of the table offsets was off by a few bytes). ====== I know this is not quite what you asked, but it does explain how I can decode the audio without knowing a damn thing about it.

sure is vadpcm in here http://www.mediafire.com/?z5it45ho5a4z9o0 not really much use to anyone yet, there's no accompanying soundfont or anything.

I took a look through prboom-plus p_setup.c and it doesn't support anything like that. What it does is a bunch of sanity checks on the blockmap, and if any of those fail, it's rebuilt from scratch. I'm pretty sure that's been the standard since Boom. That would be a pretty crappy extended format anyway, and it would still be limited to no more than 128K of blocklists (the offset table just wouldn't count against it). I'm betting it's just the faulty result of a tool.

What is a fruit salad?

So why don't you explain the misunderstanding then, instead of just posting "nuuuu-uhhh, I'm right and you're wrong"

Significantly better than http://www.doomworld.com/vb/wads-mods/55827-dont-download-this/

What? The general midi spec has about eleventy controller events in it, all of which are valid in files as well as realtime streams. Not every synth may implement every one, but saying the spec is not designed to handle effects is completely wrong. http://www.midi.org/techspecs/midimessages.php See table 3 And that's not even getting into sysex messages.

No N64 samples yet, but I have ideas...

Should drop-in replace midi2mus.exe as long as you don't use the /v or /t options. (I don't know if XWE uses those options when it runs it.)

If you're in the mood to run random crap you got off the internet, I wrote this. http://www.mediafire.com/?5lifrcfcgp339oz License is modified BSD, source code is included. Executable and object files included were compiled with mingw as a 32 bit windows executable, so should run fine on win2k+, 32bit or 64bit. It's had very little bugtesting though.

Many source ports use SDL, but all of those that use it for non-opengl graphics purposes simply use it as a dumb framebuffer, with all actual drawing (both the 3d renderer and 2d elements like menus and status bars) being done in user-space software. So the 1.3 stuff doesn't really change anything. You could in theory rewrite the engine to use a hybrid system where all of the "3d" rendering is done by the software engine, and the status bars/menus are overlayed with that accelerated system or something similar; but practically speaking its pointless, as status bar drawing doesn't consume a significant portion of time. As far as SDLGL ports go, they already do the hardware accelerated 2d rendering; you just call glOrtho() and plop crap on the screen.