Suggestions for ports

quicksilver

@ExarKunIv it's playable at 640x480 on lowest graphical settings and with my pi 4 overclocked (I'll try without overclock soon just for a comparative baseline). Game runs pretty much fullspeed this way except when there are a lot of lighting effects happening at once, in which case there are noticable frame-rate dips. So far I haven't encountered any game breaking bugs and I feel like the game can be completed. I also have classic doom mod and resurrection of evil expansion running. Only real issue I have encountered is that when launching the game through runcommand and an x session (x is required, otherwise there are game breaking graphical issues), quitting the game closes the game but not the x session so you are left at a black screen. Cntrl-alt-backspace closes the x session so I'm using that as a work around for right now.

ExarKunIv

@quicksilver very cool

i saw your post about the x session issue. its cool that we can get these working and in the future it will exit smoothly. from my take on what buzz said.

im more the happy to wait as long as there is a work around. which there is.

great work on all of this. im still on the Pi3 so anything i do it dated and most likely not working on my rig.
but hey it all about learning right :)

quicksilver

@ExarKunIv openjk is running really well on my pi 4 I suspect you could follow my above directions to get it running on your pi 3. I bet it would be playable.

ExarKunIv

@quicksilver might give that a try

ExarKunIv

@quicksilver i get a internal compiler error

but im still on 4.5.14 since that is the only version i can get Nblood to work on. so im not surprised about getting errors
im not that worried about it. most of these will wait till i have a Pi4.

mitu

@ExarKunIv said in Suggestions for ports:

@quicksilver i get a internal compiler error

It sometimes happens when you're out of memory. Likely un-noticeable on a Pi4 with 2 or 4Gb of RAM.

quicksilver

@mitu If thats the case could he just increase the amount of swap?

mitu

@gderber said in Suggestions for ports:

Doom3 BFG:
https://github.com/gderber/RetroPie-Setup/tree/feature/doom3_bfg

Looks good overall.

Incorrect license header - missing the license type (GPL3). See how other modules are adding it. It's important when generating the package license summary page (https://retropie.org.uk/stats/licences/).
missing help header (rp_module_help) - should at least indicate where you should copy your game files (.pk4).
md_ret_requires should be a file, not a folder, indicating the build process has completed succesfully.
run make clean during the build, so it always starts with a clean build.
game_data_doom3_bfg doesn't do much, fold it into configure. If the folder should be user writable, use mkUserDir instead of a simple mkdir (remember that the setup script runs as root).
addPort in configure looks wrong - look up the function definition in helpers.sh or how it's used in other scriptmodules. Last parameter should be the launch command.

https://github.com/gderber/RetroPie-Setup/tree/feature/wolf4sdl

Looks fine, but I don't know this port enough to know if the line removed is ok or not.

General comments for all the .sh files

use hard tabs for indentation (see the weird spacing in game_data_doom3..)
don't have 2 empty new lines.

A Former User

@mitu Thank you!

For the Wolf4SDL script, the removed line, I had based that on this comment on the Hexen2 pull request. I changed it back, and the other non-essential change, swapping the order of the if statement checking for the *.sod and *.sdm files. I swapped the order so it'd match the order for the main wolfenstein data files.

In both cases, they are not a requirement for the actual goal of getting a start-up script for a unified SOD launcher. So now a total of 2 lines added, no other changes.

For the rest thank you for looking at them, the feedback helped me a lot with these.

A Former User

All:

My OpenJK script "works for me"

You can find it here:
https://raw.githubusercontent.com/gderber/RetroPie-Setup/feature/openjk_ja/scriptmodules/ports/openjk_ja.sh

If anyone wants to try it, I'd really appreciate the feedback.

quicksilver

@gderber Ill try it out on my test setup and report back

quicksilver

I have literally spent all day on this, I bring you Morrowind via OpenMW! Currently launching directly through RetroPie with controller support. Performance is good :)

This is the last one on my list for now. So next I plan to do some additional testing and then I will write up build instructions for the ports I have working well.

A Former User

I found a couple bugs in my script. I'll post an update shortly.

quicksilver

So for at least three of the ports that I have running through an x session, if I set the in-game video option to fullscreen, the mouse and/or keyboard stop responding in-game. Anyone have any ideas what could be the cause of this? This seems to happen on OpenMW, dhewm3, and openjk.

mitu

@quicksilver Focus issues ? Try running a minimal window manager and see if it fixes it.

quicksilver

@mitu apologies for my ignorance 😬 but would that be something like matchbox? If so how would I get that running in conjunction with XINIT? I played around with matchbox before but was never able to tell if I was doing correctly.

mitu

@quicksilver Yes, something like matchbox should do. Look at the steamlink port to see how it's used.

A Former User

@quicksilver I found a fix for that. Open the .cfg file (openjk_sp.cfg), set the resolution to whatever your monitor resolution is. Your looking for:

seta r_customheight "1440" <-- your resolution height
seta r_customwidth "2560" <---- your resolution width
seta r_mode "-1" <-necessary for custom resolution (preventa the game from overriding your settings
seta cg_fov "96.4" <- adjusts the field of view (optional)

Hmm, re-reading your post, this may or may not help. It helped me with fullscreen with the mouse moving the screen focus away from the game.

quicksilver

@gderber I can get the screen fullscreen by matching the in game resolution to the resolution picked in runcommand even if windowed mode is selected. The issue is that if a user were to select fullscreen the mouse/keyboard would lose focus and they would be forced to edit a config somewhere to fix it. Which isn't a very good solution in my opinion. I would like to make running these games as foolproof as possible.

A Former User

@quicksilver I've been thinking about that. I don't like it either.

Have you run ioquake3? Do you have the same problem their. It's got a couple run switches that set the game resolution at run time. Those switches should work for the other quake3 engine games. OpenMW will need another solution.