[HN Gopher] SDL gets an Epic MegaGrant to work on next-gen Vulka...
___________________________________________________________________
SDL gets an Epic MegaGrant to work on next-gen Vulkan API
Author : 1_player
Score : 95 points
Date : 2021-11-12 19:29 UTC (3 hours ago)
(HTM) web link (www.patreon.com)
(TXT) w3m dump (www.patreon.com)
| dandotway wrote:
| TL;DR: SDL will develop a cross-platform GPU API that is easier
| to use and Just Works. Vulkan is neither because it needs 1000
| lines to draw a triangle on screen and is so low level that
| differences between AMD and nVidia GPUs are exposed.
|
| But I'm not sure this SDL effort is a good thing. SDL has always
| been behind on fixing its bug backlog for the hard things it does
| well, like supporting so many game controllers and audio
| backends, supporting iOS and Android, etc., and other efforts at
| an easier to use 3D API that better abstracts different vendor
| GPUs have been underway for some time:
|
| - WebGPU
|
| - Godot's shading language
|
| I have always loved that SDL separates its libraries so you don't
| have to use what you don't need: if you don't need an audio mixer
| don't include SDL_mixer, etc. Hopefully those of us that don't
| need SDL 3D will still be able to skip building and including it,
| avoiding bringing in all the bugs, bloat, and complexity therein.
| Ciantic wrote:
| > is so low level that differences between AMD and nVidia GPUs
| are exposed.
|
| I interpreted it quite differently, the author writes:
|
| > there's just less knobs in general. Almost all the magic you
| want to do is done with shaders. Since these GPU APIs have a
| little programming language of their own, the GPU API itself
| doesn't have to be super powerful. It can be small, designed to
| exactly how one would control the hardware efficiently, and the
| programmer has tons of freedom, because they can get buck-wild
| in a shader with almost no limits.
|
| Which to me implies the Vulkan API is so simple, and close to
| metal, that it doesn't differ between implementations.
| asdftway1 wrote:
| > Which to me implies the Vulkan API is so simple, and close
| to metal, that it doesn't differ between implementations
|
| As someone with 20 years 3D programming experience including
| paid work in DirectX and OpenGL ES 2.0, I attempted
| vulkantutorial.com but gave up because it is too hard. It
| really is 1000 lines of C/C++ to even get a flat shaded
| triangle on screen. Vulkan has validation layers to help with
| writing conformant portable code, but the validation layers
| are written by your GPU manufacturer and so you can get
| things that pass on an Intel GPU but fail on nVidia. If
| you've ever tried porting your "portable" ISO C++ code that
| works with GCC over to Visual C++ and dealt with 1000s of
| lines of compiler errors it's kinda the same thing. Vulkan
| has shaders that precompile to "portable" bytecode but I also
| noticed that the time delay of loading these "precompiled"
| bytecode shaders was instant on one Intel GPU but took about
| 5 seconds on an nVidia GPU. The nVidia driver then cached the
| results (I know not where) so that subsequent runs were
| faster, but the cache can be invalidated by either a driver
| update or a shader update, so your game level loader will
| need an "ifShaderLoadingSlowerThanMolasses() {...}" code path
| to deal with your users experiencing slow load times after a
| video card driver update, etc.
|
| Summary: in ages past it was possible for mere mortals to
| write visualizations and simple games directly in
| OpenGL/DirectX, but with Vulkan most of us will need a
| middleware layer on top of it to get anything done within a
| deadline. If you want an open source portable solution I
| instead recommend Godot. If you want to make a 3D game that
| makes millions of dollars with less than 3 years of
| development and can deploy to Nintendos and Playstations with
| a button click I recommend Unreal Engine or Unity.
| pzo wrote:
| It seems they are going to duplicate the efforts from bgfx
| (https://github.com/bkaradzic/bgfx)
| neatze wrote:
| More like sokol-gfx header only library.
| sophacles wrote:
| So?
| young_unixer wrote:
| When I was beggining to learn game programming, I tried really
| hard to like SDL, but I just couldn't.
|
| The official documentation [1] is just an API reference. There's
| no official tutorial or getting started guide that gives enough
| context to a beginner. There's just a bunch of links to (mostly
| outdated) third-party tutorials and books and some articles
| talking about specific parts of the library, but nothing official
| that serves as a foundation to a begginer.
|
| The SDL_* subprojects ... I'm not sure if they're official SDL
| subprojects, third party projects that share the name, or
| something in between. The homepages (e.g. [2]) of these
| subprojects are totally different from the main project's, and
| their documentation is also just a listing of every function,
| without a general context.
|
| Maybe for someone who already is a professional game developer,
| SDL is just perfect, but for a begginer (like me at the time),
| it's just obtuse.
|
| [1] https://wiki.libsdl.org/FrontPage
|
| [2] https://www.libsdl.org/projects/SDL_mixer/
| adjlaksj9 wrote:
| I've also tried to learn SDL and had trouble in the past.
| Recently however I've been working with openbsd and it also
| doesnt really have a tutorial but i've found myslef productive
| by virtue of good docs that I know are there, and I think SDL
| has the same type of thing, where it takes a bit more effort to
| understand that a tutorial can feed you but once you understand
| it and how to read its documentation you can really get very
| proficient with how it and it sub-libraries work.
| IceWreck wrote:
| SDL deserves it. Its used by a lot of open source software that
| we take for granted.
| gorb314 wrote:
| Do I understand correctly? This basically means that instead of
| "Need more power? Use OpenGL."
|
| we will be able to "Need more power? Write a
| shader." ?
___________________________________________________________________
(page generated 2021-11-12 23:01 UTC)