Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Maes

"Runworthiness" of the linuxdoom code?

Recommended Posts

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.


Another reason to use Boom instead of Linuxdoom as a base.

Share this post


Link to post

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).

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.

Or turn Doom into a text-based adventure where player input commands have the effect of pausing the game, unpausing, moving him forward, to the left, shooting etc. And you get text messages describing what you see, what happens, what will happen (thanks to the predictable random numbers, resulting something like "sergeant is going to shoot you without having time to go to cover if you don't shoot him now") and so on.

I actually tried to remove all the rendering code, but I wasn't sure what exactly to delete (I was fearing that gameplay logic might be hidden in R_ files too, for example), and wasn't sure if it would work at all, so I opted for an Eternity fork instead, benefiting both from full vanilla support and high-end mods this way -- but scrapping the idea of a non-drawn Doom code then.

Share this post


Link to post
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).

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:

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.

Honestly, if I were to write a demobot, I'd base it off PrBoom+ so that it can actually produce useful demos.

Share this post


Link to post

Fact: Not only did Bernd Kremeier do a slamdance all over the source before releasing it, but he also once totally blew off Linguica at E3. :P

Share this post


Link to post
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.


The game logic is based on the framebuffer? It doesn't use other data structures to maintain state?

I don't think this would be possible, except for simple 2D games like Arkanoid, Breakout, and other single screen games (Pengo, Pac-Man, Adventures of Lolo, Space Invaders...)

Share this post


Link to post
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).


Speaking from my experience with Mocha, it most definitively can. Perhaps the most tangible example of how rendering is a separate concern from game logic, even with unmodified vanilla Doom.exe, is to reason on how the automap works: "3D" rendering is effectively turned off (and all the slowdown that goes exclusively with it) while only the automap code "draws" on the screen, in what to some people appears like an asteroids clone ;-)

Doom is quite neatly separated into concerns on its own right, and if you wanted to make e.g. a turn-based text-based adventure or roguelike out of it (by typing commands like "go forward", "turn right 30", "switch weapon 3" etc. it would be perfectly feasible. Heh imagine if instead of seeing the monsters, you only got a textual description of what objects are in your field of view and/or in the same room as you ;-)

Now, there are a few murky points in the code (e.g. some R_ functions that are called elsewhere, too) but upon analysis most of them turn to be pure, stateless functions, so they could just as well be placed in a "package" of their own.

Similar considerations can be done for sound and player input: sound can end up into "dummies" without changing the code itself (there's s_sound.c, which is gameplay-specific and only does high-level positioning and channel management, and i_sound.c which is system-specific and actually does the gory mixing/DSP writes. You can have one without the other, if so you wish. You can make all functions of s_sound.c be dummies, or having s_sound.c completely functional but have no system-specific sound code (that's the approach I used for Mocha while it still had no sound).

Share this post


Link to post
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/


Cool - compiled without a hitch.

Share this post


Link to post

This may or may not be slightly off-topic.

I've compiled linuxdoom but get errors when trying to play a game. The same happens with sdldoom. I'm thinking there's some bugs to do with memory management, i.e caching of lumps, but not sure how to fix it.

DOOM 2: Hell on Earth v1.10
V_Init: allocate screens.
M_LoadDefaults: Load system defaults.
Z_Init: Init zone memory allocation daemon.
W_Init: Init WADfiles.
adding ./doom2.wad
===========================================================================
Commercial product - do not distribute!
Please report software piracy to the SPA: 1-800-388-PIR8
===========================================================================
M_Init: Init miscellaneous info.
R_Init: Init DOOM refresh daemon - [.Segmentation fault ]

I'm experienced in C/C++ but not with Doom code.

Share this post


Link to post
fraggle said:

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

D'oh! Yeah. Did a 32 bit compile and sweet. I guess the pointer size bugs are what the gcc warnings are referring to in a 64 bit compile.

Share this post


Link to post

To make it run as 64 bit.
Use stdint.h and start changing anything that needs a uniform word size to uint32_t and the like. Especially must get every structure that
is used to read wad data.
If you want to see where, get a copy of DoomLegacy alpha3. We have been through this exercise and think we got most of them.
Just grep for all the int32 int64 in all the *.h files and *.c files

Messes up MAXINT too, as fixed_t will no longer be same as int.
Had to create FIXED_MAX and track down all MAXINT used on fixed_t vars (this fix not committed yet).

Share this post


Link to post

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

I changed the SCREEN_MUL in doomdef.h:
#define BASE_WIDTH 320
#define SCREEN_MUL 3
#define INV_ASPECT_RATIO 0.625 // 0.75, ideally
#define SCREENWIDTH (int)(SCREEN_MUL * BASE_WIDTH) // 320
#define SCREENHEIGHT (int)(SCREENWIDTH * INV_ASPECT_RATIO) // 200
... and gone through the code and changed any hard coded numbers (320, 200, 160, 100) related to drawing and swapped for SCREENHEIGHT and SCREENWIDTH. It works to an extent, but has a weird side effect. As the screen blocks is increased (above 5 if that's relevant), the floor gets drawn higher up the screen but the walls and ceiling are in the right place.
Screenshot: http://fawtytoo.org/linuxdoom.png

Share this post


Link to post

Not ALL of these hardcoded values must be changed.

Share this post


Link to post
Maes said:

Not ALL of these hardcoded values must be changed.

I only changed few in r_draw.c and r_main.c really

Share this post


Link to post
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.

Ah, classic. Notice how in your screenshot it looks mostly okay at the top part of the screen?

See here.

  // Here lies the rub for all
  //  dynamic resize/change of resolution.
  byte          top[SCREENWIDTH];
  byte          pad2;
  byte          pad3;
  // See above.
  byte          bottom[SCREENWIDTH];
  byte          pad4;

Share this post


Link to post
fraggle said:

Ah, classic. Notice how in your screenshot it looks mostly okay at the top part of the screen?

See here.

  // Here lies the rub for all
  //  dynamic resize/change of resolution.
  byte          top[SCREENWIDTH];
  byte          pad2;
  byte          pad3;
  // See above.
  byte          bottom[SCREENWIDTH];
  byte          pad4;

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

Share this post


Link to post

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

Share this post


Link to post
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.


Heh, I nearly forgot that one. Yeah, visplane buffers are resolution-dependent but since they are driven by the SCREENWIDTH constant, that should not be a problem. In fact, you're not missing anything, width-wise.

The real problem seems to be in the DrawPlanes code or even before, when setting the bottom visplane boundaries, since you obviously are getting wrong vertical clipping for the floor.

@Quasar: if I remember correctly these pad bytes eventually do get written and serve a purpose in the MapPlanes code (?).

Share this post


Link to post

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

Share this post


Link to post
fawtytoo said:

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

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

Share this post


Link to post
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


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).

Share this post


Link to post
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

If you read the comments nearby they're there deliberately to allow the ends of the arrays to be overflowed.

Share this post


Link to post
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).


Clever idea!

Share this post


Link to post
_bruce_ said:

Clever idea!


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.

Share this post


Link to post
fawtytoo said:

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

Except now I get hundreds of these:

Patch at 0, -3 exceeds LFB
V_DrawPatch: bad patch (ignored)

Share this post


Link to post
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.


Yep - well done.

Share this post


Link to post
fawtytoo said:

Except now I get hundreds of these:

Patch at 0, -3 exceeds LFB
V_DrawPatch: bad patch (ignored)

Uh, don't worry. It was a few more hard coded numbers to change. It was trying to draw the borders' bevelled edge outside the screen area.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×