ANNC: smoothscroll

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

You’re not using LCD panels, are you…? :wink:

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.

This is getting interesting… What exactly does “without the inlines”
mean? Can you describe this “shimmer effect”?

Disabling the console window (building for subsystem
windows) reduces the occurrences of frame jumping.

Strange. Does that make Windows treat the program differently, apart from
the actual console stuff…? (There shouldn’t be any console output while
scrolling - please verify that there isn’t.)

However enabling
Vsync doesn’t appear to change anything.

As expected, actually - especially on very fast cards.

If you scroll at very high speeds (use the arrow keys), you might be able
to see some tearing without Vsync, while there shouldn’t be any tearing
with Vsync. The sub-pixel accurate rendering virtually eliminates visible
tearing in lower scrolling speeds.

//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:27, Kisai wrote:

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

You’re not using LCD panels, are you…? :wink:

I wish. No I’m not using LCD panels.

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.

This is getting interesting… What exactly does “without the inlines”
mean? Can you describe this “shimmer effect”?

When I first downloaded the code and had the inline problem I just
stripped the inline keyword from everything. When it ran, it appeared
smooth except for a slight shimmer effect from what I’d assume is from
the texture filtering. To try and describe it, it looks like the pixels
were moving closer and away from the monitor glass just enough. I don’t
know, I could be seeing things…

Disabling the console window (building for subsystem
windows) reduces the occurrences of frame jumping.

Strange. Does that make Windows treat the program differently, apart
from
the actual console stuff…? (There shouldn’t be any console output
while
scrolling - please verify that there isn’t.)

No output other than when it first starts.

However enabling
Vsync doesn’t appear to change anything.

As expected, actually - especially on very fast cards.

If you scroll at very high speeds (use the arrow keys), you might be
able
to see some tearing without Vsync, while there shouldn’t be any
tearing
with Vsync. The sub-pixel accurate rendering virtually eliminates
visible
tearing in lower scrolling speeds.

IMO, the shimmer effect could also be from the sub-pixel accurate
rendering, but the monitor being a royal piece of junk (It’s 10 years
old, oldest piece of equipment I have.)

The other computer with the radeon didn’t appear to have the shimmering
effect (It has a new monitor, less than 2 years old.)_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

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

You’re not using LCD panels, are you…? :wink:

I wish. No I’m not using LCD panels.

Ok. (BTW, I actually prefer a really good CRT, for various reasons.)

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.

This is getting interesting… What exactly does “without the
inlines” mean? Can you describe this “shimmer effect”?

When I first downloaded the code and had the inline problem I just
stripped the inline keyword from everything. When it ran, it appeared
smooth except for a slight shimmer effect from what I’d assume is from
the texture filtering. To try and describe it, it looks like the pixels
were moving closer and away from the monitor glass just enough. I don’t
know, I could be seeing things…

No, that effect is very real, and more obvious in lower resolutions. It’s
the result of the texture filtering and the screen’s gamma function not
matching perfectly, and it’s pretty hard to do anything about. (Tweaking
the gamma correction tables might help a bit, though…)

Anyway, if that’s the only “side effect” you’re seeing, things are
working correctly. :slight_smile:

Disabling the console window (building for subsystem
windows) reduces the occurrences of frame jumping.

Strange. Does that make Windows treat the program differently, apart
from
the actual console stuff…? (There shouldn’t be any console output
while
scrolling - please verify that there isn’t.)

No output other than when it first starts.

Ok.

However enabling
Vsync doesn’t appear to change anything.

As expected, actually - especially on very fast cards.
If you scroll at very high speeds (use the arrow keys), you might be
able
to see some tearing without Vsync, while there shouldn’t be any
tearing
with Vsync. The sub-pixel accurate rendering virtually eliminates
visible
tearing in lower scrolling speeds.

IMO, the shimmer effect could also be from the sub-pixel accurate
rendering, but the monitor being a royal piece of junk (It’s 10 years
old, oldest piece of equipment I have.)

Might be. Old and/or cheap monitors generally seem to have “worse” gamma
characteristics.

The other computer with the radeon didn’t appear to have the shimmering
effect (It has a new monitor, less than 2 years old.)

Right. It might also have to do with how the card implements texture
filtering. (Seems like some aren’t really using plain bilinear
interpolation.)

BTW, I’m not seeing any of that above 320x240 mode on the G400/F980
combo. Probably to be expected from that card (great 2D + rendering
quality) and a monitor that’s supposed to be usable for color
calibration…

Anyway, I’m still rather interested in what’s going on with the
inlines… 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 27 March 2002 23:31, Kisai wrote:

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.

Sorry to contradict you, but it does !

The existing ANSI C is also known as C99 and it does suport inline.
The problem is that most compiler development companies are more interested
in making their compilers ANSI C++ compliant that upgrade their C support.


Paulo Pinto (aka Moondevil in demoscene)
pjmlp_pt at yahoo.comhttp://www.progtools.org
“If you think education is expensive, try ignorance” - Derek Bok


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

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

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

[…]

the existing ANSI C doesn’t support inlines at all.

Sorry to contradict you, but it does !

The existing ANSI C is also known as C99 and it does suport inline.
The problem is that most compiler development companies are more
interested in making their compilers ANSI C++ compliant that upgrade
their C support.

Right; I should have pointed out that I basically find C99 completely
irrelevant until it’s a de facto standard.

Or should I just ignore Visual C++, .Net and others, just because my
compiler of choice happens to support at least some C99 features…?

//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 Thursday 28 March 2002 11:09, Paulo Pinto wrote:

Hi *

Now this is a somewhat late reply, but anyway…

Considering all that buzz about smooth scrolling in the last time, I decided
to try and roll my own in a pet project of mine. Turns out that the
difference of subpixel accurate rendering is much greater than I expected. In
fact, I was quite confident with what I had before, until I first ran the
game real smooth. So in the end, you managed to convince me :slight_smile:

Anyway, I was curious whether we ended up with the same solutions and
downloaded smoothscroll. And the comparison turned out with interesting
results.

smoothscroll uses the pretty straightforward method of just rendering all
tiles as quads, with float coordinates. Fair enough, and that’s what I had at
first.

Now what I’m working at is kind of a Raptor clone, and the tiles can be
rather bright in places. I got a rather annoying flicker, or shimmer, where
the tiles met. Maybe this is what someone else described earlier in this
thread, I don’t know.

Anyway, what I finally ended up with is, well, “interesting”. I added a 1
pixel transparent border around the tile graphics inside the texture. Then, I
render the tile quads 1 pixel wider than they actually should be. This means
that the tiles are actually overlapping each other, but the overlapping parts
are transparent. Now this flickering/shimmering effect is gone.

I guess one can’t see the effect in smoothscroll because the tile edges are
basically black.

Any comments on that?

cu,
Nicolai

Hi *

Now this is a somewhat late reply, but anyway…

Considering all that buzz about smooth scrolling in the last time, I
decided to try and roll my own in a pet project of mine. Turns out that
the difference of subpixel accurate rendering is much greater than I
expected.

Actually, I was a bit surprized myself that it had such great effect even
without sync’ed flips, and that it reduces the inevitable tearing on such
setups as an extra bonus. Indeed, it takes h/w acceleration, but it does
make a difference, and not just to rendering speed.

In fact, I was quite confident with what I had before, until
I first ran the game real smooth. So in the end, you managed to
convince me :slight_smile:

Good! :slight_smile: My eyes are starting to hurt from all this tearing and
jittering in “modern” games…

Anyway, I was curious whether we ended up with the same solutions and
downloaded smoothscroll. And the comparison turned out with interesting
results.

smoothscroll uses the pretty straightforward method of just rendering
all tiles as quads, with float coordinates. Fair enough, and that’s
what I had at first.

Yeah, that’s the easy solution. I didn’t want to use any more
sophisticated “tricks”, as that would make the code a lot harder to
understand.

Now what I’m working at is kind of a Raptor clone, and the tiles can be
rather bright in places. I got a rather annoying flicker, or shimmer,
where the tiles met.

Yeah, you can’t just merge tiles together in any way you like. Look
carefully at the “tile palette” texture of my demo, and how the tiles are
used. If you use the map editor to make a map that breaks the rules,
you’ll see the very same effect. (It’s not really a matter of brightness

  • although the bigger the “incompatibility” between adjacent tiles, the
    more obvious the flicker.)

The problem is that the pixels around each tile matter, so it’s
important how tiles are placed on the tile palette textures. If you check
the TODO file (Unix end-of-line format - use something more sophisticated
than Notepad if you’re on Windows), there’s some info on this, and IIRC,
I describe one or two approaches to deal with it.

Maybe this is what someone else described earlier
in this thread, I don’t know.

No, that’s a different problem, which is caused by the fact that texture
interpolation isn’t always as gamma correct as one would want it to be,
and more commonly, that card/monitor combos usually aren’t gamma
calibrated. You’ll see that effect even if you’re just scrolling a
single, huge texture, and there will be more of it if there are small
details and/or bright/sharp transients in the image.

Anyway, what I finally ended up with is, well, “interesting”. I added a
1 pixel transparent border around the tile graphics inside the texture.
Then, I render the tile quads 1 pixel wider than they actually should
be. This means that the tiles are actually overlapping each other, but
the overlapping parts are transparent. Now this flickering/shimmering
effect is gone.

Right, that’s the first solution I considered when I first started
playing with OpenGL and 2D - but that way requires that the tiles are
completely rendered with alpha blending. No big deal with a modern 3D
card, probably, but I’d rather use that power for other stuff. :slight_smile:

I guess one can’t see the effect in smoothscroll because the tile edges
are basically black.

Well, almost! :slight_smile:

The blue “construction” tiles have everything but black edges, BUT,
they’re drawn to fit together, on the map (of course) as well as on the
tile palette; the latter being the important and rather non-standard
part. If you look at the tile palette, you’ll notice that every single
tile is placed so that adjacent tiles provide the border pixels that are
necessary to get interpolation right.

//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 Friday 29 March 2002 19:51, Nicolai Haehnle wrote: