OpenGothic icon indicating copy to clipboard operation
OpenGothic copied to clipboard

Joystick support (for turning)

Open Nindaleth opened this issue 3 years ago • 14 comments

This is a Steam Deck issue (probably a gamepad issue in general) - as there appears to be no joystick support, the top Steam Deck community layout for Gothic II Gold uses a workaround - the physical joystick control emulates a d-pad, i.e. when moving, you either turn left/right 100% or not at all.

I don't really mind that this applies to the forward/backward movement too (at worst I can switch to walk mode), but It's the turning left and right that's really hard to get used to and there's no workaround for that.

Nindaleth avatar Aug 31 '22 23:08 Nindaleth

Marked as help-wanted, since there is no Steam-Deck in Norway for me :D

Try avatar Dec 29 '22 20:12 Try

I can sell you mine if you'd want one :smile: I just think you don't actually want one, but the offer is serious.

Nindaleth avatar Dec 30 '22 19:12 Nindaleth

:D haha Thanks, but no - I'll buy it myself, just later. On the other side, some PR would be nice ;)

Try avatar Dec 30 '22 21:12 Try

You don't need a steamdeck to write support for a controller. Steamdeck is just another xinput device just like dualshock or xbox controller. I wanted to write support for this myself but I quickly realized that I'm just a java dev and c++ is too complicated for me.

ezamelczyk avatar Jan 03 '24 11:01 ezamelczyk

I need at least some controller to progress :D While at it can you post here, what controller can be good for windows/mac (or controller that you prefer to use)?

Try avatar Jan 03 '24 21:01 Try

I just use my ps5 controller but xbox would be fine as well. The new ones are rather expensive tho so maybe just go for dualshock 4 (the ps4 one).

On the other hand I looked a bit more through the code and I figured that this would have to be implemented into tempest since it handles the event loop so maybe we should move this conversation over there?

I'm bad at c++ but I'm gonna try to implement this. I don't have anything better to do anyway :p

ezamelczyk avatar Jan 05 '24 03:01 ezamelczyk

Also it might be easier than I thought since there's already a pretty robust cross-platform library for this https://www.libsdl.org/

I don't know what's your stance on 3rd party libraries tho. You think this might be a good idea?

If yes: would you rather we include it as a git submodule and add to the build process or just require devs to install binaries and link via find_package?

ezamelczyk avatar Jan 05 '24 03:01 ezamelczyk

@ezamelczyk

I don't have anything better to do anyway :p

Glad to head it :D

I just use my ps5 controller but xbox would be fine as well.

OK, cool... actually still kinda want to buy steamdeck instead, for the sake of playing but will see .

I don't know what's your stance on 3rd party libraries tho.

Generally better to avoid, unless they do something irreplaceable and in good quality. Unfortunately, libsdl however is not something that can be associated with quality.

have to be implemented into tempest since it handles the event loop

Can be wrong, but joystick is not event based normally? At least on windows joystickapi appears to be immediate mode. My suggesting here would be to add initial implementation to the game-code wrapped into a class, similar to how InstallDetect works.

Try avatar Jan 05 '24 21:01 Try

@Try do you have a discord or something? I have some questions and feel like it would be easier to talk directly.

ezamelczyk avatar Jan 06 '24 12:01 ezamelczyk

On main page, there is invite, to GMDC: https://discord.gg/G9XvcFQnn6 There: projects/open-gothic

Try avatar Jan 06 '24 14:01 Try

So my initial proposal is to base the internal input api on standards set by Microsoft with GameInput and Apple with Game Controller framework

Both of these libraries provide a way to consume a stream of inputs or poll for state changes. With how Gothic works under the hood I think it's reasonable to just poll every frame since it's not exactly important to have a 1000hz polling rate. With this approach we could unify handling input from all sources (mice, keyboards and controllers) which I'm hoping would simplify the codebase a bit.

I've already implemented a working approach for MacOS but it needs reworking to conform to the new idea. It's probably gonna take a few weeks to iron out and in the meantime I'm open for comments.

ezamelczyk avatar Jan 24 '24 22:01 ezamelczyk