The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.

I recall somebody here had implemented textured triangles in the SDL2
renderers (at least I know for sure the software renderer one had this
implementation). Does anybody know what happened with it? I'm willing
to give it a try (even if it'll eventually make it to 2.0.5 instead of
2.0.4), I have a good use case for it (it's some quick pseudo-3D
effect, not worth using a full blown 3D engine just for this).
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

That was me. I mostly dropped it during the summer (I've done almost
no coding over the summer, and last touched it in June), but the two
bugzilla entries (one has things that I consider more general-purpose)
are here: https://bugzilla.libsdl.org/show_bug.cgi?id=2888 and
https://bugzilla.libsdl.org/show_bug.cgi?id=2894 .

I don't recall if I ever got it to actually render a textured
triangle, but the last time I was working on it (note: I actually
haven't uploaded this yet) it was rendering triangles. I don't have a
good dev environment setup, so I've had to do printf-style debugging
(but I heartily recommend the setup I've been using for that!).

Tell me where to send it, and I'll get you the full "conglomerate" tar
that has all of the dev files, including the makefile. I also have the
old conglomerates if you want those.

Some notes:
1) It isn't written to directly interact with the renderer. Instead,
the current version is just intended to interact with surfaces.
2) Really it's intended to test the sub-divider. I'm assuming that the
eventual patch will be rewritten by someone with more experience with
the renderers.
3) I know that there are probably at least two bugs. They are:
I) I can't write surface manipulation code to sqave my life, and I
think it shows in the results.
II) I was lazy, so part of the subdivision code is virtually
guaranteed to be producing the wrong subdivision.

The basis of the subdivider is barycentric-coordinates. The subdivider
is implemented with a relative of the X-Macro pattern, which is why it
looks so odd. To re-purpose the subdivider, make a few defines and
then include the file (this is intentional, and also saves on typing).
To compile, the test setup expects the SDL headers to be in the same
directory as the code. Debug printf()s are littered EVERYWHERE.

I'll probably pick it up again (I was actually thinking about it a few
days ago), but any such "return" will likely involve the removal of
all image-manipulation in favor of just vomiting the products of the
subdivider into a text file.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Ouch then.

2015-08-28 23:34 GMT-03:00, Jared Maddox:

My first reaction: "that sucks"... but in hindsight, that makes it an
interesting way to make it work on all renderers until a proper
implementation is made for those, albeit slow (luckily one can make
SDL prefer a different renderer for the ones without implementation).


Silly question, but wasn't there a way to just use "scanlines"? Like,
determine the slopes between all vertices (X difference in each line),
then go through two slopes rastering everything between them (you get
the remaining vertex by changing one of the slopes in the line where
it happens). Then texturing is just a matter of affine transformation
(again, just delta X and delta Y, of the texels in this case).

...I'm making it sound more complex than it actually is (・～・)
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Haven't received the latest digest yet.


The bigger reason why it targets surfaces is that I understand that
the renderer's representation is pretty close to being a surface
anyways. It also makes it easier to do custom processing: the
subdivider calls a function that is specified by a define, so you can
do whatever you feel like when you receive the sub-triangle. You
could, for example, use it as a component in a CPU-side shader system
if you wanted to.


I wrote the system myself instead of waiting for someone else to do it
because I wanted to play with barycentric coordinates in the first
place .

Also, there are some nice benefits:
The barycentric coordinates of a pixel's representation on both the
source and desination surface are identical, so it's quite
straight-forward to figure out where a destination pixel's color info
comes from. Transformations happen trivially in the transition from
destination triangle to source triangle, using the same functions that
you use elsewhere.
Also, I'm under the impression that any technique involving slopes
requires some special-casing for any slope with a formula equivalent
to ? / 0. In contrast, any case in barycentric coordinates where the
equivalent of ? / 0 arises has a 0-area triangle, which shouldn't be
dealt with as a triangle anyways, so you can just discard it.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org