This is something I discovered last month and made a YouTube video about but I forgot to post about it.
A few months ago when I wanted to set up a multiplayer game with vanilla Doom, I had noticed that multiplayer in vanilla Doom is set up not by launching DOOM.EXE directly but by launching executables called IPXSETUP.EXE or SERSETUP.EXE that then launch and communicate with DOOM.EXE. That got me wondering about what would happen if I hex-edited IPXSETUP to refer to CHEX.EXE instead of DOOM.EXE. Lo and behold, it actually sets up a multiplayer game with vanilla Chex Quest:
After trying some actual multiplayer games in vanilla Chex Quest, I noticed two things. First of all, deathmatch is not supported. Only co-op is. Probably because either getting slimed from zorch didn't make sense or because the term "deathmatch" sounded too violent. Second, the game crashes when exiting a level in co-op. I later discovered that the crash is an issue with CHEX.WAD, not CHEX.EXE, as I could eliminate the crash by simply adding a PWAD with shorter intermission graphics.
Based on my findings, it seems like Digital Cafe originally planned to have at least co-op multiplayer as an option, considering that the new levels in Chex Quest have co-op starts and the box advertised multiplayer support. But maybe they experienced the crash that happens with CHEX.WAD, and they didn't have the time to figure out how to fix it so they "disabled" multiplayer support by simply not including the multiplayer drivers. Since some of the levels also have deathmatch starts, they were probably considering having deathmatch style gameplay too even earlier in development.
Anyways, if anyone wants it I can release my Chex Quest compatible hex-edits of IPXSETUP and SERSETUP as well as some PWADs I made that shorten the intermission graphics, add more multiplayer starts to the levels and changes the player sprites to be green so that everyone has a different color outside of being slimed in multiplayer. Maybe it's not as good as using source ports for multiplayer, but it is an interesting novelty.
I'm about a decade late, but I finally got around to playing with source ports and getting TUCQ working. Thanks to Pokefan531 and Acts19quiz on Discord for much help. I played through TUCQR6 in both ZDoom 2.8.1 and GZDoom 2.2.0 on "Gobs of Goo." ZDoom has some graphical glitches in the lab and sewers, but I didn't notice other huge differences between them. Here are my thoughts:
First, great job with the graphical updates! The lighting on teleporters is really nice, as is the way the vines in the arboretum maze stand out from the surrounding walls. I like how you set up the ending of one level to connect logically to the beginning of the next throughout the game (but the cinema is completely missing?). The diner looks more vibrant than it did originally. The sky tunnel leading to the red key area in E2M4 gives it a modern look, and the elevator leading back down to the streets is a nice touch. Is the "large phasing zorcher recharge" completely new? I don't recall seeing that graphic before.
Next up, some gameplay changes. Giving the commonus and bipedicus long-range attacks increases the overall difficulty, IMO, and makes them more formidable foes. I think it also makes the original ending video more realistic; I had wondered how the flemoids got close enough to the ship to cover it in so much slime, but that's not a problem any longer if they can attack from a distance. Adding some larvae to the caverns was a surprise, but, again, one that makes sense. It seems more difficult to move through the water in the sewers than to move on the platforms, which is another realistic change IMO.
Now for some things that I found odd. In the caverns, you can only open the yellow key doors to the room containing the red key from one direction. Is that intended, or is it an issue with the source ports I used? Also in the caverns, the armored bipedicus in the secret path to the flembrane area somehow opened its door and flanked me as I was fighting the other enemies in the flembrane area. It happened in ZDoom, and I had taken the long path through the level rather than the shortcut. Never had that happen before, but I've mostly played CQ3. Oh, and the quadrumpus by the yellow key in the sewers opened the panel in the wall leading back to the main sewer area; that was in GZDoom. Another thing that's odd is how the entire blue key area seems optional in the sewers. I don't remember the original, but CQ3 has a fence that forces you to pass through the blue key area. That fence is missing in TUCQR6, so you just need the yellow key to get the red key and go to the end section. Speaking of the end section, are you supposed to be able to use the teleporter there without defeating all of the flemoids in the room first?
There were some other oddities that were specific to the secret areas. The way the secrets are counted in Episode 2 seems strange at times. In E2M1, there's that passage through grates that goes between the blue key room and the small storage space holding one larva and some food. You apparently need to enter it from each end, so it counts for at least two secrets. Opening the secret door in the red key area of the same mission by attacking it was different than any of the other secrets. There's apparently a secret in the museum that I could not find in either ZDoom or GZDoom. IDK if I'm not triggering its counting or if I need to attack something to open it, but I can't get more that 6/7 secrets there.
Finally, there's a spelling error after completing the first episode: bannishment should be banishment.
It's because Google doesn't know the website exists. Not sure why this happens, but when I used to work on websites I remember having to submit some stuff to Google. It's kinda of a pain but, they have a help page about it. https://support.google.com/webmasters/answer/7474347?hl=en You'll want to follow step 2.
Recent events had me look for the Chex Quest Gallery. The website is still up but none of its results appear on a Google search, to the point that "site:http://gallery.xboltz.net" gives me no results. Does anybody know why this is? Is it because of the TNCQ:G2 Base iwad or something?
It's a decision the compiler can make, it just so happened that 32 bit gcc interpreted the number a different way than 64 bit did. Neither one is right or wrong because both numbers are invalid integers and undefined behavior.
If it can't fit the whole number in 32 or 64 bits it tries to pick whatever it can fit into there, maybe it picked a different chunk of the data to interpret as an integer for the 32 bit version vs the 64 bit version.