DevLog #5 - Stars make-up

posted in StarDust DevLog
Published June 16, 2011
Advertisement
I got a bit bored with all the tiny dots covering approximately same area on screen with no real comparable differences in sizes and so I played a bit with the flare appearance on the distant stars. The result are visible differences in sizes. Some stars now are really looking brighter than others.

Each star has a flare (or glow) around its surface, that is increasing with the star getting further from camera. A star that is quite close can have this glow radius of about 7x its body radius. This makes a fairly large glow around star body, but not covering whole screen (remember the video with orbiting planet from previous dev log?). However stars that are many light years away can have this glow increased hundreds or even thousands of times. This increase is crucial to make distant star still visible. If the glow would remain of same size, then even if just a light year away it wouldn't be sufficient to cover a fragment of a single pixel on the screen.

starglowr.jpg

The glow has fixed size at the end for the star visibility radius. This size is 4 pixels (in diameter) on screen to secure the star is visible at least a bit before it completely disappears. It prevents a flickering of tiny distant dots over the black background. From the FOV, current screen settings (width and height) and the maximum visibility distance is calculated how large the flare/glow must be to have these 4 pixels on the screen. The actual size of flare/glow is then calculated as interpolation of the 7x body radius and this 4-pixels calculated radius.

Just this technique secures you can see distant stars as tiny dots which won't disappear because they would be too small for a pixel on screen. However all the dots would appear of being same tiny size. In a very short distance the star would be so small that it would be held on screen mostly by that 4 pixels fixation and the differences of sizes between stars would be +/- 1 or 2 pixels. To make the sizes of distant stars really comparable and the sky looking nicer (at least by my oppinion) the interpolation of glow size of star is made only in the closer half of maximum visibility radius, i.e. the glow will grow from distance 0 to distance 1/2 of visibility range. The size of glow in the 1/2 visibility range distance is that size calculated as would-be-4-pixels-if-at-the-end. This would-be-4-pixels glow is then fixed and remains of same size from 1/2 of visibility range to the end of visibility range. So at the end the star has the required 4 pixels on screen, is growing when you are getting closer because the glow is not reducing in size, and once you get close enough, the glow finally begins to reduce to fit the star body radius when you get really close to it.

Last improvement so far is a small flickering of the stars. This makes the screen looking more lively and attractive. It has been done by using a random modifier (from 0.9 to 1.1) on the star glow size. Mabe it won't stay in the game in the end since flickering stars are not realistic, but for now it is adding a fine touch to the sky.

I've tweaked a bit the star generator parameters finally to get a screen filled with more final amount of stars. There are now about 5000-7000 stars present in 360? around the observer, so an amount that is agreed to be visible by a naked eye from Earth (under optimal conditions). The frame rate dropped rapidly as I expected. So far I didn't have FPS counter displayed, so I didn't know the exact number until very recently. The frame rate fell down to 0.9 FPS. Although I am working on an older piece of HW, it's very bad result. I was tracking the cause and found out that even without the star draw implementation, the manupulation code serving the star draw calls is by itself already reducing the frame rate to 3.2 FPS. After removing pieces of code here and there I have found the major limiter - iterator through STL vector. After replacing it with old good "for" loop the FPS went up by 10 times.

// 7000 elements in array/vector

// Iterating through vector of stars (FPS 3.2)
for (vector::iterator i = stars.begin(); i!=stars.end(); i++) {
(*i)->draw(microseconds, cameraPos);
}

// Old style iteration with direct access to vector (FPS 23)
int count = stars.size();
for (i = 0; i < count; i++) {
stars->draw(microseconds, cameraPos);
}

// Old style iteration and array (FPS 32)
C_Star stars[];
for (i = 0; i < count; i++) {
stars->draw(microseconds, cameraPos);
}


Well, that closes up this weeks update. Hope to see you next time again.

Petr Marek
1 likes 2 comments

Comments

swiftcoder
I know this post is from a while back, but I wanted to mention that the performance differences you are seeing between vector iteration and a for loop over an array, are simply not possible unless you are testing your performance in a debug build.

I would be interested to see the same numbers for an optimised release build, with [url="http://msdn.microsoft.com/en-us/library/aa985965(v=vs.80).aspx"]checked iterators disabled[/url]...
August 23, 2011 03:46 PM
KaRei
Ouch, forgot to switch to Release configuration, hehe :lol:
I'll take one more look on the vectors and will bring updated numbers.

Thanks for your comment :wink:
August 23, 2011 04:24 PM
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!
Profile
Author
Advertisement
Advertisement