Blit performance

Hey, I’m feeling like an idiot. I downloaded sdl_net
and guilib. sdl_net is setup and working fine(the
server compiles and runs with no errors). Anyways I’m
trying to compile the client demo, but the linker is
giving me unresolved external symbol errors. Is there
a dll or lib file I need? Or did I fail to add a
needed .cpp file to my project? I’m using VC6.

Thanks
Herbert=====
Game Programming Groups
VS Entertainment(Houston game dev group, looking for members)
IGP(Internet game programming group, looking for members also)
Ask me for details…


Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com

you will find some ideas with this one (used on Linux).

to use it:

./make

to clean everything:

./make clean

Jocelyn.
“mgirard” a ?crit dans le message news:
mailman.1014213664.26729.sdl at libsdl.org

Hello All,

  Does someone can send me a "Makefile" example ?

  I don't have any time to send on this!  A
  default Makefile should be fun for beginner. . .
  (e.g. a default makefile with many SDL_libs in
  it, so when you need to use SDL_image, you open the
  makefile and uncomment the SDL_image section ...)

  I'm using SDL, SDL_image, SDL_mixer, and
  perhaps SDL_ttf (for later uses)(I think it's ttf...).


  Thx!

  I'm back ;)


Best regards,
mgirard mailto:mgirard at microtecsecurite.com
dawn check http://dawn.linux-site.net soon
closed for now . . .

begin 666 Makefile.dat
M05!07TY!344@/2!B=6QL90H*(T-&3$%‘4R ]("0D*’-D;“UC;VYF:6<@+2UC
M9FQA9W,I"DQ)0E,@/2 M;%-$3&UA:6X at +6Q31$P at +6QP=&AR96%D”@HN4U5&
M1DE815,Z+F@+F,"E-20R ](’-Y<W1E;2YC(&=A;64N8PI/0DH@/2!S>7-T
M96TN;R!G86UE+F*“BYC+F@. at H)9V-C(” D
BYC("UC("UO("0J+F@( H*
M)"A!4%!?3D%-12D at .B D*$]"2BD*"6=C8R D*$]"2BD at +6@)"A!4%!?3D%-
M12D@)"A,24)3*2 "7)M("UF(“HN;R @”@IB86-K(#H"7)M("UF(“HN;R *
98VQE86X at .@H)<FT at +68@*BYO(&)U;&QE”@``
`
end

Hello Bille2,

Monday, February 25, 2002, 4:27:42 PM, you wrote:

B> you will find some ideas with this one (used on Linux).

B> to use it:

B> ./make

B> to clean everything:

B> ./make clean

B> Jocelyn.
B> “mgirard” <@Mathieu_Girard> a ?crit dans le message news:
B> mailman.1014213664.26729.sdl at libsdl.org

Hello All,

  Does someone can send me a "Makefile" example ?

  I don't have any time to send on this!  A
  default Makefile should be fun for beginner. . .
  (e.g. a default makefile with many SDL_libs in
  it, so when you need to use SDL_image, you open the
  makefile and uncomment the SDL_image section ...)

  I'm using SDL, SDL_image, SDL_mixer, and
  perhaps SDL_ttf (for later uses)(I think it's ttf...).


  Thx!

  I'm back ;)


Best regards,
mgirard mailto:@Mathieu_Girard
dawn check http://dawn.linux-site.net soon
closed for now . . .

B> _______________________________________________
B> SDL mailing list
B> SDL at libsdl.org
B> http://www.libsdl.org/mailman/listinfo/sdl

Thx!!!–
Best regards,
mgirard mailto:@Mathieu_Girard

I suggest you read through the ‘video’ section of the documentation,
seeing what each function does. It shouldn’t take more than an hour,
and should give you a much better understanding of what you need to
do to improve performance.

…and 800x600 @ 32-bit is going to be slow on hardware accelerated
surfaces, too. If you need this, use OpenGL, but more likely, you don’t
need it.

If there’s going to be any real time scrolling and/or other heavy
animation going on, OpenGL will be required to achieve pleasant looking
results. There’s no other way currently, to get that smooth arcade feel.

I feel like a broken record.

So do I… heh

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Wednesday 20 February 2002 06:23, Ryan C. Gordon wrote:

[…]

Are some people
interested in helping making an OpenGL 2D backend for SDL, which would
fully take advantage of hardware acceleration?

Well, that’s glSDL - although it’s still in the form of a source level
wrapper, rather than a backend. Most of the code is there, though.

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Wednesday 20 February 2002 08:42, Alexandre Courbot wrote:

Are some people
interested in helping making an OpenGL 2D backend for SDL, which
would fully take advantage of hardware acceleration?

Alex.

Count me in. :slight_smile: I have a lot of 2D OpenGL experience (if I may say so
myself :).

I don’t have all that much experience with OpenGL in particular, but I
seems to get by… (Lots of low level 2D experience from the Amiga and
DOS days. :slight_smile:

I would only be interested in this if it were to be built into SDL
itself though.

Same here - although I hacked glSDL without knowing what it would
actually become. Still don’t know if it’s actually going into SDL, in any
form.

An auxilliary library like SDL_opengl2d would just not
do for me.

Right. Looking at how the glSDL wrapper “hides” the glue needed to
interface normal surfaces with “glSDLized” surfaces should make you even
more convinced - especially considering that the alternative is wrapping
SDL_Surface and all SDL calls that take SDL_Surfaces as arguments…
heh (Well, that’s actually what glSDL does, although it’s done with an
ugly bunch of #defines. That mess would of course go away if the code was
turned into a rendering backend.)

So when an OpenGL display mode gets initialized, all SDL hardware
surfaces should be created as 2D textures and blits would be done with
textured quads. Software surfaces should stay in system memory and be
copyed into textures when blitting.

That’s exactly what glSDL does - although it also tiles surfaces to fit
them into the smallest possible textures. (It will eventually support
tiling a surface into multiple textures as well.)

In a non-OpenGL display mode everything should of course function as
normal, with DirectDraw / X11 / and the rest.

glSDL does that as well, as an extra bonus. :wink:

But perhaps such a system is already planned for SDL 1.3?

Dunno, but glSDL already exists. In the near future, you won’t even have
to dig into the Kobo Deluxe source tree to find it! :slight_smile:

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Wednesday 20 February 2002 13:57, Dirk Gerrits wrote:

----- Original Message -----
From: “Alexandre Courbot”
To:
Sent: Wednesday, 20 February, 2002 8:42
Subject: Re: [SDL] blit performance

[…]

So when an OpenGL display mode gets initialized, all SDL hardware
surfaces should be created as 2D textures and blits would be done
with textured quads. Software surfaces should stay in system memory
and be copyed into textures when blitting.

Exactly. You could also take advantage of accelerated alpha-blending,

glSDL does that…

or apply anti-aliasing to the final rendered image.

Now, that’s really hard to get right. I know some ways to do it in an
OpenGL application, but I don’t think it’s at all possible to get right
without extra info from the application.

The problem is the edges of images… Clamp? Wrap? Smooth? “Leak” from
the edge of some other surface?

The answer is that it depends on how the image is used in the game.

Of course, there is FSAA - but I can’t really see how it would apply here

  • in fact, you even have to disable interpolation to get correct
    results!

Needless to say how
fast it will be with a good video card.

It is indeed! :slight_smile:

Someone reported KoboDeluxe doing several hundred fps even in the higher
resolutions, on some GeForce card. Even my G400 (*) can sustain more than
playable frame rates in 640x480 and higher.

(*) which is a pretty slow card, actually - but it still beats the crap
out of all other cards I’ve seen WRT high resolution signal quality.
I have yet to see another card capable of driving a high end monitor
in resolutions higher than 1600x1200. nVidia chips suck in that area -
real bad at that!

In a non-OpenGL display mode everything should of course function as
normal, with DirectDraw / X11 / and the rest.

Right. Problems might occur if the programmer uses OpenGL functions
along with the OpenGL backend, maybe. But I’m not even sure myself.

Well, that could be solved, but it would involve pushing/popping the
matrix around every single OpenGL accelerated SDL call… Maybe provide
an optional flag to enable that, or add function calls to explicitly
switch between SDL and OpenGL “modes”? (The latter would be much more
efficient.)

But perhaps such a system is already planned for SDL 1.3?

No idea. I don’t even know whether plans for 1.3 started or not.
Anyone?

David Olofson once made a quick hack to use OpenGL rendering within SDL
for his Kobo Deluxe game. It’s not exactly a backend, as it’s included
with Kobo sources and redefines some SDL functions in practise. But it
worth a look anyway. You can get Kobo source at
http://olofson.net/skobo/. Then try ./configure --help for the args to
pass to use the hack. (SDL must be built with OpenGL capability of
course). He mentions it here:
http://www.libsdl.org/pipermail/sdl/2001-December/040562.html (the rest
of the thread is quite interesting, too)

If we could start hacking this around, it would be nice.

Well, it’s already LGPLed, so…

Would be
better if we could have someone who knows a bit SDL’s internal
structure, as it’s not documented as far as I know. And we’d have
to mess with SDL’s guts to make it a backend.

Yeah. That’s the major reason why I haven’t done it already.

So, interested?

I’ll help, of course. :slight_smile:

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Wednesday 20 February 2002 14:37, Alexandre Courbot wrote:

[…]

That’s what I have in mind too. Making OpenGL a backend (or target)
just like X11, svgalib or fbcon.

Well SDL itself chooses between those backends. The OpenGL 'backend’
should be
somthing that the programmer will choose.

Yes - but it has to be possible to force unknowing applications to use it
as well. That’s actually one of the very points with making it a backend,
as applications that explicitly ask for OpenGL would perhaps be better
off using OpenGL directly.

Ok, it is easier to add an option and a flag than adding native OpenGL
rendering support to a game, but SDL-on-OpenGL won’t give you anything
but speed! No new blending effects, no transformations, no antialiasing,
no sub-pixel accuracy… Nothing but very fast opaque, colorkey and
alpha blits. (Probably sufficient motivation in itself, but anyway…)

Why? Well SDL can’t know
beforehand
whether you are doing 2d blits along with actual pixel access or just
2d blits.
The former would be a lot faster in X11, DX, etc., the latter would be
much better
off in OpenGL.

Right. (Under OpenGL, “pixel effects” should be done through alpha
blended procedural textures instead.)

So I think the current SDL_SetVideoMode( width, height,
bpp, SDL_OPENGL | moreflags ) interface should remain intact.

Yes. (glSDL uses a flag SDL_GLSDL to actually engage the OpenGL code.)

So when an OpenGL display mode gets initialized, all SDL hardware
surfaces
should be created as 2D textures and blits would be done with
textured quads. Software surfaces should stay in system memory and
be copyed into textures when blitting.

Exactly. You could also take advantage of accelerated alpha-blending,
or apply anti-aliasing to the final rendered image. Needless to say
how fast it will be with a good video card.

Yes, this is what I am doing in one of my unfinished games. I get over
700 fps
on my system with lots of sprites with alpha blending and rotation and
everything.
If this idea makes it into SDL 1.3, I can’t imagine how awesome it
would be.

:slight_smile:

It would be cool indeed - but it requires quite a few API changes, most
of which will only work with OpenGL or DirectX - or dog slow software
emulation…

If you want that kind of stuff, use OpenGL directly. It’s easier, faster
and doesn’t bloat the SDL API.

[…]

But Sam Lantinga, the author of SDL, hangs around this mailinglist as
well, so he’s bound to join the discussion sometime. :wink:

Actually, it would be kind of nice to get an official comment on this. Of
course, I might have missed something - but I still don’t know whether
I’m just wasting my time, or not…

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Wednesday 20 February 2002 15:16, Dirk Gerrits wrote:

But Sam Lantinga, the author of SDL, hangs around this mailinglist as
well, so he’s bound to join the discussion sometime. :wink:

Actually, it would be kind of nice to get an official comment on this. Of
course, I might have missed something - but I still don’t know whether
I’m just wasting my time, or not…

True. It’d be interesting to know what Sam thinks about this. I don’t
know if such a backend can make it smoothly in the 1.2 branch (a few
operations would be very slow, but the others advantages largely make
the balance), but maybe this can help driving 1.3 design. As far as I
know (not very far then ;)) no work as been done yet for 1.3. Me thinks,
it’s never too early to discuss API details! :slight_smile: IMHO, 1.3 should be
designed for speed, and allow easy support of hardware-accelerated
targets. This is what users are wanting today.

Alex.–
http://www.gnurou.org

But Sam Lantinga, the author of SDL, hangs around this mailinglist
as well, so he’s bound to join the discussion sometime. :wink:

Actually, it would be kind of nice to get an official comment on
this. Of course, I might have missed something - but I still don’t
know whether I’m just wasting my time, or not…

True. It’d be interesting to know what Sam thinks about this. I don’t
know if such a backend can make it smoothly in the 1.2 branch (a few
operations would be very slow,

Actually, only “direct” access of the frame buffer is very slow -
blitting from it, or whithin it won’t be slower than for any display with
a true h/w display surface.

but the others advantages largely make
the balance), but maybe this can help driving 1.3 design.

Yes. Locking specific areas of a surface (especially the screen surface)
would be the most important feature.

Some kind of alternative interface for write-only software rendering
effects would also be nice, as that would make it possible to take
advantage of the fact that you don’t need to read from the frame buffer
to implement them.

As far as I
know (not very far then ;)) no work as been done yet for 1.3. Me
thinks, it’s never too early to discuss API details! :slight_smile: IMHO, 1.3
should be designed for speed, and allow easy support of
hardware-accelerated targets. This is what users are wanting today.

Yes - and I think it’s important to consider the integration of h/w
acceleration and s/w rendering. It’s possible to do with APIs like
DirectX and OpenGL, but only if the application really does it “by hand”.
The APIs are unhelpful, at best.

Having an API that smoothly integrate these different ways of rendering
would really give SDL an edge compared to other APIs - especially if it
stays as nice and clean as the current SDL API.

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Saturday 02 March 2002 13:15, Alexandre Courbot wrote:

But Sam Lantinga, the author of SDL, hangs around this mailinglist as
well, so he’s bound to join the discussion sometime. :wink:

Actually, it would be kind of nice to get an official comment on this. Of
course, I might have missed something - but I still don’t know whether
I’m just wasting my time, or not…

True. It’d be interesting to know what Sam thinks about this. I don’t
know if such a backend can make it smoothly in the 1.2 branch (a few
operations would be very slow, but the others advantages largely make
the balance), but maybe this can help driving 1.3 design. As far as I
know (not very far then ;)) no work as been done yet for 1.3. Me thinks,
it’s never too early to discuss API details! :slight_smile: IMHO, 1.3 should be
designed for speed, and allow easy support of hardware-accelerated
targets. This is what users are wanting today.

Once it’s cleaned up, I’m happy to add it to the SDL 1.2 branch.
However, I’m torn on whether to enable it by default. It certainly would
be handy for many applications, but not all applications will be faster,
so you would need to benchmark it for your purposes. In addition, I
probably won’t add a dynamic link requirement for the OpenGL library, so
that adds a whole other ball of wax.

Anyway, David, once you’ve cleaned it up, I’ll be happy to add it as an
optional backend.

See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment

But Sam Lantinga, the author of SDL, hangs around this
mailinglist as well, so he’s bound to join the discussion
sometime. :wink:

Actually, it would be kind of nice to get an official comment on
this. Of course, I might have missed something - but I still don’t
know whether I’m just wasting my time, or not…

True. It’d be interesting to know what Sam thinks about this. I don’t
know if such a backend can make it smoothly in the 1.2 branch (a few
operations would be very slow, but the others advantages largely make
the balance), but maybe this can help driving 1.3 design. As far as I
know (not very far then ;)) no work as been done yet for 1.3. Me
thinks, it’s never too early to discuss API details! :slight_smile: IMHO, 1.3
should be designed for speed, and allow easy support of
hardware-accelerated targets. This is what users are wanting today.

Once it’s cleaned up, I’m happy to add it to the SDL 1.2 branch.
However, I’m torn on whether to enable it by default. It certainly
would be handy for many applications, but not all applications will be
faster, so you would need to benchmark it for your purposes.

Yeah, the problem is applications that read from the screen all the time,
and to some extent, applications that perform blits from or whithin the
screen. Or rather, the problem is that they won’t tell SDL about it at
init time…

One could add two flags SDL_NOGLSDL and SDL_GLSDL for new applications to
explicitly say whether or not they’re glSDL friendly, but for old
applications, and other apps that don’t set either flag, we just have to
leave it to the user. Environment variable hack?

In
addition, I probably won’t add a dynamic link requirement for the
OpenGL library, so that adds a whole other ball of wax.

I’m not following… Wouldn’t glSDL, ported to the backend format, work
just like the other parts of SDL that use OpenGL calls? (That is, I don’t
expect anything to change, except that glSDL needs a few calls that
aren’t used by SDL currently.)

Anyway, David, once you’ve cleaned it up, I’ll be happy to add it as an
optional backend.

Ok, good to hear. :slight_smile:

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Tuesday 05 March 2002 16:13, Sam Lantinga wrote: