I moved to a new URL! Check it out!

posts filed under: general

Dev Log: FNA Primitive Progress

Dev Log: FNA Primitive Progress
In between Super Sky Sisters tasks I'm chipping away at some basic stuff using FNA. One of the tough things to get out of the way early is drawing primitives so I've spent some time getting that up to par with how Otter does it currently.

Image


Circles and rectangles are in and working with camera movement as well. I also went ahead and put in camera zooming and rotating as well so that it matches the functionality that Otter has currently. Primitive outlines for both rectangles and circles is working too! The tough stuff I have coming up is figuring out the best way to do Tilemaps and transformations of a bunch of sprites all at once... basically Otter allows you to do things like create massive graphics, such as Tilemaps, and then give them their own scale, rotation, origin, color, etc. This doesn't seem as straight forward in FNA as far as I can tell right now, but hopefully I'll stumble across something.

Other than that,I've started messing with some basic collision detection which I plan on reworking a little bit from Otter. I'm trying to make it a little bit more organized this time around now that I have a chance to rework things from almost scratch.

The plan going forward is to start up my next game using this framework, and keep Otter SFML online "as is" and probably clean up some stuff to mark it as version 1.0.
otter programming fna
Posted June 14th 2016 5:06 PM (General)
No Comments

Dev Log: Early FNA Experiments

Dev Log: Early FNA Experiments
While I'm taking a sort of break from Super Sky Sisters I've been messing around with something called FNA which is a recreation of XNA but in an open source style with maximum portability in mind. It differs in Monogame in that it tries to be as close to XNA as it can possibly be and doesn't branch off into its own thing.

Why FNA? I mean, I'm totally not sure. The only thing I can concretely say is that it's been recommended to be from developers that I highly respect. People often say that XNA is dead because it is no longer supported by Microsoft, but there is still a huge community of people making games with XNA and that is driving things like Monogame and FNA to exist. I feel a lot better about using something that seems to be more in the forefront of game development back ends.

One major point of FNA that I like is that it's only a csproj or a bunch of dll files. No need to install project templates or content pipelines or any of that stuff. One of my goals with Otter is to make it as easy as possible to get something up and running without having to install anything if possible, and I believe FNA is the best bet for something like that.

Image


I've made it mostly through the first pass of text rendering, I've managed to get some basic shader stuff working, and now I'm working on getting primitives to show up. These are the three things that I'm most scared of so if I can get them out of the way it may be smooth sailing from there.

Basically when I do start getting serious about my next game I want to be working in something that has the possibility to be ported to other platforms. SFML does have that potential but it is not used very much in the game development community, so less people are familiar with it, and that means when it comes time to port I'm kinda up the creek without a boat.

More on this as it develops! You may even catch me working on this on one of my fancy game dev streams (warning: it's all programming and not super exciting.)
fna csharp programming otter
Posted June 5th 2016 11:34 PM (General)
No Comments

To Shader Hell and Back

To Shader Hell and Back
As I'm starting to send out builds of Super Sky Sisters for people to test I'm slowly churning through bugs and crashes that I was completely unaware of until the game runs on different hardware. One of those crashes is caused by creating way too many shaders so I've been investigating on how to address that for now.

One big idea I had was to change how Otter uses shaders internally, but I think after some experiments this idea probably isn't going to work. The idea was to have Otter's Shader class keep a cache of compiled shaders instead of creating and compiling a new shader every time. Basically when making a shader it would check to see if an exact copy of that shader has already been created and compiled, and if so it would just use that one.

However that means that every sprite using the same shader would then also be sharing that shader's parameters. So if I wanted to change the color on an enemy, it would change the color on everything else as well. In order to get around that Otter's shader class would then have to manage and apply the shader's parameters before each render. So EntityA could set its parameters before rendering, and then EntityB could do the same.

I went down the rabbit hole a little bit with this technique but quickly found it performs like crap mostly. Iterating through every parameter per shader per entity per render becomes pretty chuggy pretty quickly. At first I thought this would be a pretty good idea since it would reduce hundreds of shaders to just 1, but the process of applying parameters before each render seems to be not the fastest thing in the world.

So now I'm back to the regular old way that Otter does shaders which is creates and compiles one for every shader instance. This has some downsides but I'm pretty sure it still ends up being faster than my experiment with a compiled shader cache.

I have some work ahead of me still to stop some of the crashes for Super Sky Sisters, but I'm pretty sure I know how to fix it it's just figuring out the right arrangement of code to implement the fix!
shaders sfml otter
Posted May 20th 2016 2:22 PM (General)
No Comments

To SFML or not to SFML

To SFML or not to SFML
That is the question on my mind these days...

I think things would be smoother if I were just running the main C++ version of SFML, but unfortunately I am just way more comfortable in C# which means only having access to SFML.Net.

Don't get me wrong, SFML.Net is pretty great, but I think more and more I'm feeling like I should jump off to something else. I like SFML's API, and I think it does a lot of things in ways that make sense to me, but the support from the game development community just isn't there.

I know I am probably experiencing the old grass is greener feeling, but right now it feels very tempting to start to build Otter to run with something else underneath it. If I were to switch to anything I think right now my best option would be XNA/Monogame.

Image


This is just a quick little test, but it is running in XNA with something much like Otter. Monogame seems to have the biggest support lately when it comes to portability which is pretty appealing. Right now I can barely get the latest version of SFML.Net to cooperate and that's after having someone else send me a compiled version of the library because for the life of me I just cannot get SFML.Net to build.

Just rambling a little bit here. I did manage to get SFML.Net 2.3 working with Otter... but with an unfortunate downside with texture smoothing that for some reason doesn't exist with 2.2. Texture smoothing for whatever reason now has a weird effect on the edges of textures, and when I try to use those textures in shaders I get weird results when sampling pixels around the edges.

Just feeling pretty frustrated I guess! I'm going to go down the XNA rabbit hole a little bit inbetween finishing up Sky Sisters... maybe it's possible to get an XNA build of the game rolling but who knows!
sky sisters gamedev sfml
Posted May 18th 2016 10:19 PM (General)
1 Comment

Dev Log: Health Pick Ups

Dev Log: Health Pick Ups
Whoops I have been totally neglecting my blog this month. I've got a lot of posts to catch up on! I think when I stream a few times a week that actually gives me the same feeling as making a blog post, so I end up just totally forgetting to make a post about what I've been up to.

One of the things I'm playing with to make the demon sisters boss fight a little bit more fair is having the demon sisters drop health whenever they're knocked out by the players. Basically the demon sisters obey the same rules that the players do so they can be temporarily disabled by damaging them enough. Eventually they will revive though and continue their assault.

Image


Sometimes the best course of action in this fight is to try to knock one of them out before they unleash one of their crazier attacks. Right now this boss fight is incredibly tough but most of their attacks are a lot easier to deal with if one of them can't join in. I think I'm actually approaching the end of this boss fight and that just leaves a few things left on the list (until I add more stuff but I actually don't see that happening again for real this time.)
gamedev dev log sky sisters
Posted May 16th 2016 3:30 PM (General)
No Comments

Dev Log: Damage Numbers

Dev Log: Damage Numbers
This week I did a quick experiment with Super Sky Sisters. I didn't really think it would work out, but it I was proven wrong, I think! I ended up adding damage numbers to the game. Check it out!

Image


One problem in the game (and in any game I think) is letting the player know how effective their attacks are. In a game as fast as this one it can be pretty tough. There are a lot of objects that don't actually take damage from your bullets, but they still react. Some players end up continuously attacking things that don't take any damage, so hopefully this will help with that.

Image


Not only is it useful for communication with players, but it also looks super cool. Why do numbers flying off of things make everything better? I'm pretty sure it's some sort of fundamental rule of game design.
dev log sky sisters gamedev
Posted May 12th 2016 9:45 PM (General)
No Comments
« newer posts
older posts »