rossum Posted July 31, 2021 Share Posted July 31, 2021 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 11 Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted July 31, 2021 Share Posted July 31, 2021 (edited) 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 Quote Link to comment Share on other sites More sharing options...
rossum Posted July 31, 2021 Author Share Posted July 31, 2021 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. 4 Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted July 31, 2021 Share Posted July 31, 2021 Thanks, that answer my questions. Regarding the framerate, each code can be optimized. Maybe a 2nd or 3rd pair of eyes could help here. Quote Link to comment Share on other sites More sharing options...
rossum Posted July 31, 2021 Author Share Posted July 31, 2021 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 1 Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted July 31, 2021 Share Posted July 31, 2021 No worries, most of my code looks much worse. Which parts should I look for? E.g. m16x8 looks like it can be optimized. Quote Link to comment Share on other sites More sharing options...
rossum Posted July 31, 2021 Author Share Posted July 31, 2021 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 1 Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted July 31, 2021 Share Posted July 31, 2021 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. Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted August 1, 2021 Share Posted August 1, 2021 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 Quote Link to comment Share on other sites More sharing options...
rossum Posted August 1, 2021 Author Share Posted August 1, 2021 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. Quote Link to comment Share on other sites More sharing options...
Omegamatrix Posted August 1, 2021 Share Posted August 1, 2021 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 2 Quote Link to comment Share on other sites More sharing options...
rossum Posted August 1, 2021 Author Share Posted August 1, 2021 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 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.