Assorted DOS port compiling questions (was dog graphics in mbf)

Danfun64 said:

An idea came to me: Put Crispy Doom's demo fix into Boom.

Do you mean the "fix" that pauses the game upon menu access when recording a demo?

fabian said:

Do you mean the "fix" that pauses the game upon menu access when recording a demo?

Yes. What I did was compare the crispy doom and chocolate doom code for the fix, then when I round what I was looking for, I transplanted it to the boom source. Surprisingly, the code didn't need to be changed in order to be used in boom. My only problem is that in multiplayer, all sides must be demo recording or I get a consistency error, which may or may not be related to the fix.

Danfun64 said:

My only problem is that in multiplayer, all sides must be demo recording or I get a consistency error, which may or may not be related to the fix.

Ouch! So, it will desync on way or the other. Maybe I should disable that fix in multiplayer games. Could you please file an issue on the Github tracker so we can take this discussion there?

fabian said:

Maybe I should disable that fix in multiplayer games.

Absolutely not! That fix is one of the main reasons I use crispy doom. A partial fix is better than no fix at all. Besides, I only tested that with Boom. Crispy Doom might handle things differently.

Per the GPL, I posted the modified code in the zip containing the modified binary. I can recognize code, but I can't code myself, so I might have missed something consistency related.

edit: I tested recording multiplayer demos on crispy doom. There are no desyncs or consistency errors. It must have been something I missed on the boom side of things.

Danfun64 said:

Per the GPL, I posted the modified code in the zip containing the modified binary.

Hm, where?

edit: I tested recording multiplayer demos on crispy doom. There are no desyncs or consistency errors. It must have been something I missed on the boom side of things.

That's good to know, thanks for testing!

Don't you love it when you get to quote yourself?

Danfun64 said:

http://www.mediafire.com/download/qiiud8iojdvjyl7/boomfix.zip

Tools
Is it legal to provide your DOS development tools? I would love to have a zip of the old DOS apps and binaries/libraries necessary to compile BOOM and friends. You know, these (copied from previous post):

. bnu27b GNU binutils 2.7 for DJGPP V2
. csdpmi4b CWSDPMI binary distribution (release 4)
. djdev201 Development Kit and Runtime
. gcc2721b GNU GCC 2.7.2.1 for DJGPP V2
. mak3761b GNU Make 3.76.1 binaries for DJGPP V2
. txi390b GNU texinfo 3.9 for DJGPP V2
. Allegro version 3.0.

Any chance you can provide those as a zip file?

Dog lumps
Also, I was looking at the discussion about the hard-coded lumps in MBF. Those can be bypassed by simply providing a wad that contains lumps of the same names, if I remember correctly. Yeah, a goofy approach, but I get it - he didn't want to need any external wad files, like an "mbf.wad" that had to be loaded each time. Kinda strange...

Demo fix
On the multiplayer pause:
So, you want your game to pause all players when someone enters a menu?

In my home port, I took a different approach: The game continues when someone enters the menu, and all menu settings that can affect demo/net sync are propagated to all players in real-time, and saved in the demo. Of course, my demos are not vanilla compatible.

Cheats are also allowed, and propagated to all players in real-time. So, if one player types IDNOCLIP, all players enter no-clipping mode. Actually, it's a bit more involved. The first time the cheat is typed, each player's clip state is transmitted, and, if they're not the same, every player's IDNOCLIP state is turned off, leaving everyone in the same state. From that point on, typing the cheat toggles the setting for everyone.

This prevents cheating while cheating! Players can get in different states if, for example, everyone is no-clipping, and a player gets shot. When that player respawns, he will be clipping.

It works really well, for example, in coop, especially when playing a non-coop-friendly map. Often, you can get into a situation where a door closes behind a player, then the player dies, sealing off part of the map. Multi-user noclip cheat to the rescue! Everyone noclips, walks through the blocked door, and then everyone clips again. If done properly, everything stays in sync.

This should provide everything needed.

edit: Also, what is your home port?

Danfun64 said:

This should provide everything needed.

edit: Also, what is your home port?

It's just something I've been working on for a few years. It tries to be a highly-optimized all-purpose port with good vanilla demo compatibility and mechanics, good LAN multi-user support (I play a lot of coop), yet able to handle lots of new editing features. It's also a testbed for a new programming language I've been working on - a compiled byte-code thing. Sort of a mix between C and BASIC. One day I hope to eventually release it, while, hopefully, it still has unique features.

Does your port also support internet play? Do demos recorded in your port capture chat, which vanilla and boom don't? How many players are supported in multiplayer, vanilla's 4 player limit, or more? What is your port based off of? The original linux doom source? Chocolate/Crispy Doom? Boom? MBF? WinMBF? Prboom-plus? DOSDoom?

Sorry for all the questions :P Hey, you can't help a guy being curious, huh?

Danfun64 said:

Does your port also support internet play? Do demos recorded in your port capture chat, which vanilla and boom don't? How many players are supported in multiplayer, vanilla's 4 player limit, or more? What is your port based off of? The original linux doom source? Chocolate/Crispy Doom? Boom? MBF? WinMBF? Prboom-plus? DOSDoom?

Sorry for all the questions :P Hey, you can't help a guy being curious, huh?

No problem - it inspires me to get working! It runs a perfect 4-player LAN game over UDP, but has no client/server, or prediction code, so it would lag on the internet. It also has no desync correction or in-game joining, all of which is necessary for a good internet experience. It is planned, but I won't implement it unless I can figure out how to handle the prediction in a way that I'm satisfied with.

In a way, it's based off of pieces of all of those ports and more. It started it's life as the first ZDoom, v1.11, actually. At the time, it was the only port that would compile flawlessly with VC6 on my machine, without modification, so I ran with it. Then, I hacked on it like a madman, making it into some frankenstein POS Doom/Heretic/Hexen/anything-else-I-could-throw-at-it port. It was pretty damn awful, requiring a 250mb PWAD to simply launch.

It always annoyed me that the IWAD demos would not play, so at some point, I got fed up, and spent the next few months creating a configuration language, and converting all of my hard-coded hacks into pwad-configurable options. Eventually, I got rid of info.c and info.h, weapon/sound/pickup definitions, and just about everything else hard-coded, including all original definitions.

I also added Boom/MBF additions, and tons of demo and other fixes from those ports, as well as PrBoom/PrBoom+. And plenty of other functionalities were added from the other ports. Finally, I was able to add a few of my own, for some still unique features.

You really can spend a lifetime enhancing Doom. Especially when your goal is to add every-damn-thing you ever wanted in Doom :) Sure, I'll finish one day...

kb1 said:I also added Boom/MBF additions, and tons of demo and other fixes from those ports, as well as PrBoom/PrBoom+. And plenty of other functionalities were added from the other ports. Finally, I was able to add a few of my own, for some still unique features.

Feel free to steal anything you want from Fusion (immediate descendant of MBF):

http://www.area34.com/source/fusion/

Can your monsters throw a boomerang? Ours can! :D

Rez said:

Feel free to steal anything you want from Fusion (immediate descendant of MBF):

http://www.area34.com/source/fusion/

Can your monsters throw a boomerang? Ours can! :D

Very cool, and thanks for the kind offer. I haven't audited other sources in a long time, since I replaced all the hard-coded crap with end-user-editable configuration. Now that it's working pretty well, it's time to revisit the hard work of other port authors. Luckily for me, and everyone else, most port authors are quite generous in this regard.

I still dream of a unification of all the ports, or at least an attempt to be able to load the custom linedef types, thing properties, etc of other ports. We basically got as far as Boom/MBF, but that's about it. UDMF took a big stab at the problem, but support for it has been very slow. My port cannot yet read UDMF either, but it's planned.

Boomerangs, huh? :) Cool. I imagine hearing players: "WTF just hit me? BAM!" I'd like to see a boss throwing monsters at you, like a boomerang. Does the monster always catch the boomerang, or can it over/under shoot. Can the player catch or pick it up and use it against the monster?

I'll have to check that out! I imagine it's tricky - Doom has always been goofy about the location that missiles spawn from a monster. So I guess catching a boomerang required some trickery to make it look right.

Eventually, I intend to have a scripting language that would allow the pwad author to create a "Boomerang" effect all within scripting. However, my philosophy would cause me to create an Action function, like "A_Boomerang()", for the more obvious cases. Built-in support will always be faster than the scripting language. It's kind-of hard to draw the line, you know. I don't want a ".NET"-like library of 50,000 action function pointers either :)

Well, the monster doesn't catch the boomerang, but ... it loops back unpredictably (and sometimes at weird angles) and very often whaps you on the back of the head when you thought you were perfectly safe.

Our MythTC (we'll release it some year, we promise!) has a centaur that throws boomerangs, and occasionally when killed spawns an invisiknight. Once in a long while an invisiknight gets killed by a slow-returning centaur fireball from its own parent, which I find hilarious. -- And we have other oddities like the vomit demon (it leaves vomit here and there, some of which turns into ghosts), the magic ever-growing mushrooms, and the barons with bad aim.

Blame another member of our team for all this: Len Pitre, dehacked madman and master of weird codepointers. All I understand about this stuff is that it often makes me run for my life. :)

I wish there was some LuaDoom port or something, where the gameplay and monster logic is translated to Lua, all game objects and their properties are exposed and the mapper can create hooks at specific points where his lua code is executed.

There was a python Doom port but it's dead :-(

What do you think of hyper3DGE, VGA?

...I can't believe I'm going off topic on my own topic.

Rez said:

...
Our MythTC (we'll release it some year, we promise!) has a centaur that throws boomerangs, and occasionally when killed spawns an invisiknight. Once in a long while an invisiknight gets killed by a slow-returning centaur fireball from its own parent, which I find hilarious. -- And we have other oddities like the vomit demon (it leaves vomit here and there, some of which turns into ghosts), the magic ever-growing mushrooms, and the barons with bad aim. ...

Whoa, that sounds very cool, inventive, and unique. I'll be looking for this one. And, apparently I'll be needing to add an A_Vomit() function :)

VGA said:

I wish there was some LuaDoom port or something, where the gameplay and monster logic is translated to Lua, all game objects and their properties are exposed and the mapper can create hooks at specific points where his lua code is executed. ...

Well, for conversion of the entire codebase, there's Mocha Doom. As you asked, all of the gameplay, logic, objects and properties have been ported to Java.

My plan is not so ambitious (and may be more inline with what you were describing): Config lumps are used to setup the game objects (monster, pickup, weapon) properties. These can be altered by script code during a game. However, all gameplay/monster logic will default to built-in original native code. There will be an event model, but it will be hidden (and essentially non-existant) unless an event is explicitly defined for monitoring.. Hopefully, the script language will be 'installable', allowing it to be potentially swapped out for another.

Come to think of it, that's an ambitious goal too (heh), but it's definitely in an 'in-progress' state.

But, again, Doom will act as a testbed for my new script language, so, if a good game comes out of it, so be it.

kb1 said:
Whoa, that sounds very cool, inventive, and unique. I'll be looking for this one. And, apparently I'll be needing to add an A_Vomit() function :)

For real weirdness, I load ours on top of Strain. That produces stuff like holobots that spit gravity-affected tracking fireballs with blast radius (holy-shit deadly at the bottom of hills!) Even Len hasn't quite figured out why it runs at all, let alone how it works. :)

Rez said:

For real weirdness, I load ours on top of Strain. That produces stuff like holobots that spit gravity-affected tracking fireballs with blast radius (holy-shit deadly at the bottom of hills!) Even Len hasn't quite figured out why it runs at all, let alone how it works. :)

Eh, what?! ;)

Yep, that's what everyone says :) Yes, I load both TCs (graphics and DEHs, anyway) and use that to play ordinary maps. Puts a whole new light on old standards. And since Len used frames from so many lamps and such, the furniture comes to life and chases you around. :D

I can haz video?

Argh, I'm not sure how I'd do video (other than ordinary LMPs), being it's purely DOS. And Fusion isn't supported by PRBoom+. :(

You can record video from DOSBox. The default start/stop combination for recording video is Ctrl-Alt-F5; this probably won't work if you're on Linux, press Ctrl-F1 to remap keys.

WinXP and DOS here, no linux. DOSBox on XP was a total fail first time I tried it. Anyway I'll see if I can get it going. Everyone deserves to share the scare! :)

Rez said:

For real weirdness, I load ours on top of Strain. That produces stuff like holobots that spit gravity-affected tracking fireballs with blast radius (holy-shit deadly at the bottom of hills!) Even Len hasn't quite figured out why it runs at all, let alone how it works. :)

Ok, no fair - you just can't tell me how cool it is, and not offer a demo :)

Rez said:

WinXP and DOS here, no linux. DOSBox on XP was a total fail first time I tried it. Anyway I'll see if I can get it going. Everyone deserves to share the scare! :)

DOSBox is awesome, and pretty solid. Definitely try it again, and give the README a try. It should really just work on XP.

Two things to consider:
1. There's some keystrokes: CTRL+F11 and CTRL+F12 (I think that's what they are, or maybe it's CTRL+SHIFT+F11 and CTRL+SHIFT+12, I can't check right now). Anyway, they control the emulation speed, and, on my machine, I have to increase the speed to get good framerates. The config file also allows you to set the default speed, and many other things, like the emulated video card and sound card, etc.

2. You have to mount your DOS folder as a DOSBox drive from with DOSBox. This would be your folder containing the DOS exes and other game files that you want DOSBox to run and emulate. Let's say that those are in your C:\OldDOS\Games folder.

From the DOSBox DOS prompt, type something like "MOUNT Z C:\OldDOS\Games". This gives DOSBox a Z: drive which contains the contents of your real C:\OldDOS\Games folder. Nothing will happen until you do that. Then, type DIR Z:\*.*, and you should see your DOS games, from the perspective of a virtual Z: drive mapping.

Then, you run your game:

Z: [ENTER]
cd \DOOM [ENTER]
DOOM.EXE

Please read the DOSBox docs, cause I am typing this from memory, and I may be a bit off. Good luck!

Rez said:

For real weirdness, I load ours on top of Strain. That produces stuff like holobots that spit gravity-affected tracking fireballs with blast radius (holy-shit deadly at the bottom of hills!) Even Len hasn't quite figured out why it runs at all, let alone how it works. :)

Have you tried with The Sky May Be?

Gez said:Have you tried with The Sky May Be?

Nope, but I didn't really care for it back when I played it, a thousand years ago.

But that's a good thought... any other good TCs that might make a decent mix-and-match?