DOOM on Raspberry in 2016 ...which way?

Hi,
so I have a Raspberry Pi 3 and I'd like to play classic DOOM, HERETIC and HEXEN in Raspbian (cli, frame buffer).
I'm not interested in modern graphic features, I like blocky pixels but at least I'd like true high resolution and 60fps.

I'm reading a lot of topics here but still it's not clear to me this: is actually possible to compile and run on RPi3 a source port that can benefit from GPU hardware acceleration without manually compile SDL 2.0.5 or Retropie?

Maybe there is a limit-rem engine based on SDL 1.x that runs smoothly in HD thanks to OpenGLES acceleration?

PrBOOM, Odamex, ZDOOM... I'm searching for a "clean" compile-and-play (smoothly in HD) solution, but I'm a bit lost.

Thank you very much.

Share this post


Link to post

Didn't see this thread before I replied to the crispy one, but, chocolate doom sdl2-branch builds and runs well for me on rpi3/retropie, and I haven't built sdl2 from source. I run it from a console/framebuffer though, not in X. It runs better for me than choco v1 (sdl1) did. Unfortunately choco doesn't tick some of your other boxes (60fps, hi res). Crispy will eventually rebase on top of sdl2 choco. I think CSonicGo is a good person to talk to about what works well and what doesn't. I think they might have got zdoom working.

Share this post


Link to post

I was porting QZDoom to RPi but haven't had much interest in it because it compiles extremely slowly.

Unfortunately it's just one of those things that not a lot of people seem to be interested in. However, I noticed that PrBoom+ seems to run smoother than butter on that thing, so that's worth a try.

Share this post


Link to post
Rachael said:

I was porting QZDoom to RPi but haven't had much interest in it because it compiles extremely slowly.


I think the main problem with ZDoom's compilation is the cross-dependency mess that literally forces every single header from the class hierarchy into every file because you need PClass and that drags in an insane heap of dependencies. And with the scripting stuff it got even worse because it now drags in even more dependencies

This one needs a serious cleanup from the ground up - most importantly making sure that only those classes which are actually needed get included.
The compile times here are far beyond acceptable, even for me on a fast Windows machine. I think it says enough if both Travis and AppVeyor report compile times beyond 5 minutes for each job, that's ridiculous.

I wish the C++ consortium could approve the Modules feature which would help getting rid of this mess far more easily than trying to clean out the headers file by file.

Share this post


Link to post

On RPi2 and RPi3 it's possible to add in MAKE -j3 or -j4 options to speed up the process.

IIRC I compiled chocolate-doom (v2.x) in few minutes on my RPi3 with -j4.

I also compiled easily DOOM Retro, but it ran only under X11 so it was too slow, in framebuffer mode gave a "video device" error.

Maybe with some "love" from a skilled volunteer it's possible to optimize one of the engines... (in terms of source or simply of iter).

PRO-RETRO-TIP: with a recent firmware it's possible to set custom video modes "on the fly". Matching it with a VGA666 board it can recreate the "magical" VGA "Mode 13h" for a true retro feeling.

Share this post


Link to post

That -j4 option is really useful - thank you!

Share this post


Link to post
Rachael said:

That -j4 option is really useful - thank you!


You are welcome!

I'm very interested in a DOOM (and HEXEN) source port that could "officially" support RPi, so please if you will continue your work please keep me informed! ;)

Share this post


Link to post

It's worth using ccache too, if you are compiling multiple times or trying different patches or branches.

$ sudo apt-get install --no-install-recommends -y ccache
$ echo 'PATH=/usr/lib/ccache:$PATH' >> ~/.bashrc
$ source ~/.bashrc

Share this post


Link to post
antiriad said:

You are welcome!

I'm very interested in a DOOM (and HEXEN) source port that could "officially" support RPi, so please if you will continue your work please keep me informed! ;)

Right now, GZDoom in its current state will work (as far as I know) on the Raspberry Pi - however, OpenGL needs to be disabled for it to work.

QZDoom used to have that as well, but that was when it was depending on LLVM. Unfortunately, the code that was rewritten without LLVM support used SSE2 intrinsics instead - which makes porting back to ARM very difficult. It may be possible to simply disable all the SSE2 code but then you're left with pretty much just the old palette renderer anyway.

Share this post


Link to post
Rachael said:

Right now, GZDoom in its current state will work (as far as I know) on the Raspberry Pi - however, OpenGL needs to be disabled for it to work.


Thank you. It's based on SDL2.x or 1.x?
How can I disable OpenGL? (sorry but I'm not very skilled...)

Share this post


Link to post

On default Raspbian, the OpenGL libraries are not installed by default so you do not have to worry - CMake is set up to ignore the dependencies and it will not be there.

If you use other Linux distros, you simply start GZDoom as such:

./gzdoom +vid_renderer 0

I do not know what SDL version the software renderer uses, I assume it is SDL2.

(EDIT: Also I just had a successful GZDoom compile using Clang, so I know it still works - but no idea how GCC fares - I won't even touch Raspbian's GCC though since it has issues, I would suggest switching to Clang instead)

Share this post


Link to post
Graf Zahl said:

I wish the C++ consortium could approve the Modules feature which would help getting rid of this mess far more easily than trying to clean out the headers file by file.


I hope those "modules" are nothing like the modules as they are used in Fortran: those do work as a surrogate/substitute for header files, but create compile-time dependencies and make parallel build of anything but the most trivial projects, impossible. Also, they can create just as much of a dependency hell/mess as C/C++'s headers, with the added trouble of having to compile everything in a very specific order. They are often the source of compiler bugs, plaguing even recent versions of Intel's Visual Fortran.

But alas (quoting from here):

Modules improve access to the API of software libraries by replacing the textual preprocessor inclusion model with a more robust, more efficient semantic model. From the user’s perspective, the code looks only slightly different, because one uses an import declaration rather than a #include preprocessor directive:

import std.io; // pseudo-code; see below for syntax discussion
However, this module import behaves quite differently from the corresponding #include <stdio.h>: when the compiler sees the module import above, it loads a binary representation of the std.io module and makes its API available to the application directly.


These "binary representations" sound a lot like the dreaded *.mod files used in all Fortran compilers, and which have all the aforementioned problems. Imagine having to somehow precompile every header file and library that you need to use (in Fortran compilers, the module file can only be generated after a successful compilation, and circular compilation dependencies inside a project are very easy to cause). BONUS POINTS: they are not portable between compilers, and often not even between the same compiler with different machine architectures, not unlike proper compiled object files.

Hopefully, whatever implementation is finally adopted by the C++ standard will address the above points. Otherwise, their only saving grace here is that unless they make it mandatory/the only way, C++ will still be able to resort to plain old headers (esp. if all you wanted to share were a couple of enumerator or struct definitions). In Fortran, you don't have that choice.

Share this post


Link to post

I think you should inform yourself in better places than make conclusions from a crusty old language from times far worse.

What makes you even THINK they are repeating the mistakes from a language that's 40+ years old with design decisions from another era.

I already see that the Fortran modules contain the entire implementation, and not just the interface. The C++ model is supposed to only export the interface - just like a header (that is, with some of the preprocessor madness being removed because that would cause problems with how they are supposed to work.)

The way I understand it, what this is supposed to achieve is to avoid recompilation of the headers hundreds or thousands of times.

For a project like GZDoom, this redundant recompilation takes up 80-90% of the entire compilation time - and it doesn't even use some modern template libraries!

Share this post


Link to post
Rachael said:

Also I just had a successful GZDoom compile using Clang, so I know it still works - but no idea how GCC fares - I won't even touch Raspbian's GCC though since it has issues, I would suggest switching to Clang instead)


I'm not an expert and I don't know Clang... maybe you could point me to a tutorial?
Thanks

Share this post


Link to post
Graf Zahl said:

I think you should inform yourself in better places than make conclusions from a crusty old language from times far worse.


C and C++ aren't exactly dashing young men either, and they too, just like Fortran, evolved from far cruder forms. It would be better not to generalize and spread FUD.

Graf Zahl said:

What makes you even THINK they are repeating the mistakes from a language that's 40+ years old with design decisions from another era.


The concept of a "binary representation" is suspiciously similar to Fortran modules, so they are already treading on a treacherous road, IMO. But feel free to prove me wrong with data, documentation and facts. This is not religion or politics.

Graf Zahl said:

I already see that the Fortran modules contain the entire implementation, and not just the interface.


That might depend on the compiler, however both Intel Visual Fortran and gfortran produce both object and module files during compilation, so none of them is a complete representation or implementation. Fortran modules contain interfaces, struct definitions, method signatures, polymorphic/generic disambiguations (for newer versions) etc. but the actual code is still in the object files. However, to put everything together in a useful executable you need both. Actually, to even compile a source file that requires a specific module, you must first have successfully compiled the source file that produces that module, and so on. And that's a full compilation, not just a lightweight scan for interfaces and definitions. Having to recompile a file that's at the very bottom of the dependency list can feel, very, VERY miserable.

AFAIK, this sort of serial dependency does not normally appear in C or C++ projects. You can compile a file that references another one's symbols without needing to compile that other one first -actually, you can even compile them in parallel, and somehow the linker works it all out in the end. In Fortran, the compiler must work it out.

Graf Zahl said:

The C++ model is supposed to only export the interface - just like a header (that is, with some of the preprocessor madness being removed because that would cause problems with how they are supposed to work.


As I said, if they make it clearly better and avoid the pitfalls of the Fortran model, everything should be fine. In particular:

  • Keeping the module generation lightweight.
  • Avoiding introducing linear dependencies in the compilation chain.
  • Somehow preserve the ability to build in parallel, as losing that can have a far greater performance hit than recompiling some headers a few extra time.
  • Making module files interchangeable between compilers, especially if they are meant to replace headers for interfacing purposes.

Share this post


Link to post

What you describe sounds like in order to compile a module's interface you first have to compile the same module's implementation.

And that is indeed very problematic. But from what I read, the C++ model is supposed to compile the interface first independently and should avoid that particular problem.

In any case, if that system results in headers only being compiled once, it'd be a huge win. Like I said, in most programs compiling the headers takes infinitely more time than compiling the actual source so this needs to be addressed.

I also believe that the C++ model is not to have transferrable binary data. It will most likely have to recompile the interfaces each time unless it caches the results somewhere. But do not underestimate the time it takes to compile headers. I have been working with large bulky sets of headers, and it can easily make the compilation time for each file go up to several seconds, if each one needs the full set (with a common GUI library a very likely thing!) so even if it hurts parallelization a bit it'd still be a net gain.

Another thing to consider is that you can import modules in the implementation.
In any case the worst case scenario is, the compiler has to compile all module interfaces referenced by a given interface or implementation.
But you know what? Currently the compiler has to do the same thing anyway - but instead of compiling each interface once, it has to recompile it for each file that uses this interface, because that's how includes work!

Share this post


Link to post

Yay, another thread derailed :(

Share this post


Link to post

And while at it, why does the thread title neglect we have 2017 already?

Share this post


Link to post

My quest for the best limit-removing source port on RPi continues, and here there are my findings so far.

PRBOOM PLUS
In Raspbian repositories PrBoom+ is available. It seems optimized for RPi (GLES?) but I can't understand:
- if it's a fork or the official branch
- if it does support Hexen
- why Vsync does not work, even if it's enabled in options

ZDOOM
I installed ZDoom via Retropie-Setup script. It requires an SDL library different from the one in official Raspbian Jessie repository, but again with Retropie Setup it's easy to install everything. It runs very well with some tips (e.g. setting resolution of RPi in config.txt at 640x480) and Hexen is fully supported.
IMHO this is the way to go, but:
- maybe it could run even better with GLES acceleration (or GZDoom with GLES)
- it would be nice a script to install or compile it without the need of RetroPie Setup script (and its folder structure)

Share this post


Link to post

prboom+ doesn't support Hexen.

Share this post


Link to post
antiriad said:

Hi,
so I have a Raspberry Pi 3 and I'd like to play classic DOOM, HERETIC and HEXEN in Raspbian (cli, frame buffer).
I'm not interested in modern graphic features, I like blocky pixels but at least I'd like true high resolution and 60fps.

I'm reading a lot of topics here but still it's not clear to me this: is actually possible to compile and run on RPi3 a source port that can benefit from GPU hardware acceleration without manually compile SDL 2.0.5 or Retropie?

Maybe there is a limit-rem engine based on SDL 1.x that runs smoothly in HD thanks to OpenGLES acceleration?

PrBOOM, Odamex, ZDOOM... I'm searching for a "clean" compile-and-play (smoothly in HD) solution, but I'm a bit lost.

Thank you very much.



you can install prboom, it will give you prboom and prboom game server.
that's already pretty cool

Share this post


Link to post

Why would you use PrBoom, not PrBoom-Plus? PrBoom is more than 8 years old.

Share this post


Link to post

Some distros label prboom-plus as plain old prboom I think. Unfortunately, Retroarch doesn't have that excuse. Can someone please port the latest version of PrBoom-Plus and the SDL2 branch of Chocolate Doom to libretro?

Share this post


Link to post

I tried yet PrBoom Plus (it's even in Raspbian repositories) but aside from a VSync issue, it does not support Hexen.

IMHO actually the best ports on Raspberry Pi are Chocolate DOOM and ZDOOM.
Chocolate was once in Raspbian repositories too, but it has been removed (I don't know why). ZDOOM can be easily installed (with SDL 2.05) via RetroPie Setup script.

I was able to compile also DOOM Retro, but unfortunately I didn't get how to run it in framebuffer mode (no X11, but in plain CLI).

Of course it would be great if there was a "dedicated" repository for DOOM source ports on RPi...

Share this post


Link to post
Danfun64 said:

Some distros label prboom-plus as plain old prboom I think. Unfortunately, Retroarch doesn't have that excuse. Can someone please port the latest version of PrBoom-Plus and the SDL2 branch of Chocolate Doom to libretro?


I think there's a reason chocolate can't be ported, to do with retroarch dictating the framerate or game tic rate and it's not 35 tics per sec.

antiriad said:

I tried yet PrBoom Plus (it's even in Raspbian repositories) but aside from a VSync issue, it does not support Hexen.

IMHO actually the best ports on Raspberry Pi are Chocolate DOOM and ZDOOM.
Chocolate was once in Raspbian repositories too, but it has been removed (I don't know why). ZDOOM can be easily installed (with SDL 2.05) via RetroPie Setup script.


I dont know why chocolate was removed either, but it will have been the SDL1 version (it would have just been a copy of the Debian package that fabian and I maintain); once v3 is out and there's an SDL2 version things will be even better. And several of the chocolate-doom devs regularly use raspberry pis so we're going to keep it working well going forward.

Share this post


Link to post
Jon said:

I think there's a reason chocolate can't be ported, to do with retroarch dictating the framerate or game tic rate and it's not 35 tics per sec.

That's a rather unfortunate limitation. Surprised that it exists for such a project.

Still, Crispy Doom should make a nice target. It can play well with 60fps or any other rate.

Share this post


Link to post
chungy said:

That's a rather unfortunate limitation. Surprised that it exists for such a project.

Still, Crispy Doom should make a nice target. It can play well with 60fps or any other rate.


Yup. And there's a small chance we can get choco there, if/when we've decoupled the game rate from the screen rate, which we need for medusa emulation and probably for interpolation on 60fps displays.

Share this post


Link to post
Jon said:

I dont know why chocolate was removed either, but it will have been the SDL1 version (it would have just been a copy of the Debian package that fabian and I maintain); once v3 is out and there's an SDL2 version things will be even better. And several of the chocolate-doom devs regularly use raspberry pis so we're going to keep it working well going forward.


Thank you very much for your feedback.

Latest stable release (SDL1 version) of Chocolate DOOM still runs very well on RPi, so IMHO it could have stayed in the Raspbian repository until V3 (SDL2).

Really, it would be nice to have the opportunity to easily install Chocolate DOOM and ZDOOM on Raspberry via apt-get (from official Raspbian repository, custom repository, or even via a slimmed version of Retropie-Setup-like script). These two source ports run very well, but since installation is uncomfortable this leads many users to older ports, often without documentation.
Which is a shame. ;D

Share this post


Link to post

I think it's possible to install Debian arm64 packages directly in raspbian now (it will be possible to install Debian itself, natively, instead of raspbian, one day soon)

Share this post


Link to post
On 3/13/2017 at 3:57 AM, chungy said:

Still, Crispy Doom should make a nice target.

Say goodbye to Heretic, Hexen, and Strife support. Multiplayer aside (PrBoom-Plus still to this day has horrible netplay code AFAIK), those games are the main reason to port Chocolate to Retroarch. There don't seem to be any other good candidates for those three games to port to Retroarch, as they don't have a PrBoom-Plus equivalent.

 

edit: The best alternative I could think of is the old ZDoom maintenence branch with some (but not all) of the changes from https://github.com/drfrag666/ZDoom-LE (The ones to include are the fixes and the restoration of r_detail. The ones not to include are ones like "Removed dependency on directx9 and xinput, instead mingw32 dx8 headers and libraries are used", "Modifications made to openal-soft v112 for win95 compatibility.", etc. )

 

edit 2: Actually, add Eternity's Split Screen fork to the mix. So basically PrBoom-Plus (replacing the old PrBoom), Eternity's Split Screen fork, and either Chocolate Doom (possibly with removed/reduced limits as well as all of Crispy Doom's features on Doom's end) or the proposed ZDoom thing from the first edit.

Edited by Danfun64

Posted (edited)

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