Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

DarkBASIC Professional Discussion / Pixels brighter when stationary

Author
Message
Naphier
13
Years of Service
User Offline
Joined: 2nd Oct 2010
Location: St Petersburg, Florida
Posted: 27th Nov 2011 22:23
Hi everyone. I just ran through the TGC tutorials on parallax starfield animation using memblocks.
I was messing around to see how many stars I could have before getting screen issues and around 40,000 I start to get lines in the screen, like when you try to take video of a CRT.
What is that called?

The second, more interesting part of this is that I added keyboard controls to change the direction of the spacefield's movement and the stars are much brighter when stationary. Is this just on my computer or is it something that is in the program.

Here's the code:



As always thanks for the expert advice and assistance!!!



~Napland Games~
WLGfx
16
Years of Service
User Offline
Joined: 1st Nov 2007
Location: NW United Kingdom
Posted: 27th Nov 2011 23:32
This seems to be something you'll have to put up with. Does the same on my laptop here too...

I ran that and it reminded me of some of the old tricks I used to the Atari ST and Amiga using Planar effects. Brought back memories that did...

Mental arithmetic? Me? (That's for computers) I can't subtract a fart from a plate of beans!
Warning! May contain Nuts!
Pincho Paxton
21
Years of Service
User Offline
Joined: 8th Dec 2002
Location:
Posted: 28th Nov 2011 15:19 Edited at: 28th Nov 2011 15:19
If you make the speed 0.01, then the stars are much whiter. So that must mean something?

Naphier
13
Years of Service
User Offline
Joined: 2nd Oct 2010
Location: St Petersburg, Florida
Posted: 28th Nov 2011 15:40
Well the main loop shouldn't affect the color of the stars or their brightness in the sense of color.

The speed affects how many pixels they move per loop, so maybe keeping them close together keeps the adjacent LCD pixels warm.

I'll test it on my high contrast LED screen later this week to see if it is the monitor hardware.

I'll probably overcome this issue by not allowing the pixels to stop moving and just increase the speed with the player's movement instead of letting it stop altogether.

~Napland Games~
WLGfx
16
Years of Service
User Offline
Joined: 1st Nov 2007
Location: NW United Kingdom
Posted: 28th Nov 2011 15:43
If this effect is going to be part of a game then I wouldn't worry about the need to fix it as it is very likely to be moving over 99% of the time anyway. I think it works perfect and looks just right as it is.

Mental arithmetic? Me? (That's for computers) I can't subtract a fart from a plate of beans!
Warning! May contain Nuts!
Cybermind
Valued Member
21
Years of Service
User Offline
Joined: 28th Nov 2002
Location: Denmark
Posted: 28th Nov 2011 16:49
Here there is no difference as far as I can see.

The byte chrunchers are coming...
DIVIDING BY ZERO/BECAUSE WE SUCK...
Grog Grueslayer
Valued Member
18
Years of Service
User Offline
Joined: 30th May 2005
Playing: Green Hell
Posted: 28th Nov 2011 17:18
It's because of the human eye. The light from stationary pixels reach our eyes better because their in the same place longer. Moving pixels have less less light reaching us because our eye sees the white for a few milliseconds and the black in that same spot for a few milliseconds too. To solve it you can do what Pincho Paxton suggested or have everybody that sees it get cybernetically enhanced eyes.

Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 28th Nov 2011 17:18 Edited at: 28th Nov 2011 17:20
Very noticeable difference here - and I think the reason is simple.

When the stars are stationary you see white dots against a black background. But when they move the eye does some sort of averaging so since a given pixel is black most of the time but white only some of the time the average the brain sees is grey.

If you slow things down by using, say, sync rate 5 with sync instead of fastsync then you see the full brightness as the pixels move.

It's possible the averaging is a byproduct of the display construction rather than the way the human eye works - but either way the effect is the same.

Edit Grog beat me to it! I seem to be having a sluggish day.
Naphier
13
Years of Service
User Offline
Joined: 2nd Oct 2010
Location: St Petersburg, Florida
Posted: 5th Dec 2011 15:57
Well I've done some testing on this with various equipment and can say with certainty that it is not a visual illusion, but indeed related to monitor hardware.

Depending on the window's resolution vs. the monitor's resolution you will see different stars actually blink out since there is no pixel on the screen to write them to. I'm assuming this has to do with the pitch of the screen. I've tested on 6 different monitors with different resolutions with various results.

My biggest concern is this:
When testing on a dual screen setup one screen the stars would move at about 1/4th the speed of the other screen. There are a few differences in technical specifications between the monitors as well as resolution.

I would think that since both of the monitors use the same GPU and the same CPU that there would be no difference in the speed of which the pixels move, but there is such a significant difference in speed I have to assume it is the game engine.

So how do I get around this?
If I want the stars to move at the same speed on all machines, what hardware specification do I need to measure?


I tested a dbpro game (attached) on the same machine that shows the difference in speed between the two monitors and the game is smooth on one monitor and slightly jittery on the other as well as runs about 1/4 the speed.

I'm hoping this issue is isolated to this machine (which I now see is on a cable to split the monitors, and the video card is not dual output, and the faster, smoother, monitor is the primary).

Attachments

Login to view attachments
Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 5th Dec 2011 17:14
Quote: "not a visual illusion, but indeed related to monitor hardware."


I think you'll find that it's not only a visual illusion, but indeed also related to monitor hardware.

If the pixels in the painted image match up exactly with the screen pixels (as in my versions of your demo) then there will be no blinking out, just the time averaging or the jumping effects I described depending on the framerate used.
Naphier
13
Years of Service
User Offline
Joined: 2nd Oct 2010
Location: St Petersburg, Florida
Posted: 5th Dec 2011 17:30
I think the bigger difference is in the hardware, else I would have experienced similar dulling of the stars' brightness. Beside, they're moving ultra slow.

My bigger concern still exists:
How to normalize the speed of movement on different video hardware?

The jumping is OK and I think actually pretty cool looking.
But if I wanted to get rid of it, it would be nice to know what hardware spec I need to measure to do so.

Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 5th Dec 2011 18:28
Don't you just need to decide how much of the screen you want everything to shift per second and then divide by the frame rate to get the actual shift?

For example, if your screen width is 800 pixels and you want everything to move at 8 pixels per second, i.e. 1% of the screen width, and the frame rate is 40 fps then you need to move 0.2 pixels per frame. You'd need to work with floats and round the final position of course, otherwise a change of 0.2 will just become a change of 0.
Naphier
13
Years of Service
User Offline
Joined: 2nd Oct 2010
Location: St Petersburg, Florida
Posted: 5th Dec 2011 19:56
That's how it is going now.
The problem is that if it moves 8 pixels per second on one screen it is moving 2 pixels per second on a different screen.

Regarding the Parallax starfield code:
After some testing the difference in speed is caused by the use of fastsync. I put in a sync rate of 40 and used sync instead of fastsync and there is no perceptible difference between the two monitors.


The game, space duel, however, is not using fastsync.
I've monkeyed around with the sync rate in the Space Duel program (see attached rar for code and media) and no matter what it is smooth and fluid on the primary monitor, but if I move the window to the secondary monitor then the movement of the sprites as well as the stars slows to about 1/2 speed and becomes jittery.

I think this is due to the difference in resolution between the two monitors. The primary monitor has a resolution of 1680x1050 and the secondary monitor has resolution of 1920x1080. But the program is windowed, so I wouldn't think there would be an issue as the window should retain its own resolution, or no? Shouldn't Direct X compensate for this?

I'm very hungry to learn more about this effect.

And thanks for helping to stretch my brain, Green Gandolph.

Attachments

Login to view attachments
Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 5th Dec 2011 21:13
Quote: "The problem is that if it moves 8 pixels per second on one screen it is moving 2 pixels per second on a different screen."


Ah! I overlooked that part of the problem.

Is it possible to use the same, or very similar, screen resolution on both monitors?

Quote: "but if I move the window to the secondary monitor then the movement of the sprites as well as the stars slows to about 1/2 speed and becomes jittery."


That's interesting. On the few occasions I've used a second monitor, a large screen for example, I see exactly the same on each screen simultaneously when I work with 3D - but not when I use 2D. For example, I recently gave a talk on terrains where I'd used sprites to display various text images against the various 3D terrain backgrounds. I'd made adjustments to the sprite scales so they occupied an appropriate part of the screen on my laptop (in terms of pixels). But when it came to the talk itself, the display screen used a lower screen resolution so my text boxes obliterated rather a large part of the terrain I was trying to demonstrate.

Sounds like your problem is a variant of the same issue. In future I'll use probably 3D plains locked to the screen rather than 2D sprites or something similar. Unfortunately I don't think I can test various options here - but at least I'm aware of the issue now.

Can you organise your code so the final display uses 3D plains instead? That could be the answer - although I admit I'm not sure.

Quote: "And thanks for helping to stretch my brain, Green Gandolph."


You're welcome. These issues work both ways.
WLGfx
16
Years of Service
User Offline
Joined: 1st Nov 2007
Location: NW United Kingdom
Posted: 5th Dec 2011 21:26 Edited at: 5th Dec 2011 21:27
The problem with dual monitors mainly is that as default your main monitor receives the GPU acceleration. If you're planning on having your software running on another monitor then you will have to set that monitor as the default in your display settings. I tried and tested that some time ago and it worked. That's the reason for you getting the 1/4 speed on the other monitor. Extra monitors are classed as a separate device.

Apart from that good look with your parallax star field effect. 99.9% of monitors will show brighter pixels whilst stationary over more than one sync update. And I doubt much can be done either with 3D planes to counter the problem. The only way around it is to make sure they are constantly moving.

Mental arithmetic? Me? (That's for computers) I can't subtract a fart from a plate of beans!
Warning! May contain Nuts!
Naphier
13
Years of Service
User Offline
Joined: 2nd Oct 2010
Location: St Petersburg, Florida
Posted: 5th Dec 2011 21:39
@Gandalf
I tried changing the secondary monitor to the same resolution as the first and the display is weird with 1/3 missing and the horizontal smooshed together. The effect persisted, so this may go beyond simply the resolution and may be more of a video card issue with this particular PC.

I tried having the window overlap both screens and the result is that the game gets jittery as if it were solely on the second screen. Weird, but if I had to choose between two rates I would choose the lower of the two and that seems to be what the PC is doing.

I'll try some variations at home tonight and report the results.

Unfortunately I'm not versed in 3D commands yet so I've no clue how to code this with 3D sprites. Perhaps it will be my first project in 3D. It might be awhile since I'm working on a rail shooter project that I plan to be my first independent creation.
I'd love to be able to create a game that utilizes dual monitors some day and this will be a hurdle. Not that I'm afraid of hurdles.

@WLGfx
I thought something like that might be the case. I'm curious to see what happens with dual monitors on separate GPUs (actually crossfired, but might work separately?)...
The 3D planes that Gandalf suggest would help deal with the slower rate on the secondary monitor, or I believe that is what he thinks.
The parallax on its own doesn't seem to have an issue (probably because on its own it is direct draw to video memory). It did, however have and issue when I was using fastsync and no sync rate.


I'll check out some other games not built with DBPro and some built with. I know many have different issues, but many don't. For example, Left 4 Dead 2 I can switch to either screen at home with no issue, but Alien vs. Predator just sort of locks up.

Thanks guys, this is all quite educational and interesting.

Naphier
13
Years of Service
User Offline
Joined: 2nd Oct 2010
Location: St Petersburg, Florida
Posted: 6th Dec 2011 00:10
OK so WLGfx is on to something.

I went home to my dual radeon HD5830 video card driven (crossfire mode) and dual screen of exact type and here's what happened:

First, I ran the parallax starfield on its own and there was no difference in speed from one screen to the other. There was no difference in brightness from one screen to the other (LED backlit helping?). I stretched the window across both screens and it was beautiful, no problems whatsoever. I could notice the pixels jumping due to float to integer conversion, but it was really only noticeable when it was stretched across two screens and the program's resolution was 1/2 the width of the stretched window (i.e. I imagine the stars were occupying > 1 pixels frequently).

Second, I ran the Space Duel program with the same tests. It was beautiful. Just need to add some sprites for nebulae and galaxies.
My god it's full of stars

At any rate it seems the biggest influence is the hardware.
I'm not sure how I'll work out the kinks with a dual screen program in the future, but I can say that using fastsync is not desirable and using an actual sync rate is.

Hopefully by the time I design a dual monitor game people will have dual core GPUs that can easily handle both of the monitors and not give the majority of resources to the primary.

I don't think there's much reason for me to test other DBPro games on my dual monitor set up since I'll likely not be able to reproduce this problem.

Thanks again for the help everyone.
On to the next oddity I can find!

Login to post a reply

Server time is: 2024-04-26 07:14:32
Your offset time is: 2024-04-26 07:14:32