HacX 1.2 and Boom/MBF

Moderators: Xaser, Dr_Nostromo

MrFlibble
Posts: 20
Joined: Mon Jun 15, 2015 18:05

HacX 1.2 and Boom/MBF

Post by MrFlibble » Mon Jun 15, 2015 18:56

Being a DOS fan, a while ago I tried to run the 1.2 IWAD with Boom and MBF, but without success. If HACX.WAD is loaded with the -iwad command line parameter, both ports for some reason recognize it as a vanilla Doom IWAD and complain about missing levels. Specifically, the error message is this:
W_GetNumForName: d_e1m9 not found!
If HACX.WAD is loaded with the -file command in the presence of a valid IWAD (I used the Freedoom one), the game gets to the title screen, but crashes when it tries to load a level (e.g. when staring a new game or running a demo). The error message in this case is:
Segmentation Violation
Recently I learned about an updated version of MBF which was released last year. Because it includes numerous bug fixes and optimizations, I thought that maybe it would work better with the HacX IWAD. I tried it, but the result is still the same. However, I Googled for the "Segmentation Violation" error in Boom, and it turns out that it was caused by the absence of REJECT lumps in the WAD:
http://www.doomworld.com/vb/source-port ... boom-2-02/

I used ZenNode to rebuild REJECT lumps in HACX.WAD, after which it indeed became possible to play it in MBF as a PWAD with the Freedoom IWAD. However, the question still remains why MBF incorrectly identifies HACX.WAD as a vanilla Doom IWAD instead of Doom 2 IWAD. If this were fixed, I think it would be possible to add HACX.WAD to the list of IWADs recognized by the new version of MBF (or maybe even build a dedicated HacX DOS executable based on MBF source?).

On a side note, the registered HacX v1.1 also works as a PWAD with Boom/MBF. The only issue I have noticed so far is that regular medkits can bring the player's health above 100%. This might be related to omissions in DEH files (which are supplied with the files-only hx11pack.zip), but I can't be sure on that. HacX v1.2 does not have this problem.

Blzut3
Developer
Developer
Posts: 383
Joined: Sun Jan 24, 2010 22:21

Re: HacX 1.2 and Boom/MBF

Post by Blzut3 » Wed Jun 17, 2015 18:46

That is strange. I'm fairly sure vanilla/Chocolate Doom was able to recognize Hacx 1.2 as Doom 2 (although now it has some code to recognize it explicitly for the Window decorations IIRC).

I will need to take note of the REJECT issue for the fabled v1.3.

MrFlibble
Posts: 20
Joined: Mon Jun 15, 2015 18:05

Re: HacX 1.2 and Boom/MBF

Post by MrFlibble » Wed Jun 17, 2015 20:29

Blzut3 wrote:That is strange. I'm fairly sure vanilla/Chocolate Doom was able to recognize Hacx 1.2 as Doom 2 (although now it has some code to recognize it explicitly for the Window decorations IIRC).
Judging by the source code, MBF gets confused because the HacX IWAD contains less than 30 maps. Chocolate Doom seems to use a different algorithm in identifying IWADs, and HACX.WAD passes its test as a Doom II IWAD.

BTW, for some reason the v1.2 IWAD does not include the original HacX invulnerability palette from v1.0/v1.1. Instead it uses what seems to be the Freedoom palette. Because of this, the invulnerability mode is not true to the original if running the game in Chocolate Doom and (probably) other ports except ZDoom.

Blzut3
Developer
Developer
Posts: 383
Joined: Sun Jan 24, 2010 22:21

Re: HacX 1.2 and Boom/MBF

Post by Blzut3 » Fri Jun 19, 2015 7:51

The colormap is already fixed in the 1.3 wad. Would adding dummy markers for MAP23-30 be enough to fool MBF? (Technically not using vanilla logic to determine which IWAD is in use would be a bug, but I doubt MBF is being updated any time soon.)

MrFlibble
Posts: 20
Joined: Mon Jun 15, 2015 18:05

Re: HacX 1.2 and Boom/MBF

Post by MrFlibble » Fri Jun 19, 2015 21:08

Blzut3 wrote:Would adding dummy markers for MAP23-30 be enough to fool MBF?
If I understood the code correctly, it should think it's the vanilla Doom II IWAD if all 32 maps are present:

Code: Select all

  // Determine game mode from levels present
  // Must be a full set for whichever mode is present
  // Lack of wolf-3d levels also detected here

  for (ud=rg=sw=cm=sc=tnt=plut=0, header.numlumps = LONG(header.numlumps);
       header.numlumps && fread(&lump, sizeof lump, 1, fp); header.numlumps--)
    *n=='E' && n[2]=='M' && !n[4] ?
      n[1]=='4' ? ++ud : n[1]!='1' ? rg += n[1]=='3' || n[1]=='2' : ++sw :
    *n=='M' && n[1]=='A' && n[2]=='P' && !n[5] ?
      ++cm, sc += n[3]=='3' && (n[4]=='1' || n[4]=='2') :
    *n=='C' && n[1]=='A' && n[2]=='V' && !n[7] ? ++tnt :
    *n=='M' && n[1]=='C' && !n[3] && ++plut;

  fclose(fp);

  *gmission = doom;
  *hassec = false;
  *gmode =
    cm >= 30 ? (*gmission = tnt >= 4 ? pack_tnt :
                plut >= 8 ? pack_plut : doom2,
                *hassec = sc >= 2, commercial) :
    ud >= 9 ? retail :
    rg >= 18 ? registered :
    sw >= 9 ? shareware :
    indetermined;

User avatar
Gez
Developer
Developer
Posts: 1393
Joined: Mon Oct 22, 2007 16:47

Re: HacX 1.2 and Boom/MBF

Post by Gez » Sat Jun 20, 2015 11:18

Killoughcode is really awful. :blergh:

User avatar
Graf Zahl
GZDoom Developer
GZDoom Developer
Posts: 7148
Joined: Wed Jul 20, 2005 9:48
Location: Germany
Contact:

Re: HacX 1.2 and Boom/MBF

Post by Graf Zahl » Sun Jun 21, 2015 10:33

That code is not only awful but downright stupid with its false assumption that every IWAD imaginable has a full set of levels - not to mention that it's different from what all other ports actually check.

Blzut3
Developer
Developer
Posts: 383
Joined: Sun Jan 24, 2010 22:21

Re: HacX 1.2 and Boom/MBF

Post by Blzut3 » Mon Jun 22, 2015 3:46

The unreadable code actually doesn't impress me. What impresses me is that Killough apparently felt the need to optimize the code for detecting the IWAD. XD

MrFlibble
Posts: 20
Joined: Mon Jun 15, 2015 18:05

Re: HacX 1.2 and Boom/MBF

Post by MrFlibble » Tue Jun 23, 2015 20:52

Graf Zahl wrote:That code is not only awful but downright stupid with its false assumption that every IWAD imaginable has a full set of levels
The code is designed to detect all official IWADs known at the time, and it checks for IWAD-specific files to do that. The game mode is then displayed at startup. Gerwin Broers actually made the startup console resemble that of the original Doom games:
Image
Blzut3 wrote:The colormap is already fixed in the 1.3 wad.
What other improvements are planned for this version? TBH I wasn't aware of it before you mentioned it in this thread.

BTW, Boom-derived ports apparently have a different system for replacing message strings, as strings in the DEHACKED lump of HACX.WAD are ignored. However, the way Freedoom replaces strings in the DEHACKED lump is recognized by Boom/MBF. This turns out to be incorrect. However, strings loaded from the Freedoom IWAD for some reason override those from HACX.WAD if it is loaded as a PWAD.

MrFlibble
Posts: 20
Joined: Mon Jun 15, 2015 18:05

Re: HacX 1.2 and Boom/MBF

Post by MrFlibble » Wed Jun 24, 2015 22:00

I've thrown together a quick test of an MBF-derived executable with HacX IWAD support:

Binary executable: hacx-mbf.zip
Source: hacx-mbf-src.zip

The following changes were made to the MBF code:
  • added support for the HacX v1.2 IWAD (will be recognized without placeholder maps);
  • all additional menu text strings rendered in the HacX menu font;
  • replaced default messages with HacX messages;
  • added the HacX title screen image as the background in the setup programme;
  • added the "Ouch face" bug fix from PrBoom;
  • added the "Picked a medkit you really needed" fix from PrBoom.
The executable was compiled without the helper dogs or beta emulation features.
MrFlibble wrote:BTW, Boom-derived ports apparently have a different system for replacing message strings, as strings in the DEHACKED lump of HACX.WAD are ignored. However, the way Freedoom replaces strings in the DEHACKED lump is recognized by Boom/MBF.
This turns out to be incorrect. Somehow Freedoom's replacement strings override those of HacX if it is loaded as a PWAD. However, when HACX.WAD is treated as an IWAD, the engine uses the strings found in the DEHACKED lump.

BTW, I have noticed that in HacX v1.2, the messages shown upon exit are completely different from those found in HacX v1.0/1.1 (at least, in this package).

Also if you need the menu text for the extra options in MBF, the PWAD with those is attached to this post.

One thing I did not figure out is how to make MBF treat the blue colour of HacX messages as the remapable colour. It's used to highlight currently selected items in the extra settings menus, and the lack of highlighting is really confusing because there is no indication what the current item is.
Attachments
mbfstr.zip
PWAD with additional menu strings for MBF in HacX menu font.
(4.14 KiB) Downloaded 61 times
Last edited by MrFlibble on Wed Jul 01, 2015 15:30, edited 1 time in total.

User avatar
Gez
Developer
Developer
Posts: 1393
Joined: Mon Oct 22, 2007 16:47

Re: HacX 1.2 and Boom/MBF

Post by Gez » Thu Jun 25, 2015 14:08

Freedoom's strings are in BEX format (using identifiers) instead of classical dehacked format (using the full original string). This was done specifically to avoid containing original Doom content in Freedoom (which strings such as "you got the BFG 9000! oh yes!" would arguably be even if their only purpose would be so as not to be shown during gameplay). Hacx, on the other hand, uses the old-fashioned deh method. It seems that MBF prioritizes BEX string replacements over DEH string replacements; then this problem would be solved by simply switching the string replacement to BEX format.

MrFlibble
Posts: 20
Joined: Mon Jun 15, 2015 18:05

Re: HacX 1.2 and Boom/MBF

Post by MrFlibble » Thu Jun 25, 2015 16:17

Thanks for the explanation!

So far I got the impression that not all ports allow for exit message replacement. I've checked the latest version of Chocolate Doom and it uses the original Doom exit text instead of the messages from the HacX IWAD. BOOM/MBF also seem to ignore those replacement strings.

Blzut3
Developer
Developer
Posts: 383
Joined: Sun Jan 24, 2010 22:21

Re: HacX 1.2 and Boom/MBF

Post by Blzut3 » Sun Jun 28, 2015 0:11

MrFlibble wrote:What other improvements are planned for this version? TBH I wasn't aware of it before you mentioned it in this thread.
The main attraction is that it redoes the changes that were done 1.1->1.0 (1.1 was a prerelease build). Since we made changes to the levels for co-op compat in 1.2 I had to diff the levels 1.1->1.0 and 1.1->1.2 and merge by hand. It turns out some of the issues we fixed for 1.2 were already fixed in 1.0, although I don't remember off hand what changes those were. The one significant change I do remember is that 1.0 has a proper secret exit and the map in the level 15 slot changed.

MrFlibble
Posts: 20
Joined: Mon Jun 15, 2015 18:05

Re: HacX 1.2 and Boom/MBF

Post by MrFlibble » Sun Jun 28, 2015 22:18

Blzut3 wrote:1.1 was a prerelease build
How did that happen? I have heard that v1.1 actually had more issues than v1.0 but this one is new to me.

BTW, is hx11pack.zip v1.0 or v1.1 (says it's v1.0 in the game itself)?

I'm still curious about the exit messages. Why were they all replaced in v1.2?

Blzut3
Developer
Developer
Posts: 383
Joined: Sun Jan 24, 2010 22:21

Re: HacX 1.2 and Boom/MBF

Post by Blzut3 » Mon Jun 29, 2015 0:58

MrFlibble wrote:How did that happen? I have heard that v1.1 actually had more issues than v1.0 but this one is new to me.
Nostromo used a pre-release build for the freeware release since he recalled a problem with his map (MAP12) in the 1.0 release which was supposedly due to texture renaming. While I seem to recall some error in that map I can't find it. I might be thinking of something that happened while I was trying to merge stuff.

1.1 doesn't really have more issues, it's just more unfinished. The differences are pretty obvious in some maps.
MrFlibble wrote:BTW, is hx11pack.zip v1.0 or v1.1 (says it's v1.0 in the game itself)?
This is 1.1 going by the md5sum of the hacx wad.
MrFlibble wrote:I'm still curious about the exit messages. Why were they all replaced in v1.2?
Uhh... I actually know nothing about this one. Maybe the 1.1 dehacked file we based it off of had different strings for some reason?

Post Reply

Return to “Hacx General Discussion”