January 10, 2010 cliffski These probably need to be darker (I might make that configruable per map), but is this better?
Yeah, it’s moving in the right direction! The field parallax when the camera pans around is awesome, even though the asteroids themselves are 2D. The background band seems to be tilted at a different angle (\) than the nearby asteroids (/), which was a little distracting. And the angle of lighting is different for the planet, moon, and asteroids, but that is less noticeable (unless you’re a geek looking for that sort of thing). I’m not sure if it would work with your lighting model, but having explosions brighten nearby asteroids would tie everything together better, like when lightning courses through a large cloud. Star color like red or blue would add some color. Even low saturation tan with random offsets could restore colors without going back to brown. If it works with your fiction, artificial structures on the asteroids would make them fit nicer on screen with high tech spaceships. Asteroid stations, communication antenna, or even simply blinking warning lights could lift the dead feeling they have (although true asteroids are quite barren).
Love the look, allowing some of the stray missiles/projectiles/crashing ships to go into an animation where they crash into an asteroid would also be cool. Or even allowing for some caster/smaller rubble asteroids to careen across the screen/interact with each other would also give you that “Gratuitous” look.
That’s MUCH better, although I think all the asteroids could do with moving as well as just spinning. It would still be really good if you could interact with them, but I guess that would be a lot of work for just a patch.
This belt looks great. Have you tried using camera move instead of zoom? I think it could add even more depth to the asteroids. Also, optional depth-of-field on the asteroids would be great.
Man, the thought occurred to me as I watch you moving the view around the battle. Have you considered a smart camera system? One where there are metrics associated with interactions occurring on the battle, the camera could pan and zoom around focusing on specific high interest engagements always giving the player an exciting and engaging view of the battle. The could break out of it and take manual control of course… I recently did this in one of my own games and it really made the whole experience feel more action packed…
That looks FANTASTIC! I love the clumping into belts. re what Marcin said, DOF would be great. Have you considered using the Mip-bias render state to do super cheap and easy-to-code dof on the sprites? especially if you generate extra-blurry mipmaps yourself, rather than relying on the auto-gen mipmaps you get by default, it can look really awesome. one of the many advantages of a sprite engine over 3d :) I think it’s an old technique, can’t remember where I heard of it first, but mark used it extensively on rag doll kung fu (eg see this screenshot http://guyver-world.ru/pics/ragdollkungfu/big/rag-doll-kung-fu-skin-1b.jpg ) – and only like 1 line of code for the 1st attempt at it – he also used the precomputed lighting trick I mentioned in my last comment :) but I digress….
It’s funny you mention that because I tried it yesterday but I confess it didn’t look good and I gave up on it quite quickly. It seemed (from a quick google) that the mip map bias stuff is really shunned now in favour of shaders to do the same thing, and I’m suspicious of why that has happened. I think the problem I had was the edges. The minute you are forcing yourself to go ‘down’ a map, I get horribly blurry edges, but I may just need to do the outline-hiding alpha-shrinkage thing on the roids to avoid that. I’m more worried about optimising the roid drawing tonight :D
hmm… sod what google says, after all there is a shader instruction tex2DLod and tex2dbias to do exactly this so… bah ;) don’t you *want* blurry edges for dof? with trilinear (ie blended mipmaps) it smooths the transition too… v subtle (floating point) mip map control needed the bottom end… mark & I found that the difference between usable and non-usable was quality mip generation to avoid too many box-filtering artefacts… I think we ended up with a guassian blur rather than a simple 2×2 average, and clamped the border of the texture to always be alpha 0 all the way round, to hide the edges of the sprite box itself…. …but all of that is probably rather irrelevant compared to actually make it go fast :) I’ll shut up now :)