Port Requests


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. :p
 
Dark Pulse said:
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. :p
Click to expand...
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.

https://gitlab.com/sdcofer70/enyo-doom

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.
 
canseco said:
It would be great to updates the enyo-doom launcher too on the ZDoom PND.

https://gitlab.com/sdcofer70/enyo-doom

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.
Click to expand...
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 :(
 
ptitSeb said:
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.
Click to expand...
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 :()
 
Two port requests in one post:

"GHDL is an open-source simulator for the VHDL language. GHDL allows you to compile and execute your VHDL code directly in your PC."
https://github.com/tgingold/ghdl

And also
"GTKWave is a fully featured GTK+ based wave viewer for Unix, Win32, and Mac OSX which reads LXT, LXT2, VZT, FST, and GHW files as well as standard Verilog VCD/EVCD files and allows their viewing."
http://gtkwave.sourceforge.net/
 
Linux-SWAT said:
Two port requests in one post:

"GHDL is an open-source simulator for the VHDL language. GHDL allows you to compile and execute your VHDL code directly in your PC."
https://github.com/tgingold/ghdl

And also
"GTKWave is a fully featured GTK+ based wave viewer for Unix, Win32, and Mac OSX which reads LXT, LXT2, VZT, FST, and GHW files as well as standard Verilog VCD/EVCD files and allows their viewing."
http://gtkwave.sourceforge.net/
Click to expand...
GHDL seems pretty tricky to build. I can try to build it, but it will take some time. Also, how do you expect the PND to work? Just a command line with access to the ghdl compiler?

For GTKWave, this one seems pretty standard. It depends on GTK2 (or 1.0) and, unless I overlooked something, should be easy to build? Still, I don't have much time, so if no one dod it, I'll try to do a build later.
 
levi said:
I can't see any source for that vivaldi browser, only a prebuilt .deb file. Can you link the source if you can find it?
Click to expand...
https://vivaldi.com/source/

I also found this quote on reddit from a vivaldi dev:
I don't want to say that we are open source, but I just want to say that we are not completely closed source and give some information.
The modifications we do to chromium are dumped here https://vivaldi.com/source/
It doesn't include the JavaScript code. But you have easy access to bundle.js. CSS rules for modifications are also possible and you can use chromium developer tools to analyze the application, a tool all web developers knows to some extent.
It has happened more than once, well to be honest, two times, that an user has sent me patches directly on the behaviour they want changed and they clearly had advanced knowledge about how the source code was written. Both times I have added the code like the user requested.
Vivaldi is definitely not free software but source code isnt completely inaccessible.
Click to expand...
 
ptitSeb said:
For GTKWave, this one seems pretty standard. It depends on GTK2 (or 1.0) and, unless I overlooked something, should be easy to build?
Click to expand...

I gave a try to build GTKWave, but i have a problem at link phase, it needs to link with tcl/tk libs 8.5 but it finds the configs (tclConfig.sh and tkConfig.sh) only for 8.4 libs. Tested only on Codeblocks with gcc 6.2, not one of the latest betas.
Configure is running with:
./configure --with-tcl=/mnt/utmp/codeblocks/usr/lib --with-tk=/mnt/utmp/codeblocks/usr/lib

Any idea how to resolve?
 
How about Ygopro, a recreation of Yu-gi-oh by fans.
github.com/Fluorohydride/ygopro

The game uses Irrlicht for graphics. I tried it with the software renderer and it works fine, except that some cards look odd and transparent.
I guess it could work with glshim. (or if irrlicht suppots GLES, use that instead)
 
You must log in or register to reply here.

Similar threads

Wally
Port requests section?
Replies
12
Views
2K
levi
levi
Tobriand
  • Locked
Please Post Port Requests In Cool Ideas And Other Wishes
Replies
0
Views
8K
Tobriand
Tobriand
mmielke
Is there any way to make this run on the Pandora?
Replies
1
Views
962
apersonthinks
apersonthinks
andyhamer
Dictionary/Thesaurus & A Few Port Requests
Replies
11
Views
2K
cinaed666
C
mmielke
GP2X Caanoo Requests
Replies
1
Views
2K
EvilDragon
EvilDragon
Back
Top