5 ms·

I think you're missing the point.

by desine 5y ago

krapp 5y ago
I'm not missing the point, I'm just saying that in general, outside of specifically having the goal of not using any third party libraries, SDL is a good idea for a project like this.
- flohofwoe 5y ago
  IMHO SDL mostly makes sense on Linux because it hides a lot of really ugly window system and GLX setup code. On Windows (with Win32+DXGI+D3D11) and macOS (with Cocoa+Metal+MetalKit), things like setting up a window, 3D device and swap chain is just a few lines of relatively straightforward code, so SDL is by far not as useful there as on Linux.
  - DarylZero 5y ago
    SDL does a lot more than open windows. It gives _cross-platform_ graphics, audio, and input handling.
    - flohofwoe 5y ago
      ...which is also quite trivial with OS-native code on Win32 and macOS. Besides, the whole point of the OP's project is to not use separate dependencies.
      - DarylZero 5y ago
        "OS-native" implies not cross-platform. ??
- jstimpfle 5y ago
  Libraries like that might make it easier to get started, but they tend to limit what you can do. For example, I recently created a Desktop GUI app that could take inputs from a networking socket. How do you do that cleanly? There is often a way around limitations, for example by creating a separate thread, or by polling every so many milliseconds (which is ugly and a waste of resources). In my case, interfacing directly with Win32 without a 3rd party layer in between, it was easy to create an Event Object for the socket and am calling MsgWaitForMultipleObjects() in my message loop. Not sure what's a good solution to do this with SDL, but why should I even bother...
  - krapp 5y ago
    SDL can handle events and message passing just fine, but you would have to write most of that yourself either way, since it isn't a framework.
    - jstimpfle 5y ago
      How do you mean it "can handle events"? I barely know SDL, but it does not look like it is super straightforward to integrate a socket: https://github.com/libsdl-org/SDL/blob/main/src/video/windows/SDL_windowsevents.c#L1430 https://github.com/libsdl-org/SDL-1.2/blob/main/src/events/SDL_events.c#L403 https://github.com/SDL-mirror/SDL/blob/master/src/events/SDL_events.c#L769 Also, it seems to create a separate listener thread just to pump the messages, which I'm not sure I like. I could imagine SDL supports new event types by requiring the user to create _yet_ another thread, which waits for e.g. network events, then submits them to the SDL main event queue.

I think you're missing the point.

by desine 5y ago

I think you're missing the point.

I'm not missing the point, I'm just saying that in general, outside of specifically having the goal of not using any third party libraries, SDL is a good idea for a project like this.

flohofwoe 5y ago
IMHO SDL mostly makes sense on Linux because it hides a lot of really ugly window system and GLX setup code. On Windows (with Win32+DXGI+D3D11) and macOS (with Cocoa+Metal+MetalKit), things like setting up a window, 3D device and swap chain is just a few lines of relatively straightforward code, so SDL is by far not as useful there as on Linux.
- DarylZero 5y ago
  SDL does a lot more than open windows. It gives _cross-platform_ graphics, audio, and input handling.
  - flohofwoe 5y ago
    ...which is also quite trivial with OS-native code on Win32 and macOS. Besides, the whole point of the OP's project is to not use separate dependencies.
    - DarylZero 5y ago
      "OS-native" implies not cross-platform. ??
jstimpfle 5y ago
Libraries like that might make it easier to get started, but they tend to limit what you can do. For example, I recently created a Desktop GUI app that could take inputs from a networking socket. How do you do that cleanly? There is often a way around limitations, for example by creating a separate thread, or by polling every so many milliseconds (which is ugly and a waste of resources). In my case, interfacing directly with Win32 without a 3rd party layer in between, it was easy to create an Event Object for the socket and am calling MsgWaitForMultipleObjects() in my message loop. Not sure what's a good solution to do this with SDL, but why should I even bother...
- krapp 5y ago
  SDL can handle events and message passing just fine, but you would have to write most of that yourself either way, since it isn't a framework.
  - jstimpfle 5y ago
    How do you mean it "can handle events"? I barely know SDL, but it does not look like it is super straightforward to integrate a socket: https://github.com/libsdl-org/SDL/blob/main/src/video/windows/SDL_windowsevents.c#L1430 https://github.com/libsdl-org/SDL-1.2/blob/main/src/events/SDL_events.c#L403 https://github.com/SDL-mirror/SDL/blob/master/src/events/SDL_events.c#L769 Also, it seems to create a separate listener thread just to pump the messages, which I'm not sure I like. I could imagine SDL supports new event types by requiring the user to create _yet_ another thread, which waits for e.g. network events, then submits them to the SDL main event queue.