GLtron (SDL2 version)

[slender plover]

A 3D lightcycle game inspired by the famous movie Tron.

This is a nice alternative to the existing Armagetron Advanced port, unlike Armagetron this one does not have multiplayer, although it could have local multiplayer by fiddling with the controller and game settings.

The port is based on an existing SDL2 version made by laanwj, this turned out to be the easier codebase to work with (initial efforts were made with Debian sources which use SDL 1.2 libs). My modified source code can be found here: https://github.com/JORGETECH/gltron-portmaster

I decided to use GL4ES in all platforms (even ROCKNIX) due to some rendering errors with Panfrost drivers (at least in H700 devices), for ROCKNIX this dependency could be removed in the future if Panfrost drivers get improvements.

Since this is a FOSS game, all the game files are included

Known Issues

The camera movement inside the game is a bit finicky, I suspect this could be due to how the mouse pointer interacts with the game. I tried setting the game's mouse locking setting but it has no effect. Any ideas are welcome on how to fix this.

Changing some settings in the menu can crash the game (specially the game rules), I have to investigate this with gdb, can't promise a fix if it's an obscure programming bug (the codebase is really old).

The game may crash randomly, I don't know if this is influenced by the type of Linux system, sometimes it takes a long time to crash but other times it crashes shortlyafter starting a game. I also need to investigate with gdb

Other than those quirks, the game should be playable, but let me know if you find anything

Test chart

[X] AmberELEC
[] ArkOS
[X] dArkOS
[X] ROCKNIX (Panfrost)
[X] muOS
[X] Knulli (Optional)
[] Other (add here)

Resolution tests:

[] 480x320 (Optional)
[X] 640x480
[] 720x720 (Optional)
[] Higher resolutions (e.g., 1280x720)

The game can work with high resolutions by modifying the video settings, I will reply to this post with info on how to do that.

Also, special thanks to @fickle phoenix , @lavish saffron and @ocean peak for helping me out on making this port work. I learn a lot along the process thanks to them, it's been a long time since I tried to port anything to handhelds and the last time was on a different platform (OpenDIngux)

[bleak canyon]

<@&1216123318122577972>

[slender plover]

Testing higher resolutions

This port is set to 640x480 resolution by default since it should be the one that's more common between handhelds targeted by PortMaster, however, the game should be able to run in higher resolutions. If anyone wants to try this, there are screen options in the game's menu (inside the Video menu).

If changing those settings crashes the game, there's also the option of manually modifying the ".gltronrc" file inside your distro's home folder (e.g. /userdata/system in Knulli or /storage in ROCKNIX), the lines that should be changed are "settings.width" and "settings.height". There are also some relevant values in the file scripts/config.lua inside the port folder

Keep in mind a default .gltronrc config file is created on game startup if one is not present (this was necessary for making the controls work properly)

[royal monolith]

Great Job!
Looking forward to testing this!

https://tenor.com/view/great-job-good-job-awkward-wink-gif-7414352

[slender plover]

Thanks! I'm specially interested for people testing it on AmberELEC and (d)ArkOS since I don't own any compatible devices

[royal monolith]

No R36S!?

[royal monolith]

ArkOS

boots on R36S amberlec ✅

its very weird that the camera angle has the bike coming TOWARDS you. i think most peopel would much more prefer it goign away from them. the controls feel so weird this way

[slender plover]

I will take a deeper look to the log, I might have done something wrong in the script. Although, I can see immediatly /tmp/weston is not mounted for some reason

[slender plover]

Yes, it's a bit weird I agree, I have to see if I can change some more default settings to tweak the default camera angle. I'm glad it at least works in AmberELEC. BTW, is the mouse speed too high or slow for you?

[royal monolith]

theres no mouse..

its all controller

RG40XX-H MuOS ✅

AH HA

L2 and R2 zoom in and out

if i HOLD L1 and have it fully zoomed out, that seems most comfortable to play with in my opinion

[slender plover]

Oh, I didn't post the controls, here they are:

Button	Action
Up	Move up in menu
Down	Move down in menu
Left	Turn lightcycle left, move left in menu
Right	Turn lightcycle right, move right in menu
A	Booster
B	Wall buster
X	Booster
Y	Wall buster
Start	Select option in menu
Select	Go back in menu, pause game
L1	Glance left
L2	Left mouse click, zoom out camera
L3	Left mouse click, zoom out camera
R1	Glance right
R2	Right mouse click, zoom in camera
R3	Right mouse click, zoom in camera
Left analog stick	Same as dpad
Right analog stick	Move mouse, move camera

[slender plover]

Sorry, I meant the right analog stick, it's mapped to mouse

[royal monolith]

post this at the top with your oroginal post

oh i never needed to use mouse

[acoustic gyro]

Runs on dArkOS/RGB30, but the resoltuion options are pretty bad

[royal monolith]

i just used d pad and it went through the menu just fine

had to press start to select menu confirm but thats fine

[acoustic gyro]

The default camera is 'behind' for some reason

[slender plover]

I'm new to making this kind of posts in Discord, can I just pin it? The original message is too long to add this

[slender plover]

Which options does it give you?

The RGB30 is the one that has 720x720 screen?

[acoustic gyro]

It is. It's giving old PC resolutions options like 640x480 and 800x600

[lavish saffron]

*yet

[slender plover]

Oh, I don't think I have permission to pin messages. I hope someone with such privileges can pin the message with the controls so it's more visible

[slender plover]

About the camera thing, it could be an issue with this version of the game. If I compile for my desktop I get the same result. At first I thought it was caused by the mouse position but it seems like it's bake in the game code

In fact the mouse locking seems to be broken on desktop too... Old codebase things

The part that makes less sense is that the camera mode is already sent to "behind" instead of "mouse", so much for having different options

[slender plover]

Ok, I got something, not a perfect solution but it can be a good compromise. First of all, the camera issue is actually a bug of the game not my port, but I decided I could maybe try to fix things up a little bit. The relevant camera code is here (initFollowCamera function): https://github.com/JORGETECH/gltron-portmaster/blob/master/src/game/camera.c#L78

By blindly changing lines 78, 79 and 80 to "= 0" at the end I can get a fixed behind camera view at a respectable distance (not too close, not too near). With that change you can no longer move the camera in that mode, it becomes static, but I'm really tempted to leave it like that for the time being since there's a redundant "mouse" camera mode that the user can select for a freecam.

This is how that fixed camera angle looks like. Would this be good enough for a default setting? What do you people think?

(The glance left and right controls would still work in this mode for looking to the side in this mode BTW)

I'm not a programmer BTW, I found out by playing around with the source code to see if I change things...

[royal monolith]

Much better and with the l2/r2 zoom out, it'll be perfect

[slender plover]

I was about to say that zoom out didn't work in this mode, but that's not true, if i set CAM_FREE_R to "= 1" in the function I can get the zoom working. So we know that part enables the freecam zoom in the follow camera

So I was able to figure out the meaning of those values:

• CAM_FREE_R: Camera zoom in and out
• CAM_FREE_PHI: Horizontal camera movement
• CAM_FREE_CHI: Vertical camera movement (this is the problematic one, for some reason it "wraps around" when it shouldn't)

I think the best compromise is to leave the zoom and horizontal movement, that way the camera still gets behind the lightcycle by default but the user is still able to zoom in and out and look to the sides as needed

I think the bug is that the initial camera setup tries to leave CAM_FREE_CHI behind the lightcycle but fails to do so due to an obscure programming issue

I will compile a new version when I can, I will also lower the sensitivity of the right analog stick. But it will have to wait since I need to get some sleep

[royal monolith]

I think you have done a great job!

[slender plover]

New release, this version should include the changes to the default camera I mentioned before. I also enabled inverted mouse on the x axis since it improves horizontal camera movement a bit. Lastly, I slowed down the right analog sensitivity more since it was too fast

Keep in mind I haven't seen why it doesn't launch on (d)ArkOS yet

[slender plover]

The RGB30 has a 720x720 screen which is a weird resolution for a game that was designed for computer screens. Can you try to manually set screen resolution in the config file as I explained in the third post? If it works I would appreciate photos of how it look on the device, thanks

[slender plover]

Oh, the zoom in and out feature might not be working in "behind" camera in this version, can anyone confirm this? I may have done something wrong when changing the code

[slender plover]

As for the ArkOS log, I wonder if this message has anything to do:

/tmp/weston/westonwrap.sh: line 94: [: : integer expression expected

But Westonpack seems to be starting fine there. Can you verify if other Westonpack games work in your end? If so, it could be a device/distro specific issue with the game itself

[royal monolith]

I'll make sure that westons installed

[fickle phoenix]

That is a red herring. It's a stupid typo that has been in that script for a long time. It doesn't affect the runtime

[slender plover]

Thanks for the tip

The zoom in and out feature should work in the latest version BTW, for some reason it didn't work the first time for me

[royal monolith]

We gotta figure out arkOS

[acoustic gyro]

It seems like the .gltronrc file is ignored. Any changes made to it appear to be ignored. Setting the .width, .height, and cam type in the config.lua is working. I left the settings.resolution at 3. The default "settings.camType = 1" is for a look behind view. Is that really what the default is supposed to be?

Here it is at 720x720 with camType=4

[slender plover]

Well, at least it looks decent and seems to scale well to arbitrary resolutions. I think I could add something to the script for detecting such devices and loading an alternative configuration file. The "behind" camera is set as default on purpose BTW (specially now that I'm aware of the "mouse" camera mode issues the game has)

As for the issue on not being able to change the .gltronrc file, that's weird, I can even change the resolution from there and it works on my device

Can you try to delete the configuration file so the script copies the default one and try again to manually chnage settings in the file?

On another note, @royal monolith I read again the ArkOS log and after reading it properly I can see a GLIBC related error, which means either the distro you are using is too old or my build system is too new for it. I can also see in the log you are running an older version of ArkOS for R36S, can you try updating to a newer version? If the problem persists I can try building the port with an older compilation system (Debian Bullseye instead of Bookworm)

[lavish saffron]

Pm already does device and resolution detection

[slender plover]

So I can just detect for the environment variables PortMaster uses in the script?

Or is this something that can be done with an existing PortMaster helper script?

[royal monolith]

Is the log I uploaded for too old a version of arkos?

[lavish saffron]

Yeah

[slender plover]

I checked the GitHub releases and seems there's a couple newer ones (not sure if they change the libraries): https://github.com/AeolusUX/ArkOS-R3XS/releases

[royal monolith]

On my odin2 portal

Going to screen, and selecting any other size and then Start on Apply Changes, it just crashes

But the camera perfectly right behind the bike. Can't zoom in or out anymore though

[slender plover]

Oh, what system does the odin2 Portal use? I'm not familiar with that device

[slender plover]

This also happened to me on the first gameplay but it somehow got fixed on second launch. Have you tried clicking the sticks?

Also, I think the game reacts better to camera zoom controls before starting the match, it's just some weird logic of the game (at least in this version)

[royal monolith]

Rocknix