Forum

CS2D

General

Experimental Controller Support

Forums overview CS2D overview General overview Log in to reply

Experimental Controller Support

27 replies

1 2

Poll

Controller Support for CS2D?

Only registered users are allowed to vote

Finally! Will try it!		66.67% (10)
I probably won't use it		20.00% (3)
I don't care at all		13.33% (2)

15 votes cast

Re: Experimental Controller Support

DC OP
Admin Off

Offline

11.07.26 08:35:22 pm

Hajt: HTTP fallback guarantees that current implementations keep working without effort. Since it always was HTTP before I don't see a major issue with now using HTTPS first and then HTTP as fallback. It would be another story if I just added HTTP as fallback to an existing system that already offers HTTPS. Also properly configured servers shouldn't even serve HTTP anymore unless there is a good reason to do so.
I may remove HTTP entirely later or add an option to disable it.

Regarding Brotli:
CS2D doesn't transfer any big files via HTTP (unless you add http links to servertransfer.lst. I doubt that people are using this feature a lot because it caused lags in the past. Maybe it's not even working anymore). Therefore adding Brotli for HTTP is pretty useless.

I could switch the UDP file transfer compression to Brotli but impact wouldn't be huge. Also Brotli is much heavier on CPU which isn't optimal either.

(Apparently BlitzMax-NG even has modules with Brotli support already. I wouldn't even have to mess with C myself)

In general I'm not planning to continue optimizing tons of things in CS2D now.

@ user

Mora: If you have a compatible controller it should just work with the controls I explained in the beginning. If you have an unsupported controller you can still try to add the configuration manually to sys/gamecontrollerdb.txt
here's an explanation about how to create such a mapping: https://github.com/mdqinc/SDL_GameControllerDB
(if you do the work you can also open a pull request there so other games can benefit from it as well)

Re: Experimental Controller Support

Mora
User Off

Offline

12.07.26 04:25:09 pm

Well I have just run cs2dcontroller and theres a short video of my testing:

while trying to move it softly it looks like
https://youtu.be/6OfyKxQZ3As

It looks like my joystick is kinda bad or controls not set correctly
And is not just aimX = stickX; aimY = stickY?

edited 1×, last 12.07.26 04:58:54 pm

Re: Experimental Controller Support

DC OP
Admin Off

Offline

12.07.26 05:00:42 pm

Mora: Doesn't look quite right. I get much smoother aiminig. You can try

pad_firezone 0

<- this will disable attacking when moving the right stick a lot

gpad_deadzone 0.05

<- this will reduce the deadzone (range in which nothing happens to 5%, default is 0.15 = 15%, you may also have to try higher values)
If that doesn't help it's definitely somehow related to the controller.

Re: Experimental Controller Support

Mora
User Off

Offline

12.07.26 05:05:08 pm

I think is controller related because I have already tried commands You said before and nothing changed/no differences.

Re: Experimental Controller Support

mrc
User

Offline

12.07.26 09:34:55 pm

Same here — different controllers, including through Winlator.

One clue: the crosshair slides smoothly between angles but hitches specifically at all 8 (0°/45°/90°/135°/180°/225°/270°/315°) when rotating slowly. Not noticeable at fast rotation.

This is likely two separate issues stacked together:

1) Diagonals (45°/135°/225°/315°): raw stick values commonly exceed 1.0 magnitude here on generic pads / Winlator (unlike native XInput, which clamps to a circle). This distorts the ATan2 angle calc for a few frames right at those corners.

2) All 8 points hitching equally, with smooth sliding between: this pattern doesn't fully match #1 alone (cardinals shouldn't exceed magnitude 1.0). It looks more like there's some angle rounding/snapping/smoothing step downstream of the raw ATan2 result — possibly a leftover from 8-direction logic (similar to what you mentioned fixing for movement: "360° instead of 8 directions"). Worth checking if the aim code rounds/steps the angle anywhere, or if there's an angle-smoothing/lerp function that takes a "shortest path" between old and new angle — those often have bugs exactly at 45° boundaries if the wraparound math isn't handled correctly.

Suggested fix — covers both at once. Replace the raw stick assignment with this, and if there's any angle-smoothing/interpolation happening afterward, make sure it uses shortest-angular-path logic (not linear degree subtraction, which breaks at wraparound points):

Step 1: clamp + normalize stick vector (fixes diagonal magnitude overshoot)

1
2
3
4
5
6
7
8
9
10
11
12
13

Local rawX:Float = stickX
Local rawY:Float = stickY
Local magnitude:Float = Sqr(rawX * rawX + rawY * rawY)

If magnitude < gpad_deadzone Then
    aimX = 0
    aimY = 0
Else
    Local clampMagnitude:Float = magnitude
    If clampMagnitude > 1.0 Then clampMagnitude = 1.0
    aimX = (rawX / magnitude) * ((clampMagnitude - gpad_deadzone) / (1.0 - gpad_deadzone))
    aimY = (rawY / magnitude) * ((clampMagnitude - gpad_deadzone) / (1.0 - gpad_deadzone))
End If

Step 2: compute angle fresh each frame directly from the clamped vector — no snapping, no stepping

Local targetAngle:Float = ATan2(aimY, aimX)

Step 3: IF there's any smoothing/lerp applied to the angle afterward, make sure the delta is computed as shortest angular path, e.g.:

1
2

Local diff:Float = ((targetAngle - currentAngle) + 540) Mod 360 - 180
currentAngle = currentAngle + diff * smoothingFactor

A naive "currentAngle = currentAngle + (targetAngle - currentAngle) * factor" without the wraparound correction above will hitch/jump every time the angle crosses a boundary, which could explain the hitch at all 8 points rather than just the 4 diagonals.

If it's still hitching after this, it'd help to know if there's any Int(), Floor(), or modulo operation applied to the aim angle anywhere in the code — that would point straight at the snapping logic.

edited 11×, last 13.07.26 02:12:39 am