D32XR - Sega 32X port of Doom

[Vic]

https://github.com/viciious/d32xr

 

I'm creating this thread to kinda keep the engine-related discussions off the main thread in the "Console ports" section, to make it easier for me and others to indulge in deep technical discussions regarding the port. The main thread will be reserved for gameplay related stuff and user support.

 

D32XR is a Sega 32X port of Doom based of the original JaguarDoom source code with some Calico added to the mix. The engine is optimized to run on real hardware, which is pretty close to what you might call an "embedded system": 2 RISC CPUs, 16-bit bus, 256 KB of RAM, 256 KB of VRAM, 4 MB of ROM storage and no dedicated graphical hardware. Pretty much none of your typical optimizations for early DOS era PCs apply. This poses some extreme limitations on what is possible to do feature-wise, but it's kinda fun pushing the engine and hardware to their limits.

 

Since the inception of the project I've been mostly busy optimizing the renderer to take advantage of the dual SH-2 setup, but as of lately, I've also been exploring the possibility of multi-threading the game logic as well. I'm also interested in collaborating with experts in the Doom engine, which I'm sure there plenty of here.

[Vic]

One thing that caught my attention is that there's a slight overdraw due to missing clipping of walls and segments, which I don't how to fix in a Jaguar based port such as D32XR.

[Redneckerz]

This is as wild as @Optimus's OptiDoom for 3DO. The 32X architecture is unique, so its great seeing some interesting out of it ;)

[Vic]

One thing that I've been wrestling with lately is P_CheckSights. It's really slow on certain maps and can easily take up to 50% of the frame time.

 

So far this one has proved to be a tough nut to crack. Tried all kinds of different approaches: the supposedly faster v1.2 P_CheckSight, splitting the load between the cores, none of them worked, at least not on real hardware.

[Wavy]

2 hours ago, Vic said:

One thing that I've been wrestling with lately is P_CheckSights. It's really slow on certain maps and can easily take up to 50% of the frame time.

 

So far this one has proved to be a tough nut to crack. Tried all kinds of different approaches: the supposedly faster v1.2 P_CheckSight, splitting the load between the cores, none of them worked, at least not on real hardware.

I think you can blame this on me.

 

I completely forgot that the node builder I used for map fixes (ZDBSP) generates a reject with all 0's, meaning no Line-of-Sight optimisations are being applied. That's why I suggested using ZokumBSP, which is designed with vanillia maps in mind as well as generating actual rejects.

Edited November 30, 2021 by Wavy

[Vic]

1 hour ago, Wavy said:

I think you can blame this on me.

 

I completely forgot that the node builder I used for map fixes (ZDBSP) generates a reject with all 0's, meaning no Line-of-Sight optimisations are being applied. That's why I suggested using ZokumBSP, which is designed with vanillia maps in mind as well as generating actual rejects.

Well, the lack of proper reject tables is sure a pity, but both the BSP and the blockmap-based algorithms were equal in that regard. They were both tested in the worst case scenario, and neither was the clear winner.

[Muusi]

I don't even have the necessary hardware but holy shit this is so awesome! Definitely following this project. 

[Vic]

What else can I say?