The best way

Hi all…
I?m making a isometric tiled based game. Each tile is a
64x32 pixels surface. I need draw it on all screen
(800x600)(444 tiles in total).
I?m seeking a fastest way to do it.
Actually I uses a loop for position and SDL_BlitSurface.
After the loop update all screen using SDL_UpdateRect
(0,0,0,0). That?s very slow.
Who?s the best way?
Thanks in advance.
Sorry for my bad english.

Gaston Valiente
Bs.As. Argentina=================================================================================
Enviado via http://www.interlap.com.ar - Tu Email POP3 Gratis
lee tus mensajes con tu programa de correo de correo favorito
o desde la web. InterLAP desde 1999 comunicando a la gente…
Accede Gratis a Internet. http://www.interlap.com.ar/acceso
Rescatando a Chacalito http://www.interlap.com.ar/chacalito

wrote in message
news:mailman.1022796189.11778.sdl at libsdl.org

Hi all…
I?m making a isometric tiled based game. Each tile is a
64x32 pixels surface. I need draw it on all screen
(800x600)(444 tiles in total).
I?m seeking a fastest way to do it.
Actually I uses a loop for position and SDL_BlitSurface.
After the loop update all screen using SDL_UpdateRect
(0,0,0,0). That?s very slow.
Who?s the best way?
Thanks in advance.
Sorry for my bad english.

This should run at a more or less acceptable speed. Are you using
alpha and/or colorkey? If so, enable RLE acceleration. Are you using
’SDL_DisplayFormat’ to convert your surface to screen format? If not,
do so.–
Rainer Deyke | root at rainerdeyke.com | http://rainerdeyke.com

alpha and/or colorkey? If so, enable RLE acceleration. Are you using
RLE acceleration ?
how can i check ( i am using color keys) if it’s possible to use it (X11) ?
GJ.

| > alpha and/or colorkey? If so, enable RLE acceleration. Are you using
| RLE acceleration ?
| how can i check ( i am using color keys) if it’s possible to use it (X11) ?

In your SDL_SetColorKey(), do you have “SDL_RLEACCEL” in the flags
part?

Is that really all you need to do to enable RLE acceleration? And how
much quicker does it make things? The docs are a bit vague on this.On Fri, May 31, 2002 at 01:44:11AM +0200, Grzegorz Jaskiewicz wrote:


I will not torment the emotionally frail

6AD6 865A BF6E 76BB 1FC2 | www.piku.org.uk/public-key.asc
E4C4 DEEA 7D08 D511 E149 | www.piku.org.uk wnzrf at cvxh.bet.hx (rot13’d)

In your SDL_SetColorKey(), do you have “SDL_RLEACCEL” in the flags
part?

Is that really all you need to do to enable RLE acceleration?

Yep. :slight_smile:

And how much quicker does it make things? The docs are a bit vague on this.

Much much faster. If you’re not dynamically modifying your sprites, DO THIS! :slight_smile:

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

| > In your SDL_SetColorKey(), do you have “SDL_RLEACCEL” in the flags
| > part?
|
| > Is that really all you need to do to enable RLE acceleration?
|
| Yep. :slight_smile:
|
| > And how much quicker does it make things? The docs are a bit vague on this.
|
| Much much faster. If you’re not dynamically modifying your sprites, DO THIS! :slight_smile:

OK… I will :slight_smile:

Maybe you should put something about this in the docs?

What do you mean by “dynamically modifying” my sprites? You mean
altering pixels on the source Surface I’m blitting from? (so suppose I
was trying to fake colour cycling by altering pixels with colour
{r,g,b} then blitting them to the screen).On Thu, May 30, 2002 at 05:19:02PM -0700, Sam Lantinga wrote:


I will not spin the turtle

6AD6 865A BF6E 76BB 1FC2 | www.piku.org.uk/public-key.asc
E4C4 DEEA 7D08 D511 E149 | www.piku.org.uk wnzrf at cvxh.bet.hx (rot13’d)

Hi again…
Thanks for yours answers.
Actually I can get 37 fps on a P1.4Ghz NVidia TNT2 RH7.1.
Imagine my game on a P200Mhz…
I like very much get 60 fps… Is that possible?

Is my game main loop correct?

main loop{
get mouse state
get keyboard state
draw map
draw GUI
draw mouse cursor
Update screen ( SDL_UpdateRect(screen,0,0,0,0))
}

Are you using ‘SDL_DisplayFormat’ to convert your surface to screen format?
Yes, I am.
In your SDL_SetColorKey(), do you have “SDL_RLEACCEL” in the flags part?
Yes…

Check my code…

VIDEO FLAGS SDL_FULLSCREEN|SDL_SWSURFACE|SDL_RLEACCEL
////////////////////////////////////////////////////////////////
class CSprite
{
public:

	void LoadTexture(char *filename, int width, int height, int framest);
	void PutSprite (int x, int y);
	void NextFrame(void);
	void PrevFrame(void);
	void AnimDelay(int delay);
	void Anim(void);
	void SetAlpha(int alpha);

	int ws; 				// ancho del cuadro
	int hs;					// altura del cuadro
	int frames;				// cant. de cuadros
	int frame_actual;
	int frames_h;          
	int adelay; 			// delay entre animacion y animacion
	int adelay_actual;		// tiempo hasta cumplir el delay.
	bool alphaenable;		// Permite que un sprite se haga transparente.
	SDL_Surface *face;

};

void CSprite::LoadTexture(char *filename, int width, int height, int framest){

char file[50];

strcpy(file,IMG_DIR);
strcat(file,filename);
fprintf(stdout,"[Cargando Textura …: %s]",file);

face = IMG_Load(file);
ws = width;
hs = height;
frame_actual = 0;
frames = framest - 1;
adelay_actual = 0;
frames_h = 0;

if(face==NULL){
fprintf(stdout,"[---->ERROR]\n");
}else{
fprintf(stdout,"[OK!]\n");
}

face = SDL_DisplayFormat(face);
SDL_SetColorKey(face, SDL_SRCCOLORKEY|SDL_RLEACCEL,
SDL_MapRGB(face->format,255,0,255));

}

void CSprite::SetAlpha(int alpha){

if (SDL_SetAlpha(face, SDL_RLEACCEL|SDL_SRCALPHA, alpha)!=0)
fprintf(stdout,"[Error intentando realizar transparencia] ->Clase Sprite
->SetAlpha");

}

void CSprite::PutSprite (int x, int y)
{

SDL_Rect source_rect;
SDL_Rect dest_rect;

source_rect.x = (frame_actual * ws);
source_rect.y = frames_h;
source_rect.w = ws;
source_rect.h = hs;

dest_rect.x = x ;
dest_rect.y = y;
dest_rect.w = ws;
dest_rect.h = hs;

SDL_BlitSurface(face, &source_rect, screen, &dest_rect);

}

Thanks…
Gaston Valiente

El Jue 30 May 2002 21:19, escribiste:> > In your SDL_SetColorKey(), do you have “SDL_RLEACCEL” in the flags

part?

Is that really all you need to do to enable RLE acceleration?

Yep. :slight_smile:

And how much quicker does it make things? The docs are a bit vague on
this.

Much much faster. If you’re not dynamically modifying your sprites, DO
THIS! :slight_smile:

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


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

I guess this kind of FPS topic has already been overly
discussed on this list. Maybe somebody shall put up a
guide or summary on www.libsdl.org page?

  1. try use hardware surface (available on Windows
    in Fullscreen mode) if possible;

  2. do not use SDL_Update with hardware surface, use
    SDL_Flip instead;

  3. if you can only use software surface, try to avoid
    updating the whole screen, use SDL_UpdateRects(…)
    with only changed rectangles on screen.

  4. if you want to go extreme, avoid unnecessary redraw
    to your software surface as well.

  5. for really bleeding edge 2D stuff, try David’s glSDL.

Regards,
paulOn Fri, May 31, 2002 at 01:59:02AM -0300, Gaston wrote:

Hi again…
Thanks for yours answers.
Actually I can get 37 fps on a P1.4Ghz NVidia TNT2 RH7.1.
Imagine my game on a P200Mhz…
I like very much get 60 fps… Is that possible?

Is my game main loop correct?

main loop{
get mouse state
get keyboard state
draw map
draw GUI
draw mouse cursor
Update screen ( SDL_UpdateRect(screen,0,0,0,0))
}

Are you using ‘SDL_DisplayFormat’ to convert your surface to screen format?
Yes, I am.
In your SDL_SetColorKey(), do you have “SDL_RLEACCEL” in the flags part?
Yes…

Check my code…

VIDEO FLAGS SDL_FULLSCREEN|SDL_SWSURFACE|SDL_RLEACCEL
////////////////////////////////////////////////////////////////
class CSprite
{
public:

  void LoadTexture(char *filename, int width, int height, int framest);
  void PutSprite (int x, int y);
  void NextFrame(void);
  void PrevFrame(void);
  void AnimDelay(int delay);
  void Anim(void);
  void SetAlpha(int alpha);

  int ws; 				// ancho del cuadro
  int hs;					// altura del cuadro
  int frames;				// cant. de cuadros
  int frame_actual;
  int frames_h;          
  int adelay; 			// delay entre animacion y animacion
  int adelay_actual;		// tiempo hasta cumplir el delay.
  bool alphaenable;		// Permite que un sprite se haga transparente.
  SDL_Surface *face;

};

void CSprite::LoadTexture(char *filename, int width, int height, int framest){

char file[50];

strcpy(file,IMG_DIR);
strcat(file,filename);
fprintf(stdout,"[Cargando Textura …: %s]",file);

face = IMG_Load(file);
ws = width;
hs = height;
frame_actual = 0;
frames = framest - 1;
adelay_actual = 0;
frames_h = 0;

if(face==NULL){
fprintf(stdout,"[---->ERROR]\n");
}else{
fprintf(stdout,"[OK!]\n");
}

face = SDL_DisplayFormat(face);
SDL_SetColorKey(face, SDL_SRCCOLORKEY|SDL_RLEACCEL,
SDL_MapRGB(face->format,255,0,255));

}

void CSprite::SetAlpha(int alpha){

if (SDL_SetAlpha(face, SDL_RLEACCEL|SDL_SRCALPHA, alpha)!=0)
fprintf(stdout,"[Error intentando realizar transparencia] ->Clase Sprite
->SetAlpha");

}

void CSprite::PutSprite (int x, int y)
{

SDL_Rect source_rect;
SDL_Rect dest_rect;

source_rect.x = (frame_actual * ws);
source_rect.y = frames_h;
source_rect.w = ws;
source_rect.h = hs;

dest_rect.x = x ;
dest_rect.y = y;
dest_rect.w = ws;
dest_rect.h = hs;

SDL_BlitSurface(face, &source_rect, screen, &dest_rect);

}

Thanks…
Gaston Valiente

El Jue 30 May 2002 21:19, escribiste:

In your SDL_SetColorKey(), do you have “SDL_RLEACCEL” in the flags
part?

Is that really all you need to do to enable RLE acceleration?

Yep. :slight_smile:

And how much quicker does it make things? The docs are a bit vague on
this.

Much much faster. If you’re not dynamically modifying your sprites, DO
THIS! :slight_smile:

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


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


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

Update screen ( SDL_UpdateRect(screen,0,0,0,0))

Update less. Keep track of what’s changed and only update those parts of
the screen. Try to use SDL_UpdateRects() and do it all in one call.

If you MUST update the whole screen every time, consider using less color
depth, a smaller resolution, or OpenGL.

–ryan.

main loop{
get mouse state
get keyboard state
draw map
draw GUI
draw mouse cursor
Update screen ( SDL_UpdateRect(screen,0,0,0,0))
}

…and profile. Always profile.

My assumption is that SDL_UpdateRect() will be the slowest part of that
loop, but you might be surprised to find that the bottleneck is your own
code. It happens.

–ryan.

  1. try use hardware surface (available on Windows
    in Fullscreen mode) if possible;

The best-performance combination of video-flags should be:

FULLSCREEN | HWSURFACE | DOUBLEBUF (I didn’t see this one yet!)

You can check whether your display support is with SDL_VideoModeOK ().

I have doubts about the RLE_ACCEL flag on the screen-surface, is this
hardware supported?

  1. do not use SDL_Update with hardware surface, use
    SDL_Flip instead;

Indeed. However, you can call SDL_Flip anyway, when you have a software
surface, it calls SDL_UpdateRect itself, else it swaps the display buffers.
(Well, it asks to do so to your videocard).

To make a bitmap use the same format as your display settings, use
SDL_DisplayFormat. This saves you from converting the surface on every blit.
My loader looks like this:

void CSingleBitmap::load (string str_filename) {
log (“ENTER CSingleBitmap::load”) ;
log (“param str_filename = %s”, str_filename.c_str ()) ;
// Cleanup existing data from any previous call
clear () ;
// Does the file exist
if (!CUtils::fileExist (str_filename)) {
throw FILE_NOT_FOUND ;
}
// Temporary surface
SDL_Surface* p_sdl_surface_help ;
cout << "Loading: " << str_filename.c_str () << “…” ;
p_sdl_surface_help = SDL_LoadBMP (str_filename.c_str ()) ;
if (!p_sdl_surface_help) {
throw LOAD_BMP ;
}
// Now make the member a correct conversion of the tmp one
m_p_sdl_surface = SDL_DisplayFormat (p_sdl_surface_help) ;
// Remove the temporary one
SDL_FreeSurface (p_sdl_surface_help) ;
p_sdl_surface_help = NULL ;
if (!m_p_sdl_surface) {
throw LOAD_BMP ;
}
// Colorkeying needed?
if (hasTransparentPixels ()) {
if (SDL_SetColorKey (m_p_sdl_surface, SDL_SRCCOLORKEY, SDL_MapRGB
(m_p_sdl_surface->format, 0, 255, 0)) == -1) {
throw LOAD_BMP ;
}
}
cout << “ok!” << endl ;
}

Regards,

Patrick.

FULLSCREEN | HWSURFACE | DOUBLEBUF (I didn’t see this one yet!)

I have doubts about the RLE_ACCEL flag on the screen-surface, is this
hardware supported?

No, if your screen surface is in video ram, you don’t want to use RLE.
If your screen surface is in video ram and you need color key blits,
make sure they’re accelerated in hardware…

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

I have done for Daiminion RPG a very nice setup where you can set in the
options
every option for fullscreen, windowed mode and bpp.

you can download the stuff on http://daimonin.sourceforge.net

ATM, i wait for the linux port - so its windows only.
In some days we will do a release then.

Because this is a “real” application, it was not designed for real
testings, but even under windows you can test very complete the different
run time results from the different options.

You don’t need to connect to a server ,you will see the frame rate even in
the
login screen.

** Note you need a working socket, or the client will hang some time when
try to
get the server list at start **

With this program, i got with alpha/software surface/and whole screen
redrawing (this
is a real app, i draw much MORE as only the 800x600 pixel !) ~30 fps with a
p3/500 -
and maxed out vsync speed with fullscreen/doublebuf.

There is one thing i wonder:

Try this:

Fullscreen 1
UseUpdateRect 0

Full_HWSURFACE 1
Full_SWSURFACE 0
Full_HWACCEL 1
Full_DOUBLEBUF 0
Full_ANYFORMAT 1
Full_ASYNCBLIT 0
Full_HWPALETTE 1
Full_RESIZABLE 0
Full_NOFRAME 0
Full_RLEACCEL 0

Then i got on my computer around 166 (!) fps but with heavy flickering -
with one buffer the
vsync synchronization is broken. I have a voodoo 3/3000 - is it my driver or
sdl?

And note: my code is in work - i really must cleanup the code.

the options.dat where you set all the stuff looks like this:
[snip]

This is the Daimonin SDL client option file#

Sound & Music Volume

Parameter are from 0 (mute) to 100 (full)

SoundVolume 100
MusicVolume 0

MaxSpeed

With MaxSpeed 0 the client tries to give back unused cpu time to OS

With MaxSpeed 1 the client repeat main loop with maximal speed

Results depends on OS

MaxSpeed 0

Bit per Pixel setting

Note: 16 bpp are much faster as 32 bpp on most systems.

Note: ** Don’t use 8 bpp or your fps will go down under 10 frames **

Note: Change your real window bpp from 32 to 16 bit to run the client

faster

AutomaticBPP 1 will set BitPerPixel to current system bpp when windowed

For fullscreen mode will BitPerPixel override AutomaticBPP all times

With AutomaticBPP 0 bpp will always the BitPerPixel value

Note: On win32 systems will be the windowed mode bpp always same as the

screen bpp

Note: SDL_SetVideoMode() changes this automatically and overide the bpp

pre settings

BitPerPixel 16
AutomaticBPP 1

SDL Fullscreen & Windowed Mode Settings

IMPORTANT NOTE: Using SWSURFACE 1 in fullscreen mode will drop the frame

rate

but it will allow you to use alpha blits (transparency). You should enable

HWSURFACE

+ DOUBLEBUF only when you REALLY need the speed because Daimonin use alot

transparency effects.

Note: You can set buffers & options for both modes

Note: Use ForceRedraw 1 to control the speed effects of the settings.

Note: Don’t forget to change ForceRedraw to 0 after testing!

Fullscreen 0 is windowed mode.

All options starting with Full_xx are used for fullscreen mode

All options starting with Win_xx are used for windowed mode

RLEACCEL will speed blits in most modes alot.

This can change in a few situations if the drivers use real hw to hw

blits.

UseUpdateRect force SDL_UpdateRect() instead of flip().

Note: flip() should be faster in most cases.

WARNING: On some systems (win32,…) DOUBLEBUF and Update_Rect() cause a

black screen!

Fullscreen 0
UseUpdateRect 0

Full_HWSURFACE 0
Full_SWSURFACE 1
Full_HWACCEL 1
Full_DOUBLEBUF 0
Full_ANYFORMAT 1
Full_ASYNCBLIT 0
Full_HWPALETTE 1
Full_RESIZABLE 0
Full_NOFRAME 0
Full_RLEACCEL 1

Win_HWSURFACE 0
Win_SWSURFACE 1
Win_HWACCEL 0
Win_DOUBLEBUF 0
Win_ANYFORMAT 1
Win_ASYNCBLIT 0
Win_HWPALETTE 1
Win_RESIZABLE 0
Win_NOFRAME 0
Win_RLEACCEL 1

All public server will give a note to the metaserver where and what they

are

The client get from the metaserver a list of all this public servers

meta_server crossfire.real-time.com
meta_server_port 13326

Debug Options

OpenGL use is not implemented so far - don’t use this setting for playing

UseOpenGL 0

This shows the frame rate under the map name

This setting shows you also some more status flags about the current

system

This depends on the used source

ShowFrameRate 1

Forces the system to redraw the screen EVERY frame. For testing hardware

settings

*** Will slow down the system ALOT ****

ForceRedraw 0

FULLSCREEN | HWSURFACE | DOUBLEBUF (I didn’t see this one yet!)

I have doubts about the RLE_ACCEL flag on the screen-surface, is this
hardware supported?

No, if your screen surface is in video ram, you don’t want to use RLE.
If your screen surface is in video ram and you need color key blits,
make sure they’re accelerated in hardware…

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


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

All this “best way” stuff is nice in theory. But in practice, it
depends entirely on the particular machine.

We wrote some code to test our game in 8 different combinations
of fullscreen, windowed, hardware, software, dirty rect, and
fullscreen blt (under Windows, at the moment). Depending on the speed
of CPU, quality of video board, version of windows, quality of
drivers, etc, I think we’ve seen every combination prove
to be the most appropriate for some machine.

In most circumstances, hardware surfaces (and putting all of our
images up in the hardware) are a win for us. But on some machines,
that simply doesn’t work right. On machines with a fast CPU and weak
hardware (some laptops) the best solution is to put everything in
software and use dirty rectangles.

Basically, you need to understand both your app and your target to
make the right decisions in your case. The OpenGL solution would be
a nice one, except that I’ve spent the last three years supporting
an OpenGL-based game on Windows, and frankly, it’s just not worth
it, especially for something that’s supposed to be mass market.

(Whoever wrote the rant that users ought to be able to compile their
own drivers, I hope you never have to sell software for a living.)

   Kent

Friday, May 31, 2002, 3:03:24 AM, you wrote:

  1. try use hardware surface (available on Windows
    in Fullscreen mode) if possible;

p> The best-performance combination of video-flags should be:

p> FULLSCREEN | HWSURFACE | DOUBLEBUF (I didn’t see this one yet!)

p> You can check whether your display support is with SDL_VideoModeOK ().

p> I have doubts about the RLE_ACCEL flag on the screen-surface, is this
p> hardware supported?

  1. do not use SDL_Update with hardware surface, use
    SDL_Flip instead;

p> Indeed. However, you can call SDL_Flip anyway, when you have a software
p> surface, it calls SDL_UpdateRect itself, else it swaps the display buffers.
p> (Well, it asks to do so to your videocard).

p> To make a bitmap use the same format as your display settings, use
p> SDL_DisplayFormat. This saves you from converting the surface on every blit.
p> My loader looks like this:

p> void CSingleBitmap::load (string str_filename) {
p> log (“ENTER CSingleBitmap::load”) ;
p> log (“param str_filename = %s”, str_filename.c_str ()) ;
p> // Cleanup existing data from any previous call
p> clear () ;
p> // Does the file exist
p> if (!CUtils::fileExist (str_filename)) {
p> throw FILE_NOT_FOUND ;
p> }
p> // Temporary surface
p> SDL_Surface* p_sdl_surface_help ;
p> cout << "Loading: " << str_filename.c_str () << “…” ;
p> p_sdl_surface_help = SDL_LoadBMP (str_filename.c_str ()) ;
p> if (!p_sdl_surface_help) {
p> throw LOAD_BMP ;
p> }
p> // Now make the member a correct conversion of the tmp one
p> m_p_sdl_surface = SDL_DisplayFormat (p_sdl_surface_help) ;
p> // Remove the temporary one
p> SDL_FreeSurface (p_sdl_surface_help) ;
p> p_sdl_surface_help = NULL ;
p> if (!m_p_sdl_surface) {
p> throw LOAD_BMP ;
p> }
p> // Colorkeying needed?
p> if (hasTransparentPixels ()) {
p> if (SDL_SetColorKey (m_p_sdl_surface, SDL_SRCCOLORKEY, SDL_MapRGB
(m_p_sdl_surface->>format, 0, 255, 0)) == -1) {
p> throw LOAD_BMP ;
p> }
p> }
p> cout << “ok!” << endl ;
p> }

p> Regards,

p> Patrick.

p> _______________________________________________
p> SDL mailing list
p> SDL at libsdl.org
p> http://www.libsdl.org/mailman/listinfo/sdl--
Kent Quirk, CTO, CogniToy
@Kent_Quirk
http://www.cognitoy.com

Basically, you need to understand both your app and your target to
make the right decisions in your case. The OpenGL solution would be
a nice one, except that I’ve spent the last three years supporting
an OpenGL-based game on Windows, and frankly, it’s just not worth
it, especially for something that’s supposed to be mass market.

that why every one will be glad to have it under one (sdls of coz) interface
:wink:

GJ.

[…]

(Whoever wrote the rant that users ought to be able to compile their
own drivers, I hope you never have to sell software for a living.)

Not sure what you’re referring to, but I code for a living, and still (or rather consequently) prefer Open Source drivers. (And other Open Source software as well, for that matter.)

Either way, “being able to” != “being forced to”.

Most Linux distros install just fine without compiling anything. (It’s actually the closed source drivers that are causing trouble - although mostly for political and legal reasons, it seems.)

//David

.---------------------------------------
| David Olofson
| Programmer

david.olofson at reologica.se
Address:
REOLOGICA Instruments AB
Scheelev?gen 30
223 63 LUND
Sweden
---------------------------------------
Phone: 046-12 77 60
Fax: 046-12 50 57
Mobil:
E-mail: david.olofson at reologica.se
WWW: http://www.reologica.se

`-----> We Make Rheology RealOn Fri, 31/05/2002 10:29:40 , Kent Quirk <kent_quirk at cognitoy.com> wrote:

(Whoever wrote the rant that users ought to be able to compile their
own drivers, I hope you never have to sell software for a living.)

Not sure what you’re referring to, but I code for a living, and still
(or rather consequently) prefer Open Source drivers. (And other Open
Source software as well, for that matter.)

I think when Kent says “users” he means “people that wouldn’t ever think
of subscribing to this mailing list”, so let’s not assume any one here to
be status quo when it comes to computer literacy. :slight_smile:

–ryan.

Still, end users of that sort would benefit from having drivers which could
at least be compiled by their vendors (or other support folks).

But this is pretty off topic. So I’ll shut up.On Fri, May 31, 2002 at 11:31:46AM -0400, Ryan C. Gordon wrote:

I think when Kent says “users” he means “people that wouldn’t ever think
of subscribing to this mailing list”, so let’s not assume any one here to
be status quo when it comes to computer literacy. :slight_smile:


Matthew Miller @Matthew_Miller http://www.mattdm.org/
Boston University Linux ------> http://linux.bu.edu/

I think when Kent says “users” he means “people that wouldn’t ever think
of subscribing to this mailing list”, so let’s not assume any one here to
be status quo when it comes to computer literacy. :slight_smile:

Still, end users of that sort would benefit from having drivers which could
at least be compiled by their vendors (or other support folks).

Yes, that’s exactly what I meant.

But this is pretty off topic. So I’ll shut up.

Right. (Here we go again… :slight_smile:

//David

.---------------------------------------
| David Olofson
| Programmer

david.olofson at reologica.se
Address:
REOLOGICA Instruments AB
Scheelev?gen 30
223 63 LUND
Sweden
---------------------------------------
Phone: 046-12 77 60
Fax: 046-12 50 57
Mobil:
E-mail: david.olofson at reologica.se
WWW: http://www.reologica.se

`-----> We Make Rheology RealOn Fri, 31/05/2002 11:30:23 , Matthew Miller wrote:

On Fri, May 31, 2002 at 11:31:46AM -0400, Ryan C. Gordon wrote:

My assumption is that SDL_UpdateRect() will be the slowest part of that
loop, but you might be surprised to find that the bottleneck is your own
code. It happens.

Put timers between each stage to see where the bottleneck is.

#include <time.h>
clock_t clock1,clock2;

clock1 = clock();
//put your stage 1 here
clock2 = clock();
printf(“stage 1 completed in %.0f ms\n”,(double)(clock2-clock1)/CLOCKS_PER_SEC*1000);

clock1 = clock();
//put your stage 2 here
clock2 = clock();
printf(“stage 2 completed in %.0f ms\n”,(double)(clock2-clock1)/CLOCKS_PER_SEC*1000);

etc.