Port DOOM as experimental

[hajimehoshi]

https://github.com/chocolate-doom/chocolate-doom

Note that the license would be GPL.

[peterhellberg]

Here are some links to some information about DOOM and its renderer;

• https://doomwiki.org/wiki/Doom_rendering_engine
• http://fabiensanglard.net/doomIphone/doomClassicRenderer.php

[peterhellberg]

And a few ports of the game/renderer to other languages than C/C++:

• https://github.com/Pink-Silver/PyDoom
• https://github.com/cristicbz/rust-doom
• https://doomwiki.org/wiki/DelphiDoom
• https://github.com/AXDOOMER/mochadoom

[hajimehoshi]

https://doom.fandom.com/wiki/Source_port Port list

[hajimehoshi]

As DOOM requires 3D polygons, DOOM might not be a good example to port to Ebiten :thinking:

[chslink]

openRA? https://github.com/OpenRA/OpenRA

[shawnsmithdev]

As DOOM requires 3D polygons, DOOM might not be a good example to port to Ebiten thinking

Is that true? I am fairly sure classic DOOM actually predates 3D acceleration in video cards. I believe it was all done in software.

[hajimehoshi]

Well, 3D rendering without hardware can be possible, but this works only with ReplacePixels in Ebiten. I'm not sure this would be a good example of Ebiten.

[darkerbit]

Perhaps a Wolfenstein 3D-style raycaster would be better?

[hajimehoshi]

In Ebiten, the raycaster result would be rendered via ReplacePixels.

[peterhellberg]

@darkerbit Maybe something along the lines of this little experiment I did a while back:

Ebiten port compiled to WebAssembly: https://peter.tilde.team/ebiten-gfx-raycaster/

Source code is available as a gist and is a port of a raycaster experiment I did for the Pixel package.

[hajimehoshi]

https://github.com/hajimehoshi/ebiten/issues/411 Homography transformation might help to implement DOOM. (Originally, the original DOOM used similar technique to draw sprites, but is that correct?)