Bad Mood : Falcon030 'Doom'

[dml]

Thanks for the info! I'm not very sure about the 32X details so I didn't want to comment much on it other than the fact it looks pretty similar to BM when the same level data is used.

More than 256 cols onscreen at once... that might explain why the 3D view looks less grainy than the PC one, maybe similar to BM using 256 colour source textures from the WAD but drawing them with extra colours via light/shading etc.

Granted, I don't know where the 32X screenshot came from and it could be under-representing the image quality a good bit.

[bullis1]

More than 256 cols onscreen at once... that might explain why the 3D view looks less grainy than the PC one, maybe similar to BM using 256 colour source textures from the WAD but drawing them with extra colours via light/shading etc.

Granted, I don't know where the 32X screenshot came from and it could be under-representing the image quality a good bit.

Don't get me wrong, the main game window (the viewport) is only showing 256 colours. The extra colours are in superfluous areas.

The visual quality of the 32X port is pretty weak overall. It uses horizontally doubled pixels in conjunction with a reduced window, and only uses one of the 32X's two SH2 processors for rendering. There are earlier beta versions and an unreleased (but leaked) re-release that do things differently.

Your improvements to BadMooD (especially the shaded walls and "lightshaft" shader) really make me want to tackle a Falcon version of my game someday. However in the meantime it's the tight limits of the 32X port that keep me thinking creatively and that's why I chose it as a base.

Another interesting thing to try to implement would be the faked method of freelook as seen in the BUILD engine (Duke 3D, Blood, etc.), Rise of the Triad, or ZDoom. The BUILD engine sources and pages are full of fascinating ideas and optimizations for an engine such as this. http://advsys.net/ken/build.htm
Of course I'm well aware that simply getting Doom to run swiftly on a stock Falcon is the most interesting feat of all.

[dml]

Yeah there's some interesting stuff there. I remember the ROTT game and some of the changes that were made but not the timeline and where they came from

I had considered lookup/down in BadMood since it's an easy projection mod. I think everything else will just work, even the floor stuff since I don't have any horizon hacks in there (at least I hope not). I'm just not sure it will get much use with original Doom game code but it would be useful if the engine is used for another Falcon game.

Sloping floors etc... that's an interesting one. I forgot about that! TBH this doesn't fit with the floor shading technique optimized for Doom (no change in Z for any floor span) but I did work out how to shade angled surfaces with the DSP when I was working on Q1. I didn't finish the code but it can be done. One tricky problem is defining the slope - Doom-compatible editors just specify a floor/ceiling height but you could 'tilt' the floor using a normal and re-project the walls to meet the new floor intercepts. If I was going to implement floor gradients, that's probably how I'd do it. Although it would make sense to check what sort of editor extensions have been made in recent years before lifting a finger....

Voxels... dunno about that one. Not thought about it for BM. Would be an interesting mod though, for organic/outdoor terrain etc.

For now I'll stick with stuff that can be easily interfaced with Doom #1. Might add some other non-Doom bits later if anyone wants to work on a game.

[EDIT]

"after talking with John Carmack on the telephone"...

This reminds me of a short exchange I had with JC many years ago, but it was over something mundane like framebuffer cycling on the PC. I honestly don't know why I didn't have something better to talk to him about at the time. doh.

[dml]

I know this is getting off-topic but I've been working on a game using Doom 32X as a base for about a year now so I couldn't resist chiming in on this particular port.

Is there somewhere this game is being documented so we can take a look at progress? Interested to see what you're up to and it seems relevant to this port (if not to Atari stuff).

[bullis1]

I don't have anything online to show yet. I've been working on it for a while but it's still early days really. Basically the major changes my project has over Doom would be hub-based gameplay (like in Hexen) and a special colourmap/fade table that is designed to mimic real-world daylight. Well, that and a photorealistic art style.

The level and texture data is really optimized like crazy so I'm sure it would perform well on Falcon. Also it runs in 256KB RAM more or less. I'll have to make a major push to finish up a level hub and then I can hand it off to you for you to make some tests with sometime. I'd very much love to move the project over to Falcon and do a whole BadMood-based game but without a real Falcon for development and testing it'll have to wait. Also the whole point of starting this project was to rectify the "32X has no games" problem

I'm pretty sure ZDoom (and many modern editors) incorporates most features of BUILD now (slanted floors, scalable textures, translucency). I really suggested the freelook mostly as it seems easy to implement and it is useful in stock Doom maps. Actually I forgot that "fake" look-up-and-down was already implemented in Hexen. Might be worth having a look at those sources. Of course its far from essential. I'm basically thinking out loud.

Also I forgot to express my pleasure earlier when it was mentioned that Eero was working on Quake for TT in some form

[dml]

Also I forgot to express my pleasure earlier when it was mentioned that Eero was working on Quake for TT in some form

In fact I didn't mean to 'book' Eero into working on that - he's a busy guy with lots of other stuff going on There's no commitment from either of us on Q1 for TT!

But we did set up a repo with my old code in it, and I transferred his new BM makefiles there and got it roughly working on 68030, and he's been doing some stuff with that since - setting up autoprofile scripts, figuring out some code problems and testing on TT TOS (which it refuses to run on until I fix something). So something might come of it later, but probably not right now.

[dml]

I don't have anything online to show yet. I've been working on it for a while but it's still early days really. Basically the major changes my project has over Doom would be hub-based gameplay (like in Hexen) and a special colourmap/fade table that is designed to mimic real-world daylight. Well, that and a photorealistic art style.

Sounds good to me. Are you going to keep it under wraps until its done (usually a good move) or make the mistake of posting everything you change, like I have?

The level and texture data is really optimized like crazy so I'm sure it would perform well on Falcon. Also it runs in 256KB RAM more or less. I'll have to make a major push to finish up a level hub and then I can hand it off to you for you to make some tests with sometime. I'd very much love to move the project over to Falcon and do a whole BadMood-based game but without a real Falcon for development and testing it'll have to wait. Also the whole point of starting this project was to rectify the "32X has no games" problem

Anything that could spark a new Atari game project is interesting, esp. a 3D thing so I hope you do move it over! Even better if you can find a use for the BadEngine too

[Eero Tamminen]

I'd very much love to move the project over to Falcon and do a whole BadMood-based game but without a real Falcon for development and testing it'll have to wait.

While real machine would be nice, Hatari can emulate Falcon, so there's no need to wait.

Also I forgot to express my pleasure earlier when it was mentioned that Eero was working on Quake for TT in some form

"Working" is way too strong term, I've just added Hatari profiling support to Douglas Q1 sources and looked at bit at the problems:

• Even with 14MB (max emulated by Hatari), Q1 crashes fairly soon after timedemo starts. This was with Falcon emulation.
• As Q1 uses just CPU, TT makes more sense for it than Falcon, but Doug's current code crashes already at video init on TT. As that code is asm, I'm not going to touch it.

I'm nowadays busy at work, so if somebody wants Q1 to proceed, they would need to get involved. I can help with Hatari side and profiling where CPU is wasted.

FYI: current Q1 bottlenecks in Sparemint GCC build are:

Code: Select all

  31.80%                    17517751                       _etext_1
   6.80%                     3747288                       _D_DrawAdaptiveSpans
   4.65%   4.66%   4.66%     2561161   2568898   2568898   _CalcSurfaceExtents
   4.45%   4.46%   4.46%     2448508   2455314   2455314   _R_DrawSurfaceBlock8_mip1
   3.88%   3.89% 549.52%     2138628   2145076 302679525   _R_RecursiveWorldNode
   3.72%   3.73%   4.10%     2048613   2054624   2259578   _Mod_LoadAliasFrame
   3.20%   6.05%   7.49%     1763693   3332327   4124956   _R_ClipEdge
   3.13%   3.22%   9.36%     1726586   1772058   5158114   _R_RenderFace
   2.46%   2.47%   2.47%     1355954   1360792   1360792   _LongSwap
   2.44%   2.44%   2.44%     1342835   1345876   1345876   _D_DrawZSpans
   2.20%   2.21%   2.21%     1210940   1214706   1214706   _R_DrawSurfaceBlock8_mip2
   2.13%   2.13%   2.13%     1171550   1175313   1175313   _Draw_Character
   1.14%   1.14%   1.14%      628214    629536    629536   _strcmp

_etext stuff is a bit weird. Most of the CPU time is spent on memory address *after* the TEXT section. Doug said that there's no generated code, but that it looks like c2p code.

PS. If somebody wants to discuss Q1 more, please start separate thread.

[dml]

_etext stuff is a bit weird. Most of the CPU time is spent on memory address *after* the TEXT section. Doug said that there's no generated code, but that it looks like c2p code.

Yes it is the c2p code and it's not generated - but it's probably just the way the ASM code is being linked into the binary. Something we'll need to watch in BM too I suppose.

PS. If somebody wants to discuss Q1 more, please start separate thread.

Indeed! While it is related, it's not the same thing

[bullis1]

In fact I didn't mean to 'book' Eero into working on that - he's a busy guy with lots of other stuff going on There's no commitment from either of us on Q1 for TT!

"Working" is way too strong term...
PS. If somebody wants to discuss Q1 more, please start separate thread.

Haha don't worry about it. I'll pretend I never heard a thing

Sounds good to me. Are you going to keep it under wraps until its done (usually a good move) or make the mistake of posting everything you change, like I have?

Both approaches have their advantages I think this time I'm going to wait until I have a significant chunk done before I show anything off publicly.

I'll be strongly considering a Falcon version but I think unless I'm approached seriously with code help it will have to wait for now.

Sorry for the derail!

[dml]

Brief update...

Last night I tried an experiment which trades DSP calculation cost for instruction cache hits on the CPU side, hoping for a speedup.

Instead of drawing wall column #1 while the DSP calculates occlusion and terms for column #2, all columns are buffered immediately to memory and all walls drawn together in one pass at the end (as floors and transparencies are already).

I thought this was worth trying because the slowest scenes tend to have 1 or 2 walls per subsector (!), with subsector flushes forced by floor state changes (floors can't be generated until wall edges are, and new DSP floor zones can't begin until old ones are flushed out - typically forcing walls edges to be committed before the next subsector begins if the floors don't match - a consequence of not having enough DSP ram to buffer up all the floor areas with individual renderstates until scene end).

However tests show things are a bit slower after the change. The DSP wall column costs which become visible and the extra memory transactions to buffer/unbuffer the wall columns don't pay for the moderate/low level of cache misses in column drawing. So I'm going to stick with what I had and look at other ways to speed up worst-case maps.

It's worth noting that BM handles maps pretty well if the subsectors have several walls each - it's mainly when the subsector count approaches the wall count that things begin to crap out (e4m2 appears to be one of the worst maps in Doom1 for this, and it's notable that this last episode only appeared after 486's were commonplace...).

One thing I haven't tried is separating the BSP pass from the wall/floor generation, so the BSP walk only collects subsectors which are visible and only updates the occlusion buffer for solid walls (something like Doom's 'solidsegs'), doing nothing else at that stage. The actual wall and floor generation is done only after the BSP is complete, with a bit more flexibility for ordering things like floors. I'm not eager to rework all that stuff unless it looks like a big win so will just keep it on the shelf for now...

I have done some other optimizations which make certain types of wall setup optional, based on the type of drawing/shading for a given wall. So quite soon sprites will be cheaper to insert with constant-z and luma for all columns and no left-clip intercept for edge-y, and invisible partitions won't be setting up texture terms etc. It's not a big saving but it does add up with lots of walls and sprites.

[Eero Tamminen]

One new profile for Doomu, last level, after going out of the start room, killing few monsters.

CPU side:

Code: Select all

Visits/calls:
   8.60%               29363             R_BSPHyperPlane_RHS
   7.18%  30.07%       24528    102710   _P_MobjThinker
   6.66%   7.58%       22761     25902   _PIT_CheckLine
   6.46%               22064             R_BSPHyperPlane_LHS
   5.50%               18778             copy16_d
   3.09%   3.09%       10554     10562   _PIT_CheckThing
   2.10%   5.30%        7185     18111   _P_BlockThingsIterator
...
Executed instructions:
  34.19%                    10716363                       render_wall_1x1
  20.23%                     6339527                       R_TransparentColumnShader_Masked
   6.95%                     2179305                       R_VisPlaneSkyShader
   3.65%                     1143571                       R_VisPlaneShader
   2.29%   2.29%   2.29%      717962    718768    718768   _R_PointInSubsector
   2.25%                      705807                       R_StackTransparentSurface
   2.13%   2.13%   2.13%      666616    668926    668926   stream_texture
   1.92%   1.93%  14.76%      603351    604537   4626640   _P_MobjThinker
   1.75%   1.75%   2.30%      548032    549231    720478   _V_DrawPatch
   1.50%   1.50%   2.90%      469929    471252    910160   _P_BlockLinesIterator
...
Instruction cache misses:
   9.66%   9.69%  20.69%      300383    301124    643072   _P_BlockLinesIterator
   8.95%   8.96%  10.61%      278178    278581    329932   _PIT_CheckLine
   6.22%   6.24%  55.10%      193300    193945   1712853   _P_MobjThinker
   5.82%   5.84%  61.08%      180961    181461   1898687   _P_RunThinkers
   4.73%   4.74%  31.08%      147083    147445    966223   _P_CheckPosition
   4.08%   4.09%   4.40%      126841    127101    136649   R_AddSpriteSpans
   3.38%   3.40%   3.40%      105001    105644    105644   _R_PointInSubsector
   2.00%   2.01%  36.16%       62070     62415   1124041   _P_TryMove
   2.00%   2.01%   4.17%       62056     62434    129772   _P_BlockThingsIterator
   1.95%   1.96%   1.96%       60511     60867     61014   _PIT_CheckThing

There's new shader visible now!

DSP side:

Code: Select all

Visits/calls:
  78.15%   1.38%      984489     17339   P_CrossSubsector
   3.85%   3.85%       48563     48563   R_DoColumnPerspCorrect
   2.07%               26015             trans_skip
   1.53%               19285             lowerwall_skip
   1.37%               17223             midwall_skip
   1.03%   1.03%       13004     13004   TestLineSegVectorBisection
...
Used cycles:
  46.19%                   229783458                       command_base
  26.72%  26.72%  26.72%   132899934 132899934 132899934   R_DoColumnPerspCorrect
   5.93%                    29513824                       R_VPRenderSky
   5.23%                    25997568                       VPRenderPlaneDT_
   4.05%                    20144940                       R_VPLoadTexture
   1.67%   1.67%   1.67%     8322986   8322986   8322986   extract_subvisplane
   1.43%                     7108774                       R_ViewTestAddLine
   1.39%                     6903748                       ALGO_P_CrossBSPNode
   1.22%   1.67%   1.82%     6077604   8317624   9060520   P_CrossSubsector

[dml]

One new profile for Doomu, last level, after going out of the start room, killing few monsters.

Code: Select all

Executed instructions:
  34.19%                    10716363                       render_wall_1x1
  20.23%                     6339527                       R_TransparentColumnShader_Masked
   6.95%                     2179305                       R_VisPlaneSkyShader
   3.65%                     1143571                       R_VisPlaneShader

There's new shader visible now!

I've been slowly refactoring code and renaming/enclosing code with symbols that should help profiling and identifying activity. It's good that the transparencies are now registering in the profiler and not mixed up with other stuff. Each shader block will be separately identifiable with the next few commits.

A new masked shader will replace the existing one for large sprites and should be a lot faster.

[dml]

Have made some changes tonight which should result in a different looking DSP profile.

The DoColumnPerspectiveCorrect functon (a 'kitchen sink' textured column calculator used by everything including sprites) has been broken up into 3 separate functions:

DoColumnPerspectiveCorrect:

a precise, p-correct texturing and lighting for the closest walls with nonlinear gradients

DoColumnLinear:

a fast path for walls which have near enough linear gradients (this path is not yet active - curvature detection code is missing)

DoColumnConstant & DoColumnConstantClone:

a very fast path for sprites - first column uses DoColumnLinear, and all subsequent columns use cloned terms except for texture-u which is calculated every column (this path is now active). More can be done here e.g. transmitting the cloned terms is redundant they could be omitted completely to save more time - but this is a good start without changes to the CPU side.


These changes only affect DSP load - they don't affect drawing speed directly. Probably won't have much impact on FPS unless there are lots of sprites in the scene and not too near the viewplane.

[dml]

Another quick thing from yesterday...

Combining 'invisible' shader with translucency gives a sort of stained-glass effect. Will try to get a better snap of this later using a coloured glass texture. It's cheaper of course to do 'just translucency' but this looked interesting for some things.

trans2.png

[dml]

One other 'extension' I had thought about is supporting portalization through wall surfaces - initially just for scenery purposes.

i.e. you can assign a wall surface to be a 'mirror' and place it at corridor corners, and it allows you to see enemies round the corner. The line-of-sight testing could optionally work through such portals, allowing enemies to see you in some cases.

You could also use it to 'clone' geometry into places the engine won't otherwise allow - e.g. faking up a water surface by mirroring the sky/scenery into it upside down. You could even clone a full sector junction into the upper and lower wall sections, allowing you to 'fake' stacked sectors, for decoration purposes (more than one indentation or window in any vertical wall section).

Actually walking/shooting through portals means significant changes to game code and AI which isn't so helpful for Doom. For a separate game probably more useful.

This feature is tempting because it probably doesn't need much work to support in the renderer at least for walls (floors are a bit more trouble). However it's not very useful unless you edit the levels to incorporate them. That makes it less of a priority than everything else but still worth playing with later on.

[dml]

...another test of stained glass translucency. It's quite slow when filling this much area but still realtime providing it's used sparingly and 1 layer deep.

stgl.png

[EvilFranky]

That is a very cool effect Doug

Sent from my Nexus 4 using Tapatalk 2

[Cyprian]

yep, looks awesome

[dml]

...one more, a bit closer to the PC 'shadow' effect on spectres, but perturbing the background instead of drawing speckles.

spec3.png

[EvilFranky]

I take that this is much easier with a true colour mode?

Sent from my Nexus 4 using Tapatalk 2

[dml]

I take that this is much easier with a true colour mode?

Most of this stuff is easier/quicker with a 'chunky' display format, which the PC had, and Falcon's TC mode has.

Some things are always easier to do quickly in 8bit - TC can still cause some difficulties...

[dml]

[/doublepost]

[CiH]

Doug, re. the transparency and stained glass, is your version of Doom going to have shower cubicles in it then?

[dml]

Doug, re. the transparency and stained glass, is your version of Doom going to have shower cubicles in it then?

Yes, that - and 1970's feature walls - are all go.

fw1.png

fw2.png

I guess I should start doing something useful again instead of this shader stuff eh.