next »

[qMopey]

Well, I'm on your side with the allocators - those could certainly be way better. Other than that: you're wrong. Just reimplementing something because the default solution does all of it and then some, but some of which you don't need, is... silly.

I don't agree here, at least not 100% of the time. It does depend on the situation. For example, some code written in C++ that does not make heavy template or container usage is more easily portable to other languages, or bindable to scripting languages. These are just two examples where writing something smaller and simpler for a specific use-case could be better than using a pre-built "generic" alternative.

[Garthy]

I can try an example...

Thankyou for the elaboration. I'm afraid I could not personally *entirely* follow the progression from the two statements made to the examples just given, but I think I have a basic idea. From your example, I am given the impression that your main concern is that dependencies on buggy or incomplete code can cause issues if that code is later moved to a new environment, and that wrappers tend to fall into this category more than (and I'm unsure about this following bit) custom-written solutions and (maybe?) existing (non-wrapped eg. std::vector) solutions? Please feel free to correct my summary here, I don't know how accurate it is.

[JWki]

I can try an example...

Thankyou for the elaboration. I'm afraid I could not personally *entirely* follow the progression from the two statements made to the examples just given, but I think I have a basic idea. From your example, I am given the impression that your main concern is that dependencies on buggy or incomplete code can cause issues if that code is later moved to a new environment, and that wrappers tend to fall into this category more than (and I'm unsure about this following bit) custom-written solutions and (maybe?) existing (non-wrapped eg. std::vector) solutions? Please feel free to correct my summary here, I don't know how accurate it is.

I think the point is dependencies on anything from outside of the system can cause issues.

[qMopey]

I think the point is dependencies on anything from outside of the system can cause issues.

Exactly. There is a real cost to using code external to the system. This even includes template usage in the API, as templates are generating code for the user that must in the end be crunched by the linker, increasing compile times.

Avoiding dependencies is a part of creating reusable code, and very often is overlooked in favor of reusing pre-existing libraries, or an attempt to avoid rebuilding the wheel.

Using a "dependency manager" is not a solution either; that just creates a giant dependency on some kind of continually maintained system, which is basically a worst-case scenario.

[ferreiradaselva]

I don't use C++, so I don't have that problem in particular, but when I'm using a library, I will always check what are the dependencies that that library has. If it does more than what I need, I will look for something else. Sometimes, that something else that the library does slow down the development of the library itself, and by consequence slow down the development of my library. If that something else is not so portable, that makes my library less portable, too. IMO, that's planning for less trouble in the future.

[ferreiradaselva]

Meeeeeeeeeeanwhile...

I'm making a new window management library: SWFW (Simple Window Framework). I'm really good with acronyms.

https://github.com/ferreiradaselva/swfw

I had my frustations with GLFW (which I love, and I wouldn't even consider using SDL), so I decided to work on something to solve the problems that GLFW has (internal global state variable, no emscriptem support, some conflicts with different platforms).

The API I'm making takes pointers to make the context and the window:

Code:

enum swfw_status status = SWFW_OK;
struct swfw_context swfw_ctx = {0};
struct swfw_window swfw_win = {0};

status = swfw_make_context(&swfw_ctx, SWFW_BACKEND_AUTOMATIC);
status = swfw_make_window(&swfw_ctx, &swfw_win);

On Linux, both X11 and Wayland can be supported without recompilation (you just need to compile using both backends and pass `SWFW_BACKEND_X11` or `SWFW_BACKEND_WAYLAND` to the context creation function).

EVERY function returns a status. And, one of the values can be `SWFW_UNSUPPORTED`, which means that that feature is not supported on the backend you are using, thus making easy for the user to decide what to do (nor GLFW or SDL does that, they are kind silent on that).

I want to make official Emscriptem and mobile support. On those, the function `swfw_make_context` probably won't do anything, but the "hints" in the context can be used for the later creation of the window with `swfw_make_window` (for example, specifying the canvas HTML element that will be used for WebGL).

I have some rudimentary support for X11 and Wayland already.

Also, the "library" is just two files, "swfw.c" and "swfw.h".

Update:

X11 and Wayland are almost in good shape. Both using EGL for OpenGL.

I want to give optional compilation with Vulkan in the future, too. OpenGL and Vulkan are the only backends that I will make compilation-dependent (or one or the other).

[qMopey]

I’m  using SDL and really like it. Why don’t you like it? Just curious 

[ferreiradaselva]

I’m  using SDL and really like it. Why don’t you like it? Just curious 

Just for the reason on the previous post. It does much more than what I need (SDL_Image, SDL_Texture, SDL_AudioSpec). Other than that, it's pretty much like GLFW, except with those features that are not for window creation.

If I would use those features, then I would use SDL.

[Garthy]

I'm making a new window management library: SWFW

Good luck!

A couple of thoughts:

- Have considered making the context a pointer to a (possibly opaque) structure? That way you can keep the details of the implementation separate from the rest of the code easily. eg:

struct s_swfw_context;
typedef struct s_swfw_context swfw_context;

- Supporting X11 and Wayland together is pretty neat. Do you load the corresponding modules for each dynamically, or is the end system dependent on libraries for both being available? I don't know much about Wayland, so I'm not sure what the library dependencies would be.

[ferreiradaselva]

Good luck!

- Have considered making the context a pointer to a (possibly opaque) structure? That way you can keep the details of the implementation separate from the rest of the code easily. eg:

struct s_swfw_context;
typedef struct s_swfw_context swfw_context;

1. I have, but I would like to avoid dynamic allocations as much as possible. Also, that could increase the number of files. I plan to keep the whole thing in only two files :D

- Supporting X11 and Wayland together is pretty neat. Do you load the corresponding modules for each dynamically, or is the end system dependent on libraries for both being available? I don't know much about Wayland, so I'm not sure what the library dependencies would be.

Nope, I don't load the modules dynamically. That is made using the preprocessors -DSWFW_X11 and -DSWFW_WAYLAND and link against the libraries of both X11 and Wayland. The example `simple` has a Makefile that you can compile targeting one of those or both:

Code:

        CCLIBS_X11 ?= -lX11 -lEGL -lGL
    CCLIBS_WAYLAND ?= -lwayland-client -lwayland-egl -lEGL -lGL
CCLIBS_X11_WAYLAND ?= -lX11 -lwayland-client -lwayland-egl -lEGL -lGL

The last one (CCLIBS_X11_WAYLAND) you can see it's linking against the libraries of Wayland (-lwayland-client -lwayland-egl), X11 (-lX11) and EGL (-lEGL -lGL).

Of course, you can compile with only support for X11, or only support for Wayland.

[oahda]

I mainly use SDL because of its incredible portability (I have it working on six platforms, including mobile) and amazing gamepad support out of the box. It's been nice to find add-on or built-in support for things I didn't know it had until I needed them either, like networking (add-on) or dynamic library loading (built-in). But for less complex PC-only projects I can definitely see the appeal of something much lighter weight like this. Do tell when/if you're up and running on macOS!

(BTW, é um pouco divertido ver alguém com um nome lusófono escrever "Emscriptem" com -m )

[ferreiradaselva]

(BTW, é um pouco divertido ver alguém com um nome lusófono escrever "Emscriptem" com -m )

Desde quando você fala português!?!?!? E sim, eu sempre erro no "Emscriptem" hahaha

I mainly use SDL because of its incredible portability (I have it working on six platforms, including mobile) and amazing gamepad support out of the box. It's been nice to find add-on or built-in support for things I didn't know it had until I needed them either, like networking (add-on) or dynamic library loading (built-in). But for less complex PC-only projects I can definitely see the appeal of something much lighter weight like this.

If SDL didn't have those extras, I def would be using it (sdl is much more maintained than glfw). Except, the gamepad database support, that is a good extra. I should start thinking about that for my library.

Do tell when/if you're up and running on macOS!

I will definitelly need someone to test on macos!

[Garthy]

Nope, I don't load the modules dynamically. That is made using the preprocessors -DSWFW_X11 and -DSWFW_WAYLAND and link against the libraries of both X11 and Wayland. The example `simple` has a Makefile that you can compile targeting one of those or both:

One potential risk you may have: Suppose you develop an application with the finished library. Which modules do you build the application with? Make a combined build with Wayland and X11, which won't work if the Wayland libraries aren't there [1]; or two separate builds, which defeats the benefit of the dynamic choice?

You *might* be forced into dynamic loading in the future to get around this if you want to retain dynamic selection.

Something to ponder during development at least. This might not be something that you even need to solve for a while.

[1] Or X11, but you can almost assume that it is there nowadays!

[oahda]

(BTW, é um pouco divertido ver alguém com um nome lusófono escrever "Emscriptem" com -m )

Desde quando você fala português!?!?!? E sim, eu sempre erro no "Emscriptem" hahaha

Desde há uns anos! Aprendi um pouco espanhol na escola também. Eu gosto de línguas e sou… "aprendiz de tudo e maestra de nada"? O meu portunhol é ~aceitável~ mas não consigo falá-lo frequentemente. Posso falar outras línguas mais bem.

[ThemsAllTook]

EVERY function returns a status. And, one of the values can be `SWFW_UNSUPPORTED`, which means that that feature is not supported on the backend you are using, thus making easy for the user to decide what to do (nor GLFW or SDL does that, they are kind silent on that).

This sounds good for the most part, but I'd have some concerns about this bit if I were a user of this library. A feature being unsupported is something I'd really want to know about at compile time. The idea of writing a bunch of code to handle runtime errors for arbitrary functions (as you said, EVERY function returns a status) being completely unsupported on a platform seems kind of problematic. If it's all thoroughly documented and crystal clear which features are supported where and which ones aren't, it's probably fine, but I'd always have that nagging worry in the back of my mind that this function I call could fail for some reason I won't know about, and I'll need to handle an error that shows up on some user's computer that I can never reproduce myself.

For my own cross platform windowing libraries, my solution was to use a stripped-down unified API containing the common stuff that every implementation 100% supports, and each platform implementation can optionally include an extra layer of functions for things specific to that system. I do end up with some ifdefs in every application that uses this wrapper, but it's pretty minimal, and it ensures that I'm not accidentally writing something that won't run the way I expect.

[ferreiradaselva]

Desde há uns anos! Aprendi um pouco espanhol na escola também. Eu gosto de línguas e sou… "aprendiz de tudo e maestra de nada"? O meu portunhol é ~aceitável~ mas não consigo falá-lo frequentemente. Posso falar outras línguas mais bem.

Teu português é perfeito 

One potential risk you may have: Suppose you develop an application with the finished library. Which modules do you build the application with? Make a combined build with Wayland and X11, which won't work if the Wayland libraries aren't there [1]; or two separate builds, which defeats the benefit of the dynamic choice?

You *might* be forced into dynamic loading in the future to get around this if you want to retain dynamic selection.

Something to ponder during development at least. This might not be something that you even need to solve for a while.

[1] Or X11, but you can almost assume that it is there nowadays!

Yeah, that's a good point! I'll open an issue to remember that later. Currently I will keep this way, but I might add that option in the future.

EVERY function returns a status. And, one of the values can be `SWFW_UNSUPPORTED`, which means that that feature is not supported on the backend you are using, thus making easy for the user to decide what to do (nor GLFW or SDL does that, they are kind silent on that).

This sounds good for the most part, but I'd have some concerns about this bit if I were a user of this library. A feature being unsupported is something I'd really want to know about at compile time. The idea of writing a bunch of code to handle runtime errors for arbitrary functions (as you said, EVERY function returns a status) being completely unsupported on a platform seems kind of problematic. If it's all thoroughly documented and crystal clear which features are supported where and which ones aren't, it's probably fine, but I'd always have that nagging worry in the back of my mind that this function I call could fail for some reason I won't know about, and I'll need to handle an error that shows up on some user's computer that I can never reproduce myself.

For my own cross platform windowing libraries, my solution was to use a stripped-down unified API containing the common stuff that every implementation 100% supports, and each platform implementation can optionally include an extra layer of functions for things specific to that system. I do end up with some ifdefs in every application that uses this wrapper, but it's pretty minimal, and it ensures that I'm not accidentally writing something that won't run the way I expect.

I think I will add that to the references. I don't currently have a solution for that in-code. But, those cases are *special* cases. For example, if you make on desktop a border-less window, and force a drag operation when clicking on the window (think of the game keroblaster, where you move the window like that), that operation won't work if you compile for web. Another special case is Wayland on Linux, which is still under development and some features might not be available. There aren't many cases, it's usually focing stuff like force move the window, make borderless, force resize the widnow. I will update the reference to warn about which feature is available and which is not for each platform.

[Garthy]

One potential risk you may have: Suppose you develop an application with the finished library. Which modules do you build the application with? Make a combined build with Wayland and X11, which won't work if the Wayland libraries aren't there [1]; or two separate builds, which defeats the benefit of the dynamic choice?

You *might* be forced into dynamic loading in the future to get around this if you want to retain dynamic selection.

Something to ponder during development at least. This might not be something that you even need to solve for a while.

[1] Or X11, but you can almost assume that it is there nowadays!

Yeah, that's a good point! I'll open an issue to remember that later. Currently I will keep this way, but I might add that option in the future.

That sounds like a good plan. It's something to bear in mind, but not a showstopper. The workaround is also easy- just do two separate builds.

[JWki]

Did my first basic cloth sim for an assignment in uni, I think I got it to work as well as intended within the given framework.
There's some extreme jumps in the video that I'm just going to attribute to the super basic explicit euler integration that was already provided so none of my business.

[oahda]

You have to use the full youtube.com link for the embed to work. Cool! What's that constantly flickering over the screen tho?

[JWki]

You have to use the full youtube.com link for the embed to work. Cool! What's that constantly flickering over the screen tho?

Whoops, edited, thanks.

If you mean the cloth sometimes just jumping off, that's what I meant with the jumping - hoping that's due to the integration not being able to cope with the picking / turning sphere movement on and off. Although I should probably look into the latter again.