Reaper Grimm
Register | User Profile | Member List | F.A.Q | Privacy Policy | New Blog | Search Forums | Forums Home
Doomworld Forums : Powered by vBulletin version 2.2.5 Doomworld Forums > Classic Doom > Source Ports > "Runworthiness" of the linuxdoom code?
Pages (4): « 1 [2] 3 4 »  
Author
All times are GMT. The time now is 06:53. Post New Thread    Post A Reply
Gez
Why don't I have a custom title by now?!


Posts: 10987
Registered: 07-07



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.

Old Post 07-07-11 18:35 #
Gez is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
printz
CRAZY DUMB ZEALOT


Posts: 8765
Registered: 06-06


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.

Old Post 07-09-11 21:26 #
printz is online now Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
AlexMax
Senior Member


Posts: 1114
Registered: 01-03


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/

Old Post 07-09-11 22:00 #
AlexMax is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
Gez
Why don't I have a custom title by now?!


Posts: 10987
Registered: 07-07



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.

Old Post 07-09-11 23:19 #
Gez is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
Quasar
Moderator


Posts: 5925
Registered: 08-00


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

Old Post 07-10-11 09:49 #
Quasar is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
hex11
Senior Member


Posts: 2237
Registered: 09-09



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

Last edited by hex11 on 07-10-11 at 11:15

Old Post 07-10-11 11:08 #
hex11 is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
Maes
I like big butts!


Posts: 12204
Registered: 07-06



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

Old Post 07-10-11 11:41 #
Maes is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
_bruce_
Senior Member


Posts: 1278
Registered: 11-07



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.

Old Post 07-10-11 13:35 #
_bruce_ is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
fawtytoo
Mini-Member


Posts: 51
Registered: 09-11


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.

Old Post 12-11-11 13:12 #
fawtytoo is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
fraggle
Filled with the code of Doom


Posts: 7464
Registered: 07-00


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

Old Post 12-11-11 14:18 #
fraggle is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
fawtytoo
Mini-Member


Posts: 51
Registered: 09-11



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.

Old Post 12-11-11 14:57 #
fawtytoo is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
wesleyjohnson
Forum Regular


Posts: 987
Registered: 04-09


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

Last edited by wesleyjohnson on 12-12-11 at 21:31

Old Post 12-12-11 02:39 #
wesleyjohnson is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
fawtytoo
Mini-Member


Posts: 51
Registered: 09-11


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

Old Post 01-10-12 11:06 #
fawtytoo is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Maes
I like big butts!


Posts: 12204
Registered: 07-06


Not ALL of these hardcoded values must be changed.

Old Post 01-10-12 11:56 #
Maes is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
fawtytoo
Mini-Member


Posts: 51
Registered: 09-11



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

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

Old Post 01-10-12 12:28 #
fawtytoo is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
fraggle
Filled with the code of Doom


Posts: 7464
Registered: 07-00



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.

code:
// 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;

Old Post 01-10-12 12:30 #
fraggle is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
fawtytoo
Mini-Member


Posts: 51
Registered: 09-11



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

See here.

code:
// 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.

Old Post 01-10-12 12:47 #
fawtytoo is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Quasar
Moderator


Posts: 5925
Registered: 08-00


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

Old Post 01-10-12 13:17 #
Quasar is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Maes
I like big butts!


Posts: 12204
Registered: 07-06



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

Old Post 01-10-12 13:19 #
Maes is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
fawtytoo
Mini-Member


Posts: 51
Registered: 09-11


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

Old Post 01-10-12 14:00 #
fawtytoo is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
fawtytoo
Mini-Member


Posts: 51
Registered: 09-11



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

Old Post 01-10-12 14:33 #
fawtytoo is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Maes
I like big butts!


Posts: 12204
Registered: 07-06



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

Old Post 01-10-12 14:39 #
Maes is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
fraggle
Filled with the code of Doom


Posts: 7464
Registered: 07-00



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.

Old Post 01-10-12 14:49 #
fraggle is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
fawtytoo
Mini-Member


Posts: 51
Registered: 09-11


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

Old Post 01-10-12 15:11 #
fawtytoo is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
_bruce_
Senior Member


Posts: 1278
Registered: 11-07



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!

Old Post 01-10-12 18:02 #
_bruce_ is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
Maes
I like big butts!


Posts: 12204
Registered: 07-06



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

Old Post 01-10-12 18:23 #
Maes is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
fawtytoo
Mini-Member


Posts: 51
Registered: 09-11



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:
code:
Patch at 0, -3 exceeds LFB V_DrawPatch: bad patch (ignored)

Old Post 01-11-12 12:06 #
fawtytoo is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
_bruce_
Senior Member


Posts: 1278
Registered: 11-07



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.

Old Post 01-11-12 12:27 #
_bruce_ is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
fawtytoo
Mini-Member


Posts: 51
Registered: 09-11



fawtytoo said:

Except now I get hundreds of these:
code:
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.

Old Post 01-11-12 19:30 #
fawtytoo is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
fawtytoo
Mini-Member


Posts: 51
Registered: 09-11


Why does Final Doom: Plutonia demo3 go out of sync?

Old Post 01-15-12 15:32 #
fawtytoo is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
All times are GMT. The time now is 06:53. Post New Thread    Post A Reply
Pages (4): « 1 [2] 3 4 »  
Doomworld Forums : Powered by vBulletin version 2.2.5 Doomworld Forums > Classic Doom > Source Ports > "Runworthiness" of the linuxdoom code?

Show Printable Version | Email this Page | Subscribe to this Thread

 

Forum Rules:
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is OFF
vB code is ON
Smilies are OFF
[IMG] code is ON
 

< Contact Us - Doomworld >

Powered by: vBulletin Version 2.2.5
Copyright ©2000, 2001, Jelsoft Enterprises Limited.