visual studio

Future of the Ascgen 10

It has been a while now, but since Christmas I’ve been back working on the code.

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:

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:

Ascgen dotNET 0.9.5 released – Dithering and more 4

** Download it here **

Internal design changes, and some cool new stuff.

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:*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.

Beta 6.9 released – .NET 2.0 REQUIRED

Download it here

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:

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


The program has been converted to .net 2.0. The menus have all been replaced with draggable menustrips, and I’m using the Silk icons set for most of the items. The exe size has dropped by about 80k.

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

// Then add the strips one by one in _reverse_ order using:

// Finally add the menustrip:


Finally got .NET working properly again, but I’ve been a little distracted setting myself up a Linux server on a spare computer. I had a quick go at running ASCGEN using Mono, and I think that I’ll be able to get it working after a couple of more days banging my head against the monitor. Fingers crossed, and we’ll cross platform support right from the start.

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.

First Post!…

A couple of years after abandoning the ASCII Generator I’m back working on a new image to text converter. The old version still works, but it’s so big, bloated and ugly that I’m no longer able to work on it (and I don’t even have a copy of C++Builder any more). A few months ago I finally was able to retrieve my old domain name, and purchased some web space in a really nice deal from Hytek Hosting and moved the old site over.

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.