Accelerated 2D APIs

Alright, let’s get to the point.

What kinds of things could be incorporated into SDL in a platform-indep.
way, and more importantly, which of these should be? For example, I’m
thinking I would really like to have a function to draw a line using only
integer math (it can be done, and fast!) so everyone can just do things the
fast way without the hassle.

Something as generic as drawing lines (and maybe specifying colors at the
two endpoint to interpolate between : ) and ellipses could be useful in a
great many libraries/applications, as it could very easily accelerate all
kinds of drawing functions (I’m thinking GUIs here). OTOH I think some sort
of scrolling-tiling background library might help a few people, but might
not generalize too well, and I can see how it might quickly become an
overbearing project in itself. (I also think there’s room for disagreement
here, of course.)

Anyways, I was really curious to hear what sorts of 2D functions people
really really want/need, and which actually have a chance of making it into
the SDL, rather than some supporting library. In fact, I bet there’s a lot
of this already out there… Anyways, I cast my vote for the straight lines
with vertex coloring, using only integer math (I’m easy to please. : ).

Any input, Sam?

  • Brent

What kinds of things could be incorporated into SDL in a platform-indep.
way, and more importantly, which of these should be? For example, I’m
thinking I would really like to have a function to draw a line using only
integer math

SDL is mainly a lib to give you access to the hardware and get out of
the way; if you want drawing primitives that aren’t hardware-accelerated,
put them in a separate library. Straight solid lines might go into SDL,
if it can be shown that it’s worth the trouble

What kinds of things could be incorporated into SDL in a platform-indep.
way, and more importantly, which of these should be? For example, I’m
thinking I would really like to have a function to draw a line using only
integer math

SDL is mainly a lib to give you access to the hardware and get out of
the way; if you want drawing primitives that aren’t hardware-accelerated,
put them in a separate library. Straight solid lines might go into SDL,
if it can be shown that it’s worth the trouble

So has anyone looked into writing such a library (say, SDL_draw) without,
say, overburdening it with GUI actions? (ie: just a pure drawing library)

I’m thinking this is duable and that under Windows, MacOS, BeOS (maybe),
X, OpenGL and fbcon this could be accelerated for lines and maybe other
primitives as well…

g

G’day, eh? :slight_smile:
- Teunis

PS: me, I could write the software form of this but there’s lots of such
libraries floating around… libART and such as an example. I just work
with fbcon, opengl and X so…On Sat, 9 Dec 2000, Mattias Engdegard wrote:


Teunis of Northurrokheim, of the Free Company of Northurrok
Humbly Proud Member of the Musketeers of m’lady Ovidia of Vingaard.

Member in purple standing of the Mad Poet’s Society.
Trying to bring truth from beauty is Winterlion.
find at this winterlions’ page

Alright, let’s get to the point.

What kinds of things could be incorporated into SDL in a
platform-indep. way, and more importantly, which of these should
be? For example, I’m thinking I would really like to have a
function to draw a line using only integer math (it can be done,
and fast!) so everyone can just do things the fast way without the
hassle.

Yes, indeded. OpenGL based 2D acceleration (and similar) is really
only for full screen, high frame rate animation of games with heavy
graphical effects - and it inherently means that you’ll have to deal
with a more complex and specialized API to achieve usable. This API
would be even more specialized if it’s to be portable to other
rendering targets, such as software and virious accelerated 2D APIs.

Something as generic as drawing lines (and maybe specifying colors
at the two endpoint to interpolate between : ) and ellipses could
be useful in a great many libraries/applications, as it could very
easily accelerate all kinds of drawing functions (I’m thinking GUIs
here). OTOH I think some sort of scrolling-tiling background
library might help a few people, but might not generalize too well,
and I can see how it might quickly become an overbearing project in
itself. (I also think there’s room for disagreement here, of
course.)

Well, OpenGL seems to cope with most sorts of real time 3D engines

  • which is the kind of code that needs OpenGL. I think it should be
    possible to design a similarly flexible API for 2D animation.

The lack of a definite distinction between 2D and 3D rendering
suggests that perhaps one should simply use OpenGL directly for more
advanced 2D games, but then again, the OpenGL API doesn’t lend itself
very nicely to software acceleration of what the average 2D OpenGL
game would use it for… (That is, an API dedicated to advanced 2D
games could more easily be implemented efficiently in software than
could the OpenGL API, as the former could be designed to make it
easier for the implementation to see where simple 2D blits can be
used instead of 3D blits.)

Anyways, I was really curious to hear what sorts of 2D functions
people really really want/need, and which actually have a chance of
making it into the SDL, rather than some supporting library. In
fact, I bet there’s a lot of this already out there… Anyways, I
cast my vote for the straight lines with vertex coloring, using
only integer math (I’m easy to please. : ).

As to the things I’m initially thinking of when considering to use
OpenGL for a 2D game, that would actually be things that are still
plain 2D operations:

* Color key blits (sprites)

* Additive blending

* Alpha blending

And then some for extreme CPUs or h/w acceleration:

* Sub-pixel accurate blitting

* Scaling

* Rotation

Finally something that perhaps indicates that one should switch do
OpenGL…

* 3D transformations

As I see it, the fundamental point with a new API for "advanced 2D"
would be to enable advanced games that would normally use OpenGL to
run nicely on machines w/o h/w acceleration, although with lower
resolutions and lower quality effects. OpenGL is a high level 3D API,
and thus unsuitable for this, as it’s not nicely scalable down to the
level of 2D blits on the rasterization level. If nothing else, it
adds too much overhead for a low end machine that has to do the
blitting with the CPU as well…

//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 -'On Saturday 09 December 2000 11:07, Brent Schartung wrote:

What kinds of things could be incorporated into SDL in a
platform-indep. way, and more importantly, which of these
should be? For example, I’m thinking I would really like to
have a function to draw a line using only integer math

SDL is mainly a lib to give you access to the hardware and get
out of the way; if you want drawing primitives that aren’t
hardware-accelerated, put them in a separate library. Straight
solid lines might go into SDL, if it can be shown that it’s
worth the trouble

So has anyone looked into writing such a library (say, SDL_draw)
without, say, overburdening it with GUI actions? (ie: just a pure
drawing library)

I’m thinking this is duable and that under Windows, MacOS, BeOS
(maybe), X, OpenGL and fbcon this could be accelerated for lines
and maybe other primitives as well…

I’m thinking along these lines, although more in the sprite/tile
blitting direction. Various advanced primitives, such as antialiased,
blended lines with color scales and the like are still of interest,
though.

g

G’day, eh? :slight_smile:

  • Teunis

PS: me, I could write the software form of this but there’s lots of
such libraries floating around… libART and such as an example.
I just work with fbcon, opengl and X so…

A software implementation would be required anyway, as that, as I see
it, is one of the major points with this new API. If the new API was
designed as a toolkit for OpenGL, we might as well write our code
directly for OpenGL, leaving people without acceleration out in the
cold.

//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 -'On Saturday 09 December 2000 20:51, winterlion wrote:

On Sat, 9 Dec 2000, Mattias Engdegard wrote:

Brent Schartung wrote:

Alright, let’s get to the point.

What kinds of things could be incorporated into SDL in a platform-indep.
way, and more importantly, which of these should be? For example, I’m

In my case, I’d like to see really fast blitting rutines to different
bpp’s, like PTC does, so, I can calculate a frame in 32bpp depth,
without care the user display.–
signed
derethor of centolos

Brent Schartung wrote:

Alright, let’s get to the point.

What kinds of things could be incorporated into SDL in a platform-indep.
way, and more importantly, which of these should be? For example, I’m

In my case, I’d like to see really fast blitting rutines to different
bpp’s, like PTC does, so, I can calculate a frame in 32bpp depth,
without care the user display.

Well, remembering my past experience with GGI (since pretty much it’s
inception actually and even somewhat before :), they got into a
blitting-acceleration engine at one point. I wouldn’t be surprised if
it’s still there - perhaps that would be a good place to look?
(I stopped paying attention to GGI about ummm beginning of this year
because I needed opengl acceleration…)

G’day, eh? :slight_smile:
- TeunisOn Mon, 11 Dec 2000, Derethor wrote:


Teunis of Northurrokheim, of the Free Company of Northurrok
Humbly Proud Member of the Musketeers of m’lady Ovidia of Vingaard.

Member in purple standing of the Mad Poet’s Society.
Trying to bring truth from beauty is Winterlion.
find at this winterlions’ page

In my case, I’d like to see really fast blitting rutines to different
bpp’s, like PTC does, so, I can calculate a frame in 32bpp depth,
without care the user display.

Well, remembering my past experience with GGI (since pretty much it’s
inception actually and even somewhat before :), they got into a
blitting-acceleration engine at one point. I wouldn’t be surprised if
it’s still there - perhaps that would be a good place to look?
(I stopped paying attention to GGI about ummm beginning of this year
because I needed opengl acceleration…)

Actually, the PTC and SDL routines are (were?) very similar in speed.
SDL uses the same core assembly routines as the Hermes blitting library,
and it’s C routines have been heavily optimized for the kinds of blitting
SDL applications do, including converting between 8/16/32 bpp formats.

See ya,
-Sam Lantinga, Lead Programmer, Loki Entertainment Software

Mon, 11 Dec 2000 Derethor wrote:

Brent Schartung wrote:

Alright, let’s get to the point.

What kinds of things could be incorporated into SDL in a platform-indep.
way, and more importantly, which of these should be? For example, I’m

In my case, I’d like to see really fast blitting rutines to different
bpp’s, like PTC does, so, I can calculate a frame in 32bpp depth,
without care the user display.

Seems like h/w acceleration is the best bet, if you want to do that fast. (You
really need to write pixel format specific code if you want speed on lower
end systems; nothing much to do about that. PC h/w is a mess - game consoles
rule…)

Anyway, if you for some reason want to do 32 bpp software rendering, you
probably need quite some CPU in the first place. (If we’re talking about full
screen animation, that is - can’t see a problem with animation of smaller
areas.) That is, there most likely will be MMX or similar SIMD extensions,
which are quite usable for this kind of stuff - in case the video card can’t do
conversion when blitting textures. (Some cards can’t, and some cards don’t even
accelerate anything to do with 32 bpp at all… This goes for most of the
Voodoo cards, for example.)

OpenGL would probably be the most portable and best supported way of getting
to any usable features of this kind.

Ok, so why go for h/w acceleration in the first place?

Well, the idea is to make use of the existing OpenGL drivers in order to get
around this “VRAM access” disaster. Many drivers seem to use DMA for
downloading textures, which could mean that there actually is a way around
the CPU -> PCI/AGP bottleneck. A nice one with various bonus effects at that. I
have yet to try it, though…

//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 -’