Mayfly Studio

Jan 08

Okay, this bit of the space engine is sort of working again too, emphasis on “sort of.” There should be a shadow on the rings, and there kind of is, except the lighting direction in the engine is simply broken and so the whole thing looks dark. Man, there’s nothing I love more than fighting with broken light direction calculations in OpenGL/GLSL. Wait a minute, not “love,” what’s that word…
As a side note, the Jovian planet generation isn’t nearly as sophisticated as the terrestrial planet stuff. Yes, it does use a 1D texture for cloud bands and a 3D texture for detail and blah blah blah, but the actual color/noise parameters are hardcoded right now. It would be fun to add code for generating Jovian planets which took into account the size of the planet and the heat delivered to the planet (or even generated by it) to come up with the cloud bands. Off the top of my head I’d judge that a larger planet receiving more heat from the sun will have a more dynamic atmosphere, with larger, more contrasty cloud bands containing more swirly detail. As the planet got colder and smaller, the atmosphere would be less active until you reached largely featureless gas giants like Uranus. As for color, that would be mostly random (the varying colors of gas giants in our own Solar System are due to trace gas proportions) but as we edged up towards brown dwarf category the planet would become more red due to its own radiation.
It’d also be good to add a system for generating a few storms, Great Red Spot-style; way back in the day when I was fooling around with ray-traced planet generation in a more realistic style, I had some nice tricks that should drop right in to a shader for adding good-looking storms. Like here, see?
There’s actually a huge variety of things I’d like to do in this engine now. That may be a bad thing as I could just be paralyzed between them and go do something else. Gonna wager on that being the final outcome here.

Okay, this bit of the space engine is sort of working again too, emphasis on “sort of.” There should be a shadow on the rings, and there kind of is, except the lighting direction in the engine is simply broken and so the whole thing looks dark. Man, there’s nothing I love more than fighting with broken light direction calculations in OpenGL/GLSL. Wait a minute, not “love,” what’s that word…

As a side note, the Jovian planet generation isn’t nearly as sophisticated as the terrestrial planet stuff. Yes, it does use a 1D texture for cloud bands and a 3D texture for detail and blah blah blah, but the actual color/noise parameters are hardcoded right now. It would be fun to add code for generating Jovian planets which took into account the size of the planet and the heat delivered to the planet (or even generated by it) to come up with the cloud bands. Off the top of my head I’d judge that a larger planet receiving more heat from the sun will have a more dynamic atmosphere, with larger, more contrasty cloud bands containing more swirly detail. As the planet got colder and smaller, the atmosphere would be less active until you reached largely featureless gas giants like Uranus. As for color, that would be mostly random (the varying colors of gas giants in our own Solar System are due to trace gas proportions) but as we edged up towards brown dwarf category the planet would become more red due to its own radiation.

It’d also be good to add a system for generating a few storms, Great Red Spot-style; way back in the day when I was fooling around with ray-traced planet generation in a more realistic style, I had some nice tricks that should drop right in to a shader for adding good-looking storms. Like here, see?

There’s actually a huge variety of things I’d like to do in this engine now. That may be a bad thing as I could just be paralyzed between them and go do something else. Gonna wager on that being the final outcome here.

Aw, you caught me. I’ve been spending an hour each night or so getting that old painterly space engine I was working on up and running again, which also involved fixing bugs in code that hadn’t been exercised by A. CYBORG.
(Protip: you need to explicitly call a function to generate mipmaps in OpenGL these days. Also it’s not enough to just know that, you have to actually do it.)
To recap, what you see here is a system which generates the planet textures entirely in pixel shaders by combining 3D noise with a definitional texture that indicates the colors to use for various altitudes and latitudes. The definitional texture itself can be generated procedurally based on the planet’s size and insolation (heat received from the sun) so you can have Mercury, Mars, Pluto, Earth, or anything in between. Meanwhile, clouds are defined by another 3D noise texture which moves slowly “through” the planet, creating the illusion that they grow and move over time.
It’s risky to make any predictions given my past performance, but there’s definitely a lot of stuff I’d like to do once I’m sure the rest of this functions. I’d like to use glDepthRange to allow optimal draw order and make render queries useful even with multi-world scenes, so the scene can blow out when you look at the Sun. It might be fun to actually implement stencil shadows from scratch for the player’s ship, which will also involve busting out Blender again to make a proper cockpit. Getting more space-y, I have some thoughts for swirling the texture coordinates to make clouds that look more like from-space-clouds and less like weird amoebae. Oh, and also that galactic nebula in the background looks like poo. Eh, we’ll see what happens.

Aw, you caught me. I’ve been spending an hour each night or so getting that old painterly space engine I was working on up and running again, which also involved fixing bugs in code that hadn’t been exercised by A. CYBORG.

(Protip: you need to explicitly call a function to generate mipmaps in OpenGL these days. Also it’s not enough to just know that, you have to actually do it.)

To recap, what you see here is a system which generates the planet textures entirely in pixel shaders by combining 3D noise with a definitional texture that indicates the colors to use for various altitudes and latitudes. The definitional texture itself can be generated procedurally based on the planet’s size and insolation (heat received from the sun) so you can have Mercury, Mars, Pluto, Earth, or anything in between. Meanwhile, clouds are defined by another 3D noise texture which moves slowly “through” the planet, creating the illusion that they grow and move over time.

It’s risky to make any predictions given my past performance, but there’s definitely a lot of stuff I’d like to do once I’m sure the rest of this functions. I’d like to use glDepthRange to allow optimal draw order and make render queries useful even with multi-world scenes, so the scene can blow out when you look at the Sun. It might be fun to actually implement stencil shadows from scratch for the player’s ship, which will also involve busting out Blender again to make a proper cockpit. Getting more space-y, I have some thoughts for swirling the texture coordinates to make clouds that look more like from-space-clouds and less like weird amoebae. Oh, and also that galactic nebula in the background looks like poo. Eh, we’ll see what happens.

Dec 26

My, where does the time go?

I’m on Christmas break from my real job right now, and had hoped to spend much of it on gamedev. Yeah, that didn’t happen. I suspect I’ve been burning the candle at a bit too many ends, judging by all the lying in bed until noon and accomplishing nothing that’s been going on up in here. That aside, I’ve at least added some infrastructure for tracking score and mission progress to A. CYBORG. Really basic stuff, but it needed to get done. Enemies are now divided into types, a particular type and quantity can be set as the current mission target, and progress is tracked as the player shoots down enemies of that particular type. With that in, it would seem to make sense to get the UI stuff I was working on a little while ago functional and wire it all together.

Feelin’ that dangerous urge to switch projects again, though…

Dec 15

Status Update Of No Particular Import

Did some A. CYBORG stuff today, specifically trying to implement a KO/death/whatever state. Yes, sad as it may be to contemplate, our daring heroine can get shot down — don’t worry, though, she’s a cyborg after all! A couple hours in the shop and she’s good as new. The real sad part of this situation is that I have to code it, and it’s been more difficult than anticipated. There are two reasons for this:

  1. The main tick loop for the avatar, while not too long by some standards, is still a mess of ugly hacks: unsurprising, as some of it dates back years to my first efforts fooling around with the sprite landscape. Camera control is in there with a raft of magic numbers that are hard-glued to the character position, there’s a whole section which handles autopiloting when transitioning between levels, all the user control handling is in there as well, nothing is properly encapsulated. Adding additional conditional clauses on top of that mess to handle falling/crashing made it even worse. It runs, but basically it’s completely unsustainable and needs to be rewritten.
  2. The scaling issues that I’ve run into from time to time get especially bad here. It’s not obvious from the screenshots, but the scale of the game is more or less “realistic” — if you assume that A. CYBORG is of average height, the enemy planes are correctly many times larger than her, landscape elements are roughly the correct size and so forth. Compared to the volume of space she can move around in, the heroine is tiny, and we can only keep track of her at all because the camera is glued to her. But doing that when she’s supposed to be on fire and falling to the ground means the camera jams right into the ground itself, and for obvious reasons the ground in this game does not stand up to close inspection! I managed to bang out something which more or less works to keep the camera well back while she’s crashing, but the scale is just a frustration and not really something I can change.

I think that if I can get the tick function into some sort of tolerable state, I’ll feel a lot better about the rest of it. All the random stuff going on in there needs to be split away and a proper state machine set up for handling and blending player motion, as well as camera behavior, under different conditions.

Dec 14

I had to return Mr. Eldridge’s gesture and draw a picture of Stevie from Frost - Bone - Ember. It turns out that I am only drawing pixels these days! And furthermore, it was a lot of fun.
As a side note this character could not be more ’80s if she was wearing leggings and listening to a Mister Mister album.

I had to return Mr. Eldridge’s gesture and draw a picture of Stevie from Frost - Bone - Ember. It turns out that I am only drawing pixels these days! And furthermore, it was a lot of fun.

As a side note this character could not be more ’80s if she was wearing leggings and listening to a Mister Mister album.

Dec 11

wesleyeldridge:

I was messing around at work the other day and busted out a few quick fan art sketches for A. CYBORG!  My take skewed a little bit more sci-fi then I think Mr. Sachs is going for. I’m really looking forward to it though and hope is has a chance to finish it!
Check out A. CYBORG and Mark Sachs’ other projects on Mayfly Studio’s tumblr! http://mayflystudio.tumblr.com/

:D

wesleyeldridge:

I was messing around at work the other day and busted out a few quick fan art sketches for A. CYBORG!  My take skewed a little bit more sci-fi then I think Mr. Sachs is going for. I’m really looking forward to it though and hope is has a chance to finish it!

Check out A. CYBORG and Mark Sachs’ other projects on Mayfly Studio’s tumblr! http://mayflystudio.tumblr.com/

:D

(Source: prismaslice)

Dec 10

Gettin’ my font on so A. CYBORG can have an in-game HUD. Past experience suggests that will make it feel more like a Real Game (tm), and having a way to deliver meaningful feedback to the player should also encourage me to work on the level structure.
Since my rush to implement a half-assed skin chooser interface on Saturday, I’ve been going back into the code and reimplementing things in a more fully assed way. Part of that has meant dealing with sections of the code that I’ve just never gotten around to fixing up. For example, I only now have a nice wrapper for constructing and drawing OpenGL “meshes” (ie, a vertex and index buffer object) along with the associated vertex format representations. Yes, all that stuff was hand-rolled until now, and yes, it sucked to keep forgetting to fill out the right form and then bang my head against the desk wondering why things weren’t drawing. And, of course, as mentioned a few weeks back I cleaned up the sad mess which was my old texture management code. Happily, all this is making creating a few custom UI objects much simpler than it would otherwise be, so I’m hoping to have something to show for it this weekend.

Gettin’ my font on so A. CYBORG can have an in-game HUD. Past experience suggests that will make it feel more like a Real Game (tm), and having a way to deliver meaningful feedback to the player should also encourage me to work on the level structure.

Since my rush to implement a half-assed skin chooser interface on Saturday, I’ve been going back into the code and reimplementing things in a more fully assed way. Part of that has meant dealing with sections of the code that I’ve just never gotten around to fixing up. For example, I only now have a nice wrapper for constructing and drawing OpenGL “meshes” (ie, a vertex and index buffer object) along with the associated vertex format representations. Yes, all that stuff was hand-rolled until now, and yes, it sucked to keep forgetting to fill out the right form and then bang my head against the desk wondering why things weren’t drawing. And, of course, as mentioned a few weeks back I cleaned up the sad mess which was my old texture management code. Happily, all this is making creating a few custom UI objects much simpler than it would otherwise be, so I’m hoping to have something to show for it this weekend.

Dec 07

Screenshot Saturday IN B4 THE LOCK — for some reason I really, really wanted to get some version of the skin selection screen done tonight. Please forgive the rough art (knocked it out in an hour or two) though it’s reasonably accurate to the heroine’s simplified design. It does show that the same shader code can recolor her anywhere she appears, such as in various cutscenes, and not just with the in-game sprite.
One nice thing about having this feature, besides it feeding my unhealthy desire to play dress-up with my characters, is that new skins are an excellent and cheap-to-create award for beating the mission requirements on each level, or indeed just about any other achievement in the game.

Screenshot Saturday IN B4 THE LOCK — for some reason I really, really wanted to get some version of the skin selection screen done tonight. Please forgive the rough art (knocked it out in an hour or two) though it’s reasonably accurate to the heroine’s simplified design. It does show that the same shader code can recolor her anywhere she appears, such as in various cutscenes, and not just with the in-game sprite.

One nice thing about having this feature, besides it feeding my unhealthy desire to play dress-up with my characters, is that new skins are an excellent and cheap-to-create award for beating the mission requirements on each level, or indeed just about any other achievement in the game.

Dec 05

[video]

Nov 16

So there we have it, realtime occlusion map shadows and lighting.
I resolved the problems I was having with lack of dynamic range by rendering the lighting into floating-point textures, which can store values limited only by the size of a half- or even full-sized floating point number. With that, I could render the sun with a brightness such as (150, 150, 150) instead of (1, 1, 1). Then, when time comes to generate the final lightmap that’s draped over the terrain, I normalize the colors: divide each pixel’s brightness by the brightness you’d get if the entire sky was visible, thus scaling it back to an (0, 1) range, and then raise the result to a fractional exponent to reduce the steepness of the light curve. The result is shadows that are obvious but don’t obliterate the more subtle effects — note how the sides of the pyramid are darker due to having a large portion of the remaining sky occluded, and this effect is noticeable both on the lit and shadowed sides. Also, the shadow has an umbra and penumbra caused by only part of the relatively large and diffuse light source being occluded at various locations.
The main downside is something that became sadly obvious in my previous experiments: an 8x8 sky image is too low resolution for good results. Even though I’m filtering it down from a higher-res initial image, the sun ends up occupying just a few pixels, and as it moves to the next set of pixels the result is a stair-steppy occlusion pattern as the first pixels blink off and the next ones blink on. To address this I increased the sky and occlusion images to 32x32, producing much smoother transitions. Unfortunately, increasing that resolution also increases the size of the full-sized occlusion result image, containing a copy of the occlusion overlaid on the sky for every vertex, dramatically; it was already 2048x2048 for 256x256 copies of an 8x8, and increasing it to 8192x8192 would be larger than I’m comfortable with asking my weaksauce video card to deal with. Even if it could store one of these, I kinda want there to be more than one landscape tile in the world. I took the drastic step of reducing the landscape from 256x256 to 64x64 vertices, keeping the final size of the occlusion result image the same. It does the job, but the low resolution of the landscape and the lighting texture gets quite obvious at times.
If I want to do anything else with this in the future, I’ll have to find some way to deal with the size of the occlusion results texture. I don’t like having to keep even a 2048x2048 around for each tile, so it’s either come up with a way around that or convince myself that it’s not so bad.
Maybe I should work on A. CYBORG instead. Or play some video games, that sounds good too.

So there we have it, realtime occlusion map shadows and lighting.

I resolved the problems I was having with lack of dynamic range by rendering the lighting into floating-point textures, which can store values limited only by the size of a half- or even full-sized floating point number. With that, I could render the sun with a brightness such as (150, 150, 150) instead of (1, 1, 1). Then, when time comes to generate the final lightmap that’s draped over the terrain, I normalize the colors: divide each pixel’s brightness by the brightness you’d get if the entire sky was visible, thus scaling it back to an (0, 1) range, and then raise the result to a fractional exponent to reduce the steepness of the light curve. The result is shadows that are obvious but don’t obliterate the more subtle effects — note how the sides of the pyramid are darker due to having a large portion of the remaining sky occluded, and this effect is noticeable both on the lit and shadowed sides. Also, the shadow has an umbra and penumbra caused by only part of the relatively large and diffuse light source being occluded at various locations.

The main downside is something that became sadly obvious in my previous experiments: an 8x8 sky image is too low resolution for good results. Even though I’m filtering it down from a higher-res initial image, the sun ends up occupying just a few pixels, and as it moves to the next set of pixels the result is a stair-steppy occlusion pattern as the first pixels blink off and the next ones blink on. To address this I increased the sky and occlusion images to 32x32, producing much smoother transitions. Unfortunately, increasing that resolution also increases the size of the full-sized occlusion result image, containing a copy of the occlusion overlaid on the sky for every vertex, dramatically; it was already 2048x2048 for 256x256 copies of an 8x8, and increasing it to 8192x8192 would be larger than I’m comfortable with asking my weaksauce video card to deal with. Even if it could store one of these, I kinda want there to be more than one landscape tile in the world. I took the drastic step of reducing the landscape from 256x256 to 64x64 vertices, keeping the final size of the occlusion result image the same. It does the job, but the low resolution of the landscape and the lighting texture gets quite obvious at times.

If I want to do anything else with this in the future, I’ll have to find some way to deal with the size of the occlusion results texture. I don’t like having to keep even a 2048x2048 around for each tile, so it’s either come up with a way around that or convince myself that it’s not so bad.

Maybe I should work on A. CYBORG instead. Or play some video games, that sounds good too.