So we meet again, blog post.
I intended to post on schedule, I really did. We were even going to release the private beta on Friday! The day was going well, all the changes we HAD to make were implemented and we were doing our final run through before packaging up. That is when sinoth noticed some geometry wasn't showing up. Not a LOT of geometry, but big geometry that makes an impact on the look and feel of the level. Cue three days of frustrating, bewildering bug hunting. The issue still isn't entirely fixed, but is pretty much worked around for the moment. We have enlisted the aide of internet experts to tease out the true cause of this issue because we are fairly certain it is Not Our Fault. Hopefully in a couple of days we will understand the root of the issue and regain the ability to sleep at night.
Assuming we don't stumble upon another heinous bug within the next 5 hours, we will be uploading the private beta tonight. If you'd like to get your grubby little hands on it, hit up our beta signup and we'll get it out to you. We especially need Mac testers to find compatibility bugs we haven't found yet.
6.27.2011
6.20.2011
i made a whale
I've had to push my non-existent modeling skills to their limits for the level I'm working on currently. I envisioned the underwater stage to have some critters swimming about, and they are turning out to be a bit harder to model than huge angular architecture.
I feel like I'm starting to get the hang of the Blender workflow, and for the most part I can create a vague approximation of what I'm wanting. Still, for future projects we'll likely find a skilled modeler rather than hack at it ourselves. I had thought low-poly models would be relatively easy, but that is a naive way of thinking. Low-poly models are like low-res pixel art... it takes true talent to get it right. Regardless, buub0nik and I are going to trudge forward and do our best to give you a visually unique experience :)
Behold! Some of my marvelous creations:
Whale!
Shark!
I feel like I'm starting to get the hang of the Blender workflow, and for the most part I can create a vague approximation of what I'm wanting. Still, for future projects we'll likely find a skilled modeler rather than hack at it ourselves. I had thought low-poly models would be relatively easy, but that is a naive way of thinking. Low-poly models are like low-res pixel art... it takes true talent to get it right. Regardless, buub0nik and I are going to trudge forward and do our best to give you a visually unique experience :)
Behold! Some of my marvelous creations:
Whale!
Shark!
6.17.2011
Progress?
We've been scrambling to get a demo out for too long now when we entertained the thought of releasing a weekly build, no matter the amount of progress. We have always followed the philosophy of 'polish one more thing' before it is ready to go out, but that keeps people waiting and probably losing interest in us. This has plagued our blog posts as well where, instead of posting regularly and informing people that real work is being accomplished, we hold off until we can get a pretty screenshot out. I am definitely worse when it comes to posting on the blog. I have a hard time bringing myself to talk about fixing the issue where the scallywag was getting out of sync with the ballyhoo causing the whowitzer to crash if you followed this procedure. If you wanted to know these things, you could be reading our repository logs (or changelogs if we ever get a release out). I would imagine that most people only care about these things if you are describing a grand new feature they have been anxiously awaiting, or to announce the fixing of a particularly heinous bug that was game-breaking for a host of players. The result of this habit has turned our blog in to a barren wasteland of month long stretches with no signs of a post. If I were on the outside, I would have written the game off as vaporware a long time ago. I do not want this. It is not good for business. I will be the boring, droning nerd that no one reads if it will at least show signs of life.
Maybe we will be able to bring ourselves to this mindset with beta builds as well. We do have a few people signed up for the private beta, but have not thrown anything their way yet. Hopefully this evening will see an end to the drought and our fan will wet his lips on a juicy new beta build.
And I can't forget to mention:
We have a Mac build.
Maybe we will be able to bring ourselves to this mindset with beta builds as well. We do have a few people signed up for the private beta, but have not thrown anything their way yet. Hopefully this evening will see an end to the drought and our fan will wet his lips on a juicy new beta build.
And I can't forget to mention:
We have a Mac build.
6.13.2011
splish splash
I've been slogging away at the water level. Progress has been slower than I'd like but we've also been fixing bugs here and there, as well as expanding the exporter to accommodate our level ideas.
Once I finish this level we'll be sending out a round of beta mails so you can play it. We're hoping to get a group of dedicated testers for feedback so we can crank these levels out faster. As a reminder, you can sign up for the beta here!
Once I finish this level we'll be sending out a round of beta mails so you can play it. We're hoping to get a group of dedicated testers for feedback so we can crank these levels out faster. As a reminder, you can sign up for the beta here!
6.03.2011
It's a blog post! (And what a blog post!)
It has been a long few weeks. I have been reworking our lighting for too long now, and finally have some shots to show. It was an arduous process, full of demoralizing one line bugs, misunderstanding of topics and a couple of pressing meatspace issues. Sadly, these things have pushed our private beta release back a couple of times and I am sure our fan is getting impatient. We are almost there though, and will soon have a faster build and a level for all you testers to nom on.
I'd like to go into some of the issues with the old lighting system, so please bear with me. There will be plenty of images sprinkled throughout.
Visually, it looked good. We took some liberties for, which I will claim to be, stylistic reasons, but the end result I felt was pretty sharp. We essentially had a couple of lighting functions we called which were attached to our shaders. Every fragment that was drawn had to iterate through the list of lights and figure out the contribution and add these to the final color output. Now, right off the bat there are a couple of problems here. This meant every shader had to be told where every light was. We basically had a an array of light structure uniforms that we uploaded to the shaders that needed lighting information. On my test machine I had an upper limit of about 70 lights before I started getting shader size limit errors.
Our client side class was short-sighted and it became cumbersome to do things that we might want to do, like move lights, or remove them, but we charged ahead. When people started playing, however, there would be strange bugs that we could not figure out and after hours we pinned down to there being too many lights attached. This slowly dwindled our max number of lights down to 16. This is barely more than the OpenGL standard pipeline limit. We tried sending in lights as a texture, but at the time we were bumping into undefined behavior that we did not discover until after we culled that approach. In a way, the lower light limit was a good thing because any more passed that would cause our machines to bog down, especially if there was a lot of overdraw. There are methods to get around this low limit with this technique, but they involve doing multiple passes of our geometry, which is expensive for us. Something had to change.
One day, Sinoth read about deferred lighting. 'Hey buub0nik,' he says, 'check out deferred lighting! Might be a way to solve our problems!' So I do, and the flood gates are open. This will fix our light limit! It'll be easier to move lights! We can have custom light types! Our edge detection will be quicker! We can....(I had a lot of ideas). But we waited. There were more pressing issues with the game. It was playable, but the UI was choked, and there were other things we weren't quite pleased with. The lighting as it was, worked. We went several months with the idea of deferred in the back of our heads, and finally it was time to implement it.
The idea behind deferred lighting is to separate your lighting out from your geometry. You make a pass with your scene geometry and render relevant data to buffers. This generally includes color, normal information and depth information, plus whatever you can squeeze in for your desired effects. You then make a lighting pass, rendering your lights as geometry. Directional lights are fullscreen quads, point lights are spheres or billboarded quads, spotlights are cones. You use the buffers you made in your geometry pass to determine how the light interacts with the current fragment and write these to a lighting buffer. Combine these, and we're done.
I lied about the sprinkled images by the way. Here are some comparison shots though. Since I've blathered on long enough I will go ahead and skip the troubles I had getting deferred lighting to work. Those tales are more suited for around a campfire anyway.
There are still some issues to be handled. Some blending could stand to be tweaked, same goes for edge detection values. HOPEFULLY it is smooth sailing from here on out.
I'd like to go into some of the issues with the old lighting system, so please bear with me. There will be plenty of images sprinkled throughout.
Visually, it looked good. We took some liberties for, which I will claim to be, stylistic reasons, but the end result I felt was pretty sharp. We essentially had a couple of lighting functions we called which were attached to our shaders. Every fragment that was drawn had to iterate through the list of lights and figure out the contribution and add these to the final color output. Now, right off the bat there are a couple of problems here. This meant every shader had to be told where every light was. We basically had a an array of light structure uniforms that we uploaded to the shaders that needed lighting information. On my test machine I had an upper limit of about 70 lights before I started getting shader size limit errors.
Our client side class was short-sighted and it became cumbersome to do things that we might want to do, like move lights, or remove them, but we charged ahead. When people started playing, however, there would be strange bugs that we could not figure out and after hours we pinned down to there being too many lights attached. This slowly dwindled our max number of lights down to 16. This is barely more than the OpenGL standard pipeline limit. We tried sending in lights as a texture, but at the time we were bumping into undefined behavior that we did not discover until after we culled that approach. In a way, the lower light limit was a good thing because any more passed that would cause our machines to bog down, especially if there was a lot of overdraw. There are methods to get around this low limit with this technique, but they involve doing multiple passes of our geometry, which is expensive for us. Something had to change.
One day, Sinoth read about deferred lighting. 'Hey buub0nik,' he says, 'check out deferred lighting! Might be a way to solve our problems!' So I do, and the flood gates are open. This will fix our light limit! It'll be easier to move lights! We can have custom light types! Our edge detection will be quicker! We can....(I had a lot of ideas). But we waited. There were more pressing issues with the game. It was playable, but the UI was choked, and there were other things we weren't quite pleased with. The lighting as it was, worked. We went several months with the idea of deferred in the back of our heads, and finally it was time to implement it.
The idea behind deferred lighting is to separate your lighting out from your geometry. You make a pass with your scene geometry and render relevant data to buffers. This generally includes color, normal information and depth information, plus whatever you can squeeze in for your desired effects. You then make a lighting pass, rendering your lights as geometry. Directional lights are fullscreen quads, point lights are spheres or billboarded quads, spotlights are cones. You use the buffers you made in your geometry pass to determine how the light interacts with the current fragment and write these to a lighting buffer. Combine these, and we're done.
I lied about the sprinkled images by the way. Here are some comparison shots though. Since I've blathered on long enough I will go ahead and skip the troubles I had getting deferred lighting to work. Those tales are more suited for around a campfire anyway.
There are still some issues to be handled. Some blending could stand to be tweaked, same goes for edge detection values. HOPEFULLY it is smooth sailing from here on out.
Subscribe to:
Posts (Atom)