The entire code base has been cleaned (with the help of these + CodeRush and Refactor!), the whole design is being improved, and lots of little bugs have been fixed. It’s already massively different and far more readable then before. I’m keeping the change log up to date with the code in the SVN CVS: http://ascgendotnet.jmsoftware.co.uk/changelog

The next release will be Ascgen dotNet version 2.0.0 (or to make things easier, Ascgen 2.0). I don’t know when it will be ready, it just depends on whether I want to release something functionally almost identical to the current version, or if I go forward with some new features.

The main new thing I want to add is a new method of conversion which will be available in addition to the current ones. It’s for fixed width fonts only, and gives a much better output for line art style images.

Also, I don’t know if I’ll keep up with this, but: http://twitter.com/ascgen

Internal design changes, and some cool new stuff.

Dithering
Thanks to an great idea sent to me through sourceforge, the program now comes with the ability to run a dithering filter over the output.

Why would you want this? Well, the text output is like having an image with a small palette of colours. Adding noise to the output helps to blend the different greyscale colours together and produces a result that is (hopefully) more pleasing the eye. There’s also a random element which weights the dithering and helps hide the pattern.

Check out the wikipedia article for more information on the theory behind this topic.

Translation file changes
The program will now automatically load a translation file if one (and only one) is in the same directory as the executable. The filename has to be in the format translation.*.xml with * being the language code (although at the moment it doesn’t matter what you put there). For an example, here’s the American translation file: translation.en-us.xml

The full list of untranslated strings is here:
http://ascgen2.cvs.sourceforge.net/*checkout*/ascgen2/ascgen2/translation.xml

Text Widget
The brightness/contrast and levels widgets have been merged into one new widget, using tabs to switch between them and a new control for adjusting the dithering levels.

Visual Studio 2008
The codebase has been moved to the new Visual C# 2008 Express Edition, so you’ll need that if you want to compile the source code yourself. The executable is still being targeted at .Net 2.0 so hopefully there shouldn’t be any difference (I can’t see any good reason to change it to the latest .Net yet).

Full change log:
Fixed extra characters being added to colour rtf files in some font sizes
Added automatic loading of a translation file (translation.?.xml) if one is present
Added a basic dithering filter to the output
Changed Ascii filters to implement an interface rather then inheriting a class
Added specialized interfaces for the filters
Moved brightness/contrast and levels into one widget
Improved the levels control
Stopped brightness/contrast accepting clicks from anything other than the left mouse button
Stopped brightness/contrast control updating the output twice on reset or image load
Added new control for dithering level and dithering random level to the text widget
Added loading and saving the dithering values to the settings file
Changed text widget to implement the brightness-contrast/levels/dither interfaces
Changed brightness-contrast widget to implement the brightness-contrast interfaces
Made main form access the widgets through their interfaces rather then directly
Moved code development to Visual Studio 2008
Fixed processing the conversion twice during image load

It’ll be at least a few more weeks before I get around to finishing the edit settings form, so here is everything I have so far:

Changes:
Ported code to .Net framework 2.0
Menu and toolbar changed to MenuStrip and multiple ToolStrips (all rearrangable)
Replaced native measure and draw text code with TextRenderer functions
Added “???? ” ansi ramp and valid characters – Select “Plain Text (Unicode)” as the type when saving the text
Changed “Close without saving the output?” to “Save the output before closing?”
Added menu icons
Replaced context menus with context menu strips

All but one of the native winapi functions have been replaced with .net functions (for the last I need to either find a way to check the text metrics in .net or an accurate method to detect if the font is fixed width).

About having accurate output for all the fonts, and this is a real kicker, they were always accurate. The richtextbox control doesn’t display them correctly. Even in the older version, if the text is all messed up and you save it as an image it will save correctly. Using ANSI characters, some of the fonts display the characters in the control as a square, but still save the output correctly. We will just have to live with it until I sort out a way to fix the output, or write my own text control.

I want to add one more thing before I release the new version (a form to edit the settings), so unless I get distracted by another project it’ll be out sometime this week.

Boring technical stuff that I couldn’t find the solution for online and had to workout for myself, part 1
You have a toolStripContainer with a MenuStrip and a set of ToolStrips. After spending a couple of minutes neatly lining them all up how you want, you save and compile and everything’s good. Except that every single time you reload the form, or just switch to the code then back to the designer, all the controls are rearranged to fit one per line. EVERY SINGLE TIME.

Here is how to set the control positions at runtime:

// First clear the container
toolStripContainer1.TopToolStripPanel.Controls.Clear();

// Then add the strips one by one in _reverse_ order using:
ToolStripContainer1.TopToolStripPanel.Join(ToolStripWhatever);

// Finally add the menustrip:
toolStripContainer1.TopToolStripPanel.Join(menuStrip1);

Anyway, program-wise I’ve changed the GUI layout (again), and I’m getting to the stage where I’m more or less happy with the design.

After abandoning another project I was working on (don’t ask), I decided to go back to my roots and see how feasible it would be to port the ASCGEN over, and the answer was ‘not very’. But… I did run some tests and not only managed to rewrite the conversion engine in C#, but it was faster and smaller.

So, I decided to rewrite the ASCII Generator in Microsoft Visual C#.NET. The main reasons for this are that the development time is fast, and I need to learn it. The main drawback is that you’ll need the .NET Framework installed (one day it’ll come as standard in Windows and this won’t be an issue), but this will be a one time ~20Mb install and then the exe files will be tiny. I’m not going to just replicate the old program (which grew into a really weird text editor), this will be a slimmed down SDI application with just the important features.

This will be a development journal only, so don’t expect any live journal style attention whoring. I’ll get around to fixing the design of this blog soon.

The first version of the program will not be released until it’s ready, and it produces a better output then the old program.