Yahhh!! I’ve completed the rewrite! Wiki, NuGet, GitHub have all been updated.
Home of SadConsole & more
Over the last two months I’ve spent a lot of time looking at how SadConsole is put together. Specifically, paying attention to namespaces and class names. There a few complexities in the object model that I wanted to address and just make things simpler. I’ve come to a point now where I would guess that I’m 99% complete on implementing these changes, and I’m extremely happy with how things have turned out.
Two major changes that I’ve figured out impact you as a coder.
- All four libraries (Core, Ansi, Controls, GameHelpers) have been merged into a single library:
- Instead of two libraries, one for OpenGl and one for DirectX, a single library handles both.
Originally I thought I needed both types of libraries, however it turns out that you (creating the game) choose which target (OpenGL or DirectX) based on which MonoGame you choose. SadConsole will just play along without a problem.
The internal rendering and processing system has also changed.
First, NuGet has been updated with a bunch more fixes. I’m trying my best now to stick with the semantic versioning format. It’s hard to transition from the old versioning style. It’s also getting harder and harder to not break interface on updates. So I’m really going to try hard to no longer do that.
Down to business…..
I’ve created new init sequences for SadConsole that removes all the crap that comes with MonoGame. That means if you’re not making a full MonoGame-game where you need all the extra 3D management, you can omit the whole giant
game1.cs class and instead use this nice, compact, easy, startup file.
It’s finally done! Version 3 of SadConsole brings a lot of structural changes and increases flexibility. Previously it was hard to implement new types of objects that hooked into the rendering system. And whenever I did create something extra, I always felt like I was trying to fit it around the system instead of the system being flexible enough to handle it. Not any more!
Version 3.0 has taken me 2 1/2 months, 113 commits to the code repository, and 192 files were edited.
Here is a class diagram of how the system is put together now. Click below after the picture for more about the changes.
Oh hai! As part of my rewrite of how SadConsole renders to the screen (my v3 branch) I came up with a few new console types. Well.. not really a new console, but it’s actually a new renderer. The class is SadConsole.Consoles.CachedTextSurfaceRenderer (name subject to change) and it works by rendering the text data to a texture instead of the screen. Then when the renderer is drawn, it draws the texture instead of console cell data.
The more and more that I use SadConsole on my own little games, the more I grow to dislike the way I render to the screen. Now, I don’t mean specifically the rendering code itself. It’s pretty good, though I have an improvement coming soon. What I mean is the way you, say from a console, get your data rendered to the screen.
A console generally has two roles, it either reads input from the user (providing visual feedback) and/or it presents characters to the user. However, the capabilities you want in drawing characters to the screen may vary. You may:
- Use a standard Width x Height console.
- Use a bigger console and allow scrolling.
- Use a single console the entire time.
- Use many different consoles positioned on the screen.
- A console that has multiple layers.
- A console with a bunch of extra metadata.
- A console for UI controls.
- A floating window console.
- An animated console (entity).
I think that is all the types provided by SadConsole. Here is a diagram of (out of all the libraries for SadConsole) the way the classes are structured.
Yesterday I was writing some code to generate an entity that animated white static, like you have on an old TV.
And I found a bug..
The bug has to do with when you create an entity and then add a new animation to it that replaces the default animation. The entity has the new animation but the
Entity.CurrentAnimation property still points to the old one. Not good.
Fixed now in version 2.7+.