Brie Doom (SDL2 Eiffel DOOM)

[imustafin]

Hello, doomworld!

 

Just registered here to share my project with you. It is called Brie Doom (brie like cheese) https://github.com/imustafin/brie_doom.

 

I'm working on a source port of Doom in Eiffel language. It is based on https://github.com/id-Software/DOOM with audio/video from Chocolate Doom.

 

Right now the code supports sfx and music (mus2mid) via SDL2 and some in-game rendering.

 

Currently the code is more like a word-by-word translation of C to Eiffel. Automatic translation seems to be too hard for the moment, mostly because Eiffel to C is like Java to C and similar problems as in Mocha Doom's development arise.

 

I was really hesitant about sharing this anywhere until I had something remotely working, but now should be the time! Just several minutes ago I saw some walls got finally rendered (see screenshots). I believe that if I got at least this to work, then all the other things should be possible too :)

 

Science

Additionally, I hope to do some scientific research on comparing Eiffel and C for purposes of developing such applications. My plan for this is:

1. Translate the essential single-player features from C to Eiffel mostly word-by-word
2. Refactor the code a bit (use Eiffel contracts to avoid bugs)
3. Try to highlight and fix some known Doom bugs using contracts
4. Compare the results based on some metrics

Your input on this plan would be highly appreciated.

 

P.S. I really believed the Doom's code to be much smaller :)

 

Screenshots

Main menu

Spoiler

Some walls rendered on E1M1.

Spoiler

Edited July 14, 2021 by imustafin

[fran]

oh là-là 🧀

[Redneckerz]

Hi, @imustafin! I was wondering when you would show up with your port :) I have been keeping tabs on your work and the unusual environment you are putting it through. Very nice! Any port that does more than the barebones is a winner to me :)

[imustafin]

In the past months I did some progress on the port.

 

The rendering engine is almost fully ported and some parts of Enemy AI and shooting are also implemented.

 

Additionally, I wrote my university thesis on the topic of porting C programs to an OOP language on the example of Doom, please take a look, the screenshots are on p. 30 :). This text is in Russian but I will publish the English version in the next weeks.

 

The defense is next week. I'm not sure what to do next with this project. Given something is really working, I can try to port some optimizations and limit removing patches from other projects.

 

[Redneckerz]

On 7/14/2021 at 1:49 PM, imustafin said:

In the past months I did some progress on the port.

 

The rendering engine is almost fully ported and some parts of Enemy AI and shooting are also implemented.

 

Additionally, I wrote my university thesis on the topic of porting C programs to an OOP language on the example of Doom, please take a look, the screenshots are on p. 30 :). This text is in Russian but I will publish the English version in the next weeks.

 

The defense is next week. I'm not sure what to do next with this project. Given something is really working, I can try to port some optimizations and limit removing patches from other projects.

 

I wish you good luck with this! Based on the work you have done for the thesis, i expect you pass with flying colours.

 

As for your limit removing patches: DeHacked support is always nice!

 

Good luck.

[imustafin]

On 7/15/2021 at 5:59 PM, Redneckerz said:

I wish you good luck with this! Based on the work you have done for the thesis, i expect you pass with flying colours.

Thanks! Indeed, it went very well. One of the examiners almost cried when he I played the demo with sounds and music. Pro tip: insert At Doom's Gate into your presentations :)

 

I think I'm halfway from the somewhat full port. With mouse support and in full screen it really feels like a game.

 

FPS is actually lower than I expected. The optimized build gives ≈ 54 FPS on E1M1 (chocolate doom gives 250 FPS, for comparison). Still, it is somewhat ok as long as it is > 35, right?

This nice plot is from https://briedoom.imustafin.tatar/performance, and there is a website for Brie Doom at https://briedoom.imustafin.tatar/

I believe it will be possible to improve the performance later.

 

Also, was there a sourceport with high concurrency? Not only for drawing (like the wonderful Rum and Raisin Doom) but also for everything else? Like all thinkers (monsters, etc.) working at the same time. If we let everyone to act not at each tick but between ticks, maybe something interesting can happen. On the other hand, maybe the difference will be negligible if everything manages to be computed in one realtic. However, if we have really much stuff going on (nuts.wad, etc.), this approach might shine.

 

I guess this would require a lot of work to synchronize to properly orchestrate this concurrency in C based ports. Maybe ports in other languages did this? I wonder if Eiffel's SCOOP can be used in the future for Brie Doom, for example.

[ketmar]

29 minutes ago, imustafin said:

Also, was there a sourceport with high concurrency?

not possible in the general case. the engine never serializes access to internal mobj fields, and with DECORATE it's even worser. you will need to protect EACH access to EACH mobj field, because even if current code is not accesing other mobjs, it doesn't mean that other code won't access "your" mobj. you can redesign and rewrite vanilla code to play nice, but then you will lost even DeHackEd support, and more advanced modding is completely out of question. also don't forget that even things like light flickering and texture scrolling internally done via invisible map things, so you have to serialise access to sector properties too.

 

in the end of the day, you will either have a vanilla-like engine that cannot support anything beyound very simple pwads, or even slower engine due to locking/serializing. that's why in 20+ years there are still no multithreaded playsim implementations. the engine had to be designed from the ground up with multithreading in mind to make it worth the efforts.

 

GZDoom is using multiple threads in renderer, to speed up some things, but this is as much as possible to do without dropping all attempts to be a Doom sourceport. alas.

[Gez]

47 minutes ago, imustafin said:

Also, was there a sourceport with high concurrency? Not only for drawing (like the wonderful Rum and Raisin Doom) but also for everything else? Like all thinkers (monsters, etc.) working at the same time. If we let everyone to act not at each tick but between ticks, maybe something interesting can happen. On the other hand, maybe the difference will be negligible if everything manages to be computed in one realtic. However, if we have really much stuff going on (nuts.wad, etc.), this approach might shine.

You'd definitely change how the engine works on a fundamental level. It's hard to predict how exactly it would behave as a result. One thing is certain, you'd lose demo compatibility and would need to rethink how the multiplayer code works, because you could say bye-bye to Doom's intrinsic predictability.

 

Just a simple example: two zombies are infighting. At the exact same tic, they both attack the other. What happens? In vanilla, since obviously there's just one thread for all thinkers, one of the two zombies will act first, and since their attacks are hitscan it will deal damage instantly, and kill the other zombie. Then the other zombie will not get to act, so the first zombie survives. If you have both zombies acting in separate concurrent threads, then zombie A will kill zombie B in thread #1, while zombie B will kill zombie A in thread #2. How do you reconcile the two threads afterwards? Do you kill both zombies? Or let them both survive? How do you merge back the timeline? I thought dragon breaks only occurred in the Elder Scrolls!

[Gibbon]

Nice!  One of my original GNU projects was written in Eiffel (before I rewrote it in C).

 

Which compiler is it for?

Edited November 12, 2021 by Gibbon

[imustafin]

20 hours ago, ketmar said:

in the end of the day, you will either have a vanilla-like engine that cannot support anything beyound very simple pwads, or even slower engine due to locking/serializing. that's why in 20+ years there are still no multithreaded playsim implementations. the engine had to be designed from the ground up with multithreading in mind to make it worth the efforts.

 

GZDoom is using multiple threads in renderer, to speed up some things, but this is as much as possible to do without dropping all attempts to be a Doom sourceport. alas.

 

20 hours ago, Gez said:

You'd definitely change how the engine works on a fundamental level. It's hard to predict how exactly it would behave as a result. One thing is certain, you'd lose demo compatibility and would need to rethink how the multiplayer code works, because you could say bye-bye to Doom's intrinsic predictability.

 

Yes, we loose Doom predictability, demos and possibly multiplier (we could do this concurrent computing on the server for example). Yes it will be much work to do with the mainstream-language-like concurrency. But still.......

 

Ultra naïve reasoning follows: take functional programming, for example. If the game state is immutable, but composed periodically from actions of different actors, it might be somewhat easier to parallelize. I guess this counts as:

20 hours ago, ketmar said:

the engine had to be designed from the ground up with multithreading in mind to make it worth the efforts.

so we are on the same page, I think.

 

The same reasoning applies to SCOOP (I hope). For it to work, the whole system should be made more OOP-like. And then with some tweaking it might become concurrent.

 

Also, thanks for the words multithreaded playsim. I managed to find some discussion on ZDoom forum but it didn't last long.

 

7 hours ago, Gibbon said:

Nice!  One of my original GNU projects was written in Eiffel (before I rewrote it in C).

 

Which compiler is it for?

It is for the EiffelStudio 19.5 GPL edition. I am ultra glad to meet an eiffelist here :)

Why rewrite in C? I guess this could have been a time/memory efficiency decision.

Edited November 12, 2021 by imustafin
Added link to ZDoom discussion

[Gibbon]

The original code was not portable to anything else other than an old smart Eiffel compiler version and gobo version (from 2004).  I did try to rewrite it in Eiffel studio but basically it would have been a rewrite anyway.

 

It is a stunning language though.

[ketmar]

57 minutes ago, imustafin said:

so we are on the same page, I think.

yeah. and then there is little reason to stick to idTech1 architecture at all, because it is flawed in soooo many ways… you can do much better by designing it from ground up to be scalable, and better organized. make game world immutable and convert all moving things to separate objects, forbid direct access to other actor's properties, and so on, and so on… you can then port vanilla maps and actor AI code to this new framework, and it will… well… resebmle Doom.

 

but this still will be a somewhat wasted time, because you will need to (semi)manually convert each new pwad. and people won't be very attracted to this new engine if they will not have an easy access to all existing Doom content to play. ;-) i.e. it will be a brand new engine with it's own content pipeline anyway, and then you can simply create a full 3D engine instead, dropping Doom "2.5D" limitations. i.e. i believe that it will be better to create something like Quake instead (and use TrenchBroom to create maps).

[CBM]

1 hour ago, Gibbon said:

The original code was not portable to anything else other than an old smart Eiffel compiler version and gobo version (from 2004).  I did try to rewrite it in Eiffel studio but basically it would have been a rewrite anyway.

 

It is a stunning language though.

I have only briefly dealt with Eiffel at the university. But it is certainly different from anything else I've seen.

What is your impression of Eiffel as a language?

[Gibbon]

39 minutes ago, CBM said:

I have only briefly dealt with Eiffel at the university. But it is certainly different from anything else I've seen.

What is your impression of Eiffel as a language?

Overall I like it, but it has two downsides.

 

1. scoping can get messy

2. Classes and subclusters reminds me of Pascal.  It always felt like an afterthought rather than a core language feature.

Edited November 12, 2021 by Gibbon