Blasphemer 0.14 out now

Stilgar said:

Yes, but who would edit/maintain it? The messages are subject to change but at least they're a trivial fix; limit removal requires more than hacking a few lines of code though if I'm not mistaken (it's been a long time since I've looked at any of the engine innards). I'm not much of a coder and futzing about with something as archaic as Doom's renderer doesn't exactly appeal to me.

I'm not very clear on what the custom messages actually are. Maybe you can clarify this? But if it's something trivial like a DeHackEd or BEX lump embedded in the IWAD, I think fraggle already added some code to chocolate-doom to handle similar stuff in the Freedoom project. For example, all the monster and weapons got renamed, and these custom strings appear when playing the game instead of the original Doom messages.

As far as the actual limit-removing aspect itself goes, that would be a piece of cake. There's just a handful of constants in the source code that define max visplanes and such. In fact, doom+ & friends are just binary patches against the original executables, so the scope is very limited by that nature. Here's the actual changes:
http://prboom-plus.sourceforge.net/doom-plus.features.html
And I believe ChocoRenderLimits already implements most (all?) of these:
http://remood.org/standard/index.php?page=chocorenderlimits&guid=none

I'm attempting to compose a new track for E1M1, but I don't have any access to any advanced MIDI composers so I'm stuck with anvil studio, thus someone will probably have to clean the track up assuming you guys like it. (Hope you do!)

I'm obviously biased about this (I made all the music), but filling resource gaps is preferable to replacing content that has already been created.

Well if anyone's interested, here's a diff that gives chocolate-heretic the same functionality as heretic+ (note: it's a text file with Unix EOL terminators):
http://www.sendspace.com/file/hvj9d5

I tested it and it doesn't crash when I play the E1M3 map in the blasphemer IWAD (vanilla heretic crashes with VPO not far after passing the bridge over the small river). I also played the first handful of maps in the Heretic Treasure Chest megawad, with mostly just some small glitches (tutti fruti and such). That is until I got to E1M4 where it crashes hard, and by that I mean an unexplained segmentation fault rather than VPO or something like that:
http://www.sendspace.com/file/zxe2lj

Since it dumped core, I debugged the process and it's dying in R_PointOnSegSide() while trying to access struct data that has an invalid memory address, but the actual problem is happening somewhere higher up in the stack. I don't know enough about the Doom engine to tell exactly where or why, but I'm sure the 32 "sector X is not closed" errors that Yadex reports for that map probably have something to do with it, because I observed similar crashes on maps with the same error being reported when inspecting them in the editor. The weird thing is that when I zoom in to the problem sector it actually appears to be closed and all the linedefs have good valid sector references. But there are some vertices which are very, very close together, maybe only two map units apart or so. And I'm wondering if the vanilla Doom engine simply doesn't scale well down to that level of precision? Well if anyone has any ideas, please share. :) Also, if there are any good docs, text files or whatnot on the engine internals, please post 'em.

Incidentally, a couple errors I found while playing blasphemer:
E1M3 - linedef 1555 needs a sector tag and sector 326 needs identical tag number (I used 7 for both)
E1M7 - 2-sided linedef 1509 has a multi-patch texture (maybe change it to STNGLS2 instead?)
Some ports may correct these automatically, but it's not guaranteed. The default behavior for an untagged linedef (i.e. tag 0) is to apply to ALL untagged sectors. And the default behavior for multi-patch textures on 2S linedef is to produce visual glitches. These problabaly fell through the cracks due to someone testing with an engine that went above and beyond simply removing the hard limits such as max visplanes, etc.

Last thing: I was wrong about fraggle adding the BEX string stuff to chocolate-doom. He DID talk about it sometime last year in the Freedoom forum, but my svn co from two months ago doesn't have it. If he's not going to do it, I might look into it perhaps.

Well, DoomBSP was apparently limited to a grid of 8; though I haven't heard the issue actually existed in Doom itself.

Custom messages currently dwell in LUMPS\LANGUAGE.LMP (which is plain-text formatted.) As far as I know, only ZDoom-based ports can load this; we used to have a DEHACKED.LMP but it caused fatal errors in certain ports (namely Vavoom.)

On the topic of errors, I'd like to call the attention of any interested Doomsday users/developers to this issue. I can't say much more than "doesn't work" about it without additional input.

Hey just a thought: you could always provide a separate blasphemer.deh file (not embedded in the IWAD) that can be used by any port that doesn't grok the IWAD's language.lmp. That way you'd even get custom strings with heretic+, assuming Heretic's DeHackEd equivalent is able to patch the limit-removing binary (otherwise maybe it'd be necessary to run the DeHackEd first, and then apply the actual limit-removing bits). For keeping the two files in sync, a simple build script could just read the languages.lmp and then create the blasphemer.deh from a template file that contains the same string constants (so just a simple search & replace does the trick).

DeHackEd seems to mean Doom.exe hacking editor. Not Heretic.exe. I can't imagine Dehacked being used for something else than Doom, unless someone modifies the configurations and maybe the source code inside out. And developers hate HHE.

My bad, I meant a standalone blasphemer.heh (or is that .hhe?) rather than blasphemer.deh. In any event I'm willing to write the conversion script if that helps any. Does the build environment have perl or sed?

printz said:

DeHackEd seems to mean Doom.exe hacking editor. Not Heretic.exe. I can't imagine Dehacked being used for something else than Doom, unless someone modifies the configurations and maybe the source code inside out. And developers hate HHE.

You seem to be confusing the DeHackEd utility with a DEHACKED lump (which works fine to change Heretic messages in ZDoom, at the least.)

As for HHE, it's not worth using, no port supports it, and because of the patch format (which, unlike DEH patches, relies directly on the structure of the original Heretic exe), they probably never will.

Well chocolate-heretic supports the HHE:
http://www.chocolate-doom.org/wiki/index.php/HHE_support
Maybe it's the only port that does though...

Hmm, well I'll test to see if chocolate-heretic also supports DEH files as well. Then perhaps only heretic+ is limited to using HHE files, and I could always build both DEH and HHE files from the same template, so every limit-removing port is fully functional in one of three ways (the default option being the embedded language.lmp file).

Hmmm, that's interesting. Thanks for calling it to my attention.

Still, it'd be better to have the custom messages in a text format, which HHE isn't.

Nice to see an update on blasphemer.

Regarding music: I mostly defer to Jute's judgement on this since he's more of the music and sound guy, but I wouldn't mind dropping the Bach cover (Intermission music), swapping one of the more mellow tracks into the intermission slot and taking in at least one more in-level track.

Thoughts on this?

I also noticed that not all the music we have currently was actually used. I've fixed this in the SVN trunk.

I'm okay with losing the Bach.

Well it looks like Chocolate Heretic doesn't like normal DeHackEd style patches and instead enforces the HHE format when you try to load a patch with the -deh switch.

Additionally, it enforces a max string length based on 32-bit integer boundaries, so any of the original Heretic strings can only be extended by at most 3 characters. Oh, and btw all the characters must be uppercase, otherwise it prints garbage.

So I guess that leaves two options:

1) Build an HHE patch by hand, using abbreviated replacement strings whenever necessary. It can't be scripted because some thought is needed for each and every string that exceeds the max length. But this method would work as-is, without having to modify Chocolate Heretic any further, and might also work with Heretic+ (in fact, it's pretty much the only method that stands a chance to work with it).

2) Modify Chocolate Heretic's HHE/DeHackEd parsing so it doesn't enforce the max string length. Then it's no longer necessary to build the HHE patch file by hand, and instead a build script will be needed to create it from the language.lmp contents.

(Edit)
Guess I'll just go with a compromise between those two: a build script creates the HHE patch from the languages.lmp contents, but flags those strings that exceed the max length, so that someone can edit them (not a big deal since the HHE patch is just a plain text file, much like DEH patch files).

We are not using HHE.

- The listing of Heretic+ is only meant to indicate that the wad works on it. It is not an endorsement of it as a target port, given that it's not even a port, just a hack of the original Heretic .EXE.
I'd much rather see Doomsday support get working again.

- Chocolate Heretic doesn't support some of our maps anyway. We're not going to drop them just because of that, so it'd have to be a modification of the port anyway, and therefore might as well support a decent patch format.

Well I meant the modified chocolate-heretic that I posted a diff for earlier (bumps-up the limits same as heretic+). Anyway, don't sweat it about the HHE stuff. I'm really just doing this as a stopgap until fraggle implements the BEX string changes he talked about for Freedoom. If a long time goes by and he doesn't do it, then I'll look into it. And if you really hate HHE and don't want to include it in releases, then I can just post it on another website along with that other diff. Eventually, if someone with Win32 or OS/X builds binaries with that diff, I can post 'em there too.