ANNC: smoothscroll

Well, I thought I should post something interesting/useful/whatever for a
change, so here goes…

http://olofson.net/mixed.html

"This is a simple demo of ultra smooth scrolling using
OpenGL for sub-pixel accurate and fast rendering. It works
best with retrace synchronized pageflipping and full frame
rate, but works remarkably well under much worse conditions.
It even seems to reduce tearing with poor OpenGL drivers to
great extent! A simple map editor is integrated, and can be
invoked from the command line."

It’s worked better than expected on anything I’ve tried it on so far. I’d
be interested in further reports, of course.

Oh, to avoid confusion: yes, it will run even if it can’t get an OpenGL
display - but there won’t be any sub-pixel accurate rendering. No
"magic", that is.

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

Doesn’t compile in Visual Studio 6 right off the bat, MS’s compiler is
complaining about inlines. Removing the inlines fixes the compile
errors, (however that isn’t correct method to solving this.)

The other glitch is that most of the time when it goes to full screen
it’s flickering against the desktop (incredibly annoying), alt-tabbing
between it and anything else fixes it. IMO this may have something to do
with the console window. Window mode doesn’t have the problem.

The editor does work in OpenGL, to the best of my knowledge.

David> -----Original Message-----

From: sdl-admin at libsdl.org [mailto:sdl-admin at libsdl.org] On Behalf Of
Olofson
Sent: Tuesday, March 26, 2002 8:13 PM
To: sdl at libsdl.org
Subject: [SDL] ANNC: smoothscroll

Well, I thought I should post something interesting/useful/whatever
for a
change, so here goes…

http://olofson.net/mixed.html

“This is a simple demo of ultra smooth scrolling using
OpenGL for sub-pixel accurate and fast rendering. It works
best with retrace synchronized pageflipping and full frame
rate, but works remarkably well under much worse conditions.
It even seems to reduce tearing with poor OpenGL drivers to
great extent! A simple map editor is integrated, and can be
invoked from the command line.”

It’s worked better than expected on anything I’ve tried it on so far.
I’d
be interested in further reports, of course.

Oh, to avoid confusion: yes, it will run even if it can’t get an
OpenGL
display - but there won’t be any sub-pixel accurate rendering. No
"magic", that is.

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


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


Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Doesn’t compile in Visual Studio 6 right off the bat, MS’s compiler is
complaining about inlines. Removing the inlines fixes the compile
errors, (however that isn’t correct method to solving this.)

A better solution:

#if ((defined _MSC_VER) && (!defined inline))
#define inline inline
#endif

(in short, MSVC supports inlines, just with a different keyword)

–ryan.

At 00:13 27.03.2002 -0800, you wrote:

The other glitch is that most of the time when it goes to full screen
it’s flickering against the desktop (incredibly annoying), alt-tabbing
between it and anything else fixes it. IMO this may have something to do
with the console window. Window mode doesn’t have the problem.
Well, to get rid of the flickering just turn on the vsync inside
display-properties->extended->OpenGL-Settings.
St0fF.

Kisai

Doesn’t compile in Visual Studio 6 right off the bat, MS’s compiler is
complaining about inlines. Removing the inlines fixes the compile
errors, (however that isn’t correct method to solving this.)

I had the same inline complaints in .net. It went away when I told it to
compile the file as C++ (but required a couple of casts here and there).
Given that, I assume it’s some kind of C vs. C++ escoterica regarding
inlines.

It works on my machine, but scrolls slowly, as I don’t have a
hardware-accelerated OpenGL driver. Scrolling was much nicer with the -sdl
switch enabled.

Nice piece of code, though. Thanks, David!> From: sdl-admin at libsdl.org [mailto:sdl-admin at libsdl.org]On Behalf Of

Sent: Wednesday, March 27, 2002 2:14 AM
To: sdl at libsdl.org
Subject: RE: [SDL] ANNC: smoothscroll


John Hattan Sweet software for a saturnine world
@John_Hattan http://www.thecodezone.com

I had the same inline complaints in .net. It went away when I told it to
compile the file as C++ (but required a couple of casts here and there).
Given that, I assume it’s some kind of C vs. C++ escoterica regarding
inlines.

Inline functions aren’t ANSI C, and therefore are specific to compilers that
decide they want to support it, and how. In C, the normal way to do things
like that is with #define directives. If you want your code to be C, and be
portable, then don’t use inline. If you want to use inline, you can make it
C++ and just code it like you would C. You can still do that, you know. :wink:
Just because you use C++ doesn’t mean you have to suddenly make everything
overwhelmingly Object Oriented or anything.

It works on my machine, but scrolls slowly, as I don’t have a
hardware-accelerated OpenGL driver. Scrolling was much nicer with the -sdl
switch enabled.

It was probably doing software OpenGL, which will be very slow. I would
guess the -sdl switch tells it to not use OpenGL, which makes it fast again.
:slight_smile: For something like this, it would probably make sense to be able to
detect if software OpenGL would be used, and if so, don’t bother using it by
default. Is there a way to determine that I wonder? Probably not, heh.

-Jason

----- Original Message -----
From: john@thecodezone.com (John Hattan)
To:
Sent: Wednesday, March 27, 2002 8:25 AM
Subject: RE: [SDL] ANNC: smoothscroll

Jason Hoffoss

I had the same inline complaints in .net. It went away when I told it to
compile the file as C++ (but required a couple of casts here and there).
Given that, I assume it’s some kind of C vs. C++ escoterica regarding
inlines.

Inline functions aren’t ANSI C, and therefore are specific to
compilers that
decide they want to support it, and how. In C, the normal way to
do things
like that is with #define directives. If you want your code to
be C, and be
portable, then don’t use inline. If you want to use inline, you
can make it
C++ and just code it like you would C. You can still do that,
you know. :wink:
Just because you use C++ doesn’t mean you have to suddenly make everything
overwhelmingly Object Oriented or anything.

[John slaps forehead]

Yep. I got so caught up with that draft-standard C stuff that I forgot that
the existing ANSI C doesn’t support inlines at all.

It works on my machine, but scrolls slowly, as I don’t have a
hardware-accelerated OpenGL driver. Scrolling was much nicer
with the -sdl
switch enabled.

It was probably doing software OpenGL, which will be very slow. I would
guess the -sdl switch tells it to not use OpenGL, which makes it
fast again.
:slight_smile: For something like this, it would probably make sense to be able to
detect if software OpenGL would be used, and if so, don’t bother
using it by default.

Yeah, that’d probably be ideal.

Is there a way to determine that I wonder? Probably not, heh.

I don’t think there’s a cross-platform way. Under Windows, you can check the
structure filled by DescribePixelFormat(). Here’s some code that does it.

http://www.opengl.org/developers/faqs/technical/mswindows.htm> From: sdl-admin at libsdl.org [mailto:sdl-admin at libsdl.org]On Behalf Of

Sent: Wednesday, March 27, 2002 7:59 AM
To: sdl at libsdl.org
Subject: Re: [SDL] ANNC: smoothscroll


John Hattan Sweet software for a saturnine world
@John_Hattan http://www.thecodezone.com

Doesn’t compile in Visual Studio 6 right off the bat, MS’s compiler is
complaining about inlines. Removing the inlines fixes the compile
errors, (however that isn’t correct method to solving this.)

Ah! Sorry about that. Some #define hackery should soleve that - but OTOH,
one might as well remove them instead… (Ouch! Will cost several cycles
per tile! :wink:

The other glitch is that most of the time when it goes to full screen
it’s flickering against the desktop (incredibly annoying), alt-tabbing
between it and anything else fixes it. IMO this may have something to
do with the console window. Window mode doesn’t have the problem.

Oh oh… I haven’t seen this on my Windows systems. Are you compiling it
as a console application? You shouldn’t need to, as there isn’t really
any important output. It might as well just go to std(err|out).txt. (Just
in case the program would “silently” refuse to start for some reason.)

This would be a nice place for a cross-platform error message dialog…

The editor does work in OpenGL, to the best of my knowledge.

I wouldn’t think so, actually… There’s no code that would make that
possible - unless SDL_FillRect() works in pure OpenGL mode in some SDL
versions. :slight_smile:

What happens is that the program ignores the -gl switch and uses SDL 2D
mode anyway, if you start the editor.

//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 27 March 2002 09:13, Kisai wrote:

In fact, it almost seems like it would be a good idea to do this:

#ifndef inline
#define inline __inline__
#endif

…or just use inline directly. inline seems to be more portable
than inline.

Does anyone know of a compiler that does not understand inline?

//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 27 March 2002 09:34, Ryan C. Gordon wrote:

Doesn’t compile in Visual Studio 6 right off the bat, MS’s compiler
is complaining about inlines. Removing the inlines fixes the compile
errors, (however that isn’t correct method to solving this.)

A better solution:

#if ((defined _MSC_VER) && (!defined inline))
#define inline inline
#endif

(in short, MSVC supports inlines, just with a different keyword)

[…inline…]

I had the same inline complaints in .net. It went away when I told it
to compile the file as C++ (but required a couple of casts here and
there). Given that, I assume it’s some kind of C vs. C++ escoterica
regarding inlines.

AFAIK, the whole problem is that “inline” is not available in ANSI C. The
reason why it’s there is that the code was snipped from a project where
the autoconf scripts were supposed to take care of it.

It works on my machine, but scrolls slowly, as I don’t have a
hardware-accelerated OpenGL driver.

Ouch!

Scrolling was much nicer with the
-sdl switch enabled.

As expected. :slight_smile:

Nice piece of code, though. Thanks, David!

Thanks!

//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 27 March 2002 14:25, John Hattan wrote:

I had the same inline complaints in .net. It went away when I told it
to compile the file as C++ (but required a couple of casts here and
there). Given that, I assume it’s some kind of C vs. C++ escoterica
regarding inlines.

Inline functions aren’t ANSI C, and therefore are specific to compilers
that decide they want to support it, and how. In C, the normal way to
do things like that is with #define directives.

Right. The code comes from a place where “inline” would have been defined
if not present - just didn’t think about removing it. heh

If you want your code
to be C, and be portable, then don’t use inline. If you want to use
inline, you can make it C++ and just code it like you would C. You can
still do that, you know. :wink: Just because you use C++ doesn’t mean you
have to suddenly make everything overwhelmingly Object Oriented or
anything.

Speaking of which, this code is the first C code I write in a good while
that is not object oriented in any way. :slight_smile: (Well, at least, I can’t
remember anything like that in it…)

It works on my machine, but scrolls slowly, as I don’t have a
hardware-accelerated OpenGL driver. Scrolling was much nicer with the
-sdl switch enabled.

It was probably doing software OpenGL, which will be very slow. I
would guess the -sdl switch tells it to not use OpenGL, which makes it
fast again.

Yep.

Kind of eliminates the whole point with the program, though. :slight_smile:

The main reason why there is SDL 2D support is that I thought it would be
nice to be able to directly compare the methods with the same graphics
and higher level code.

It would have been easy enough to make the editor use OpenGL instead - I
was just lazy, and decided that SDL 2D would be most likely to work right
every where, so I implemented the editor specific rendering stuff using
SDL 2D calls. (Will be fixed in the next version, of course! :slight_smile:

:slight_smile: For something like this, it would probably make sense to be able to

detect if software OpenGL would be used, and if so, don’t bother using
it by default. Is there a way to determine that I wonder? Probably
not, heh.

Well, you can try to recognize the driver name… Will catch the known
software implementations, at least. heh

Another alternative would be checking the frame rate. If it’s too slow,
whine about something being wrong, and restart in “SDL 2D mode”.

//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 27 March 2002 14:59, Jason Hoffoss wrote:

----- Original Message -----
From: “John Hattan”
To:
Sent: Wednesday, March 27, 2002 8:25 AM
Subject: RE: [SDL] ANNC: smoothscroll

[…inline…]

[John slaps forehead]

Yep. I got so caught up with that draft-standard C stuff that I forgot
that the existing ANSI C doesn’t support inlines at all.

I didn’t even think that far… :wink:

[…]

Is there a way to determine that I wonder? Probably not, heh.

I don’t think there’s a cross-platform way. Under Windows, you can
check the structure filled by DescribePixelFormat(). Here’s some code
that does it.

http://www.opengl.org/developers/faqs/technical/mswindows.htm

I’ll look into that, at least for glSDL. (Slightly overkill for a small
example, I guess. Then again, it could make a nice cut’n’paste
resource… :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 27 March 2002 15:44, John Hattan wrote:

Downloaded it, ran it. For the most part, it is smooth, but every few
seconds it seems to go backwards and then forwards again. Very distracting.

I’m using a NVIdia TNT2 board with the NVidia OpenGL drivers on a 500MHz
K6-2 256MB, RH 7.2 with all patches, and SDL 1.2.3

David Olofson wrote:> Well, I thought I should post something interesting/useful/whatever for a

change, so here goes…

http://olofson.net/mixed.html

“This is a simple demo of ultra smooth scrolling using
OpenGL for sub-pixel accurate and fast rendering. It works
best with retrace synchronized pageflipping and full frame
rate, but works remarkably well under much worse conditions.
It even seems to reduce tearing with poor OpenGL drivers to
great extent! A simple map editor is integrated, and can be
invoked from the command line.”

It’s worked better than expected on anything I’ve tried it on so far. I’d
be interested in further reports, of course.

Oh, to avoid confusion: yes, it will run even if it can’t get an OpenGL
display - but there won’t be any sub-pixel accurate rendering. No
"magic", that is.

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


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


±-----------------------------------+

  • Bob Pendleton is seeking contract +
  • and consulting work. Find out more +
  • at http://www.jump.net/~bobp +
    ±-----------------------------------+

In fact, it almost seems like it would be a good idea to do this:

#ifndef inline
#define inline inline
#endif

BTW, if you include SDL.h, you can safely use inline, as I do
the necessary magic to figure out what calling convention to use
for various compilers.

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

Downloaded it, ran it. For the most part, it is smooth, but every few
seconds it seems to go backwards and then forwards again.

Backwards? :slight_smile: If you look at the code, you’ll probably find that time
as returned by SDL_GetTicks() must go backwards for that to happen. This
is all code involved in this:

	tick2 = SDL_GetTicks();
	dt = (tick2 - tick1) * 0.001f;
	tick1 = tick2;

and

	xpos += dt * sx;
	ypos += dt * sy;

Sounds more like what it looks like when one or more frames are dropped
occasionally. (This is rather likely to happen every now and then, if the
nVidia driver tries to implement retrace sync with busy-waiting/polling.)

Very
distracting.

I bet. (Guess why I’m bitching about triple buffering, proper drivers and
stuff all the time…)

I’m using a NVIdia TNT2 board with the NVidia OpenGL drivers on a
500MHz K6-2 256MB, RH 7.2 with all patches, and SDL 1.2.3

Are you running with retrace sync enabled? If so, try disabling it. (Most
attempts to do retrace sync on Linux I have seen so far are more or less
broken, and will only eliminate tearing at the cost of entirely dropping
frames every now and then.)

If that’s not it, the problem is probably some background job stealing
the CPU occasionally. Doesn’t happen normally on any of my systems, but
it does happen when there’s too much going on in the background.

//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 27 March 2002 19:23, Bob Pendleton wrote:

Cool - I’ll just use that. :slight_smile:

Oh, and that’s an official feature of SDL.h?

//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 27 March 2002 20:21, Sam Lantinga wrote:

In fact, it almost seems like it would be a good idea to do this:

#ifndef inline
#define inline __inline__
#endif

BTW, if you include SDL.h, you can safely use inline, as I do
the necessary magic to figure out what calling convention to use
for various compilers.

Ummmm sure! :slight_smile:

See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment> On Wednesday 27 March 2002 20:21, Sam Lantinga wrote:

In fact, it almost seems like it would be a good idea to do this:

#ifndef inline
#define inline __inline__
#endif

BTW, if you include SDL.h, you can safely use inline, as I do
the necessary magic to figure out what calling convention to use
for various compilers.

Cool - I’ll just use that. :slight_smile:

Oh, and that’s an official feature of SDL.h?

David Olofson wrote:

Downloaded it, ran it. For the most part, it is smooth, but every few
seconds it seems to go backwards and then forwards again.

Backwards? :slight_smile: If you look at the code, you’ll probably find that time
as returned by SDL_GetTicks() must go backwards for that to happen. This
is all code involved in this:

  tick2 = SDL_GetTicks();
  dt = (tick2 - tick1) * 0.001f;
  tick1 = tick2;

and

  xpos += dt * sx;
  ypos += dt * sy;

Sounds more like what it looks like when one or more frames are dropped
occasionally. (This is rather likely to happen every now and then, if the
nVidia driver tries to implement retrace sync with busy-waiting/polling.)

It was top. I have been computing solutions to the knights tour problem
for square boards of size 5x5 to 6000x6000, most just because I want to,
and I’ve been keeping track of how long the program has run using top. I
remembered to stop the knights tour program but forgot to stop top. (I
have 110 boards left to go and the program has been running for 4.4 days.)

The “going backward” was an optical illusion caused by the mind
expecting motion an projecting what it expected to see. When what you
really see is different from what you expect it can look like the object
moved backward. Psychooptics is such a fun field of study.

The card I have in that machine doesn’t even support retrace synching. I
bought a week card for development to ensure my code doesn’t depend on
top of the line hardware. The old saying that “The game works best on
the developers computer” can be used to manage the target machine. My
game playing machine has a nice GeForce II card that seems to be holding
it’s own.

Very
distracting.

I bet. (Guess why I’m bitching about triple buffering, proper drivers and
stuff all the time…)

Oh, I understand. But, without rehashing all the experience that makes
me think so, let me just say that I think you are making a lot out of a
very little thing. I think you also grossly underestimate the qualitiy
of work in the drivers that are out there. Any way, no matter what you
do you can’t get every driver in every OS to work the way you think it
should. You can’t even get the hardware to work the way you think it
should. But, you can write code that works as well as it can on every
driver and OS. So, you do what you can and live in the real world.

Now, if you want to get me started on why the basic idea of the X server
is wrong… well, I will happily get into that with you. But, not on
this list.

	Bob Pendleton

P.S.

If you WANT to know about the experience that leads me to my
conclusions, look at the URL just under this line.> On Wednesday 27 March 2002 19:23, Bob Pendleton wrote:

±-----------------------------------+

  • Bob Pendleton is seeking contract +
  • and consulting work. Find out more +
  • at http://www.jump.net/~bobp +
    ±-----------------------------------+

There is a similar problem on Windows, on two different machines running
two different video cards.

On both machines (a PIII with a Rage 128 32MB and an Athlon with a
Radeon 7500 64MB DDR) with the inlines, it appears that every 1 second
it skips back a frame. Without the inlines it just has a bit of a
shimmer effect. Disabling the console window (building for subsystem
windows) reduces the occurrences of frame jumping. However enabling
Vsync doesn’t appear to change anything.

David> -----Original Message-----

From: sdl-admin at libsdl.org [mailto:sdl-admin at libsdl.org] On Behalf Of
Olofson
Sent: Wednesday, March 27, 2002 11:57 AM
To: sdl at libsdl.org
Subject: Re: [SDL] ANNC: smoothscroll

On Wednesday 27 March 2002 19:23, Bob Pendleton wrote:

Downloaded it, ran it. For the most part, it is smooth, but every
few

seconds it seems to go backwards and then forwards again.

Backwards? :slight_smile: If you look at the code, you’ll probably find that
time
as returned by SDL_GetTicks() must go backwards for that to happen.
This
is all code involved in this:

  tick2 = SDL_GetTicks();
  dt = (tick2 - tick1) * 0.001f;
  tick1 = tick2;

and

  xpos += dt * sx;
  ypos += dt * sy;

Sounds more like what it looks like when one or more frames are
dropped
occasionally. (This is rather likely to happen every now and then, if
the
nVidia driver tries to implement retrace sync with
busy-waiting/polling.)

Very
distracting.

I bet. (Guess why I’m bitching about triple buffering, proper drivers
and
stuff all the time…)

I’m using a NVIdia TNT2 board with the NVidia OpenGL drivers on a
500MHz K6-2 256MB, RH 7.2 with all patches, and SDL 1.2.3

Are you running with retrace sync enabled? If so, try disabling it.
(Most
attempts to do retrace sync on Linux I have seen so far are more or
less
broken, and will only eliminate tearing at the cost of entirely
dropping
frames every now and then.)

If that’s not it, the problem is probably some background job stealing
the CPU occasionally. Doesn’t happen normally on any of my systems,
but
it does happen when there’s too much going on in the background.

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


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


Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

[…]

It was top. I have been computing solutions to the knights tour problem
for square boards of size 5x5 to 6000x6000, most just because I want
to, and I’ve been keeping track of how long the program has run using
top. I remembered to stop the knights tour program but forgot to stop
top. (I have 110 boards left to go and the program has been running for
4.4 days.)

hehe Top is nasty, for some reason. (Applies to anything doing heavy
/proc access; not just top.)

The “going backward” was an optical illusion caused by the mind
expecting motion an projecting what it expected to see. When what you
really see is different from what you expect it can look like the
object moved backward. Psychooptics is such a fun field of study.

Yeah… :slight_smile:

The card I have in that machine doesn’t even support retrace synching.

Weird. I didn’t know any such cards existed - only that most cards make
it very hard to implement properly in the drivers…

I bought a week card for development to ensure my code doesn’t depend
on top of the line hardware. The old saying that “The game works best
on the developers computer” can be used to manage the target machine.
My game playing machine has a nice GeForce II card that seems to be
holding it’s own.

Very
distracting.

I bet. (Guess why I’m bitching about triple buffering, proper drivers
and stuff all the time…)

Oh, I understand. But, without rehashing all the experience that makes
me think so, let me just say that I think you are making a lot out of a
very little thing.

Well, you don’t see tearing and unsmooth animation as a problem, while I
find it terribly annoying.

I think you also grossly underestimate the qualitiy
of work in the drivers that are out there.

I don’t even have an opinion about most of the code in those drivers - I
just don’t agree with the idea that you should have to resort to
hysterical brute force approaches to get reasonably smooth and tearing
free animation. It’s basically all about one feature, that seems to
have been totally forgotten.

Any way, no matter what you
do you can’t get every driver in every OS to work the way you think it
should.

Right.

You can’t even get the hardware to work the way you think it
should.

Most hardware already does work the way it should. Drivers are just
having some trouble making use of it, because of some "missing features"
on most cards.

But, you can write code that works as well as it can on every
driver and OS.

I’m trying to do that already. It’s not like my code refuses to work
without triple buffering + retrace sync, just because I claim that it
would look better on such a setup.

So, you do what you can and live in the real world.

Or; do your own thing, and don’t even think about trying to improve
things.

I don’t mind doing some driver hacking occasionally, if it gives a
significant number of users better performance. One might argue that
anything less than every single XFree86 user is not a significant number

  • but in that case, why care about any other OS than Windows, at all?

Now, if you want to get me started on why the basic idea of the X
server is wrong… well, I will happily get into that with you. But,
not on this list.

Well, I don’t have any plans on replacing X, nor defending it… If it’s
what most people use, it’s what I hack if I care about more than 5% of
the Linux users. That’s all there is to it.

  Bob Pendleton

P.S.

If you WANT to know about the experience that leads me to my
conclusions, look at the URL just under this line.

Right, that’s rather impressive. :slight_smile:

But you have to realize that I still think it’s a bad idea to waste good
hardware, and that I will try to improve the situation if I can. If it
turns out that it just isn’t possible to solve the problem for a
significant amount of systems, so be it, but as DirectX/Win32 can do it,
I have to assume that it is possible, one way or another.

//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 27 March 2002 22:11, Bob Pendleton wrote: