Seems the steam app steals the input. If I close steam I got it working. But not with the gamepad functions, only with the joystick functions. Have something super hacky working now which is good enough at the moment :) #glfw #steamdeck

Anyone gotten working gamepad input on Steam deck using glfw? Updated mappings but even the joystick test in glfw do not work correctly. #glfw #joystick #SteamDeck

Made my GLFW-base OpenGL game-engine build work for Wayland...

... I guess there something more I am missing, as the resulting windows doesn´t show anything meaningful. :P :D

#gamedev #indiedev #glfw #wayland

Trying to compile GLFW from withing my game-engine for Wayland, over the usual X11 support. Not that straight-forward as one could hope...

... and I don't even know what to expect in case I succeed! :P :D

#gamedev #indiedev #glfw #wayland

example demo of external model loading in real time. Or as I like to call it: "Scene Appending"

#CustomEngine #OpenGL #GLFW #Collada #CPP #ImGUI #rendering

My first window with #GLFW and #Zig (linking the C library).

It was super easy, barely and inconvenience!

Just adding these 3 lines to the build.zig file, and copying the header files (+ a little bit of tweaking because macOS and OpenGL).

❤️

Both #SDL2 and #GLFW are filled to the brim with missing APIs and functionality that the other has. I pray some day we can just merge them or something...

It's almost comical:

GLFW misses an event to notify you of keyboard layout changes, SDL2 misses an API to meaningfully query the keyboard layout.

GLFW has broken OpenGL vsync on macOS, SDL2 has broken OpenGL vsync on Windows.

Not in the mood to go on further. I guess I'll probably file an issue on the SDL2 GitHub tomorrow.

Discovering that #SDL2 doesn't have any API for getting proper key labels like #GLFW does and I'm very annoyed right now.

On this macbook, the key below escape (left of 1) is § and ± (shifted). GLFW correctly prints this for glfwGetKeyName(), but SDL2 doesn't have any API like this at all. Both of SDL2's APIs (SDL_GetKeyName and SDL_GetScancodeName) simply return hardcoded names that match 1:1 with the enum names. SDL2 says the name of § is ` (grave), which is actually a different key...

Guess I'm gonna try to push through on making #SDL2 the default windowing API for SS14 on macOS, bye #glfw.

Still a few TODOs on the SDL2 backend I wanna get rid of though. Also I can finally properly integrate dynamically update shown keybinds in game when the keyboard layout changes, since SDL2 actually has an event for that!

(I get to partially resurrect that cursed unmerged commit where I made that work on GLFW Win32 with WNDPROC subclassing: https://github.com/space-wizards/RobustToolbox/commit/3b788e94c0339496f5245ed39c098f1f3c02af2c)

Due to some idle time and new suggestions IceBro Lite is now at version 1.06

IceBro Lite is a debugger for #Commodore64 programs that connects to VICE #C64 3.6 or later.

Available here: https://github.com/Sakrac/IceBroLite/releases/tag/v1.06

* Updated to latest #dearImGui and latest #GLFW
* Watch values can individually be switched between hexadecimal, decimal or binary
* Selected style is saved
* New style added (picture)
* Bug fixes

shoutout to the Rendering Cookbook - already paying off by solving a bug where imgui wasn't receiving mouse clicks.

had to use a #GLFW callback to sync with the #imgui I/O (which was an example in the book😁)

finally got things in a stable place. new template is up using #GLFW for window, #DX12 for backend, #imgui for UI. now we can play

#GameDev #DirectX #GraphicsProgramming

https://github.com/whoisryosuke/dx12-starter/tree/triangle

Now it's my time for #introduction.

Hi! I am a game developer, but I haven't any demos to show, just have some ideas and projects on the early stages. I started my gamedev journey at the beginning of this year by changing my prevoius work, where I spend almost 7 years as system engineer. Now I work remote at small gamedev company located in Cyprus as junior C++ developer. And I'm kind of like it. It's much more intersting to me.

In 2020 I started my own project a visual novel game engine that uses #OpenGL, #GLFW and #OpenAL. And I have an idea for one #visual_novel game that I want implement on that engine someday.

I know about microblogging, I have twitter account, but I never was an everyday user. So I might be that kind of users here and may not post toots as much as other users do. I came here to learn new thing about gamedev and may be find some new friends.

And there is a one thing I want to mention, I'm not good english speaker, because it's not my native langauge. I'm really sorry about misspells

It seems it is not possible to prevent window resizing with #GLUT/FreeGLUT.
Let's try #GLFW.

Spent an hour fighting #cabal #sandbox and got my #haskell #bytebeat #genetic #algorithm project to work with the current versions of things on #hackage.

It was a lot easier once I realized I no longer needed #gtkglext which I had already replaced with #glfw in the main code base

Still not packaged up nicely, not sure how to distribute code that has Haskell as well as #C executables, and runtime dependencies on GCC. So far it's just a Makefile.

https://code.mathr.co.uk/bitbreeder

I ported the graphgrow user interface to #android using #glfm for touch UI instead of #glfw on the desktop version. it steals the main loop, but that wasn't too much trouble to work around. minor changes to the other callbacks, too, nothing too hard.

I had intended to use the #debian packaged android tools, but I couldn't get them to work at all. probably due to me not having a clue. maybe I'll revisit that once I've finished v1 of the graphgrow ui app (want some network status display in case of errors)

what was a major headache was getting liblo for #osc to compile and link with my code in Android Studio, eventually I gave up and just listed the sources in my CMakeLists to compile it statically, instead of doing it cleanly as a reusable shared library (.aar with native .so might not work anyway?).

this meant I needed to manually set a few configure substitutions in some header files, namely making endianness autodetected at compile time instead of at configure time, and disabling the threaded server include (because it broke things for me), and setting a printf macro for long long int.

there was one very small bug/issue in liblo when compiling for android, which is needing to replace index() by strchr() in one location (which it already does for Windows, don't know why it isn't used on all OS).

this user interface broadcasts data over #OSC to a video rendering program, also C++ with #OpenGL and #GLFW, which renders a graph-directed iterated function system using texture array feedback. there are 4 buffers each of which pulls data from the others, with histogram equalization to prevent the colours getting too bright or dark.

it runs fine on my new GPU at very high quality settings, but I'll be using my old desktop for this, so I need to check how hard i can push it without the frame rate dropping too much. the code is instrumented with timer queries, so i can see which parts of the OpenGL code are the bottle-necks.

some optimisations i could activate if necessary include building the histogram from a smaller mipmap level, or only doing that every few frames instead of every frame. quality may suffer, the main thing is to avoid strobing artifacts because they're very distracting and the rest of the visual has a calm feel to it.

old GUI was very powerful but also very complicated, and not so intuitive to just start playing around - it also started from a blank canvas, so to get it to do anything you have to 1. click "add node", 2. click a couple of times in the empty space in the middle, 3. click "add link", 4. drag some links between the nodes in the middle, 5. and only after all of that is there any output. and to get the output interesting you have to add nodes and links in all 4 workspaces (selectable on the left) and "mod link" them to switch the colours up

so this morning I worked on simplifying it a great deal. now there are no multiple modes, the only things you can do are select workspaces and drag nodes. the graph topology is preset to something nice, and when you leave it alone the nodes gradually drift back to their preset starting positions. it's still possible to get it in a state that doesn't generate good output, but much easier to get out of those states.

need to adjust the colours a bit, maybe a pastel background would be better than dark.

this is written in C++ with #OpenGL via #GLFW but I need to port it to run on my #android tablet - ideally before xmas so I don't panic near the deadline...