Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
imustafin

Brie Doom (SDL2 Eiffel DOOM)

Recommended Posts

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

2021-04-22_1619085062.png

Some walls rendered on E1M1.

Spoiler

2021-04-22_1619085081.png

Edited by imustafin

Share this post


Link to post

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 :)

Share this post


Link to post

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.

 

Share this post


Link to post
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.

Share this post


Link to post
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.

Screenshot 2021-11-11 at 23-10-52 Performance.png

Share this post


Link to post
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.

Share this post


Link to post
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!

Share this post


Link to post

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

 

Which compiler is it for?

Share this post


Link to post
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.

Share this post


Link to post

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.

Share this post


Link to post
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).

Share this post


Link to post
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?

Share this post


Link to post
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.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×