library
Message-ID: <20150104210604.GC20976 at amaya.spiritsubstance.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Simply put, SDLâs renderer as written cannot reasonably do several
things that are trivial for 2D games, at least one of which I
intended to port to SDL2 at one point only to discover that it
couldnât handle it. The issues in question were circles, lines, and
flat and filled polygons. (Original used turtle-style graphics(!),
so a port would involve a thin state machine?)
When I proposed adding stuff to SDLâs renderer thatâd do
this?something I could do for software, trivially with a shader for
GL/GLES 2+, and with a little effort for GL/GLES 1.x, but would need
someone who knows the API a little better to help me translate to D3D
people absolutely SCREAMED their opposition. The API is frozen! I
never intended to change it, only add. You canât do curves in GL
1.x! Yes, you can, if you know a little math. Itâs not possible to
add any features to the renderer because itâs just TOO HARD to
maintain them and NOBODY EVER can produce results for all the
different renderer targets!!! Um, nobody necessarily has to know
every single API, provided that somebody who knows each one is
prepared to contribute that bit. Oh and finally, THE RENDERER IS
OBSOLETE CRUFT!!! YOU CANâT BLOAT THE LIBRARY ANY MORE!!!
Tell me about it. I stopped working on a software-renderer
textured-triangle implementation because I was under the impression
that Gabrielo (I might have misspelled that) was going to get one in
(about a year ago, or maybe even two), and I canât find any sign of
any version in the current Mercurial source.
Though admittedly, I might have opposed circles on the basis of âtoo
easyâ or something. Or maybe used âthe height of 1980âs rendering
technologyâ to support textured triangles. I forget which.
And what about software rendering?! Shock, horror! Yeah, the
algorithms for that are older than the majority of the people
freaking out about it. Theyâre optimized, produce excellent results,
and they just work well.
Shoot, who cares about optimized? Softwareâs a fall-back, so I say
that we should hold no fear of 15-FPS (or maybe even 2-FPS) algorithms
for the software renderer. I scratched out my textured triangle
algorithm on the basis of barycentric coordinates, and as I recall
didnât find anything that directly talked about the subject (it worked
too, except that I apparently canât render to a pixel buffer to save
my life; Handmade Hero has made me suspect that I was AT LEAST writing
color channels to the wrong destinations, which would explain some of
the color artifactsâŚ), the only bits that I recall being incomplete
were corner cases (specifically related to color blending: I did not
take the fast route).> Date: Sun, 4 Jan 2015 13:06:04 -0800
From: âT. Joseph Carterâ
To: SDL Development List
Subject: Re: [SDL] Adding features to SDL vs creating a satellite
Date: Sun, 4 Jan 2015 14:20:25 -0800
From: âT. Joseph Carterâ
To: SDL Development List
Subject: Re: [SDL] Adding features to SDL vs creating a satellite
library
Message-ID: <20150104222025.GD20976 at amaya.spiritsubstance.com>
Content-Type: text/plain; charset=utf-8; format=flowed
No time for a proper reply, so Iâll make it quick.
What would be neat is compiling in a satellite library and initializing it
through SDL_init, ie:
SDL_Init( SDL_VIDEO | SDL_NET | SDL_GPU );
This is a bad idea. Youâll get different groups trying to use the same
value, thereby making satellite libraries incompatible with each
other.
Iâm going to just agree with that one.
Or you could kind of keep it as-is described above, in which case
this idea of baking extensions into SDL becomes more about some build
system consideration to allow libraries to be built as standalone
(the Linux distribution probably preferred way of doing it, though
Iâd advise doing it that way generally by default) and perhaps some
sort of hook in library and SDL to allow you to build them as one.
My biggest problem with the whole idea, admittedly, is that my concept
of how this SHOULD work in order to preserve SDLâs dll-swapability
jive with yours, but I DONâT see how itâs supposed to get along with
the impression that SDL_Init( SDL_NET ) gives me.
If you really want to initialize satellite libraries through a
conventional SDL function then add something like this:
int SDL_StringInit( char* );
It would take a string naming the sub-system, and return a result,
just like the other init functions. This completely avoids the
problem.
Again, Iâll note my preference is for this to be how itâs done, if
anything. But again if itâs just a matter of namespace, itâs purely
an aesthetics discussion. If itâs about building together, then I
donât know why you must compile two libraries into one pretty much
ever.
I agree, but I also worry that it might be done in a poorly-conceived
fashion. Hence the suggestion.
If itâs about extensions having deeper access to the core of
SDL so that say, SDL_gpu could extend the razzin-frazzin render API
rather than an alternative of limited usefulness, then maybe the REAL
issue is that it should be possible to do that somehow with the
system as it is designed today?
Continuing with the renderer discussion for just a moment, say you
were to create one using Appleâs Metal API for iOS. Itâs not ready
to go in to SDL proper yet. So do you maintain a fork of SDL, or
could you maybe just call a function to tell SDL that hey, hereâs a
new renderer for you!
Iâve talked on the list about this sort of thing before. I think that
youâd ultimately want to slightly modify (at least some of) the
existing structures, but basically only so that you can include a
"version" field at the very start. After all, internals are
implementation details, so they should basically be EXPECTED to
change.
A render plugin that I think it would be useful to support is
basically anything network-centric. There are, for example, XServer
systems for Windows, but since they arenât standard SDL doesnât
support them⌠and probably SHOULDNâT. However, I personally think it
would be at least convenient to be able to use an extension library to
add such a backend (or even better, a "duplicate to network"
extension: perfect for both stores and competitions). With the current
setup, all that you can do is provide a custom dynamic library.
Another nice one would, of course, be something to allow you to adapt
the standard renderers to YOUR specifications. I donât know exactly
how that would work, but I assume a conceptual inspiration from
DOS-era TSRs (no, I wasnât programming at the time, I just found an
old book and read it a decade or more ago).
Hey, just because I constantly mock C++ and hate the language (more
accurately its backward-incompatible revisioning) doesnât mean I fail
to recognize when Bjarne did something useful even by accident.
I personally believe that thereâs only a few things (all inherited
from C) wrong with C++ that couldnât be fixed by taking the list of
features and redesigning the language from scratch⌠including
swapping out those template angle brackets with parentheses WRAPPING
angle brackets (how many years of parser errors could that simple fix
have avoided? And goodness knows thereâs no sensible way to parse a
meaning out of such a construct in C, so it wouldnât step on any valid
toes⌠-_- ).
Fixing C++ while keeping it as C++ though⌠yeah, I donât think
thatâs sensible.
But is that really necessary, aside from maybe making how SDL-using
extension libraries get built somehow âstandardâ and theoretically
able to be built as many different ways as SDL itself can be? Even
that seems kind of crazy-making, because SDL itself supports a lot of
random build systems. Multiple MSVC versions, a couple of XCode
versions, autoconf with God only knows what vaguely standard UNIX
build environment, CMake theoretically like 2.8 or so(?), premake,
and possibly more not coming to mind just now.
Is that desired for every single random library, by the people
producing those libraries I mean? I donât have ANY version of MSVC,
and frankly I donât really want it either. I could dig up an old OS
X 10.7 or even 10.6 to shove in a VM for those versions of XCode, but
should I? And while I like the concept of CMake, its execution I
find woefully inadequate. I havenât got the first clue about premake
but it doesnât really interest me.
I can see the possible value of providing a quasi-imake so that
programmers can get fairly reliable support for conditionals in
makefiles (Microsoft, BSD, and GNU all do it, and they all do it
DIFFERENTLY), and maybe a simple scripting-tool to read a file and run
the quasi-imake on a list of targets described within it. Both a C
preprocessor and a Make variant can trivially be found for most (maybe
all?) platforms (even Microsoft ships one with MSVC: apparently they
use it to build Windows). What I suggest would be limited (no looping,
for one), but it provides intermediate to advanced makefile use in a
simple way.
My preference is simply to use autoconf/automake. Not because I LIKE
either one, nor because I think either one is terribly efficient or
even necessarily good at what they do. But because I can set up a
basic build tree to start a new project in about a minute thanks to a
handy over-glorified shell script built for the job, and it works on
every desktop OS I might ever build for including Windows. Mobile
dev Iâve not really gotten into yet.
Plus, as ugly as it is, judicious use of the poorly utilized ability
to modularize your configure.ac file and some planning of your build
tree makes configure.ac and Makefile.am into essentially what CMake
promised regarding a readable, maintainable build description. Sadly
itâs not possible to match CMakeâs promise of a self-contained one
simple thing that works everywhere (and even CMake has failed to
deliver the â, and works wellâ that should follow?), but nobody else
has done any better.
The result is that if you NEED something else (XCode for iOS maybe),
you only need to read through a relatively short/sweet list of things
to be checked for in configure.ac so that you can set up your build
system accordingly and produce the requisite config.h, and then look
at Makefile.am for a list of what source files to build. You could
almost automake the latter if other build systems followed any kind
of documented standard and remained backward compatible from version
to version.
What I would personally like is a build AND package-manager system (I
consider the two categories to strongly overlap) inspired by the
autotools system, but implemented as an
Actor-Oriented-Programming/LPMud-Object system in the form of a C
library (itâs C, so if someone doesnât like the language they can just
implement a wrapper). That would be too big a project to shoehorn into
SDL, though.
In fact, if I could get pass by reference, exceptions, and thin
support for object types in the base C language, thatâd be kind of
neat if they didnât screw it up. My suggestion would be to look at
things that already implement objects in pure C and examine the stuff
that requires ugly #define macros to accomplish, and start there.
But thatâs getting off topic fast.
And in my eyes passing arrays by value instead of by pointer, but you
quickly get into magic hidden variables, so better to leave that to
something else. Ah well, back to the topic.
Date: Sun, 4 Jan 2015 16:26:34 -0500
From: Alex Barry <alex.barry at gmail.com>
To: SDL Mailing List
Subject: Re: [SDL] Adding features to SDL vs creating a satellite
library
Message-ID:
<CAJSO58NcW9p+HoNY_L3HB-J10pp+fa2aVYEWhQuyCubJbon3rA at mail.gmail.com>
Content-Type: text/plain; charset=âutf-8â
Can we stay on topic, please?
I donât know how my threads usually go off the rails like this, but I want
to make it clear, Iâm not talking about adding features or breaking ABI
stuff.
What Iâm suggesting is implementing hooks for libraries that would highly
encourage a consistent and structured way for SDL satellite libraries to be
written, and making it easier for main SDL developers to include new
features if they sprouted from satellite libraries.
Actually, that IS adding a feature: SDL isnât designed to do that
right now. Also, the email that you quoted provided a point in favor
of the âAddâ side of the equation, thus it is on topic.
In case it wasnât clear, several of us consider SDL to be SMALLER than
it should be at the moment, NOT larger, and have been discussing these
additions because we consider their omission HIGHLY ill-advised.
Init variables would be addressed in the merging process/code review, and
would not have conflicts unless we have terrible build testing, but it
seems the build bot would catch that in the worst case scenario.
I consider this to be inherently wrong, for the simple reason that it
requires SDL admins to be involved with external code. A system to
make it easier for satellite libraries to augment SDL should be fine,
but anything that requires direct involvement from SDL developers
should be considered a no-go (among other things, a well-designed
system may be highly useful for customizing SDL to individual
machines⌠but such customized versions should NOT be expected to be
shared projects).
Date: Sun, 4 Jan 2015 19:28:16 -0300
From: Sik the hedgehog <sik.the.hedgehog at gmail.com>
To: SDL Development List
Subject: Re: [SDL] Adding features to SDL vs creating a satellite
library
Message-ID:
<CAEyBR+VbooCRDMfg+Vfdjj6kuyo_HSc4nNxMU8Bs5OOf8jY1nQ at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Itâs not just the renderer API though, itâs the entire SDL thatâs
like that. Every time anybody ever suggests the possibility of adding
something nearly everybody will scream to not add it to SDL and to
maybe put it into its own separate library (often ignoring the
existing ones as well, ironically). Itâs like people want SDL to be
frozen forever and the only development to be bugfixes.
Actually, I remember it just being a vocal few: Alex for example, as
demonstrated by this very thread. More common were cries that someone
should implement the neglected versions first (which is why I was
working on software-renderer textured-triangles for a while: the
software renderer was the neglected platform for those).
I think this is pretty much the purpose of this whole thread, to see
how we move forwards, because as it stands, if it was up to the
mailing list SDL should be completely frozen. Normally Sam or Ryan
would get in and take a decision settling the whole matter, but lately
they donât seem to be around here (vacation?).
Maybe, but just as likely other job duties. I donât know if I even
heard where Ryan works, but I assume that Valve did NOT hire Sam to
only work on SDL.
Date: Mon, 5 Jan 2015 04:26:14 -0300
From: Sik the hedgehog <sik.the.hedgehog at gmail.com>
To: SDL Development List
Subject: Re: [SDL] Adding features to SDL vs creating a satellite
library
Message-ID:
<CAEyBR+U3cskUYQPXU836u9jNwiz_c8rFLhvaqcT9cugFVFGb4A at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
To be fair the problem with the renderer is that we canât tell what is
its internal state, nor what API is it using. I suppose that if you
could override the renderer functions that would help - sounds like
defeating the whole point at first, until you realize that it makes
sense when you start adding third-party libraries that make use of the
renderer.
While exposing the internals of all of SDL could potentially end up
being a mess, being able to specify your own renderer could be useful
I suppose.
Youâre basically talking about a version id number, and some functions
in a separate header file (because you probably only care about this
stuff if youâre writing an extension library, if youâre just using one
then an init or pre-init function + whatever functions the library
exposes for ITâS functionality should be enough).