I've been away from the AGI community for about a decade but recently my interest was renewed again. For some reason I felt like revisiting my AGI picture editor tool PICEDIT. I've been a Java developer for the past 13 years and have no desire to write C code anymore, so I decided as a starting point to extending PICEDIT I would rewrite the tool in Java. I have now completed this conversion to Java and the first beta release is available on my new web site below:

I'd be very keen for as many AGI/SCI fanmade game fans as possible to download PICEDIT 1.2.1 and let me know what you think. You'll need to download and install Java 6 first but after that all you'll need to do is double click on the downloaded PICEDIT 1.2.1 JAR file. The good thing about it being written in Java is that it is instantly available for all platforms... so you'll be able to run it on Windows (XP/Vista/7), Linux, Mac, etc.

It is very likely that there are still bugs in it so I apologise in advance for this. What I'm really looking for is testers though. I'll fix bugs as soon as they are reported.

From this point I'm hoping to add a lot more features. At the moment it is almost the same as the original PICEDIT 1.2 that I released back in 1997. Over the next month or so I'll be adding many more features. It would be good to get some suggestions from the AGI and SCI community about the features that should be added.

Good timing, after Chris Cromer's messageboard gave up the ghost, I suspected this might be the end of AGI community.

The new java PICEDIT works just fine, and doubling the size from the original is good idea, yet it's still kind of small with 1920x1080, thus is there any chance of putting some options there to enlarge/preview to full screen/resize the application?

Good idea! Actually my screen is also 1920x1080, so I know what you mean. Currently, as you say, it is using a 2x factor, which makes the size 640x400. If we included a 3x option then it would increase the size to 960x600, and a 4x option would increase it to 1280x800, and a 5x option would increase it to 1600x1000. I guess that is about where we would stop for now. What I'll most likely do is add an option to the menu to select anywhere from 2-5 times.

Let me know if you have any other suggestions. I've got a list of ideas already but wanted to know what other people thought.

Once upon time there was a new picture editor being designed, known as APE which derived, if I recall correctly, from Another Picture Editor. It had website and all but all I was able to find now was the one screenshot of it from AGIDev.com. APE was able to display both Visual and Priority-screen simultaneously.

APE was something that Joakim Moller was working on. I remember trying it out at the time. I can't remember what other features it had other than the one you've mentioned already.

Yes, implementing something like that dual mode would be fairly straight forward. Java has a lot of cool image routines built in, including a variable opacity setting for each color. What I could do is something similar to what it is already doing for the background tracing image, except that the opacity of all colours is 50% instead and the priority screen is drawn behind.

Working with the PICEDIT is otherwise pleasant, if we forget the that after using a tool (right clicking to stop using it), one has to reselect the tool one used/select a new one. Maybe an option that right clicking does not unselect the currently used tool but just stops using it could be added?

Keyboard shortcuts - Keyboard shortcuts, say press l for line, f for fill etc. That would rock, or go as far as user defined keyboard shortcuts. Creating pictures should be as smooth as possible.

New tool, selection/layers - Ok, this is bit far-fetched but how about a new tool, for selection area of the picture and being able to copy/paste it, that could be used alone or with layers, like in photoshop.

Fill behaves oddly, it seems that it can only be used as once per picture. (And if in original DOS PICEDIT using fill reseted the currently used tool, please consider the alternative suggested in the first paragraph).

Are the keyboard shortcuts not working (as listed in the help page)? If not then that would be a bug. Those keyboard shortcuts you mention should already be working. There are actually two keyboard shortcuts for each tool, e.g. for Line there is l and f1. I'll investigate this.

Not sure that I understand the fill issue that you mentioned. I'll play around with it a bit and see if I can spot the issue.

Regarding selection of parts of the picture for deleting etc., I think I might be able to do something along those lines, perhaps not exactly as you describe but some sort of selection mechanism and clipboard.

The 3x3, 4x4, 5x5 zoom factor change is easier than I thought. I've just got it working. It will be part of the next release.

Regarding the keyboard shortcuts, they seem to be working fine for me, in fact this would be one alternative for reactivating a tool after clicking the right mouse button.

The idea to make a right click retain the selected tool is a good one. I just need to think through whether there are any side effects. I can't think of any at the moment. What I'm wondering is whether there is ever a need to turn of the currently selected tool? Probably not. In fact thinking about it I think this change would make it more consistent with the navigation. For example, if I draw a line then right click, it sets the tool to "None", but if I then go back one step and forward one step, it leaves the tool as "Line". If I then start clicking in the picture it draws a new line. So it would indeed be more consistent if a right click only resets the drawing but not the tool.

lance.ewing wrote:Are the keyboard shortcuts not working (as listed in the help page)? If not then that would be a bug. Those keyboard shortcuts you mention should already be working. There are actually two keyboard shortcuts for each tool, e.g. for Line there is l and f1. I'll investigate this.

Hehee, my bad, yet to my defence I'd might say, I was temporarily blinded when I was reading that section! But I'm still wondering whether one could freely define own controls?

lance.ewing wrote:
Not sure that I understand the fill issue that you mentioned. I'll play around with it a bit and see if I can spot the issue.

I choose a new picture from menu, randomly pick some colour, point somewhere within the picture, press f for fill, click, the colour I chose fills the screen. Then I pick another colour and again, press f for fill, point somewhere in the picture, click, nothing happens. Same applies both visual and priority-screens. One fill for them both, then unable to fill ever again.

Mouse's scroll wheel - Since tools are easily choosed with keyboard shortcuts, how about changing the current colour with scroll wheel? Depending whether one is viewing the priority- or visual-screen, just scroll the wheel to or fro, erm backward or forward, to change the colour. Or if you'd go along with the customizable controls-idea, mouse wheel-behaviour could be among them? (Yup yup yup, this would be most likely require own options screen.)

Thanks for describing the fill issue. Actually that is as designed..., not my design but Sierra's design. If you perform a fill on top of another fill then the AGI interpreter will ignore it. What I could do though is put in some smarts that figures out what the original fill command was and then replaces it with the new colour. It might be a bit tricky though. Because an AGI picture is drawn in a sequence of recorded steps, changing something early on in the picture can impact the behaviour of later steps. So I would need to do a hack of sorts... which would be to wrap the fill action in two change colour codes. The code before would set the colour to the new colour. The code after would set it to the old colour.

I've been thinking about mouse wheel suggestion. You may have noticed I used the mouse wheel on the "view data" screen. I'm not 100% sure about using it for changing the colour. The main reason at present is because every time the colour is changed, it adds a picture code to the picture code buffer to say that the colour changed. This means that if you scroll through the colours with the mouse wheel, it will add many redundant change colour codes and fill up the picture code buffer.

What I could do though is hold back adding the 'change colour' action until the user starts using a tool. That probably makes more sense as a general rule in any case. If I were to make that change then the mouse wheel idea makes a lot of sense.

I've been thinking a lot about how to make colour changing different. I say different rather than better because I have a more selfish need. I'm starting to add SCI0 picture support to PICEDIT. With SCI0 I don't get the luxury of having the grey panel at the bottom. It will have to slide down out of the way (e.g. like the windows task bar can be configured to do). Having to slide the grey bar up all the time to change colours would be a bit infuriating.

So I was thinking maybe of handling colour changes by clicking on the corresponding colour box on the status line at the top. For example, this might pop up a box with the palette in it that the user can select the colour from.

For SCI0 the mouse wheel idea might come upstuck. It has a palette feature that effectively gives you a lot more colours. Scrolling through that would be time consuming.