Announcement

Collapse
No announcement yet.

SDL 2.0.22 Released With New APIs, Continued Wayland Work

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • SDL 2.0.22 Released With New APIs, Continued Wayland Work

    Phoronix: SDL 2.0.22 Released With New APIs, Continued Wayland Work

    SDL 2.0.22 is now officially out as the newest version of this widely-used library by multi-platform games and other software for abstracting various input, graphics, and other system details...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Originally posted by phoronix View Post
    floating point rectangle functions,
    I thought SDL_FRect and SDL_RenderCopyF were a thing since 2.0.1x?

    Comment


    • #3
      Originally posted by tildearrow View Post

      I thought SDL_FRect and SDL_RenderCopyF were a thing since 2.0.1x?
      Hmm, I often find myself coupling it with glm (in particular vec4).

      So val.z is width and of course annoyingly val.w is height

      Comment


      • #4
        > new APIs sought after by developers for returning the renderer associated with a window

        You... what?

        Someone's gonna have to explain that one to me. If you don't know what renderer your window's using, you've got a problem; and if it's not your window, it's not your business.

        Short of some kind of hack for third-party code I can't think of any good reason for this, and even then I'd expect the library/whatever to either implicitly match because it was built to be used in that project in the first place; or to be told at the time you init it / give it a window handle.

        Overlays, maybe? Whatever the cause, this looks bizarre enough to be interesting somehow.

        Comment


        • #5
          Originally posted by tildearrow View Post

          I thought SDL_FRect and SDL_RenderCopyF were a thing since 2.0.1x?
          They were, but this adds the previously missing SDL_FRect calls corresponding to the rest of the SDL_Rect API (intersections, union, point-in-rect, equailty/empty checks, etc) which makes it easier to switch everything to FRect.

          Comment

          Working...
          X