Release PGen


ptitSeb

Serial Porter
Joined
Aug 15, 2012
Messages
9,340
Age
52
Location
France, near Lyon
Here is PGen, the Portable Genesis by CPasJuste

preview01.png


This will use gl4es for the rendering. I ported only the OpenGL 1.x backend, so no shader effects. Also, if the emulator goes to fast, update gl4es (just update the system with `sudo apt update && sudo apt upgrade`), to have latest version thta include a fake VSync option. The keymap should be Pyra friendly.

This Emulator handle Genesis/Megadrive with 32X and MegaCD extension, but also the 8bits generation of console from Sega, like Gamegear and the Master System (also the sg1000). Tested Virtual Racing for example, and it was working nicely.

You may need to install libglew2.1 and a few other for this one to work. Use
Code:
sudo install libglew2.1 libtinyxml2-6a libminizip1 libfuse2
if it doesn't start.

By default, all roms are fetched from some folder in "appdata/pgen/roms", but you can redirect the folders by editing "appdata/pgen/config.cfg" after a 1st run. Note that you cannot add new folder, it's 1 folder per system.

History log
=========

Build 03
----------

  • fresh build
  • repacked for better compatibility
Build 02
-----------

  • fixed Pyra keymap
  • hide mouse cursor
Build 01 (unpublished)
-----------
  • Initial build
  • Some Pyra adaptations (fullscreen & keymap)
 
Last edited:
Nice , thanks, will get testet and put in a Video tomorrow^^
You got it running? I'm getting the same error in these P* emulators.

Code:
asimov@asimov-pyra:~$ dbp-run-path /media/asimov/SD16/dragonbox/packages/pgen-6.05.0.02.dbp
--------------------------------------------------------------
Setting PATH to /mnt/dbp/union/pgen:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
--------------------------------------------------------------
Setting HOME to /mnt/dbp/union/pgen
cp: cannot stat '/mnt/dbp/union/pgen/pyrainput.sav': No such file or directory
/usr/sbin/pyrainputctl {enable|disable} {keypad|gamepad|mouse}
/usr/sbin/pyrainputctl overload <path-to-config-file>
/usr/sbin/pyrainputctl no-overload
bin/pgen: error while loading shared libraries: libtinyxml2.so.6: cannot open shared object file: No such file or directory
asimov@asimov-pyra:~$
 
Thanks !! Just played happily GG Shinobi on this :D
This seems the only GG emulator in the repo.

But on Bookworm I had to do this in order to make it work:
Code:
sudo apt install libtinyxml2-9
sudo ln -s /usr/lib/arm-linux-gnueabihf/libtinyxml2.so.9 /usr/lib/arm-linux-gnueabihf/libtinyxml2.so.6

Also I have to ignore at every launch the warning about the missing library "libtinyxml2-6a".

Is there a way to disable that warning ?
 
The easiest way would be to repackage disabling the warning... I thought the warning was happening only 1 time?
The only options are:
  • "Install missing dependencies" (but the package don't exist anymore in the repo for this OS version)
  • "Abort launch"
  • "Launch anyway"

I'll have a deeper look maybe in the weekend, but my impression is that it searches for the presence of the dependencies at every launch.

If the check was instead on the requested library, maybe just a symlink could have stopped the warning.
But in that case a more complex search could be needed to find dynamically in what package of the actual repo is present that library ... +o(

EDIT:
... I'll just put here something related to package checks that jumped in my mind ...
Maybe could be possible to list the needed libraries of DBPs just from a file on the REPO, with entries separated by OS version ?!

Example:
DBP by default has no list of libraries to check, instead it reads the related repo list file online, gets the requested packages list for the current OS, and only then it will check for missing packages and asks to install them.

This way there's only a single file to be updated on the repo if something changes between OS versions, and the DBP can stay (in the majority of the cases) the same.

Also this approach could be upgraded a bit, adding to the online file commands to (for example) create automatically symlinks with the name of old libraries, in case those are not present in a different OS version ...
(I told "commands" and not scripts, because for security reasons it is better to limit what that file can make a DBP do to the system...)

Also also, that online file can contain a flag to prevent the DBP to run on a specific OS version, if for example the DBP is too old (or too new) and should be completely recompiled for that OS version ...

Also also also, to limit the online checks, if the file is found locally (maybe in the same folder of the DBP and with the same name), the online check is skipped, else the file will be downloaded in the same folder as before, so to get all the dependencies required and stopping future online checks ...
 
Last edited:
Back
Top