RaspZDoom

[Rachael]

https://github.com/madame-rachelle/raspzdoom

This is currently completely based on drfrag666's legacy port of GZDoom. I haven't done anything other than that on it, yet. The point of this is, in conjunction with the legacy port, keep support for the Raspberry Pi alive for GZDoom.

Currently, the only real future plan is to resurrect the pure-SDL implementation of the software renderer, if possible, but otherwise keep it updated with both drfrag666's features and with regular ZScript features in the main GZDoom version. In its current form, though, both hardware acceleration must be enabled, and the use of X11 are required for it to work.

My motivation for this is, I have a pi that I am using as a gaming unit when my niece and nephew comes over to visit. It's mainly useful for playing Chex Quest on, and obviously my favoured port of choice for that is GZDoom. I am sure there are other uses for it in the future, but for now, this port will be exclusively focused for the Raspberry Pi.

Credit goes to drfrag666 for providing the basis for this.

[drfrag]

I actually don't consider the vintage build a real port but an alternative version of GZDoom itself. It's just drfrag but that one was already taken.
Thanks for the credit but it's Graf's project and you should probably credit yourself before me since it's mostly the same code as in master minus the refactorings.
That said, i think AFAIK LZDoom should work well on the Pi and has the "pure-SDL implementation of the software renderer" so i was hoping you joined the LZDoom bandwagon instead, you already have access to the repo.
On the other hand there's a couple of missing things already in LZDoom so the official legacy build is more complete and of course it's official. Keeping the old codebase up to date is certainly more complicated, that's why i'd need some help.
So it's fine, it's always good to see a new source port. Good luck.

[Graf Zahl]

While I can understand why this is done, I have to say that I really do not like how GZDoom is getting fragmented recently with all those special legacy forks for various platforms.
Do we really need all of it or can this be streamlined?

[Rachael]

When differing between the 3.3 tree and 3.4 tree, definitely not. It's even more different than 3.4 and 3.5.

It's likely whatever I do in piZDoom will probably go right back to the legacy branch anyway, especially if I revive the unaccelerated SDL stuff. Mostly, for my own reasons, I wanted something that was focused on a platform that I still have interest in, even as underpowered as it is. I am quite invested in the future of GZDoom, obviously, having supported the removal of the pre-GL3.3 code, in order to move forward with Vulkan, but obviously it's not my only interest.

[Rachael]

So I renamed this RaspZDoom.

It has come to my attention that it is a very child-unfriendly swear word in Russian.

Now when I think about it - I personally don't mind having a program called "cunt". I'm sorry, I'm just being real here. But then I got to thinking about it, and I realized there is not only a significant number of Russians in the Doom community, but there's likely a number of them who might not want their name attached to a program called "cunt" - least of all in any sort of official capacity. It is for this consideration that I have renamed the source port to something slightly more professional. And being a fork of another project, that puts them in a position where they have their name attached to it whether they want it or not, just on the basis of contributing to a parent port from which it derives its code. Meaning, they wouldn't have a say in that matter. And yeah, I can't live with myself being THAT inconsiderate.

It is not my intent to offend or harm anyone, so I hope the new name I have chosen is slightly better.

(Thank you btw, SanyaWaffles, for the new name)

[Enjay]

Well, I learned something today.

[JPL]

If this fork(?) is still being maintained, I tried building it today on my Pi3 and eventually got this error:

---

Code: Select all • Expand view

[  4%] Built target asmjit
[  8%] Built target jpeg
[  9%] Built target bz2
[ 15%] Built target gme
[ 18%] Built target lzma
[ 18%] Built target lemon
[ 25%] Built target re2c
[ 25%] Built target updaterevision
[ 26%] Built target zipdir
[ 37%] Built target dumb
[ 37%] Built target arithchk
[ 37%] Built target qnan
[ 37%] Built target gdtoa
src/gitinfo.h is up to date at commit pi0.0-711-g942dcdba0.
[ 37%] Built target revision_check
[ 37%] Linking CXX executable ../raspzdoom
CMakeFiles/zdoom.dir/scripting/vm/jit.cpp.o: In function `JitCompiler::Codegen()':
/home/pi/RaspZDoom/src/scripting/vm/jit.cpp:142: undefined reference to `asmjit::X86Compiler::finalize()'
CMakeFiles/zdoom.dir/scripting/vm/jit.cpp.o:(.data.rel.ro+0x0): undefined reference to `asmjit::x86OpData'
CMakeFiles/zdoom.dir/scripting/vm/jit.cpp.o:(.data.rel.ro+0x4): undefined reference to `asmjit::x86OpData'
CMakeFiles/zdoom.dir/scripting/vm/jit.cpp.o:(.data.rel.ro+0x8): undefined reference to `asmjit::x86OpData'
CMakeFiles/zdoom.dir/scripting/vm/jit.cpp.o:(.data.rel.ro+0xc): undefined reference to `asmjit::x86OpData'
CMakeFiles/zdoom.dir/scripting/vm/jit.cpp.o:(.data.rel.ro+0x10): undefined reference to `asmjit::x86OpData'
CMakeFiles/zdoom.dir/scripting/vm/jit.cpp.o:(.data.rel.ro+0x14): more undefined references to `asmjit::x86OpData' follow
CMakeFiles/zdoom.dir/scripting/vm/jit.cpp.o: In function `JitCompiler::JitCompiler(asmjit::CodeHolder*, VMScriptFunction*)':
/home/pi/RaspZDoom/src/scripting/vm/jitintern.h:38: undefined reference to `asmjit::X86Compiler::X86Compiler(asmjit::CodeHolder*)'
CMakeFiles/zdoom.dir/scripting/vm/jit.cpp.o: In function `JitCompiler::~JitCompiler()':
/home/pi/RaspZDoom/src/scripting/vm/jitintern.h:35: undefined reference to `asmjit::X86Compiler::~X86Compiler()'
CMakeFiles/zdoom.dir/scripting/vm/jit_runtime.cpp.o: In function `CreateUnwindInfoUnix(asmjit::CCFunc*, unsigned int&)':
/home/pi/RaspZDoom/src/scripting/vm/jit_runtime.cpp:538: undefined reference to `asmjit::X86Assembler::X86Assembler(asmjit::CodeHolder*)'
/home/pi/RaspZDoom/src/scripting/vm/jit_runtime.cpp:538: undefined reference to `asmjit::X86Assembler::~X86Assembler()'
/home/pi/RaspZDoom/src/scripting/vm/jit_runtime.cpp:538: undefined reference to `asmjit::X86Assembler::~X86Assembler()'
CMakeFiles/zdoom.dir/scripting/vm/jit_runtime.cpp.o: In function `AddJitFunction(asmjit::CodeHolder*, JitCompiler*)':
/home/pi/RaspZDoom/src/scripting/vm/jit_runtime.cpp:724: undefined reference to `__register_frame'
CMakeFiles/zdoom.dir/scripting/vm/jit_runtime.cpp.o: In function `JitRelease()':
/home/pi/RaspZDoom/src/scripting/vm/jit_runtime.cpp:745: undefined reference to `__deregister_frame'
CMakeFiles/zdoom.dir/scripting/vm/jit_runtime.cpp.o:(.data.rel.ro+0x0): undefined reference to `asmjit::x86OpData'
CMakeFiles/zdoom.dir/scripting/vm/jit_runtime.cpp.o:(.data.rel.ro+0x4): undefined reference to `asmjit::x86OpData'
CMakeFiles/zdoom.dir/scripting/vm/jit_runtime.cpp.o:(.data.rel.ro+0x8): undefined reference to `asmjit::x86OpData'
CMakeFiles/zdoom.dir/scripting/vm/jit_runtime.cpp.o:(.data.rel.ro+0xc): undefined reference to `asmjit::x86OpData'
CMakeFiles/zdoom.dir/scripting/vm/jit_runtime.cpp.o:(.data.rel.ro+0x10): undefined reference to `asmjit::x86OpData'
CMakeFiles/zdoom.dir/scripting/vm/jit_runtime.cpp.o:(.data.rel.ro+0x14): more undefined references to `asmjit::x86OpData' follow
collect2: error: ld returned 1 exit status
src/CMakeFiles/zdoom.dir/build.make:12816: recipe for target 'raspzdoom' failed
make[2]: *** [raspzdoom] Error 1
CMakeFiles/Makefile2:1087: recipe for target 'src/CMakeFiles/zdoom.dir/all' failed
make[1]: *** [src/CMakeFiles/zdoom.dir/all] Error 2
Makefile:127: recipe for target 'all' failed
make: *** [all] Error 2


[Rachael]

Fixed. I had to downstream the ASMJit fix.