A couple of little fixes and some changes in preparation for the next big release.
Changelog:
Fixed picturebox not receiving focus when it was clicked on
Fixed problem when an area is being selected and the picturebox loses focus
Various small optimizations of the apply text effects code
Moved text to values code into a separate class
I’m looking forward to the next major! 🙂 I want to experiment around with reinstalling .NET 2.0 because I had some problems installing it over 1.3. I wonder if that could be the reason for the error I’ve been experiencing with the selection box? It’s getting pretty bad at times.
http://photobucket.com/albums/a307/Dwayne2005/
Uninstall / reinstall of didn’t work 🙁
Is it always the same message when it crashes? With this bit:
System.DivideByZeroException: Attempted to divide by zero.
at JMSoftware.AsciiGeneratorDotNet.FormConvertImage.UpdateHeight()
See if this stops it crashing: (snip)
Tried 0.5.2a and got this again:
************** Exception Text **************
(this bit to my awareness has always been the same)System.DivideByZeroException: Attempted to divide by zero.
at JMSoftware.AsciiConversion.AscgenConverter.CalculateOtherDimension(Int32 dimension, Int32 imageDimension, Int32 otherImageDimension, Int32 characterDimension, Int32 otherCharacterDimension)
at JMSoftware.AsciiGeneratorDotNet.FormConvertImage.UpdateHeight()
at JMSoftware.AsciiGeneratorDotNet.FormConvertImage.UpdateValues()
at JMSoftware.AsciiGeneratorDotNet.FormConvertImage.pbxMain_SelectionChanged(Object sender, EventArgs e)
at JMSoftware.CustomControl.JMSelectablePictureBox.set_SelectedArea(Rectangle value)
at JMSoftware.CustomControl.JMSelectablePictureBox.OnMouseMove(MouseEventArgs e)
at System.Windows.Forms.Control.WmMouseMove(Message& m)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.Label.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
My PC is not in the best of states either (the end task Windows feature keeps crashing and I’m yet to repair a few problems I’m having with my system). I’ll go back to an older version and see if that also triggers it. Or go back to DotNet 1.1.
Same on beta 4.4
I’ll try and mess around with more earlier versions. I don’t believe I experienced it before 5.0, but I might have. I used an older version, 4.3, for a while in preference to the newer version because I compiled it with my own ramps.
I tried going through an even older version (3. something) and versions 5.0, and 5.1 where I new the error existed. I tried for about 15 minutes and it didn’t crash. Usually it crashes within the first 5 or so images. I haven’t yielded any crash with 4.3 yet, but I can’t say for certain at this stage.
My best guess at this point is that either it came in the 4.4 changes, or since installing .NET 2.0
4.3… crash, yet again. Highly unlikely that I dismissed such an error without realizing? I suspect it’s probably due to .NET 2.0
It just shouldn’t crash there. Try this and let me know what the messagebox says:
(snip)
You should probably uninstall every .net framework you have and only reinstall 1.1
That version produced this comment twice in its place:
2-dimension = 150, characterDimension = 7
Much nicer than the other error, and it seems everythings to ratio after you continue out of it.
I just had a characterComment = 5, so that’s two of 7 and one of 5 if that matters.
I also tried running an older version and comparing the ratio of an image after the crash, with the ratio after this comment that appears to be correct. It seems what you done is computing the correct aspect ratio, which was the crux of the problem.
All I did was catch the exception to try and help see what was happening, but I’ve got no idea how 150 / 7 can give a divide by zero error.
Here’s the file without the messageboxes popping up:
http://www.jmsoftware.co.uk/files/ascgen2-0.5.2a.zip
Well, I’m pretty confident it also effected the ratio. After the exception, when you continued out you could select an image and you knew it was at least slightly off. When you selected a different area, the image became quite distorted in ratio. I wasn’t getting that at all from my experiments with the caught exception 0.5.2a version. Everything looked right, no matter how many tests I done with various selection areas.
What’s instore for 0.6.0? And do we have an approximate timeline?
🙂
sorry, it was me again, I forget to retype my name in.
Unless there’s a major problem adding it, 0.6.0 = variable width conversions. I’m still trying to get my head around how to let the user change the output width/character width etc.
Also:
http://ascgendotnet.jmsoftware.co.uk/wp-register.php
I’m always cleaning out my systems cookies, so I don’t think I’ll register at this stage.
That is something that I never contemplated. I’ll give some thought about it and get back to you. You’re always a thousand steps ahead of me, anyway, but if I can offer suggestions I will.
Take your time getting it perfected. I’m just quite eager for the new potential it offers!!
I was thinking that there has to be a base measurement, and that should be the largest character in the generation. Say if, even if the software doesn’t work this way, this largest char is the only one used in a row. I’d like it if that were the base value I was controlling for detail. Even if it only occured once in the row, or even the entire image, perception I feel would be better served if every value in the output size was based on its dimensions. Of course, say it was a 15/18 size char, if you had a row of 3/18 size you’d end up with 5 times the amount of characters in the output. So, essentially it’s a lowest detail setting.
In regards to the character width, maybe the key there is to have +/- values of the original rather than set values? So, every character gets a plus/negative one when the value is changed. Of course, the height it wouldn’t matter.
Sorry, this is all I could come up with. I’ll certainly give it some more thought.
Now that I think about it, you might be still trying to get the image to ratio?
To clarify what I meant above, when you enter a value in the length-width generations, each of those units, in the example size, should be 15×18 pixels. The value, let’s say default width 150, should represent 150×15 pixels. Each of the characters
Each of the characters (less than*)15 width `collect’ the right amount of pixels, but at the low end of detail, it would be the widest character in the ramp or valid keys forms that collects 1 unit.
I don’t know if it preprocesses fewer pixels on the image with the output width/height?
Okay, that’s probably as messed up as the first time I tried explaining it.
The second point about character ratios, at the moment to my awareness, I still like it. If you had Times New Roman size 12, I believe the height is 19 pixels which would appear in the box. In the width box would be a 0 (equal width). You can then manually enter in a positive or negative value and it increases or decreases all of the ASCII characters widths.
It’s not a ratio, but then you’ve got x amount of characters and I don’t think it’s possible to work with a straight forward ratio. Whereis, where it’s mono space. You could include instructions later on.
I can’t think of how to make 1:1 (0x19, for example).
* Note: It doesn’t appear your blog likes the less than sign.
Just another note.
Well, the ratio thing I suggested would be weak, I imagine. Trying to get my head around the processes. Characters will be distorted in ratio if it were all changed in the same increments. Maybe you could have the ratio box 1×1 = unadjusted. Every ratio works on the characters ratios? So 3/4 ratio (width/height) creates a 15/19 character with a ratio of 45/76, a 8/19 character ratio of 24/76 or a 3/19 character ratio of 9/76 to influence the proportions of the output.
okay, I have no idea what I’m talking about (since it works on the overall ratio rather than the character ratio… it might work, I don’t know). I’ll probably think of a few more foolish ideas, however. 😀
Don’t worry, I think I’ve got it. I was overcomplicating things and thinking about letting the user set the output size in pixels, when I can just keep the user input as it is. If I just give all variable width fonts a character width of 5 pixels for the calculations, then the output size width of 150 will give an output width of ~700 pixels which is about the right size.
Okay, that sounds great! It’s nice to know I was at least in the vacinity of the problem and that you think you’ve got it resolved.
Cheers.
Bravo! It’s nice having another gen to wet my appetite. 🙂
Any tastes of things to come or news on developements?
The variable width code is in the CVS, but there are lots of crashing bugs to fix plus a couple of things to improve the output. The other problem at the moment is that for some fonts the image is off because the width is being reported wrong on some characters, and I’ve no idea why.
Ok, thanks for the info. I’ll be happy for a 0.6 release, with or without bugs. 🙂