Doomed - a 3D portal engine for the Atari 2600

[rossum]

Since getting the Runes of Moria raycasting engine in reasonable shape I have been fixated on the idea of a more capable 3D engine for the 2600. The resulted is the "Doomed" 3D portal engine test. It can render modest amounts of non-euclidian geometry at reasonable (12-30FPS) frame rates. The math is necessarily janky and far from complete, the walls are wiggly and it is easy to get stuck in them, and none of the code is really optimal, but I think it shows promise given the modest capabilities of the platform. Like R.O.M, it is 4K vanilla.

 

Portal Renderers are fantastic and ideal of you have no memory, compute etc. You still have to deal with a 3D pipeline (doomed uses polar coordinates for speeding up transformations as logs for math) but you don't need any of the complexity of the binary space partitioning stuff that DOOM used.  

 

Will it run DOOM? Nope. But it can allow you to build maps that look a little like the Hangar E1M1 from the original.

 

If anyone wants to make a game out of it I would be happy to share the source.

 

doomed_ntsc.rom

doomed_pal.rom

[Thomas Jentzsch]

Impressive, but I am not sure what the difference to R.O.M. is? Was R.O.M. done using BSP? Where does the new demo show its benefits?

 

Also, how do I read the map graphics? What's the meaning of the little arrows?

Edited July 31, 2021 by Thomas Jentzsch

[rossum]

16 minutes ago, Thomas Jentzsch said:

Impressive, but I am not sure what the difference to R.O.M. is? Was R.O.M. done using BSP? Where does the new demo show its benfits?

 

Also, how do I read the map graphics? What's the meaning of the little arrows?

R.O.M is a raycasting engine - like Wolfenstein - everything needs to be made out of blocks. Frame rate is proportional to the horizontal resolution and how far away the walls are.

 

The Doomed demo is a real 3D engine. You can make huge worlds with non-orthogonal walls that can be dynamically moved. Frame rate is dependent on how much geometry is in the field of view. The little arrows indicate the 'direction' of the wall as well as its color. Walls are drawn in this anti-clockwise order. Sectors are draw recursively, with 'portals' into adjacent sectors used to clip subsequent drawing.

 

It isn't clear the Doomed is a better engine for games on the 2600 than R.O.M. Doomed could be great on the A800 - it runs at a solid 30fps at fullscreen at full resolution.

 

[Thomas Jentzsch]

Thanks, that answer my questions.

 

Regarding the framerate, each code can be optimized. Maybe a 2nd or 3rd pair of eyes could help here. 

[rossum]

4 minutes ago, Thomas Jentzsch said:

Thanks, that answer my questions.

 

Regarding the framerate, each code can be optimized. Maybe a 2nd or 3rd pair of eyes could help here. 

I would welcome any input - I am a little embarrassed as to how clunky it looks...

The display kernel is identical to R.O.M.

doomed_01.a

[Thomas Jentzsch]

No worries, most of my code looks much worse.  

 

Which parts should I look for? E.g. m16x8 looks like it can be optimized.

[rossum]

22 minutes ago, Thomas Jentzsch said:

No worries, most of my code looks much worse.  

 

Which parts should I look for? E.g. m16x8 looks like it can be optimized.

nearly all of the time is spent in the point loader / polar transformation routine next_point and in the log math: delta_ln,ln,ln_pos,ex

m16x8 gets called at most a few times per frame

 

[Thomas Jentzsch]

At first glance the code looks pretty much optimized. Maybe increasing some tables would save a few cycles here and there, but you know that already. Besides that I only found very few cycles.

[Thomas Jentzsch]

Attached is  the very slightly optimized code.

 

These are only peephole optimizations, I am not sure if the general math can be optimized. 16 bit math is really costly, maybe there are places where 8 bit would be sufficient?

doomed_01.asm

[rossum]

7 hours ago, Thomas Jentzsch said:

Attached is  the very slightly optimized code.

 

These are only peephole optimizations, I am not sure if the general math can be optimized. 16 bit math is really costly, maybe there are places where 8 bit would be sufficient?

doomed_01.asm 57.21 kB · 3 downloads

Thanks! Every little bit helps.

 

It would be great to find some formulation where I could keep everything in 8 bit logs or minifloats but much of the math needs a linear representation.

 

[Omegamatrix]

I took a brief look and in couple of places I think sbx could be used:

 

Old:
        txa     ; 128 bytes vs 16 cycles / chunk of code
        clc
        adc #$40
        tax


New:
        txa
        sbx #-$40    ; X holds correct value

 

 

Old:
        clc
.pos_s  sta s           ;

        ; 8 bit unsigned cos
        txa
        adc #$40
        tax


New:
			; no CLC needed
.pos_s  sta s           ;

        ; 8 bit unsigned cos
        txa
        sbx #-$40	; X holds correct value

 

[rossum]

40 minutes ago, Omegamatrix said:

I took a brief look and in couple of places I think sbx could be used:

 

Old:
        txa     ; 128 bytes vs 16 cycles / chunk of code
        clc
        adc #$40
        tax


New:
        txa
        sbx #-$40    ; X holds correct value

 

 

Old:
        clc
.pos_s  sta s           ;

        ; 8 bit unsigned cos
        txa
        adc #$40
        tax


New:
			; no CLC needed
.pos_s  sta s           ;

        ; 8 bit unsigned cos
        txa
        sbx #-$40	; X holds correct value

 

nice. thx much