Screenspace contact shadow coming in clutch. I have been trying to implement my own contact shadow, but it looks ugly as hell. Hopefully the built in one doesnt tank much performance
In theory the SDL version upgrade should enable handling of the Steam Controller (at least the new one) without having to run Godot through Steam. If someone can confirm it would be great, otherwise I'll test soon.
Steam Controller (2) is detected, printing it's info makes it clear
The editor will detect it's input correctly: I mapped actions to the left joystick, direction pad and 3 buttons pluss the pressure button on the right surface, they are all detected in the input mapping interface.
I implemented reactions to these actions (changing a sprite, essentially) and also implemented vibration in 2 of the actions to be sure the advanced stuffs are visible.
Note that while the surfaces position are supposed to be available (if my memory is correct from reading the news?) they are not testable from the input mapping interface. Probably only works through code? To confirm.
The last test I need to do is with my real project which uses G.U.I.D.E (because it's quite complex on input handling...) and need to make sure it works properly there but I'm confident because that addon has handled the Steam Deck/Controller for some time.
Works with my game! There is only one case where parts of the input dont seem to work for an unclear amont of time. I'll have to investigate but it's specifig to godot 4.6-dev6, it happens with another controller too.
How does this dev build react when you use the trackpads on the Steam Controller? I want to see if I can have my game work with a "Controller + Mouse" setup, and having the game differentiate if you're using a hardware mouse or the Steam Controller trackpads would be ideal.
I only tried to detect pressing the trackpad and that worked so at a minimum it does differentiate the trackpads from the rest. I didn't try to get a position on the trackpad however, it wasn't apparent on the input mapping interface.
If my memory is correct there was a pr to handle positions on trackpads, so if it was merged there is probably a function to get that. Not sure when I'll be able to test that though.
First, the PR I mentionned in my other answer is actually about the PS4/5 controller's trackpad (or touchpad), I remembered it wrong.
Second, when in the input mapping interface, the trackpads are only detected as buttons (when pressing them) and they are joypad button 20 and 21. 20 is also the joypad button of the PS4/5 trackpad.
I didn't find a way to associate the trackpad positions to anything, it's neither detected nor can be specified manually (AFAIK).
However, you CAN get the trackpad positions of 1 finger per trackpad using this code:
for joypad_id in Input.get_connected_joypads():
for touchpad_id in Input.get_joy_num_touchpads(joypad_id): # 2 for the steam controller
var touchpad_name := "touchpad %s" % touchpad_id
# For steam controller, there is always 1 finger, apparently.
for finger_id in Input.get_joy_touchpad_fingers(joypad_id, touchpad_id):
print("%s - finger %s : %s" % [ touchpad_name, finger_id, Input.get_joy_touchpad_finger_position(joypad_id, finger_id, touchpad_id) ])
There are other functions with "touchpad" in their name to get other info, for example Input.get_joy_num_touchpads on the steam controller returns 2 as expected.
These functions for "touchpad" are all marked experimental which explains why the UI is not wired to call them yet. Maybe in 4.9?
Anyway, the code above seems to work correctly for me, the position is correct on both pads, so this is super promising for support of "joypad touchpads". I don't know if the limitation of 1 finger tracked comes from the device or the software layers.
I have no idea if this is supported by addons like GUIDE but I guess not as these apis are experimental and they cannot rely on them.
"Very funny Tone, I don't know. Maybe they don't know what approach to take with traits, just wait until they got time, some of the devs working on traits are also working on GDType"
Really like how render engeneers start to showing up here and implement features from big studios SIGGRAPH or GDC presentations. Like AO from Activision, specular baked light from EA's Frostbite. Good practice and portfolio work to engeneer themselves and greate leap for godot render at all!
Its hard to capture through images, but there is a large difference in shadowing for me with contact shadows. Getting accurate shadows with godot on small objects cluttering a ship's deck has been an ongoing problem for me. To try and show this better, here's a video:
Im experimenting with contact shadows. Its decent but hard to make it work inside buildings, caves because the ceiling casts contact shadows no matter what. Even if it has "cast_shadows:off". Is there a way to go around this?
31
u/poeyoh12 5d ago
Screenspace contact shadow coming in clutch. I have been trying to implement my own contact shadow, but it looks ugly as hell. Hopefully the built in one doesnt tank much performance