Discussion in 'General Discussions' started by mmielke, Nov 11, 2010.
Ok, it's on the repo now
GZDoom as a standalone build.
I noticed ptitSeb actually already has an upload with the Brutal Doom mod. Thing is, GZDoom can handle so much more - and not just that, both the mod (now V21) and the version of GZDoom (dunno what build is on the repo, probably a 2.X build) are old now, especially GZDoom in all likelihood - there was a major version bump a few months ago, and current latest is 3.2.1, which introduces all sorts of new stuff like ZScript (which mods are starting to use).
For those of us who are well-versed with using the GZDoom engine, it's probably good to have it "decoupled" from a mod like this, as we know where we can stuff our WAD files or PK3s. Although possibly a launcher (I use ZDoom Executor - also with available source, though built for Windows only?) would be a nice bonus, and save us from manually running stuff just to load up different WAD/mod combos.
I'd definitely enjoy this on my Pyra. Hell, I'd love to have it on my Switch, too, but the homebrew scene for that is just taking off now.
Well, I do have a build of the latest verison of GZDoom runing, using latets gl4es (because GZDoom need OpenGL 2.x minimum, so it was part of my experiment with OpenGL 2 games on the Pandora). But I find the build a bit odd, there are some cases were "shots" miss and they shouldn't. I'm not sure what the issue is, but I suspect it's some ARM specific issue. Still, I can update the "ZDoom" PND by updating the GZDoom build to latest I guess.
It would be great to updates the enyo-doom launcher too on the ZDoom PND.
And another request:
Could you update your SDL2 github repo to 2.0.7?
How difficult would be to make your patches for OpenPandora upstream?
There are new controllers supported that i would like to try with the next Retroarch release.
Ah, enyo-doom got some updates? Ok, I'll take a look.
About SDL2, yeah, I have to work on that. Oh, 2.0.7 already? I haven't updated to 2.0.6 yet.
About pushing the Pandora patch upstream, I'm afraid the Joystick hack will never be accepted upstream, it's really too hacky, even if I put Pandora code behind #ifdef
It could also be engine bugs - there's a well-known bug where shots miss where they shouldn't. ZDoom (and thus, GZDoom) probably fixed this bug however, so if that's not what you mean, I'm not sure what sorts of "shots" are missing.
It is possible you may gain some info by looking into the build for the Pi 2, since of course, that runs on ARM as well (An ARM Cortex-A7 IIRC) and is thus fairly close to the Pandora.
That said, my request was more for the Pyra than the Pandora. I do have the Pandora as well, mind, but it's getting a bit too underpowered for GZDoom - two of the 3.2.0 changelog notes is this:
OpenGL 3.0 is now allowed for software OpenGL framebuffer (aka vid_glswfb) - The Mesa rendering library supports this just fine, and it seems it runs without trouble on known troublesome 3.0 cards.
OpenGL 3.3 is now required for the modern rendering path for hardware rendering. This means that ALL OpenGL cards prior to this version will revert to the legacy rendering path; no longer using shaders or clip planes. This was done due to there being too many compatibility issues and bugs with cards and drivers from this era.
I don't think this will hurt the Pyra, but it may start to be a deal-breaker for the Pandora without some trickery. That said, the latest GZDoom also merged QZDoom, which is a purely software-based renderer, into GZDoom, so if worse comes to worse, there might be that, assuming performance isn't totally murdered.
(Though looking on Wikipedia, the GPU in the Pyra also doesn't support OpenGL 3.0, much less 3.3, so maybe the Pyra can't handle it either... bummer )
Separate names with a comma.