posts tagged with: otter

Otter FNA Progress

Otter FNA Progress
Sorry for the huge gap of silence. I got back from Game Developers Conference at the beginning of the month and then some kind of super heavy depression hit me hard. I'm starting to crawl out of it and making some progress on things again. Starting to get really annoyed at my brain and will probably have to take this a little bit more seriously in the future. Maybe some kinda doctor can help me out or something. Anyway!...

One of the projects I'm spinning up more now is a new version of Otter that uses FNA. FNA is an open source implementation of the XNA framework. A lot of people seem to think that XNA is somehow dead but with the advancements of things like FNA and Monogame I don't believe that to be true at all. As long as Game Maker wont let me use C#, and as long as using Unity for 2d is a gigantic pain, I'll be sticking with my current plan of making my next game with FNA.

The beginnings of Otter FNA in a somewhat broken state can be found on Github. I'm migrating over from Bitbucket so that hopefully more people can contribute and discover Otter. I personally really like Mercurial and Bitbucket, but the bigger audience is definitely over on Github.

The framework is somewhat useable right now, but has a long way to go. It's missing a lot in the realms of graphics and collider types still as I port those over from Otter SFML as I need them. I'm going to be building it out along side a game project. More on this as it develops, but I don't have as much time as I usually do because of another secret project that I'm involved with.

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.

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.)

Otter Updates

Otter Updates
A lot of Otter updates have gone through the pipe over the past few weeks and I should mention what they are!

* RichText bugs related to calculating the longest line of text have been fixed. Basically for one frame the RichText would miscalculate the length of its lines resulting in a slight offset for that frame.

* Fixed a bug with CollideEntities where the same entity could be registered to the list more than once.

* Entities now have a Position property vector.

* Added Scene.GetEntitiesAll()

* Added the ability to load in assets with a packed byte array. (See the Files class for more details.)

* Animating characters after text is written with RichText is now handled in a way that wont reset all the animations when appending to the string. If you don't know what this means don't worry about it.

* Added Coroutine.WaitForTween() to make it simpler to pause a coroutine until a tween has finished.

* Debugger.Summon() is now public and can be called from code. This isn't tested very thoroughly and could result in some undesired behavior in rare cases.

* Added Component.GetEntity<T>() to make it easier to get the correct Entity type. (Basically just hiding the casting in that method instead of having to cast Component.Entity)

* Input has static methods for getting joystick information (GetJoystickName, VendorId, and ProductId)

* Slight optimization in some collision methods (not very noticeable probably.)

* Added Graphic.TextureChanged() virtual method. Called when a graphic's texture has been changed.

* Added a Countdown Component for simple timers that just count down to zero from a specific time.

* Scene and Entity have indexers now for integers. Entities and Components are given unique integer ids when they are added to Scenes and Entities respectively. Not sure if this is useful, but adding it seemed like a good idea.

Okay I think that covers most of it.

Also for other types of Otter updates you should follow this instragram.

Otter on Nuget

Otter on Nuget
Thanks to the help of some friendly internet folks I finally got a process to get Otter up and running on Nuget! You can check out the latest main build of Otter all wrapped up as a Nuget package right here.

Image


I know that it was in demand for awhile now but for the longest time I just couldn't figure out the process needed to get Otter up there. Now you can enjoy all the luxuries of the Otter game making framework without having to go download files and move them around and all that junk. Just install the package from Nuget and you're good to go!

Also somehow the name Otter wasn't taken already?

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!