Raptor Computing Systems Community Forums (BETA)
Software => Applications and Porting => Topic started by: tle on September 21, 2023, 05:56:00 am
-
This is yet another source port for Quake 3 and considered one of the best Vulkan renderer port out there.
(https://user-images.githubusercontent.com/135605/260970692-640ff3c1-f4d5-417f-ac47-261589985139.png)
I am happy that the author has finally accepted my Pull Request to make it compile for ppc64le
https://github.com/suijingfeng/vkQuake3/pull/18
-
all of the engines currently still use an interpreter for QVM (which means really bad performance, noticeable in the mod CPMA), quake3e plans on having native support for ppc64le eventually.
-
all of the engines currently still use an interpreter for QVM (which means really bad performance, noticeable in the mod CPMA), quake3e plans on having native support for ppc64le eventually.
Could you please point me to the conversation about native support for ppc64le?
-
I'm pretty sure he's referencing to your own feature request.
-
I'm pretty sure he's referencing to your own feature request.
its mainly on the discord. The main dev is in ukraine so deals with bombings.
I should add quake3e as it is can compile just fine on ppc64le (after one guy made some hacky build instructions to slap on it), and it performs better than ioquake3 and the like still.
-
Quake3e still needs a bytecode compiler for ppc64le if you were still interested in helping with that.
-
Quake3e still needs a bytecode compiler for ppc64le if you were still interested in helping with that.
It would be great if someone who has more experiences to tackle https://github.com/ec-/Quake3e/issues/232. I am more than happy to tag along to learn and help out whatever I could
-
I don't think this would work as written for the original PowerPC Q3VM, which was big-endian (little-endian PowerPC wasn't really a thing in those days). There may also be a few 32-64 bit edges, though I would think that would be minor.
-
I don't think this would work as written for the original PowerPC Q3VM, which was big-endian (little-endian PowerPC wasn't really a thing in those days). There may also be a few 32-64 bit edges, though I would think that would be minor.
it wouldn't, it needs a new one. Game/sourceport still works as is though, just some mods will have performance degradation..
-
> I don't think this would work as written for the original PowerPC Q3VM, which was big-endian (little-endian PowerPC wasn't really a thing in those days). There may also be a few 32-64 bit edges, though I would think that would be minor.
@ClassicHasClass if you have capacity, I would love to pair with you to see if we could add optimisation for LE for the ioq3 port (which is supposed to be the most supported / de-facto source port for Q3)
ref: https://github.com/ioquake/ioq3/blob/main/code/qcommon/vm_powerpc_asm.c
-
Btw, for Fedorans out there, the quake3 has been broken and so-out-date, I hope my PR https://src.fedoraproject.org/rpms/quake3/pull-request/2 would be reviewed and merged before Fedora 42 is out.
-
I'm happy to advise, but I can't really do much coding for it. I'm still committed to maintaining the Firefox JIT (in at least the current state) and the DOSBox JIT and my actual coding time in front of the Talos II is increasingly limited.
That said, https://github.com/ioquake/ioq3/blob/main/code/qcommon/vm_powerpc.c looks like where you'd need to do most of the work to get ppc64le to work. ppc64 is a supported target, so you'd need to audit this for endianness and write ppc64le-specific code paths for those sections that assume big endian. That may be sufficient to get it off the ground.