Hi all,
Ryan C. Gordon wrote:
>> It looks rather horrifying.
>
> I wouldn't have gone that far.
>
> But I'm curious if keeping an array of memory offsets
where a glyph's
> pixels exist would actually beat SDL's blitters...the
method we're
> discussing writes to less memory that a default surface
blit, but it
> doesn't take advantage of the possibility of blitting
between hardware
> surfaces, or that pixel formats, alpha blending, and
conversions can be
> handled without cluttering your application and
possibly with
> MMX/Altivec/SSE behind the scenes.
>
> Colorkey blitting with RLE encoding might achieve close
to the same
> speed inside SDL for about the same memory usage, too.
> [snip]
Here's some data, at least, I hope the following will be
helpful
in some way for people still targeting 2D modes. Timings
generated
based on: Desktop is a Sempron 3000+ (power saving mode)
with a
basic Nvidia (WinXP), while laptop is a old Celeron 766MHz
with a
2D Trident (WinME). SDL 1.2.11 from libsdl's MinGW
developer's
library, text_speed.c compiled using MinGW (gcc 3.4.2) on
-O2.
Display modes are 32-bit, at least 1024x768.
Timings are for a single run, copied verbatim from
stdout.txt
files. Timings are quite stable from run to run. For info,
in the
first item, the screen is written 1000 times (actually about
1372
out of 1920 positions are written to).
No changes (desktop)
--------------------
Time needed to display text pages: 15280.
- spent in text output: 984
- spent in screen refreshes: 14293
- spent in miscellaneous: 3
Time needed to display text lines: 20600.
- spent in text output: 931
- spent in screen refreshes: 19648
- spent in miscellaneous: 21
Time needed to display individual characters: 9858.
- spent in text output: 1037
- spent in screen refreshes: 8761
- spent in miscellaneous: 60
The bulk of the work is spent on SDL_UpdateRects. So one
screen
update (the first item) is about 15.3ms (15280/1000).
No changes (laptop)
-------------------
Time needed to display text pages: 41370.
- spent in text output: 14326
- spent in screen refreshes: 26158
- spent in miscellaneous: 886
Time needed to display text lines: 57253.
- spent in text output: 15748
- spent in screen refreshes: 40265
- spent in miscellaneous: 1240
Time needed to display individual characters: 43425.
- spent in text output: 13043
- spent in screen refreshes: 23522
- spent in miscellaneous: 6860
An old Celeron is much slower crunching the pixel array
(41.4ms).
Sluggish, but turn-based games should survive.
No changes (desktop, directx)
-----------------------------
Time needed to display text pages: 3967.
- spent in text output: 931
- spent in screen refreshes: 3028
- spent in miscellaneous: 8
Time needed to display text lines: 5366.
- spent in text output: 984
- spent in screen refreshes: 4362
- spent in miscellaneous: 20
Time needed to display individual characters: 40438.
- spent in text output: 898
- spent in screen refreshes: 39478
- spent in miscellaneous: 62
One screen update is done in about 4ms. However, for
directx, the
time for individual characters is much slower. Is this due
to some
kind of windib optimization?
Single UpdateRects of 800x480 (desktop)
---------------------------------------
Time needed to display text pages: 21451.
- spent in text output: 957
- spent in screen refreshes: 20490
- spent in miscellaneous: 4
This refreshes the entire screen area of 80x24 as
implemented in
the code. Since more positions are drawn (1920 versus 1372),
it is
slower, but a simple calculation confirms that the scaling
of rect
update time is linear. So, to minimize redraw with windib, a
textmode buffer can minimize the number of changes required,
if
that's absolutely necessary.
Single UpdateRects of 800x480 (desktop)
Array of display SDL_Surface
---------------------------------------
Time needed to display text pages: 21962.
- spent in text output: 2037
- spent in screen refreshes: 19919
- spent in miscellaneous: 6
Draws the first test using surfaces generated using
SDL_DisplayFormat, using a single SDL_UpdateRects. The text
output
section takes double the time of Leon's method, but the
overall
performance impact is small (22.0ms versus 21.5ms). However,
if
there is a need to set many background and foreground
colours,
some kind of caching will be desirable.
Single UpdateRects of 800x480 (desktop)
Array of 8-bit SDL_Surface
---------------------------------------
Time needed to display text pages: 22418.
- spent in text output: 2479
- spent in screen refreshes: 19935
- spent in miscellaneous: 4
Draws the first test using 8-bit surfaces generated by
SDL_TTF,
using a single SDL_UpdateRects. This is slightly slower than
drawing SDL_DisplayFormat surfaces. Scaling from the 15.3ms
in the
first results, for this method the same redraw would
probably take
about 17ms. For this format, any fg/bg colour choice can be
made,
with blit operation doing all the hard work. Plus, it is
only
slightly slower than using opaque display-format surfaces.
Single UpdateRects of 800x480 (desktop)
Array of 8-bit SDL_Surface + SDL_SRCCOLORKEY|SDL_RLEACCEL
---------------------------------------------------------
Time needed to display text pages: 22256.
- spent in text output: 2344
- spent in screen refreshes: 19907
- spent in miscellaneous: 5
Using SDL_SRCCOLORKEY|SDL_RLEACCEL with 8-bit surfaces is
slightly
faster than without those flags. There is a single clear to
background call for each Term_text_sdl call; so if each
position
can have its own fg/bg colour, this will be slower.
Single UpdateRects of 800x480 (desktop)
Array of display SDL_Surface + SDL_SRCCOLORKEY|SDL_RLEACCEL
-----------------------------------------------------------
Time needed to display text pages: 21481.
- spent in text output: 1456
- spent in screen refreshes: 20017
- spent in miscellaneous: 8
Using SDL_SRCCOLORKEY|SDL_RLEACCEL with SDL_DisplayFormat
surfaces
is much faster than without those flags. There is a single
clear
to background call for each Term_text_sdl call; so if each
position can have its own fg/bg colour, this will be
slower.
It look like there's not a whole lot to be gained from all
the
effort optimizing this thingy for 2D video mode, especially
if the
game is a turn-based one (just assuming) and windib is used.
Perhaps other graphic cards might give significantly
different
results.
--
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia
_______________________________________________
SDL mailing list
SDL lists.libsdl.org
h
ttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
|
