---

hex11 said:
Anyway, in the article it says the Boom team was temporarily given access to the original DOS Doom source, so they could correct any discrepancies.

---

---

printz said:
I'm curious: does compiled Linuxdoom run successfully if you manage to strip it of all the graphics, sounds and player input overhead, remaining a mere console utility instead? Keep in mind that the game logic must still work fully, but nothing to display other than relevant text messages at the DOS prompt (no video mode change, no waiting, no music, no sound).

---

---

printz said:
All this is in the interest to have access to the whole Doom logic (WAD support, gameplay thinking, monsters, things...) so I can take advantage of it if I want to code a demo-recording bot, without actually having to see it record in real time. Imagine having the ability to autorecord (with varying success) a megawad within a single minute or less, because there's no rendering overhead.

---

---

Gez said:

I don't think you can preserve game logic if you remove the renderer entirely. At the very least, you'll have the software renderer still drawing into framebuffers, even if these are not then sent to the screen.

---

---

printz said:
I'm curious: does compiled Linuxdoom run successfully if you manage to strip it of all the graphics, sounds and player input overhead, remaining a mere console utility instead? Keep in mind that the game logic must still work fully, but nothing to display other than relevant text messages at the DOS prompt (no video mode change, no waiting, no music, no sound).

---

---

AlexMax said:
For what it's worth, if you want something a little more advanced than Vanilla Doom yet still pretty "simple" that compiles with a few minor modifications, you can give WinMBF a try.

http://mancubus.net/svn/winmbf/

---

---

fraggle said:
Are you doing a 64-bit compile? There's a huge host of pointer size bugs in there.

---

---

Maes said:
Not ALL of these hardcoded values must be changed.

---

---

fawtytoo said:
I've dome some improvements and bug fixes to linuxdoom (64 bit can wait), but am having some trouble with increasing the resolution.

---

---

fawtytoo said:
I noticed that too, but that would only affect a dynamic change, whereas mine is still hard coded. Unless I've not understood something.

---

---

fawtytoo said:
Yes Fraggle, now I understand. The top and bottom in the visplanes are bytes and restrict the view height to 256 pixels.

---

---

fawtytoo said:

And suggestions on how to fix this would be appreciated as simply making them integers gives an error:

Error: R_MapPlane: 0, 639 at -1

---

---

Quasar said:
I've always loved how those pad bytes in the visplane are a tacit admission that DOOM couldn't control its memory access to the byte :P

---

---

Maes said:


Source ports with super-vanilla resolutions typically expand the visplane's datatype to short to handle this sort of issues. This also implies there's a maximum resolution limit for visplanes.

Furthermore, in Mocha Doom, the upper bits of visplanes markers are interpreted as thread concurrency locks to ease parallel rendering of visplanes under certain modes, thus putting a lower upper limit still (e.g. 3 bits reserved for thread id numbers, the remaining 13 for height markers, so max vertical resolution is "just" 8K pixels using this concurrency method).

---

---

_bruce_ said:
Clever idea!

---

---

fawtytoo said:
In fact, changing top and bottom to unsigned shorts and all the markers from 0xff to 0xffff works.

---

---

Maes said:


The locks thing? I needed a way for threads to tell apart (horizontal) delimiters set from other threads without "stomping" them, which could cause threads to do needless overdraw or even deadlock. This was the least intrusive system, as it allowed encoding both the marker's value and the thread owner in the same spot, thus making sure each thread only mapped its own horizontal portion of a given visplane.

---