Odamex slow on the Raspberry Pi & More...

I was finally able to compile Odamex on the Raspberry Pi. Once under RetroPie, and once under Raspian.

Under Retropie it loads, but does not allow for any input from the mouse or keyboard.

Under Raspian it works, but the only way to play it at a decent speed it in a windows of 640x480. I also noticed that while in higher resolutions, it plays less sluggish when 32bit mode is off.
.
How can this be? If Odamex can manage on an XBOX with only 64Mb or RAM and something short of an 800Mhz Single Core CPU with a severely outdated GFX chipset, then surely it can perform better on the Pi; can't it?

The Gfx chipset won't matter as Odamex is software rendering.

According to Wikipedia, raspberry pi has a 700Mhz CPU, i.e. worse than the XBOX you mentioned.

Software rendering is inherently slow, and will be even slower when using 32-bit for each pixel (that is a lot more data to be pushing around compared to 8-bit pixels which DOOM originally used).

andrewj said:

The Gfx chipset won't matter as Odamex is software rendering.

According to Wikipedia, raspberry pi has a 700Mhz CPU, i.e. worse than the XBOX you mentioned.

Software rendering is inherently slow, and will be even slower when using 32-bit for each pixel (that is a lot more data to be pushing around compared to 8-bit pixels which DOOM originally used).

I have the Pi 2, which is 900Mhz and I over clocked it to 1000Mhz.

In RetroPie (no X), it runs fast at 640x480 full screen... but again, no keyboard and mouse input, where as in Raspian (X environment), the Keyboard and Mouse work.

EDIT: I also forgot to mention that PrBOOM-Plus runs at pretty descent speeds in software modes in most resolutions, and Crispy-DOOM runs great at the highest resolution.

crispy-doom stretches from 640x480, prboom-plus is heavily optimized

It does run well (as far as the demo seems to show), in full screen under Retropie, which is good enough for me. It's not important that it run under Raspian and X for me.


What eludes me though is why it picks up on the keyboard and mouse under Raspian and in X, but under RetroPie, without X, they don't register.

You are making the old, common mistake of comparing just CPU frequencies, between CPUs with vastly different architectures. The ARM CPU used in the Pi doesn't hold a candle to the Pentium 3 used in the Xbox, especially at frequency parity.

The P3 has branch prediction, a CRISP architecture and 32 KB L1 and 128 KB L2 cache on the XBOX. The ARM is RISC, has no or less powerful branch prediction, smaller L1 cache, and the L2 cache is hogged by the GPU.

The only real advantage of the ARM CPU woulbe be better energy efficiency.

Actually, I've tested my Pi 2 head to head with an old 3Ghz Pentium 3 machine with Nvidia, and in regards to emulation, the systems were about even on what they could achieve.

I know CPU's are different, but I was impressed at what all that old slow ARM could do!

Likewise, I have a 400Mhz Efika with 128Mb of RAM. It's PPC and runs MorphOS...
...ironically about the same as Odamex on Retropie in full screen, all bit a tad bit slower.

It's DOOM and not too heavily modified, I figured a 486 would do. ;)

3 GHz Pentium III? Now that's something I'd like to see ;)

While emulation would -normally- be a good pure CPU index benchmark, unless you used exactly the same emulators on both systems, with identical settings (e.g scanline emulation and video post-processing) and same accuracy options, the comparison wouldn't be significant. Esp. MAME is not renowned for performance, in its full build, while ports to consoles and embedded systems are usually based on FastMAME or older versions of MAMEFX, not the current official full thing, which has become ridiculously slow in the name of "accuracy".

Also, doom.exe != ZDoom or prBoom. And as for the 486 bit...heh...if only that was true, back in the day. Sure, it was playable on a DX/33 and above, but it was literally begging for a Pentium-class CPU to be played as it should. And that was at vanilla resolution.

I did my tests using RetroArch, and while I know some of the cores I used were different from PC to Pi, one that was consistent was the PSP. If the Pi had a 1.5Mhz CPU in it, then PSP could work just as well as it does on the 3Ghz P3, as it works nearly as good at only 1Ghz on the Pi.

I believe new technologies and new processor instructions, not to mention the extra cores, go a long way in all of this.

Are you sure your P3 is "3 GHz"? The fastest Pentium III CPUs to see wide commercial release were those with the 1.0-1.4 GHz Tualatin cores. The "Pentium III" used in the XBOX had only 128 KB of cache, same as the budget Celeron-core Pentium IIIs.

Now, while I have no doubt that the Pentium III (esp. its more powerful incarnations), as a single core CPU, is more powerful than any ARM core at frequency parity, there are legit reasons why a particular piece of software may perform better on a different platform with lower nominal specs. OS overhead, bus & memory bandwidth (which almost certainly is better than on most Pentium III mobos) etc.

The Pentium III was an underutilized chip, IMO, killed by lousy chipsets and receiving heavy competition from the Athlon XP chips by AMD, which eventually got DDR chipsets.

Maes said:

Are you sure your P3 is "3 GHz"? The fastest Pentium III CPUs to see wide commercial release were those with the 1.0-1.4 GHz Tualatin cores. The "Pentium III" used in the XBOX had only 128 KB of cache, same as the budget Celeron-core Pentium IIIs.

Now, while I have no doubt that the Pentium III (esp. its more powerful incarnations), as a single core CPU, is more powerful than any ARM core at frequency parity, there are legit reasons why a particular piece of software may perform better on a different platform with lower nominal specs. OS overhead, bus & memory bandwidth (which almost certainly is better than on most Pentium III mobos) etc.

The Pentium III was an underutilized chip, IMO, killed by lousy chipsets and receiving heavy competition from the Athlon XP chips by AMD, which eventually got DDR chipsets.

My bad... Pentium 4.

P4 is weaker clock-for-clock than the P3 :D

To see the difference you'd have to use a very early P4 (sub-2.0 GHz) with really shitty 100 MHz FSB, early slow DDR-200 to match, just 256KB of cache etc.

I doubt a later-gen P4 was still using that early transitional architecture, P4s were made with Hyperthreading, Dual Core, EMT64 support, LGA775 packaging, FSB up to 800 MHz etc.

Breeder said:

I was finally able to compile Odamex on the Raspberry Pi. Once under RetroPie, and once under Raspian.

Under Retropie it loads, but does not allow for any input from the mouse or keyboard.

Under Raspian it works, but the only way to play it at a decent speed it in a windows of 640x480. I also noticed that while in higher resolutions, it plays less sluggish when 32bit mode is off.
.
How can this be? If Odamex can manage on an XBOX with only 64Mb or RAM and something short of an 800Mhz Single Core CPU with a severely outdated GFX chipset, then surely it can perform better on the Pi; can't it?

Since no one in here has answered your main question: This is not anyone's fault directly, but a result of aging APIs and all that jazz.

SDL1.2 only has a few methods of rendering to the screen: surface, OpenGL, and a few not-as-popular ways, like rendering to a video overlay. The Raspberry Pi uses VCHIQ (Videocore) which is another method of graphics entirely- not unlike the dual graphics card setups of old. Think of the way the Voodoo2 worked, and you have a general idea of how this beast works.

VCHIQ does not use OpenGL, either - it uses OpenGLES2 - Which is that stripped-down version of OpenGL that Khronos wanted to make popular everywhere, and is supported on most graphics cards. This makes OpenGL acceleration difficult unless there is a wrapper - which has now been done, but is still incomplete.

You'll need to do one of two things: Play in framebuffer mode (No X11 at all) with the custom SDL1 libraries that are included in the raspbian repo, or use an SDL2 port.

As for the mouse support being broken, I do think that is an SDL1.2 issue - or Odamex, as Eternity Engine plays fine with the mouse in framebuffer mode, and Odamex does not.

Odamex plays well on the XBOX because SDL1.2 has support for the XBOX. SDL2 has support for the Raspberry Pi specifically (without X11).

Csonicgo said:

Since no one in here has answered your main question: This is not anyone's fault directly, but a result of aging APIs and all that jazz.

SDL1.2 only has a few methods of rendering to the screen: surface, OpenGL, and a few not-as-popular ways, like rendering to a video overlay. The Raspberry Pi uses VCHIQ (Videocore) which is another method of graphics entirely- not unlike the dual graphics card setups of old. Think of the way the Voodoo2 worked, and you have a general idea of how this beast works.

VCHIQ does not use OpenGL, either - it uses OpenGLES2 - Which is that stripped-down version of OpenGL that Khronos wanted to make popular everywhere, and is supported on most graphics cards. This makes OpenGL acceleration difficult unless there is a wrapper - which has now been done, but is still incomplete.

You'll need to do one of two things: Play in framebuffer mode (No X11 at all) with the custom SDL1 libraries that are included in the raspbian repo, or use an SDL2 port.

As for the mouse support being broken, I do think that is an SDL1.2 issue - or Odamex, as Eternity Engine plays fine with the mouse in framebuffer mode, and Odamex does not.

Odamex plays well on the XBOX because SDL1.2 has support for the XBOX. SDL2 has support for the Raspberry Pi specifically (without X11).

Detailed response, thank you!

How would I go about telling it to compile for SDL2 and not 1 specifically?

It's not so simple as changing a build flag. Odamex would need to be forward-ported to SDL2, which will involve rather extensive changes to the code itself.

Doom engines are usually not so bad, and I don't imagine Odamex would be that difficult to port over. Most of the stuff that handles SDL should be in the i_* files.