|
Devblog
10th November 2011:In the process of making the planet graphics good in orbit and introducing real star locations and planet orbits, I had inadvertantly wrecked the zoomed-in graphics. I spent most of today fixing that, which actually improved the in-orbit graphics too. I went on to fix the bulding-placement mechanic, which oddly doesn't work when I'm recording with fraps but works every time when I'm not recording.I've never really shown off a video of the game in action, so I decided to include one in this update. Update: New video shows the graphics a little better. You still don't really see the twinkling stars that well and the lighting isn't perfect, but you can see a lot of the stuff that wasn't present in the straight upload. Video of work: Next steps: 8th November 2011:I integrated every single thing to do with the skybox and background rendering into the Skybox class, and as a result I was able to cut out a lot of repeated or no longer needed code. The Skybox generator no longer needs to save each layer of the background as a file and then load it again moments later. The Skybox class now generates the skybox and scene, sets the resulting texturecube, planet and asteroid field etc in a series of static variables and then nulls everything else and garbage collects, thereafter acting as just a container for that information.I fixed the lighting in planet mode by making it use whatever planet is currently in the skybox, and then I made it draw the skybox while in the planet screen. Graphically, the planet and third-person screens are now identical. The planet screen of course has a locked camera and different controls, as it's meant to be a fixed-position satellite in orbit. Both screens are now instantiated in static variables in the main game class, so now I can swap between them by adding and removing them from the screen manager and no loading needs to be done! The switch between the screens is instant, as it needs to be in order to keep the player's attention. Interestingly, since the two screens are graphically identical if you're looking at the planet, I could make the transition between these two screens appear to be completely seamless by automatically turning and moving the camera. That's pretty exciting (well, it's exciting to me :D). Screenshot of work: Next steps: 14th October 2011:I re-introduced planets to the background and developed a new realtime atmospheric glow effect that doesn't rely on bloom. Planets now look just as good in realtime as when rendered once to the background, which is awesome when rotating the planet around the sun or rotating the planet on its axis.I spent most of today tweaking the supernova remnant graphics, which now contain some stars in the middle. So now it looks like a gas cloud with dark holes in the middle where it's collapsed into stars. Some pictures of red ones can be found below, but I can make any colour I want: Screenshot of work: Next steps: 06th October 2011:Using my new system for rendering stars, gas, dust and nebyulae to arrays of textures and then burning htem to the final skybox texturecube, I designed a new process for building the background to look a lot more like the milky way reference images. Background nebulae are drawn, then stars, then gas and the galactic bulge, and finally opaque dust. Some of the dust has been rendered in such a way that it allows some of the red in the background to permeate, creating these blood-red patches of discolouration that looks awesome.One of the most interesting things I've done is to develop a very fast method for rendering hollow nebulae that appear to be almost a random dirty outline of a nebula. This is designed to mimic the gas clouds left by old supernovae. The hollow nebulae are rendered to the background before any stars, and I can render them in any colour or range of colours. Red is the most realistic, but alternatives like green and blue look way more awesome. I was thinking that the colours might be varied depending on game difficulty or a similar factor. Harder game modes might be made to look more scinister through colour, for example. Screenshot of work: Next steps: 25th August 2011:Haven't had much time to work on the project over the past month, but I fixed the rotation problem with stars at the poles. Turned out to be happening because star sprites were lining up perpendicular with the camera, and adding some random rotation to stars solved the problem. I proceeded to rebuild the galaxy skybox generator with a visual target of photographs of the milky way. I built a quick density algorithm that determines the chance of a star existing at a given set of x-y-z rotations. Stars now clump along the galactic plane, with a bulge in the direction of galactic central core.Today I solved the massive problem of applying time-consuming bloom effects and the visual distortion caused by bloom on each skybox face being planar to that face (and therefore view-dependent). Instead of blooming the star cube, I render all stars multiple times, at successively larger sizes but lower alpha. The resulting blended stars look very much the same as post-processed bloom effects but the effect is entirely view-independent and so the edges of the skybox are never visible. As I've managed to cut the build time for the star phase down considerably, I can afford the extra draw time to do this instead of blooming. I built a system for rendering star/nebula handlers to an array of 6 textures, then a second system for burning the textures to the final skybox texturecube. This allows proper subtractive blending and lets me easily change the order in which things are burned to the skybox to see what works best. Screenshot of work: Next steps: 27th July 2011:Over the past few years, I've spent my spare time developing various graphics rendering technologies. The first was a galaxy skybox renderer, which at its simplest renders stars to the six faces of a cube for use as a 3D skybox in a game. People online talked about rendering to a skybox as if it would be trivial, but I had a lot of trouble getting it right. Because I'm a stubborn bastard, I worked at it and eventually produced a solid implementation. After that, I set my sights on developing new terrain rendering techniques, a procedural planet renderer, tiling choherent 2D and 3D noise generators and other systems. A lot of people told me that the ideas I had wouldn't work, but through that same stubbornness I worked at them for months and eventually got them all to work. Having already done the impossible, I'm pretty confident in my ability to continue development.I've always planned to use these technologies together in a game, and have filled books with notes and idea but have not been able to get the time together to produce something complete or playable. I'm also constantly tempted to go back and change graphics rather than working on gameplay. With that in mind, I've started this "untitled space game" project and have recruited a few other people to help in their spare time. Between us we should be able to bang something out. Screenshot of work: Next steps: |