SFML community forums

General => SFML projects => Topic started by: Jonny on April 22, 2016, 09:25:21 pm

Title: SFML DOOM
Post by: Jonny on April 22, 2016, 09:25:21 pm
DOOM, with SFML!

I was surprised to see nobody had done  this yet, so I've hacked apart the DOOM source to use SFML!


http://www.youtube.com/watch?v=3DyMV-IM2oM

Multiplayer works with the original command line params ("-net"), but I've only managed to get it to work on the local network.

If you have any questions or feedback fire away!

Source and release here: https://github.com/JonnyPtn/SFML-DOOM
Title: Re: SFML DOOM
Post by: FRex on April 25, 2016, 11:31:04 am
It's a cute idea but for low level things like these I think SDL has became the default library.
Especially since Doom 1 and 2 are pure software renderers (unless one of ports or hacks changed that, but I never followed them).
To get 8 bit samples to 16 bit you could have just multiplied them by 256 and put in the 16 bit variable, not squared them.
It sadly doesn't work on Linux so I can't see it... :P
Title: Re: SFML DOOM
Post by: eXpl0it3r on April 25, 2016, 11:36:52 am
Nice! :)

It's a cute idea but for low level things like these I think SDL has became the default library.
So what? Everyone can use whatever they want, no need to restrict yourself to what anyone thinks is the "default" library, however you want to define such a thing anyways...
Title: Re: SFML DOOM
Post by: Jonny on April 25, 2016, 11:51:39 am
It's a cute idea but for low level things like these I think SDL has became the default library.

Funnily enough I think SDL DOOM was one of the very first source ports. I'm not particularly doing this with any purpose in mind, and certainly not looking to make any sort of competing DOOM source port. Just having a bit of fun and seeing where it goes. Hardware rendering would definitely be on the cards, but probably quite far down the line

Currently the main issue with Linux builds is that it needs to be a 32bit build, which I understand can be a bit of a pain? It's something I'm hoping to look at and rectify this week though.

And thanks for the tip on the audio, will try that instead!
edit: Just tried your tip on the audio, and it sounds worse (to me)? Line 365 of s_sound.cpp is the one to change if anyone wants to test. I'll try and grab some video footage to show you the difference
edit 2: They actually sound roughly the same, I guess I'd just forgotten how bad it sounded :P
Title: Re: SFML DOOM
Post by: FRex on April 25, 2016, 01:08:50 pm
I have 32 bit Linux.
The problem is that you use C++11 features but CMake doesn't set the right flag for them and if I do so myself then there are still some functions missing and many warnings like:
./d_englsh.hpp:24:72: error: invalid suffix on literal; C++11 requires a space between literal and identifier [-Wreserved-user-defined-literal]
#define QLPROMPT        "do you want to quickload the game named\n\n'%s'?\n\n"PRESSYN

i_sound.cpp:576:3: error: use of undeclared identifier '_write'; did you mean 'write'?
  _write(audio_fd, mixbuffer, SAMPLECOUNT*BUFMUL);
  ^~~~~~
 
and so on (there is over 4000 lines of error log, maybe I missed some flag now :P).

Quote
Hardware rendering would definitely be on the cards, but probably quite far down the line
Even Doom 1 emulated in Doom 3 does it via pure software so it clearly isn't worthwhile or id would do it themselves then.
Maybe port Quake (or event better - Hexen 2!) to SFML if you want to play with GL.

Although the id tech technology is so widely proliferated (and so old and hack-y since most of it was written by a single person on computers not meant for gaming) that it seems SO not worthwhile. :-\
There are like 3 or 4 Radiants and a lot of games, ports, mods and forks of each engine at this point.
But of course if you have fun then it's all great.
And anything you learn is applicable - SFML and these engines are totally viable for indie or non commercial games.
I don't want to sound discouraging, just sharing my opinion, to me the id technology tree is just too daunting and too hardcore.
Title: Re: SFML DOOM
Post by: Jonny on April 25, 2016, 02:00:42 pm
Maybe port Quake (or event better - Hexen 2!) to SFML if you want to play with GL.

I don't want to play with GL in particular

Mario set up CMake and I haven't used it yet so I hadn't noticed the missing flag, that's easily fixed, and yeah you need to turn off every warning to get close to compiling. It's over 20 years old so to be expected!

Like I said, just doing it for fun. I'm fully aware of the difficulties, but couldn't really give a hoot to be honest.

I've been using SFML professionally (and unprofessionally) on a daily basis for almost 3 years, so I'm not really doing it to learn SFML, I'm doing because I'm interested in doom, and I enjoy a challenge.
Title: Re: SFML DOOM
Post by: SeriousITGuy on April 29, 2016, 01:29:33 pm
Thumbs up for DOOM!  ;D
Thought about doing the same thing for Duke Nukem 3D, but after reading through the original source code for some hours I completely scrapped the idea, because D3D original source is a horrible mess. Maybe I should give the Doom Source a go ;)
Title: Re: SFML DOOM
Post by: FRex on April 29, 2016, 02:15:38 pm
There exists a cleaner version of Duke than the original one if you want to give it a go: http://fabiensanglard.net/duke3d/chocolate_duke_nukem_3D.php
Title: Re: SFML DOOM
Post by: Jonny on April 29, 2016, 07:36:38 pm
Haha I'd be surprised if you find the DOOM source much better. It does an awful lot of funky stuff which allowed it to run on PCs in the 90's. But I haven't seen Duke code so couldn't say for sure. That site looks really useful though FRex!

Made a lot of improvements to SFML-DOOM over the past week or two. It's a lot more stable and has  lot more things implemented. The only major things now are the networking (which I haven't attempted yet, but will get round to) and the music, which is giving me a real headache.

I also got it building on Linux 32bit too, so hopefully you shouldn't have any trouble if you want to give it another go FRex (hopefully I updated Cmake and everything correctly, let me know if not).

I've got some videos and stuff to add to the OP which I'll hopefully get round to in the next few days
Title: Re: SFML DOOM
Post by: FRex on April 30, 2016, 01:10:29 am
It builds now without a problem but it sounds like the sound is totally busted especially the menu going down like blood when you start a new game sounds VERY bad and screechy. And is there no music at all in shareware version?
Title: Re: SFML DOOM
Post by: Jonny on April 30, 2016, 01:50:00 pm
Yeah the sound is the main thing I want to get sorted before  tackling networking. Currently the sounds have no position so everything sounds like it's right in your face.

And yeah the music has been annoying me (that's what the weird screech on level load is meant to be...) haven't worked out how to tackle it yet but hopefully I'll work something out. I was hoping it would just be 8 bit samples like the sound effects but it seems a whole lot more complicated than that
Title: Re: SFML DOOM
Post by: Mario on May 05, 2016, 11:17:44 pm
Part of your sound problem is the fact that you're doing the upsampling wrong. :)

Basically, an 8 bit sample ranges from 0 to 255, so you've got 256 steps.
A 16 bit sample ranges from 0 to 65,025, so you've got 65,026 steps.

The upscaling has to be done in a very simple rule of three: s_16(x) = s_8(x) * f

f is the factor between 255 and 65,025, which essentially is 255 as well (and this is probably what confused you).

So, to fix the distorted sounds, change the scaling from "sample * sample" to "sample << 8". However, since this will get you ugly distortions (capping out on full volume), I'd suggest using "sample << 7 " instead.

While this won't get you smooth curves, you'll get perfect upsampling without new distortions the best way you can do without modifying the actual input.

Tried it locally, but didn't bother to write a pull request for this simple change, but this makes sound quality a lot better and you're now also able to differentiate the different death screams of enemies.
Title: Re: SFML DOOM
Post by: Jonny on May 05, 2016, 11:29:36 pm
Yeah sounds awesome Mario, thanks!

I've got the correct sounds working now too except for the player direction so hopefully both things make a vast improvement!
Title: Re: SFML DOOM
Post by: FRex on May 06, 2016, 08:50:41 am
You've made a small mistake (two opening brackets but three closing ones):
/home/frex/code/SFML-DOOM/s_sound.cpp: In function ‘void S_StartSoundAtVolume(void*, int, int)’:
/home/frex/code/SFML-DOOM/s_sound.cpp:359:57: error: expected ‘;’ before ‘)’ token
    newData.push_back(static_cast<sf::Int16>(data[i])<<7));
Title: Re: SFML DOOM
Post by: Jonny on May 06, 2016, 12:11:39 pm
Ah thanks for pointing that out FRex, that'll teach me for being a doofus and committing without checking!
Title: Re: SFML DOOM
Post by: Hapax on May 09, 2016, 01:11:48 am
A 16 bit sample ranges from 0 to 65,025, so you've got 65,026 steps.
Isn't this 65,536 steps? i.e. [-32768, 32767]
Title: Re: SFML DOOM
Post by: Mario on May 09, 2016, 05:59:14 pm
Yeah, my bad. I should use 256 rather than 255 in the math. ;)

256 * 256 = 65,536
Title: Re: SFML DOOM
Post by: Hapax on May 10, 2016, 01:41:35 am
It was an accident. I knew as much! ;)

It does mean that shifting left 8 times shouldn't cause any clipping though. You're effectively just shifting the 8 bits to the 8 most significant bits of the 16, which is the idea.
Title: Re: SFML DOOM
Post by: Mario on May 10, 2016, 04:33:19 pm
Correct, but at least in my case the sound got really loud and it felt like overdriving (despite that not being the case). This might have to do with additional audio processing done by the sound card (stereo upmix), but not sure to be honest.
Title: Re: SFML DOOM
Post by: Jonny on July 03, 2016, 04:17:08 pm
A couple of updates:

Title: Re: SFML DOOM
Post by: CleverBoy on August 20, 2016, 01:49:33 pm
Hi,

I am trying to compile the code in ubuntu linux using the latest version of SFML 2.4.0 and almost the spent the entire day with no luck. Built SFML version 2.2 as well but get errors regarding undefined references. I might have missed, but can anyone please let me know which version of SFML is to be used and if compiling steps are listed that would be great..

Many Thanks.... 
Title: Re: SFML DOOM
Post by: Mario on August 20, 2016, 10:47:53 pm
Think Jonny started this with 2.3.x, but it should build with 2.4 just fine. Do you have some specific error messages?
Title: Re: SFML DOOM
Post by: CleverBoy on August 21, 2016, 12:09:15 pm
This the error..

[100%] Linking CXX executable doom
/usr/local/lib/libsfml-graphics.so: error adding symbols: File in wrong format
collect2: error: ld returned 1 exit status
CMakeFiles/doom.dir/build.make:1659: recipe for target 'doom' failed
make[2]: *** [doom] Error 1
CMakeFiles/Makefile2:67: recipe for target 'CMakeFiles/doom.dir/all' failed
make[1]: *** [CMakeFiles/doom.dir/all] Error 2
Makefile:83: recipe for target 'all' failed
make: *** [all] Error 2

This is with the latest stable version of SFML 2.4
Title: AW: SFML DOOM
Post by: eXpl0it3r on August 22, 2016, 10:35:56 am
Try to do a full rebuild of your app and/or reinstall/rebuild SFML.
Sounds like the SFML .so is corrupted for some reason.
Title: Re: SFML DOOM
Post by: CleverBoy on August 22, 2016, 02:02:45 pm
Tried after re-installing SFML and created both static and release versions of the libraries. Also rebuilt the game. Same error. I used the BUILD_SHARED_LIBS flag to yes to build both 32 and 62 bit version. Am i doing anything wrong ?
Title: AW: SFML DOOM
Post by: eXpl0it3r on August 22, 2016, 09:50:28 pm
After quickly Googling the error it seems that it might be a architecture mismatch. Like you've built Thor in 32bit but then you might try to link 64bit libraries.

Make sure that either everything is 32bit or everything is 64bit, don't mix them!
Title: Re: SFML DOOM
Post by: Jonny on August 24, 2016, 11:55:54 am
Updated it to use 2.4 yesterday for the new cursor grab stuff, so that's the minimum required version now.

Currently it only works as 32bit because of the pointer arithmetic, which I understand is a bit of a pain on Linux, but can certainly be done. I'm not sure if BUILD_SHARED_LIBS will have any impact on whether you're building 64 or 32 bit. IIRC I had to manually modify the makefile for SFML to add the -m32 flag to get it to build 32bit.

Title: Re: SFML DOOM
Post by: CleverBoy on August 26, 2016, 04:20:27 pm
Hi Jonny,

Thank you for your reply. 

Are you on windows  64 bit and SFML 32 bit libraries ?

>>Currently it only works as 32bit because of the pointer arithmetic.
Can you please let me know do i need to install Linux 32 bit version? I am not able to get the 32 bit SFML compiled due to linking errors libX11 on 64 bit linux.

>> IIRC I had to manually modify the makefile for SFML to add the -m32 flag to get it to build 32bit.
I see there is a -m32 flag in CMakeLists.txt but is still fails on Linux 64 bit version.
[ 16%] Linking CXX executable doom
/usr/local/lib/libsfml-graphics.so: error adding symbols: File in wrong format
collect2: error: ld returned 1 exit status
CMakeFiles/doom.dir/build.make:1659: recipe for target 'doom' failed
make[2]: *** [doom] Error

Title: Re: SFML DOOM
Post by: Jonny on August 30, 2016, 12:48:06 pm
Yes I'm on windows, building everything 32 bit

The -m32 flag is already there for SFML-DOOM, but without 32 bit SFML binaries it won't work, so you'll have to use the same flag when compiling SFML. I think to install the 32 bit versions of SFML dependencies just add ":i386" on to the end of the package name (that worked for me using apt-get at least).

Once you've got SFML compiled as 32 bit then the cmakelists provided for SFML-DOOM should theoretically just work (although sods law I've put the wrong slash in one of the includes since I last built on Linux!)

Hope this helps
Title: Re: SFML DOOM v0.1
Post by: Jonny on September 23, 2016, 09:21:24 am
Thanks to Aster and some of the other #sfml IRC posse, linux 64 bit builds should now be working. I've also added builds for Linux and Windows to the github page, OS X will follow shortly.

Feel free to add any issues/feedback you have either in here or on the github page - I'm kind of procrastinating to avoid doing the music/network code so anything else to focus on would be great :P
Title: Re: SFML DOOM v0.1
Post by: CleverBoy on September 24, 2016, 08:39:53 am
Thank you so much Johnny and Aster for making the linux 64 bit builds. Wooooohoooo... finally built the game successfully. God bless you all and long live SFML.   
Title: Re: SFML DOOM
Post by: Jonny on February 03, 2017, 03:21:18 am
Since the last update I've added network play, which works for me on the local network, and works cross-platform (I tested macOS playing with win10)

I've also finally got some music playing out of it! Some interesting results along the way...

http://www.youtube.com/watch?v=Dcf5oMY7iTs
Title: Re: SFML DOOM
Post by: Jonny on March 20, 2017, 06:23:12 pm
I've put builds up on github for each of the platforms, so anybody can try them. I'm aware there's still a few bugs, and the OSX build doesn't work right now due to the resource path stuff (working on it...).

I've included the shareware wad, but the music is disabled for that due to the license. If you have any official DOOM or DOOM2 wad then they should work and will be fully featured. Theoretically other doom engine games (hexen?) should work too, although I haven't tested. Also any unofficial wads compatible with vanilla doom should work.

Controller  or kb+m for input. ctrl+f for fullscreen. Shout if you have any issues/feedback
Title: Re: SFML DOOM
Post by: CleverBoy on March 20, 2017, 11:22:58 pm
Thanks Jonny for taking the time to do this. This is definitely something I am sure will help anyone who has the curiosity and interest to learn from this epic game... great work..