The last two weeks have been pretty busy, but I’ve been slowly banging around on the controls redesign for SadConsole. One thing that I didn’t like with how the controls worked was that each control does its own drawing. This means that if you have a button control, and you wanted it to draw a border around it all of the time, you had to create a new button class; adding whole new types of controls just to tweak the drawing of an existing control.
The new system for 7.0 decouples the drawing from the control, putting all drawing in the theme assigned to the control. To create a new button look-and-feel, create a new theme type and customize the draw method. This new “the theme draws the control” system is also implemented on the ControlsConsole and Window types.
To test this out I create 3 types of themes for the button type:
The normal button from v6.
A 3d button.
Bordered 3d button (which uses the SadConsole extended character sheet).
As the previous entry stated, the Console type is changing. As an example take creating a border on the outside of a console. This involved creating a derived class that handled the drawing of the console itself and the border. There was a lot to do just to create the border.
border.Draw(TimeSpan.Zero); border.Position = new Point(-1, -1);
Sure, some code is missing because it’s easier to draw shapes now, but this also requires less overhead in types you create just to do simple things. And since any surface is now a positionable and drawable object, it can be added as a child to a console. Now the position of the border is automatically kept in place.
A month and a half into the V7.0 rewrite, and I’m about 90% complete. There are some major changes to how a console and surfaces work. A friend of mine did a nice writeup about how SadConsole looks to a first-time user. The current pull request on GitHub shows all of the changes so far; 200+ files changed.
The major change is that the whole concept of changable backing surfaces is gone. Prior to 7.0, a console was the editor for a TextSurface property, a property represented the actual graphical text surface of a console. You could easily change the surface in/out of the console. There was also a SurfaceEditor class (which console inherited from) that could be directed at any TextSurface object, and edit it. This SurfaceEditor type was what had all of the editing methods such as SetForeground and Print.
This has been changed to where every Surface type itself (ex: layered, animated, basic) has all of the methods needed to manipulate the cells themselves directly. Surfaces are also positionable and drawable without the need a Console, if you don’t want one. Previously every surface had to be wrapped by a console or by a bunch of code. A Console now inherits from a surface base class which means a console is a surface now.
I think this will greatly simplify the getting started aspects of the engine. I’ll have more to talk about soon.
It’s been over a year since my last post. Unacceptable! I need to keep up on this.
Over the last year, SadConsole has seen a lot of minor changes and improvement. A few new controls were added, various input bugs fixed, windowing adjust, it’s been fun. SadConsole as a whole is pretty solid and good. I now want to start playing with some fun enhancements such as angled cells, cell decorations (such as underline), TrueType fonts, that kind of fun stuff.
The next major release (it has to be a major release because some things are breaking) is going to be 7.0. I’ve created a GitHub project to track all of things to be adressed. Some things may get cut and new items may be added. If you have an idea, please add a new issue to the repository.
I have a few more blog posts coming up soon, with screenshots and all! Stay tuned…
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: SadConsole.dll.
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.