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

DOOM on Raspberry in 2016 ...which way?

Recommended Posts

Just fixed compilation on Raspberry Pi.
w3vYVcrl.png


Works as of this commit. (As a note - dpJudas ported a lot of these drawers to non-SSE2 variants - so real credit goes to him :P)

Share this post


Link to post
On 21/3/2017 at 10:59 PM, Rachael said:

Just fixed compilation on Raspberry Pi.

Works as of this commit. (As a note - dpJudas ported a lot of these drawers to non-SSE2 variants - so real credit goes to him :P)

 

Hi Rachel, I was going to point you in this thread on RPi forums when I read this great news: so does it take advantage of hardware acceleration? Does it run in pure CLI? Thank you very much for all your work (and that of dpJudas!)

Share this post


Link to post

No there is currently no hardware acceleration available. I have not tested "pure CLI" - that really depends on SDL2, if an SDL2 app will run that way then GZDoom will, too. I think it's safe to assume that is not the case.

 

Currently, it runs a bit choppy. Until we figure out the problems that are plaguing OpenGLES, there's really no way around that. And for that, we need a proper debugger. There's this thread for interest in case you have a stack trace that we can use.

Share this post


Link to post
6 hours ago, Rachael said:

No there is currently no hardware acceleration available. I have not tested "pure CLI"...

 

Maybe this could help: there is a Quake 1 port optimized for Raspberry that runs at 60fps@1080p even on a RPi 1B thanks to Open GLES.

It's called Qurp and its source code is here:

 

https://github.com/welford/qurp

 

Maybe it could be of any help (I'm not a developer).

Thanks

Share this post


Link to post
On 4/3/2017 at 3:33 PM, Rachael said:

No there is currently no hardware acceleration available. I have not tested "pure CLI" - that really depends on SDL2, if an SDL2 app will run that way then GZDoom will, too. I think it's safe to assume that is not the case.

 

It should work: I will see about testing it. I've only ever actually used SDL2 apps from the console (=framebuffer) rather than in X. At some point SDL2 on the Pi was broken under X anyway. But Chocolate-doom sdl2-branch works fine launched from the console.

 

Edit: it compiles fine and runs via framebuffer (picked a resolution of 640x480, I can't recall what size the kernel thinks the buffer is, the native screen size is 1024x768 but I have it connected via composite). It's very slow, though. Not sure what the frame rate is exactly but I tried plutonia map07 and I would guesstimate it at between 5-10fps

Edited by Jon

Share this post


Link to post

For what it's worth, I'm running Arch Linux ARM on my Rpi3.

 

I could compile and install(*) the following Doom ports:

  • chocolate-doom : runs fine without issues in 320x200 scaled up to the native resolution of my screen, 1280x1024.
  • crispy-doom: runs fine in 1280x1024
  • prboom-plus: runs fine in 640x512 scaled up to 1280x1024 (render_screen_multiply = 2). Gets a bit choppy and gets screen tearing in full 1280x1024 resolution.

All these are rendering in software mode in X, I haven't tried any GL based ports.

 

(*) I used the AUR, but had to modify each PKGBUILD manually to add 'armv7h' as a supported architecture, because by default they only list 'i686' and 'x86_64'.

Share this post


Link to post

dpJudas made a few changes recently that should allow RPi to run GZDoom in OpenGL ES mode if you have hardware acceleration. You will need the proper OpenGL packages installed as well as proper GPU drivers for it.

 

It's untested - but at the very least, it runs on Mesa, and with a somewhat testable framerate at 320x200. With hardware acceleration it'll probably be even faster and run better at higher resolutions.

 

This is a list of CVars you should know about when running on the Pi:

 

vid_renderer 0/1: Software/OpenGL (It probably defaults to Software on the Pi, just so you know)

gl_es 0/1: Requests the OpenGL ES context when starting. This defaults to 1 on Pi.

vid_glswfb 0/1: Only relevant with vid_renderer 0 - this requests an OpenGL hardware accelerated framebuffer in Software mode, similar to how Direct3D9 worked in ZDoom. Defaults to 0 - but we're changing it to default to 1 soon.

Edited by Rachael

Share this post


Link to post
On 07/04/2017 at 10:34 AM, Rachael said:

dpJudas made a few changes recently that should allow RPi to run GZDoom in OpenGL ES mode if you have hardware acceleration. You will need the proper OpenGL packages installed as well as proper GPU drivers for it.

 

It's untested - but at the very least, it runs on Mesa, and with a somewhat testable framerate at 320x200. With hardware acceleration it'll probably be even faster and run better at higher resolutions.

 

This is a list of CVars you should know about when running on the Pi:

 

vid_renderer 0/1: Software/OpenGL (It probably defaults to Software on the Pi, just so you know)

gl_es 0/1: Requests the OpenGL ES context when starting. This defaults to 1 on Pi.

vid_glswfb 0/1: Only relevant with vid_renderer 0 - this requests an OpenGL hardware accelerated framebuffer in Software mode, similar to how Direct3D9 worked in ZDoom. Defaults to 0 - but we're changing it to default to 1 soon.

That's all well and good, but gzdoom still shouldn't crash if you don't have these installed or not set, and they really don't need to be installed for the software renderer (and right now out of the box with no ini gzdoom segfaults on my RPi2, trying to set a GL context). These really need to be command-line args as well and not hidden behind +set. They are impossible to find otherwise. Might be good to document this stuff in a README since Raspberry Pi is a special case?

Whatever zdoom used for the software renderer on the Pi, still works for this RPi 2 box I'm typing this on. there's no problems with framerate either. SDL2 already handles output with the RPI driver. 

 

Regarding Vid_Renderer: Unfortunately It doesn't default to Software, and for some reason, vid_renderer is now flipped, at least on my RPi3. vid_renderer set to "1" is the software renderer.

 

Honestly I don't think the RPi is as universal on the GL side of things as we would like,  as OpenGLES2 on Pi is handled differently than most implementations thanks to Broadcom, and that will require you to set a RPI-specific context , and using stuff from this: https://github.com/raspberrypi/firmware/blob/master/opt/vc/include/bcm_host.h

Meanwhile:

 

Using video driver RPI
Resolution: 640 x 480
pure virtual method called
terminate called without an active exception

Program received signal SIGABRT, Aborted.
0x76a8ef70 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56      ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) [10185.133566] sysrq: SysRq : Keyboard mode set to system default

(gdb) where
#0  0x76a8ef70 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x76a90324 in __GI_abort () at abort.c:89
#2  0x76c96b5c in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/arm-linux-gnueabihf/libstdc++.so.6
#3  0x76c949a0 in ?? () from /usr/lib/arm-linux-gnueabihf/libstdc++.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

 

Looks like the Rpi3 and RPi2 are different - well of course they would be, one is ARMv7 while the other is ARMv8.

Oh, and while using clang with cmake, SSE seems to be enabled on the Pi, and I can't figure out why.

Share this post


Link to post
1 hour ago, Csonicgo said:

That's all well and good, but gzdoom still shouldn't crash if you don't have these installed or not set, and they really don't need to be installed for the software renderer (and right now out of the box with no ini gzdoom segfaults on my RPi2, trying to set a GL context). These really need to be command-line args as well and not hidden behind +set. They are impossible to find otherwise. Might be good to document this stuff in a README since Raspberry Pi is a special case?

Whatever zdoom used for the software renderer on the Pi, still works for this RPi 2 box I'm typing this on. there's no problems with framerate either. SDL2 already handles output with the RPI driver.

The primary reason the software renderer wants to use OpenGL is because this allows it to use a much faster way of copying the final contents to the screen. The difference is not insignificant, where for example I was getting 75 FPS with the old SDL 2 path on my Linux Mint and 245 fps with OpenGL presenting the result. The hardware accelerated 2D (vid_hw2d) is just icing on the cake.

 

In any case, since it isn't working I'll add some #ifdefs that disables the support entirely on ARM.

Share this post


Link to post

So after going through a few source ports, I'm still not sure if I found the right one for the Raspberry Pi 3. So far I've tried:

 

prboom - installed from the raspbian repository, not self compiled, runs rather sluggish with software render, haven't tried open gl, propably will be worse

chocolate doom - runs fine, no problems besides I'm basically limited to vanilla WADs

crispy doom - the one I currently use as it's somewhat boom compatible, also runs fine fullscreen with a resolution of 1280x960

zdoom - not sure, but no matter which render I choose, it won't run smooth(like 10fps) on the same resolution as crispy does

eternity - kinda the same as zdoom, but 960x720 makes it somewhat playable, however it isn't upscaled in fullscreen and I run a native resolution of 1680x1050 on the RPi3, so it's only half the screen size(that also applies to crispy, but isn't less noticable)

 

It may help to say that I use the RPi3 as my desktop currently, so I'd like to not go for RetroPie, already tried, I prefer launching doom from the commandline but haven't found out yet how to do that with RetroPie, seems easier to just compile the ports and then figuring out how to get them to run properly.

 

As you can't change screen resolution on the fly on the Pi, so I'd have to reboot it everytime I wanna try some changes I made to a WAD, instead of just alt+tab and then pressing up and enter.

 

I'm also not sure on the whole SDL2 thing, I got it compiled and installed, but it seems I failed to set the proper flags while compiling(I'm still figuring it out).

 

Or can I just safely remove the old SDL1.2 packages, I'm not sure if SDL2 is all backwards compatible.

Edited by torekk

Share this post


Link to post

What distro are you using currently on your Pi?

 

I guess the other big question, really, is whether you have 3D acceleration turned on or not. That will make a huge impact with any SDL app, and I think all of the ones you listed here are.

Share this post


Link to post

I'm running Raspbian Jessie.

 

And if you mean with 3D acceleration that I used the SDL2 version from RetroPie, I happened to just try ZDoom again yesterday after uninstalling the self-compiled SDL2 and installed the packages from here: http://malus.exotica.org.uk/~buzz/pi/sdl/sdl2/

 

However it doesn't seem to make a difference. Or I am doing something wrong(propably more this).

 

So far I think ZDoom and Crispy Doom(and Chocolate Doom) are the only ones that use SDL2, atleast those are the last ports I recompiled after installing the SDL2 packages.

 

One thing I also noticed: ZDoom refuses to run without X for me, however on the Wiki it says it's vice versa? If I start ZDoom without X SDL reports it can't find an available video device. My guess: missing environment variables? I haven't done much without X yet.

 

But Crispy Doom still runs fine under X. I'm quite puzzled by all this.

Edited by torekk

Share this post


Link to post

ZDoom itself is not being updated anymore. Please try GZDoom: https://github.com/coelckers/gzdoom

 

While you do - here's some CVars and CCmds:

 

vid_renderer 0/1: Software/OpenGL (It probably defaults to Software on the Pi, just so you know)

gl_es 0/1: Requests the OpenGL ES context when starting. This defaults to 1 on Pi.

vid_glswfb 0/1: Only relevant with vid_renderer 0 - this requests an OpenGL hardware accelerated framebuffer in Software mode, similar to how Direct3D9 worked in ZDoom. Defaults to 0 - but we're changing it to default to 1 soon.

 

Now - reportedly, GZDoom attempts to use GLES 3.0 and that's not currently available on the Pi. But it might be worth flipping those switches around just in case and see what happens.

 

Lastly: You can also try this to speed things up a bit:

vid_setmode 320 240 - This runs Doom very close to its original resolution (excepting, of course, using square pixels for an extra 40 rows). I noticed a huge performance gain on my RPi in doing this, and it can be run in fullscreen.

Share this post


Link to post

I just compiled GZDoom and as you said it kind of works in 320x240 in fullscreen, however I get the "hot temp" icon so basically the RPi is starting to throttle itself down after a while. However in windowed mode 640x480 runs somewhat decent? CPU load for that is like 50%(if that helps anything). All under X, same as ZDoom it won't run without X as SDL reports no available video device.

 

Using software renderer as set in the options menu with the SDL setting. I also turned off decals and stuff like fake contrast, mipmapped textures and particles, not sure if that helps.

 

320x240 in windowed mode runs pretty ok for me, but I would be insane to play that way, right? Don't mind the "Couldn't open MIDI device", I was playing with the sound settings to see if they affect performance.

Share this post


Link to post

Yeah - it feels very cramped to play it in such a small window. :(

 

Well - I can tell you that fullscreen mode does work (type "toggle fullscreen" in the console) - but as for SDL2 ... ugh. It really does not work well on the Pi at all, from what I have observed. I've been trying to figure out ways to make it work a little better and run faster, but I think we kind of have to figure out whatever Crispy Doom is doing and do that. :P (I haven't personally tested that, yet, though)

 

Another thing that speeds it up is to play in palette mode, and to turn off dynamic lights. It sucks - but those two are big performance eaters even on x86 systems - and they do a number on the Pi, too.

 

It really would be nice, though, if you could change your resolution on the Pi like you could in Windows - but from what I have observed it seems like the system was not built for that kind of thing in mind.

Share this post


Link to post

I know that fullscreen works, it just runs worse than windowed mode for some reason.

 

I'm wondering, I mean Doom is 2.5D right? Why does for example PCSX_ReARMed run Duke Nukem 3D: Land of the Babes with like 50fps constantly? I mean sure the PSX had a lower resolution(I think it was 320x240), but there's a setting to double it to 640x480.

 

So far I know PCSX_ReARMed is using SDL1.2, dynamic recompiling and NEON gpu, not sure if any source port does the same or could benefit from this. It also utilizes the framebuffer as far as I got it, but in terms of game development I actually have no idea what I'm talking about most the times.

 

On the other hand it's propably much work, not sure if that's worth it. Sure there's more ARM devices than just an RPi, e.g. the Pandora/Pyra handhelds, in fact PCSX_ReARMed comes from that, it's an pandora port.

Share this post


Link to post

The reason why it's slower is because it's still doing more pixels. And obviously 3d acceleration is not turned on.

 

Using NEON intrinsics has been on my to-do list but that will really only improve performance for truecolor mode. At this point I think getting a decent framebuffer working at all on the Pi is a higher priority so that you're not stuck at such terribly low resolutions. That will all come in due time, when I feel like tearing into it and actually seeing what I can pull off.

Share this post


Link to post

Doesn't the Pi already have a framebuffer that replaces "surface" rendering? SDL2.0.x as far as I know has a special "RPi" driver just for this, and GZDoom already uses it.

Share this post


Link to post

I just uninstalled the SDL2 that I installed from here: http://malus.exotica.org.uk/~buzz/pi/sdl/sdl2/ and then recompiled it myself according to this guide: https://solarianprogrammer.com/2015/01/22/raspberry-pi-raspbian-getting-started-sdl-2/

 

Now I can run GZDoom and such without X and performance also seems to have increased, atleast 320x240 is playable. 640x480 would be preferable, but it seems to run below 30fps at times(checked with vid_fps 1).

 

I mainly did this to try out Duke Nukem 3D via eduke32, which runs mostly smooth in 1024x600(anything higher makes it start to stutter).

 

I'll propably just stick with Crispy Doom for now until Raspbian Stretch is out, heard it may change a few things regarding graphics.

Share this post


Link to post
On 8-3-2017 at 0:33 PM, Rachael said:

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.

This thread is old but mee dude and i know others who would love to get more ports for doom on the rpi 3 the rpi is my main source for doom :( since my expansive ass pc died on me.

 

Also i still use zdoom on Retropie is there any way i can get rasbian Jesse and gzdoom on software?

So i can play more wads and mods?

Edited by RetroDoomKid

Share this post


Link to post
6 hours ago, RetroDoomKid said:

This thread is old but mee dude and i know others who would love to get more ports for doom on the rpi 3 the rpi is my main source for doom :( since my expansive ass pc died on me.

 

Also i still use zdoom on Retropie is there any way i can get rasbian Jesse and gzdoom on software?

So i can play more wads and mods?

The issue is that GZDoom doesn't do Software rendering out of the box by default. ZDoom is discontinued and GZDoom is the successor, so GZDoom probably should default to Software renderer now. You'll need to force GZDoom to start with the software renderer. I want to say it's "+set vid_renderer 0" in the command line, but I'm not sure.

Share this post


Link to post

Since this is about rpi and stuff can some one help me and tell me how i can get prboom plus on my raspberry?

Please ive been searching for hours i cant figure it out..

Share this post


Link to post
13 hours ago, RetroDoomKid said:

Since this is about rpi and stuff can some one help me and tell me how i can get prboom plus on my raspberry?

Please ive been searching for hours i cant figure it out..

 

apt install prboom-plus

Share this post


Link to post
4 hours ago, Jon said:

 

apt install prboom-plus

I guess prboom plus only works under X??

Not Retropie?

Also how i get Chocolate doom and crispy doom? Cant seem to find the commands for it either ;( once i have those ill be set do you know it by chance?

 

Nvm i got Chocolate and crispy installed on the pi my only problem is idk how to Configure my setup i keep getting command not found with Chocolate-doom-setup any help?

Edited by RetroDoomKid

Share this post


Link to post
20 hours ago, RetroDoomKid said:

I guess prboom plus only works under X??

Not Retropie?

 

Prboom-plus is an SDL1 application, so it should work in the console as well as via X, depending on how Debian or Raspbian have built the SDL library. Try

export SDL_VIDEODRIVER=fbcon prboom-plus

and see if that works.

 

20 hours ago, RetroDoomKid said:

 

Nvm i got Chocolate and crispy installed on the pi my only problem is idk how to Configure my setup i keep getting command not found with Chocolate-doom-setup any help?

 

try chocolate-setup on its own, but how did you install them? that will give us a clue as to how

Share this post


Link to post

OK I just tried installing prboom-plus on my retropie, and I didn't need to even specify SDL_VIDEODRIVER, just running /usr/games/prboom-plus worked from a console.

Share this post


Link to post

For those of you on Raspberry Pi, I have a poll that I need answered: https://forum.zdoom.org/viewtopic.php?f=4&t=58256

 

The question is which RPi generation you have (2 or 3). Based on the responses so far (as of this post) I am ready to deprecate Raspberry Pi 2 completely and remove the CMake directives that allow it to build, making Raspberry Pi 3 a base requirement for GZDoom. That will happen unless I see a significant number of users interested in keeping Pi 2 support.

Share this post


Link to post

While I like the idea of Pi 2 support, and I used the Pi 1 and 2 to test zdoom's ARM support back in those days, if it means more features for the RPi3 in future (you know, like hardware acceleration) then I'm more than willing to part with it. Just know that I use GZDoom without X11 (it's not required on Pi thank god) so whatever changes in the rendering pipeline shouldn't require X11 to work.

Share this post


Link to post

Mostly, I just want to focus everything onto one architecture/processor and the difference between arm7 and arm8 is significant in terms of speed boost. Supporting RPi2 feels a bit like dead weight to me.

 

Dropping RPi2 won't immediately mean hardware acceleration. I ultimately will need to save up money to buy a new MicroSD card for my Pi in order to start supporting that, so I can flash a Raspbian image or something that actually supports it. (My Ubuntu Mate, sadly, does advertise supporting it, but every time I activate it, the system freezes on boot)

 

What I am thinking of doing is activating GZDoom's legacy renderer for GL ES, to see if that works. GL ES 3.0 does support the modern rendering path (inasmuch as you can get it working) but GL ES 2.0 apparently does not.

Share this post


Link to post

Related question, does 32 vs 64 matter much from your perspective? The vast majority of rpi distros run 32, but it's possible to run 64 bit debian. I'm experimenting with that now. However the desktop responsiveness is terrible and I don't know if that's related. 

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
×