Message-ID:
<1366338036.95197.YahooMailNeo at web122502.mail.ne1.yahoo.com>
Content-Type: text/plain; charset=“iso-8859-1”
The problem with that is that it forces the developer to do essentially the
same thing I’m proposing, just on their end.
It’s still perfectly fine. Any language that supports C’s qsort, C++'s
std::map, or any half-way similar functionality, will by definition
provide all of the primitives needed to actually implement a solution
to this. It’s not a big deal once they recognize that they need a
sorted data structure. If SDL provided a generic C-language tree
implementation then it would certainly be more convenient to everyone,
but that’s a minor thing.
If you have a scene with a bunch of sprites in it, they’re most likely not
ordered by texture, and certainly not grouped by texture.? That’s not a
natural way to set it up, and not something someone’s going to do unless
they’re specifically trying to do what I’m trying to do here.? Which means
that at draw time, at some point, someone somewhere has to translate the
list of what’s being drawn into some sort of structure that’s grouped by
texture–such as a multimap.
I’ve written 3d code that does the job. Depending on the complexity of
your modelling, you can do this in C++'s standard containers in as
little as ~50 lines of code (and that’s a very-ballpark estimate, I
use a lot of whitespace in my code).
As long as “group by texture” has to be done one way or another in order to
get the performance benefits we’re talking about here, why force it to be
outside of the API and require every developer to reinvent the wheel??
That’s what libraries are for, isn’t it?
You know, perhaps I’m confusing you with someone else, but I seem to
remember you wanting to rip OUT portions of SDL. Now you’re trying to
add in parts that the rest of us consider only partially appropriate,
DESPITE already having been told that it requires a forbidden API
change?> Date: Thu, 18 Apr 2013 19:20:36 -0700 (PDT)
From: Mason Wheeler
To: “sdl at lists.libsdl.org”
Subject: Re: [SDL] External dependencies in the renderer?
Date: Fri, 19 Apr 2013 09:00:09 -0700
From: “Nathaniel J Fries”
To: sdl at lists.libsdl.org
Subject: Re: [SDL] External dependencies in the renderer?
Message-ID: <1366387208.m2f.36714 at forums.libsdl.org>
Content-Type: text/plain; charset=“iso-8859-1”
Grouping is what is actually needed, but grouping without considering order
effectively negates order, so SDL must either group and order or do
neither.
I proposed earlier a spritebatch mechanism for SDL which would do all this
internally, but it was suggested that this be an extension library; however
to even implement that in a non-hackish manner, SDL would still need to
provide an interface for rendering the same texture multiple times.
For that matter, if the “multi-render” function were added then that
would be enough for my “buffering-render” suggestion to be implemented
with an external library. It’s a really straightforward optimization,
and doesn’t need to break the API.