| Joakim |
Hi all,
Long time, no see! I have been busy doing all kinds of other stuff, but the last few weeks I have had some spare time to code AGI again. I have taken all my old code from the Picture Editor in Visual AGI for Win32 and moved to C# and .NET. The result is pretty good!
Try it out for yourself, you find it at;
http://beta.visualagi.cjb.net/vAGI-PicEdit_1.0.1403.zip
It's probably a bit rough as it has only been tested by a few people. Please let me know of any troubles and/or feature requests.
Cheers,
Joakim
|
| Brian_Provinciano |
Would you be able to do static linked versions? I don't really like having to install entire frameworks just to run one app.
|
| Brian_Provinciano |
n/m, I installed the framework now.
Looks very good. One suggestion though is that when moving a line, maybe you draw the original one translucent, or lighter? And also, it might be a DirectDraw default, but I think the antialiasing distorts the image.
Nice job!
|
| AGI1122 |
Very nice tool, although it is very resource hungry... I would hate to see what it would do to my old pc... the one I am using now I got this January.
|
| Joakim |
Brian Provinciano wrote:
Would you be able to do static linked versions? I don't really like having to install entire frameworks just to run one app.
It is not possible, unfortunately. .NET Framework is the new API for Windows (after Win32) and needs to update your system. New versions of Windows (Longhorn) and future service packs will include the framework, but for now you need to install it manually.
/ Joakim
|
| Brian_Provinciano |
Makes sense I guess that it was part of Windows Update. I suppose it's not a problem at all that you use the .NET framework anyway, since it will ensure the most modern tools possible :)
|
| AGI1122 |
Actually my copy of Windows XP came with .NET installed. Although I use XP Professional.
|
| Joakim |
Brian Provinciano wrote:
One suggestion though is that when moving a line, maybe you draw the original one translucent, or lighter?
Good idea. I will try to add something like that.
And also, it might be a DirectDraw default, but I think the antialiasing distorts the image.
Yes, it really does and I hate it! But I haven't found a way (yet) to shut it off, it is the DrawImage method in .NET that automatically smooths the image when scaling. Either there is some way to shut it off, or I will create my own bitmap scaling routine in a later version.
/ Joakim
|
| Joakim |
Chris Cromer wrote:
Very nice tool, although it is very resource hungry... I would hate to see what it would do to my old pc... the one I am using now I got this January.
Yes, it is the Fill command that is very slow. Right now I am using the SetPixel command of .NET to draw pixels, because it is easier when debugging. In a future final version, I will access the bitmap directly. That will speed up enormously.
/ Joakim
|
| Brian_Provinciano |
Joakim wrote:
Chris Cromer wrote:
Very nice tool, although it is very resource hungry... I would hate to see what it would do to my old pc... the one I am using now I got this January.
Yes, it is the Fill command that is very slow. Right now I am using the SetPixel command of .NET to draw pixels, because it is easier when debugging. In a future final version, I will access the bitmap directly. That will speed up enormously.
/ Joakim
I suggest the array/look up fill algorithm as used in SCI Studio 3 and Lance Ewing's Tools. I wrote a function callback fill routine once, but it was far too resource hungry as well.
|
| AGI1122 |
Actually I hadn't filled when it started bugging out on me. I was drawing some lines in the visual screen, then I went to play around with the priority screen, when I tried to turn on the priority color it took forever and slowed my system down quite a bit. Most likely because the visual color was still on?
|
| Joakim |
Brian Provinciano wrote:
I suggest the array/look up fill algorithm as used in SCI Studio 3 and Lance Ewing's Tools. I wrote a function callback fill routine once, but it was far too resource hungry as well.
I'm using the push/pop method (similar to Lance's) right now, so that is not the cause for slowdowns. It's the SetPixel command of GDI+, it's very, very, very slow. At the same time, it's very, very, very easy to use. :) I choose that tradeoff in this version..
/ Joakim
|
| Joakim |
Chris Cromer wrote:
Actually I hadn't filled when it started bugging out on me. I was drawing some lines in the visual screen, then I went to play around with the priority screen, when I tried to turn on the priority color it took forever and slowed my system down quite a bit. Most likely because the visual color was still on?
That sounds very strange. Can you reproduce it and send the exact steps you make to cause the slowdown? I tried to reproduce it myself, but can not see any slowdown. It should be no problem at all that both Visual and Priority color is enabled!
/ Joakim
|
| AGI1122 |
I didn't actually save my work, I was just drawing lines randomly to test it out. So can't really reproduce it. :-\
|
| Joakim |
I have put up a (slightly ;) ) polished version of the picture editor now.
Other than cleaning up bugs, I have spent some time optimizing the drawing routines. Try it out!
Please report any bugs found so that I can kill them and release a final version of the editor. I need to move on and work on the View editor instead.
/ Joakim
|