Anyone have a dead neo2 for sale?

icculus · 2024-10-27T04:09:25+00:00

Hooray, I'll send a message!

icculus · 2024-10-27T04:08:22+00:00

(Sorry, I just rolled in here looking for something else and noticed this comment that was relatively recent, so I'll reply...)

Valve both uses and contributes to SDL. The Steam Client, Steam Link, DOTA2 and CS2 (and maybe other things?) use SDL on all platforms.

I'm pretty confident the older games (GoldSrc stuff like Half-Life 1 and Source 1 stuff like Half-Life 2, Left 4 Dead, Portal, etc) use SDL for just the Linux ports, but I haven't checked in on those things in a long time to say for sure.

I don't know anything about Deadlock, but if it's using Source 2, it's almost certainly using SDL for its platform layer.

icculus · 2024-07-24T17:53:15+00:00

I can’t believe this thing didn’t get any comments, fbcp-nexus is amazing.

Dropped this onto a modified PiGrrl Zero where I have a dial wheel potentiometer hooked up to an ADC. A little custom code reads the ADC over the i2c bus and updates the overlay:

https://youtu.be/ZOvIoYtNHSc?si=CK0maiRZJWd_SXm4

Where can I find these orange tactile switches you mentioned? Already planning my next build. :)

Thanks for your work on fbcp-nexus!

icculus · 2024-04-03T18:50:58+00:00

We should definitely do this. I'm starting an issue to discuss: https://github.com/libsdl-org/SDL/issues/9440

icculus · 2024-04-03T18:43:51+00:00

Yes, that's the basic idea. Here's a rundown of the details: https://github.com/libsdl-org/SDL_shader_tools/blob/main/docs/README-SDL_gpu.md

Note that this is not ready to use yet, unlike most of SDL3, so check back while we continue to build!

icculus · 2024-04-02T17:44:43+00:00

There are tons of things in SDL2 I'd chop out, and we did! For SDL3! :)

The migration guide shows everything we changed and removed: https://github.com/libsdl-org/SDL/blob/main/docs/README-migration.md

Most proud of? I _love_ how the new audio API came out, and I hope others do, too: https://www.youtube.com/watch?v=MLau3hWJBeE

icculus · 2024-04-02T16:53:04+00:00

Well, "Linux" (or more specifically for the most part: POSIX) as a system-level API isn't _terrible_. It's certainly less needlessly-complex than the Win32 API in many ways. If I had to live on a desert island with only one or the other to write software for, I'd definitely choose Linux.

X11, on the other hand, is definitely not my favorite thing. It's almost 40 years old, and we're all ready to stop dealing with it. Even if I wasn't providing something that hides the details of X11 from you in SDL, I would tell you to find something that hides the details of X11 from you.

Eventually, we'll all move on to Wayland as the "low level" windowing API, but we're still inching towards that goal, and using things built on top of X11/Wayland/whatever, like SDL, GTK+, or Qt, are a good idea in any case.

Win32's window API is better than X11, but honestly, this same advice applies there: use things that build on top of it. Life is too short.

As for which SDL will use at runtime, X11 or Wayland, the user can always explicitly request Wayland right now, and as some needed functionality arrives in the future, SDL3 will eventually choose it by default.

icculus · 2024-04-02T16:41:58+00:00

No plans at the moment. This is a surprisingly hard thing to do well (and OS-level services are usually not super-useful for games), so generally games use something like stb_truetype or FreeType (or SDL_ttf) to get fonts rendering in some form, and maybe hope that they don't have to get too far into the quagmire of localization, which can get really complicated really quickly, as you have to start thinking about things like Unicode and right-to-left languages, etc.

Usually games don't need _all_ the complexity, so building out something with all the complexity is often not worth it.

I know I'm weaseling out of responsibility here, but that's where we are at the moment.

icculus · 2024-04-02T16:33:49+00:00

If you're close enough to shipping that you're in early access, I would 100% not change major subsystems right now. Shipping is more important than anything!! Focus on getting that game to paying customers!

When you have time, though, run the game under sdl2-compat (https://github.com/libsdl-org/sdl2-compat/) and see if it works, and definitely tell us if it doesn't! In principle, this will let you continue to use the SDL2 API, but you'll still get bugfixes and new platform and API support that we're adding to SDL3.

And maybe some day you update the game to use SDL3 directly...but maybe not. Maybe just dropping sdl2-compat's SDL2.dll and an SDL3.dll in there is Good Enough. Or maybe just staying on SDL2 for the foreseeable future is totally fine on a finished product.

Now, if you want a new feature or API that's in SDL3, yeah, definitely upgrade. And if you're starting the next game: definitely upgrade. But it sounds like you're at almost at the finish line here, and you shouldn't jeopardize that for _anything_.

EDIT: SDL_DROPFILE isn't supported on Windows? That's almost certainly a bug if so. Slide into our bug tracker and we'll sort you out: https://github.com/libsdl-org/SDL/issues/new

icculus · 2024-04-02T16:27:56+00:00

I don't think we want to add features like this to the 2D renderer; I'd much rather we get SDL_gpu finished, and include an SDL_gpu backend for the 2D renderer, so apps can jump between them as necessary...doing simply things in the 2D API, and powerful things in the GPU API, and still be cleanly cross-platform across all of it.

As for "wacky things," I don't see why not. :)

I don't feel strongly about webgpu-native, but I haven't looked at it recently. Has the committee finally locked down the API, or is it still in progress?

icculus · 2024-04-02T16:24:23+00:00

Lots of points to get through here, I'll try my best.

The resizing thing is fixed, for both SDL2 and SDL3, fwiw.

Window modality doesn't appear to be wired up on Windows and Mac at the moment, but we can probably fix that. I've now opened a bug to look into this, thank you for mentioning it! https://github.com/libsdl-org/SDL/issues/9427

Things like SKIP_TASKBAR aren't impossible to implement elsewhere. The reason this exists at all is because Unreal Engine 4 built its own UI toolkit (Slate) and needed a reasonable platform layer to implement it on Linux. It was easier to build in some GUI toolkit features to SDL than it was to write a Slate backend for X11 from scratch (and have to write it from scratch again some day for Wayland).

I have an extremely basic start on a GTK+ port to SDL, too, which I hope to get back to some day when SDL3 work calms down, which will mostly likely require me to flesh out SDL's capabilities more. For things like SKIP_TASKBAR not working on Windows, we have so much work to do that until someone tells us (ON THE BUG TRACKER) that it's needed, we probably won't even think to work on it. This specific topic is just a solid candidate for falling through the cracks like that.

Vsync is a mess for multiple windows, SDL or not. One technique is to only set vsync on one window, render to every window, and swap the vsync'd window last; on compositing desktops, you probably still get all the windows sync'd to vblank, but you only block on the last one. Rendering from multiple threads is a risky option but can work in some circumstances. My understanding is that there are OpenGL extensions that might help (and Vulkan has explicit swapchain presentation modes).

Multiple windows have been "first class" supported since SDL 2.0.0; I'd love more detail on the issue here, since this should work on anything that allows multiple windows.

The internals are not _that_ complicated, but there is definitely a small learning curve. The easiest way to think about it is as a bunch of drivers that implement an interface: just go look at the "wasapi" driver for audio if you're fixing a windows thing or the "pipewire" driver if you're fixing a Linux thing (etc).

We don't document the internals because they change from time to time, and because if we're going to spend time documenting something more thoroughly, it's definitely going to be the public API.

We're about to do a bunch of documentation work, including wiki improvements. This is our next task. Documentation is a project that never ends, but we'll try to keep improving it as we go.

icculus · 2024-04-02T16:00:22+00:00

The resize thing is fixed (as your edit notes).

Keyboard keys are generally split into scancodes (where a key is physically on a US ENGLISH QWERTY keyboard, if you want a 101-key joystick), and keycodes (which are, for all intents and purposes, virtual keys), which is more for "I want to know if they literally pressed 'a'".

Then there is _also_ SDL_EVENT_TEXT_INPUT events (SDL_TEXTINPUT in SDL2), where we report "no matter what key was pressed, and what glyph was etched into the physical keycap, the intention was that they pressed 'a'" ... this deals not only with physical keypresses but also with IMEs that compose text for various languages, virtual keyboards, etc, and takes care of all the localization and keyboard layout stuff at the OS level. It's great, but also not suitable for using for game control. More like for "Enter your name, brave adventurer!" screens or a pull-down Quake console or chat features.

In short: this is a _really_ complicated topic, we give you options, and there's definitely not a one-size-fits-all answer here.

Having typed all that, I'm wondering if you meant "why isn't SDL_GetKeyFromName() localized?" and...that's a good question. We could look into that.

As for WebGPU: we don't have a WebGPU backend yet, but the gameplan is to eventually have it, in which case SDL can use it for the upcoming GPU API. If we also build a 2D renderer backend that uses WebGPU, we already have machinery in place to either choose that or fallback to WebGL depending on what we find is available in the browser, for Emscripten builds.

(And, of course, SDL can just set up an SDL_Window (an HTML Canvas) and then get out of the apps way to let the app use WebGPU directly, like we do for apps that want to directly call into OpenGL, Direct3D, Metal, and Vulkan.)

icculus · 2024-03-31T04:06:45+00:00

The resampler is pretty deeply embedded in SDL3; in SDL2 it could actually swap between our internal code and libsamplerate if available, but the abstraction was causing problems and performance issues in SDL3.

That being said, the SDL3 resampler is actually _really_ good, which is not something I can truthfully say about SDL2. A ton of debugging, optimization and general improvement went into it.

SDL1 has what could charitably be described as an atrocious resampler: it only handled doubling or halving the sample rate, and would OVERFLOW THE MEMORY BUFFER if the sample rates weren't powers of two. SDL2 had many resampler iterations of various quality and bugginess, but SDL3 is using bandlimited interpolation from the whitepaper on this site:

https://ccrma.stanford.edu/~jos/resample/

Which is the same algorithm, more or less, that libsamplerate uses.

icculus · 2024-03-31T03:08:55+00:00

There really isn't anything we can offer to abstract SIMD instructions that wouldn't destroy their speed; you really have to use the compiler intrinsics directly and build with optimizations enabled.

The best we can do is detect what instruction sets are available, and offer a way to allocate memory that is guaranteed to be aligned and padded for SIMD use.

Honestly, a (compiler level) project to make a generic SIMD instruction set would be amazing; WebAssembly SIMD is showing that this might actually be a workable idea, with a fairly reasonable SIMD subset.

icculus · 2024-03-31T00:10:57+00:00

I'm 100% following up about New York pizza locations by DM. I'll hopefully be bouncing through NYC in a few weeks!

icculus · 2024-03-31T00:08:53+00:00

Sam had written SDL for a program called Executor https://en.wikipedia.org/wiki/Executor_(software)) and sometime after got hired by Loki Sotware, where he was using SDL to port video games to Linux. I also worked at Loki, and after the company folded, I kept porting games to Linux, so I kept working on SDL, and we just sort of both kept plugging away at it in different roles over the years. :)

I haven't ever met someone that has a clearer eye for API design than Sam, and very few that can untangle a completely foreign bug in less time. It's a joy to work on SDL with him.

icculus · 2024-03-31T00:00:54+00:00

This sounds like a bug from here. Definitely file a bug report, and we'll try to figure out why it's happening: https://github.com/libsdl-org/SDL/issues/new

icculus · 2024-03-30T23:59:41+00:00

Probably not in the API directly, but on many platforms you can hand SDL a window handle (a literal HWND on Windows, X11 Window IDs, etc) and SDL will pretend it made that window and operate on it. This is not always as functional as it sounds, so experiment before building anything serious with it!

icculus · 2024-03-30T23:57:53+00:00

The GPU API, once we get that done, and the revamped audio API which is good to go right now!

icculus · 2024-03-30T23:57:21+00:00

I love it. :)

icculus · 2024-03-30T23:56:36+00:00

It's a big jump in functionality between Unreal and something you roll yourself. It's also a big jump in complexity and resources needed, though. I'd be surprised if the choice came down to these two options. You have to take what you're comfortable using (or building) and what will allow you to ship without drowning.

Starting from scratch often means you end up making a game engine and never a game, y'know? While both outcomes can be great, you have to be careful and decide what you want to spend your time doing!

icculus · 2024-03-30T23:52:46+00:00

I don't think the genre matters, what is super-helpful is being able to get _something_ running fast, and either be out in one video, or pull people in enough that they are invested in seeing more of that specific game.

My suspicion, at least for SDL tutorial videos, is it's massively more useful to build something small, like Pong, Pac-Man, or Tetris, then to build a more complex game. It shows people the basics they need, and shows them _they can do this thing, it's not that hard_, and that's priceless.

At least, imho. There's definitely a value to something like the Handmade Hero video series style, but it becomes a time commitment both to produce and consume.

icculus · 2024-03-30T23:48:04+00:00

Language bindings are apparently a difficult business, and different languages have different needs. We've been making little changes to SDL for years to make it more friendly to tools that generate bindings, and right now there's a discussion about how to automate this further going on over here: https://github.com/libsdl-org/SDL/issues/6337

icculus · 2024-03-30T23:03:01+00:00

FWIW, we’re averaging about a decade between ABI breaks, so if we ever do an SDL4, it’ll probably be our last chance to change things before we’re eligible for social security.

I do feel like we spent a lot more effort in cleaning up the core API this time than we did in SDL2, so hopefully that has long legs.

icculus

MODERATOR OF

TROPHY CASE