I moved to a new URL! Check it out!

Incoming Otter Updates

Incoming Otter Updates
Sorry for the total lack of posts over the past week. I guess I have gone into a heads-down mode for the updates I've been working on for Otter.

About a week and a half ago I went in and tore apart a lot of the code for Graphics and the sub classes. This resulted in rendering being totally messed up for awhile as I tried to figure out a good way to batch sprites using common SFML RenderStates.

So far this seems like a fruitless effort, as even when I have basic sprite batching working the performance remains exactly the same. If anything right now the bottleneck for rendering just seems to be iterating through all of the entities to render, so for now I'm going to hold off on officially supporting sprite batching until version 1.1 or higher.

I did make a pretty big breakthrough on Sunday and finished the last of the collision detection functions. The last ones on the list were all using the PixelCollider class. Some of the functions could be optimized better, but for now this will work for a version 1.0 release sometime in the near future. I don't imagine seeing the PixelCollider class being used that much anyway.

For the time being I'm going through every single class now and organizing it and documenting it (if I haven't done so already) Soon Otter will be a very neat organized package of code all set up with fancy regions and comments. Then that will bring me to the beta of (hopefully) version 1.0. If nothing goes horribly wrong, I would image Otter will be at 1.0 status in a few weeks!

It's not as exciting as working on an actual game, but there were some things lurking in the shadows of Otter that I needed to address before they came back and bit me later. Thanks to everyone that has been finding bugs and suggesting things for Otter! It's pretty awesome and terrifying to know that people out there are using the engine.
otter programming sfml
Posted May 20th 2014 2:00 PM (Otter)
3 Comments

Doodle Post

Image
doodles
Posted May 13th 2014 11:12 PM (Doodle)
No Comments

Offspring Fling Humble Store Sale

Offspring Fling Humble Store Sale
Just a quick heads up that Offspring Fling is available DRM free for 50% off over at the Humble Store! I'm not sure how long the discount lasts, but if you're still aching for a copy of the game then now's your chance to save a few bucks.

It's hard to believe it's been over two years since the game came out. It seems like only yesterday I was crunching 18 hours a day to get it ready for a release on Steam... those were fun times. The morning it actually launched I hadn't slept for 30-something hours, so that was pretty intense. Hopefully I can avoid that situation with future game launches.
offspring fling promotion yay!
Posted May 13th 2014 8:55 PM (Offspringfling)
No Comments

Doodle Post

Image
doodles
Posted May 13th 2014 11:44 AM (Doodle)
No Comments

Dev Log: To Batch or not to Batch

Dev Log: To Batch or not to Batch
One of the things gnawing at me over the past few months is the rendering performance of Otter. So far it hasn't really been a problem, but I've only made a couple of low resolution prototypes and a game jam game with it so far. For my current project, a 1920 x 1080 resolution game, I started to worry about the rendering time as I add more and more assets to it.

So I was thinking "Hey maybe I can add some kinda sprite batching to Otter like XNA or Monogame has!" The basic concept is that it is very expensive to switch textures when rendering things with a GPU, so you take a bunch of sprites that all share the same texture and try to mash them together into one draw call from the video card. This way you can render all your sprites but you don't have to switch textures for every single one of them.

To start on this I basically tore down a bunch of rendering code in Otter. This was a few days ago, and since then I do have some sort of basic sprite batch working. In a little example I have 1000 sprites rendering with the same texture and as far as the video card knows it's actually only 2 renders... but so far I actually don't think this has affected performance at all!

I'm using SFML.Net for the core rendering of Otter. Everything that goes to the video card to show up on the screen goes through SFML's Draw functions. So far according to my small tests it seems that the video card isn't really having any issue switching textures a thousand times, but something before that is actually causing the slow down.

It seems that just going through and appending vertices to a vertex array in SFML.Net is just really slow. For example Otter's RichText class suffers from a pretty big performance hit if it's used to render a lot of text, like enough letters to cover the entire screen. This is pretty odd since RichText.cs in Otter is pretty much a copy of SFML's own text class from the C++ source! Almost the same code in C# runs almost 10x slower than C++, and of course this is not a big surprise since C# has a bunch of extra stuff with the managed memory and garbage collection. Still, it is pretty discouraging to realize. (Another tough one is the Tilemap class, which will suffer from big slow down during real time modification of a huge tilemap due to the rebuilding of the VertexArray!)

So right now I'm still reorganizing a bunch of code in Otter's rendering stuff. Hopefully the API will remain mostly unchanged, but right now my hope is that using texture atlases in Otter becomes smoother and actually has a performance benefit. Yay programming.
otter programming dev log
Posted May 9th 2014 1:38 PM (General)
5 Comments

Dev Log: Using Config Objects

Dev Log: Using Config Objects
One of the recent changes in Otter is the ability to configure the RichText object with a RichTextConfig object. This was inspired by something I saw some friends of mine doing in their project. Instead of having a long drawn out list of possible parameters for the creation of an object, instead you can pass in a config object that has all of those parameters set. Here's a quick example.
//In a static class that holds all the Config objects

public static RichTextConfig RTSkyCellStat = new RichTextConfig() {

    ShadowColor = G.Colors.Dark,

    OutlineColor = G.Colors.Dark,

    OutlineThickness = 3,

    CharColor = G.Colors.Light,

    ShadowY = 3,

    Font = Assets.FontHud,

    MonospaceWidth = 16,

    FontSize = 28

};

And creating the RichText object with this looks like this:
public RichText TextHealth = new RichText("600", Config.RTSkyCellStat);

One of the coolest things about using a Config object is that one Config object can be used for a bunch of different RichText objects. This means that I can define common styles of RichText in a static class somewhere and reuse them as much as I want, so if I need to change something across all of those RichText objects all I need to do is change the config.

I'm not sure if this is the best method of doing this in C# land but so far it seems to be working pretty well. I'm also using Configs for a lot of my UI elements as it lets me define a couple of different styles for panels and buttons and reuse them for elements that share similar roles.
csharp programming dev log
Posted May 7th 2014 12:42 PM (General)
No Comments
« newer posts
older posts »