Polygons

Why does the rendering interface lack the fundamental vector
drawing routine: filled polygon?–
john skaller
@john_skaller
http://felix-lang.org

2013/7/27 john skaller

Why does the rendering interface lack the fundamental vector
drawing routine: filled polygon?


john skaller
skaller at users.sourceforge.net
http://felix-lang.org

SDL’s drawing and texture rendering routines are kept quite basic by design
(for a long time there was no way to render a rotated texture), and the
answer you’ll get is that if you want more advanced functionality, you
should use OpenGL or Direct3D. Still, every now and then some of us push
for just a little bit more of functionality in this regard, so I
guess…patches welcome? (software rendering included!)–
Gabriel.

Message-ID:
<1723D1DB-23A0-43EF-BCDD-68C350939909 at users.sourceforge.net>
Content-Type: text/plain; charset=us-ascii

Why does the rendering interface lack the fundamental vector
drawing routine: filled polygon?

I’d personally say that triangles are the fundamental routine, with
polygons being a generalization thereof, but regardless of that it is
as Gabriel said. I even scratched out a possible version for textures
(though I don’t think the rendering going to be quite as good as I
would have liked). I can shoot you the code if you want to take a
look, but I’d imagine that you can work out the math at least as good
as I did.> Date: Sun, 28 Jul 2013 00:53:34 +1000

From: john skaller
To: SDL Development List
Subject: [SDL] polygons

Why does the rendering interface lack the fundamental vector
drawing routine: filled polygon?

I’d personally say that triangles are the fundamental routine,

I imagined that to, though I’m not sure it’s quite the same if you’re
outlining (corners, etc).

with
polygons being a generalization thereof, but regardless of that it is
as Gabriel said. I even scratched out a possible version for textures
(though I don’t think the rendering going to be quite as good as I
would have liked). I can shoot you the code if you want to take a
look, but I’d imagine that you can work out the math at least as good
as I did.

The math is extremely slow filling a polygon, which is why this
routine should be in the rendering interface, because drawing
polygons is assuredly a fundamental primitive of the GPU where
it can be optimised and parallelised.On 28/07/2013, at 1:34 PM, Jared Maddox wrote:


john skaller
@john_skaller
http://felix-lang.org

Message-ID:

Content-Type: text/plain; charset=us-ascii

with
polygons being a generalization thereof, but regardless of that it is
as Gabriel said. I even scratched out a possible version for textures
(though I don’t think the rendering going to be quite as good as I
would have liked). I can shoot you the code if you want to take a
look, but I’d imagine that you can work out the math at least as good
as I did.

The math is extremely slow filling a polygon, which is why this
routine should be in the rendering interface, because drawing
polygons is assuredly a fundamental primitive of the GPU where
it can be optimised and parallelised.

Allow me to clarify: the code I wrote was for the software renderer,
so that if this function was added it would be available in all
renderers. I wasn’t expecting it to be fast, because I was assuming
that to basically be impossible. I believe that every graphics chip
that I’ve heard even an inference of since the late 90s has supported
textured triangles in some way, so the software renderer is the one
real barrier to 100% support, assuming that the function gets added.> Date: Sun, 28 Jul 2013 15:46:29 +1000

From: john skaller
To: SDL Development List
Subject: Re: [SDL] polygons
On 28/07/2013, at 1:34 PM, Jared Maddox wrote:

Allow me to clarify: the code I wrote was for the software renderer,
so that if this function was added it would be available in all
renderers. I wasn’t expecting it to be fast, because I was assuming
that to basically be impossible. I believe that every graphics chip
that I’ve heard even an inference of since the late 90s has supported
textured triangles in some way, so the software renderer is the one
real barrier to 100% support, assuming that the function gets added.

Good stuff! So now, interface to hardware renderers is the obstacle.On 28/07/2013, at 5:00 PM, Jared Maddox wrote:


john skaller
@john_skaller
http://felix-lang.org