Is this library obsolete? about graphics HOT 5 CLOSED

Why would it be obsolete? Are there alternatives that have the same API?

from graphics.

Well if you say "same API" you already exclude that there could be an alternative because no library has the "same API". The reason I am asking is, to me this library looks like a pointless wrapper of SDL1 that doesn't really solve any real problem and isn't really well thought through. Here are some examples:

  PSurface* = ref Surface ## a surface to draw onto
  Surface* {.pure, final.} = object
    w*, h*: Natural
    s*: sdl.PSurface

It looks pointless to me, because it just introduce another pointer indirection. The dimensions of an SDL_Surface are direct members of it. There is really no point in duplicating that information there.

There are other issues as well. For examples here:

Font {.pure, final.} = object
    f: sdl_ttf.PFont
    color: sdl.Color

Why does this library couple a color with a font and then call the join Font. In my opinion that is just a weird design decision.

Regarding drawLine, nice addition to SDL1, but if you use a newer version of SDL, then you get it bundled: https://wiki.libsdl.org/SDL_RenderDrawLine.

Regarding >-< and >|<, didn't we already agree that introducing new operators is a bad idea that hurts code readability?

There are probably many more issues in the library. These are only the issues that I realized by briefly looking over the code. Issues that come up through using this libraries are not covered.

Of course all of these issues can be fixed one by one in a very time intensive process. But I don't think that should be the focus of nim-lang main repository.

The alternative would be a thin wrapper for SDL2 (which we already have), plus maybe SDL2_gfx for the drawing primitives (which we also already have).

SDL2_gfx has many more graphics primitives, that we don't need to maintain.

from graphics.

It's not a "pointless" wrapper it's an API that happens to only support SDL1 for now. It's really not so hard to understand it when you try to understand it instead of your common "oh, it's all different than I would like to use and see" attitude.

from graphics.

an API that happens to only support SDL1 for now

Sorry, but that improve the justification for this wrapper for me. SDL is already that API indirections, that has multiple implementations for multiple backends. Putting yet another abstraction over that abstraction is not just pointless, I think it is also harmful. Stacking as many abstractions as possible on top of each other doesn't make software more responsive and reliable.

But when I ignore all that and just judge this API as what you describe, an API that happens to only support one backend at the moment. I don't think this is really a well fleshed out API right now. From what I can tell, this looks much more like an experiment for a graphics API that you might want to use in the future, not like a well thought through API that you would really want to implement multiple backends for and support in the future.

The point is, as long as this API isn't really something with a stable, thought through and well tested API that won't be broken in the future, Raw SDL is the much safer foundation for software here. And as long as this is the case, I don't think graphcis should be listed in the official nim-lang repository. Or at least it should be tagged as experimental or something in that direction so that newcomers who don't have an opinion about how graphics programming should work stumble upon it, try it out and then fall flat because it is unfinished.

But if you think you can ignore all of this advice. You can do so. Feel free to close this issue and keep everything as it is. You are the boss.

from graphics.

Exactly.

from graphics.