# Hw filled polygons & hw lines \[was Re : XFillPolygon() replaceme nt?\]

**URL:** <https://discourse.libsdl.org/t/hw-filled-polygons-hw-lines-was-re-xfillpolygon-replaceme-nt/3568>\
**Category:** SDL Development\
**Created:** [December 4, 2000, 11:25am UTC](https://discourse.libsdl.org/t/hw-filled-polygons-hw-lines-was-re-xfillpolygon-replaceme-nt/3568 "2000-12-04T11:25:44Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Dominique\_Biesmans](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/d/8797f3/32.png) [@Dominique\_Biesmans](https://discourse.libsdl.org/u/Dominique_Biesmans)\
**Post date:** [December 4, 2000, 11:25am UTC](https://discourse.libsdl.org/t/hw-filled-polygons-hw-lines-was-re-xfillpolygon-replaceme-nt/3568/1 "2000-12-04T11:25:44Z")

</div>

> [snip]  
> Speaking of which, since filled polygons are frequently accelerated,  
> I was considering adding it to the SDL API for post-1.2, along with  
> drawing line segments. Nothing decided yet though

Filled polygons are often accelerated, yes, but only in a 3D context. I’m  
wondering how things API wise will evolve when 3D stuff is pulled in…  
Unless you’d layer _everything_ on top of a 3D API (e.g. blitting a surface  
would be done by drawing a textured quad), I think it will be hard  
(impossible?) to offer hw accelerated polys & lines in a portable way …\> -----Original Message-----

> From: Mattias Engdeg?rd [mailto:f91-men at nada.kth.se]

---

<div class="post-metadata">

**Author:** ![Mattias\_Engdegard](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/m/49beb7/32.png) [@Mattias\_Engdegard](https://discourse.libsdl.org/u/Mattias_Engdegard)\
**Post date:** [December 4, 2000, 12:43pm UTC](https://discourse.libsdl.org/t/hw-filled-polygons-hw-lines-was-re-xfillpolygon-replaceme-nt/3568/2 "2000-12-04T12:43:20Z")

</div>

> Filled polygons are often accelerated, yes, but only in a 3D context.

It’s not uncommon on workstations, but I’m not really at home with PC  
hardware (which I presume you are talking about) so you may be right  
about that. A friend claims the voodoo3 has a 2d polygon primitive,  
but that it was deemed too buggy to be used in the XFree server.

Solid lines should be present even on mere PCs, so maybe it merits an  
API. It does not have the highest priority though

---

<div class="post-metadata">

**Author:** ![David\_Olofson](https://discourse.libsdl.org/user_avatar/discourse.libsdl.org/david_olofson/32/115_2.png) [@David\_Olofson](https://discourse.libsdl.org/u/David_Olofson)\
**Post date:** [December 4, 2000, 12:51pm UTC](https://discourse.libsdl.org/t/hw-filled-polygons-hw-lines-was-re-xfillpolygon-replaceme-nt/3568/3 "2000-12-04T12:51:55Z")

</div>

Mon, 04 Dec 2000 Dominique Biesmans wrote:\> \> -----Original Message-----

> > From: Mattias Engdeg?rd [mailto:f91-men at nada.kth.se]  
> > [snip]  
> > Speaking of which, since filled polygons are frequently accelerated,  
> > I was considering adding it to the SDL API for post-1.2, along with  
> > drawing line segments. Nothing decided yet though
> 
> Filled polygons are often accelerated, yes, but only in a 3D context. I’m  
> wondering how things API wise will evolve when 3D stuff is pulled in…  
> Unless you’d layer _everything_ on top of a 3D API (e.g. blitting a surface  
> would be done by drawing a textured quad), I think it will be hard  
> (impossible?) to offer hw accelerated polys & lines in a portable way …

3D is where serious work is spent on APIs and fast drivers - the rest is “just  
for buttons and text”, and no one seems to care enough to even make sure that  
there is a real API for 2D acceleration. Many cards have _great_ 2D  
acceleration, but I have yet to see a single API/driver combo that takes  
advantage of more than a fraction of it.

“Ok, so 3D acceleration is widely available and supported; lets use that  
instead!” Yeah, but… 3D APIs are meant for 3D, and the same goes for the  
hardware. On a practical level, that means you have to deal with power-of-two  
texture sizes, no “clean” way of passing 2D geometry to the card and similar  
limitations. Sure, a 2D API on top of a 3D API is doable, but most existing 2D  
APIs do things that are not compatible with 3D APIs, and they do things in ways  
that are not suitable for 3D APIs from an efficiency POV.

Still, I’m interested in a _serious_ accelerated 2D API (for games, mainly),  
and I’m thinking about ways to build it on top of OpenGL. I’d be interested in  
discussing design issues, experiences, ideas etc, although I can’t say when  
I’ll be able to put serious hacking time into this project.

To begin somewhere, here’s what I’m looking for, basically:

```
* Speed
* Sub-pixel accurate sprites and scrolling
* High quality rendering w/ rotation and other transformations
* Speed
* Fast blending and transparency
* Massive parallax scrolling fields
* Speed
* 16 and 24 bit color
* Speed

```

Basically, I want to get a little bit closer to what 2D graphics should be  
today, considering what 3D looks like. (Look at Quake III Arena on a decent  
machine, and then have a look at the majority of 2D games, including those that  
requrire massive CPU for smooth animation. Something is wrong here…)

Of course, this should be done using a nice API that lends itself to h/w  
acceleration (using OpenGL, Glide, …, or dedicated drivers), as well as  
software rasterizing engines. 🙂

//David

…- M A I A -------------------------------------------------.  
| Multimedia Application Integration Architecture |  
| A Free/Open Source Plugin API for Professional Multimedia |  
`----------------------> http://www.linuxaudiodev.com/maia -' ..- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter | `--------------------------------------\> david at [linuxdj.com](http://linuxdj.com) -’