Community
AGI Programming => AGI Development Tools => Topic started by: lance.ewing on June 14, 2011, 04:59:24 PM
-
I have built and released the first milestone release of PICEDIT 1.3. So far I have only put it in the downloads section of the Google Code project. It isn't yet on www.agifans.com, but I'll get to that soon.
http://code.google.com/p/picedit/downloads/list
The new features include:
* Four window sizes to choose from. The 2x option is the old screen size. The default is now 3x.
* Priority bands/grid lines. This was something missing from version 1.2 that is now fairly standard in AGI and SCI picture editors. It shows where each of the priority bands start.
* Dual visual/priority mode (where priority and visual screens mix, as first shown in the APE tool). This is a bit gimmicky but I quite liked it when Joakim Moller first demonstrated this with the APE tool. What it does is render the priority screen and then the visual screen is drawn on top with 50% transparency. Try picture 45 in SQ2 to compare with the APE screen shot on www.agidev.com.
* Load and Save dialogs now start in the current directory and remember the directory between uses, and the current picture file name is displayed on the title bar.
* Right clicking now stops the current tool but does not set tool to None. This allows the user to draw more lines in one go. They no longer have to keep choosing Line. They simply select Line at the start, then draw a line, right click, and then start drawing another line in another place on the screen. Right clicking twice will switch the tool to None.
Let me know what you all think. I am very keen to hear all of your feedback and suggestions.
-
See my news page below for a comparison of the dual mode in APE with that in PICEDIT 1.3 milestone 1.
http://www.agifans.com/news/picedit13milestone1released
-
Has anyone had a chance to take a look at the new version yet? Ironically, it looks like there have been more downloads of the 1.2.1 version over the past 3 days than the new 1.3M1 version. Here is a direct link to encourage more downloads:
http://picedit.googlecode.com/files/picedit-1.3M1.jar
-
I haven't had time to do more than a cursory look over, but I really like the zoom. I think that is a really big improvement.
-
No worries. I might advertise it a bit more, maybe put a message up on the SCUMMVM AGI forum. I think sact might be interested in some of the new features.
I guess the feedback I'm after is not just regarding the new features but is also regarding what could be made better, even if it is something seemingly small, like the behaviour of the file dialogs, but which could have a big impact.
-
Speaking of file dialog, the default on Windows is opening starting with the System32 directory.
Small features, how about an eraser? Also, a dither fill.
-
I must admit I haven't tried it in Windows yet. The reason I've implemented it the way it currently is though is so that it will work when invoked from AGI Studio. I am assuming that if you use the batch script that you came up with, that when launched from AGI Studio, it will use the location where the game pictures are. I haven't tested this yet though, but I am guessing it will. The System32 folder must be where java is launched from when a jar file is double clicked (on the Mac it seems to pick up the location where the jar is located, from what I can tell).
A dither fill might be a bit tricky for AGI, but when I've added SCI0 support (which is something that is ongoing in the background), the SCI mode will have all the standard SCI0 fills. A dither fill in AGI would need to use diagonal lines of alternating colours, which is definitely possible but might generate a lot of data. A standard AGI fill, on the other hand, is about 3 bytes. But it does sound like a feature that people would like regardless of how much data it generates. I guess it might restrict games to being run on NAGI though.
What do you mean by an eraser? Perhaps a feature where the user can select parts of the picture to delete?
-
I had just launched it by double clicking on the JAR. Using the batch it does open in the bat file's folder. Not that big of a deal, but thought it would be better to not open in a system folder.
I was thinking more of SCI for the dither fill.
Yes, a delete for where the cursor is clicked, not just an undo, as undo would also remove all other actions that occurred after what to be removed was first added.
-
Highlighting the button of which function is currently selected might be nice (Line|Step|Fill|Brush). Never mind, I see that the currently selected tool is displayed in the title bar. Still, might be nice...
EDIT: Interesting implementation of the zoom feature. Just resize the whole app, rather than the window. How do you feel about utilizing the mouse scroll wheel as an alternate way to zoom?
-
Highlighting the button of which function is currently selected might be nice (Line|Step|Fill|Brush). Never mind, I see that the currently selected tool is displayed in the title bar. Still, might be nice...
That would seem more intuitive to anyone used to the standard image editors.
EDIT: Interesting implementation of the zoom feature. Just resize the whole app, rather than the window. How do you feel about utilizing the mouse scroll wheel as an alternate way to zoom?
Again, this would be in keeping with standards for image editors.
-
I had just launched it by double clicking on the JAR. Using the batch it does open in the bat file's folder. Not that big of a deal, but thought it would be better to not open in a system folder.
It does seem strange that it opens in the system32 folder in that scenario. I'll see what I can do about that. I might be able to put a check in there that if the current directory at startup is a windows folder then use the user home directory instead.
Yes, a delete for where the cursor is clicked, not just an undo, as undo would also remove all other actions that occurred after what to be removed was first added.
There are a few similar features I'm thinking of for 1.3 that you might see in the next Milestone. One such feature is the ability to move the vertices around by clicking on them and dragging them with the mouse. I was told by a reliable source that Sierra's SCI editor had such a feature. To implement this, it would require the application to recognise what part of the picture is drawn at each point on the screen. So after I've given the application this kind of awareness, then it makes a lot of other features possible, such as being able to delete what you click on, or move vertices around... maybe even introduce new vertices to a line.
-
Highlighting the button of which function is currently selected might be nice (Line|Step|Fill|Brush). Never mind, I see that the currently selected tool is displayed in the title bar. Still, might be nice...
Yeah, sounds like a nice feature. I'm actually thinking about redesigning that whole panel at the bottom, which may include changing those to icons. I need some extra space for a new feature.
Actually, for SCI it needs all of the panel space for the picture. So I've got to decide whether to implement a slide away panel (which was my first thought), or to simply make the screen bigger to accomodate the SCI picture size. I'm reluctant to make the screen bigger because at the moment the screen dimensions relate to the original interpreters screen size (i.e. 320x200, albeit multiplied by 2, 3, 4, or 5). I like the fact that it looks like the original interpreter. But maybe at some point I have to abandon that look and feel and use a more standard windows appearance with a proper menu, proper buttons, etc. But something like WinAGI already has that look and feel, so the current PICEDIT look is something that is part of its character I guess and what makes it different. Maybe I'm being too nostalgic trying to hold on to the Sierra interpreter look and feel.
A slide away panel might work for SCI. Do you think people would find that strange? The idea is that if they take the mouse cursor below the SCI picture then the panel slides up, and as long as the mouse is then over that panel, it stays visible, which allows them to select something. It would slide away when they move the mouse out of the panel again. I'm worried that the panel might tend to slide up a lot more often than what the user wants though. So it might be better to have a key shortcut for it.
-
EDIT: Interesting implementation of the zoom feature. Just resize the whole app, rather than the window. How do you feel about utilizing the mouse scroll wheel as an alternate way to zoom?
Again, this would be in keeping with standards for image editors.
As Gumby noted, it isn't really zooming in but rather resizing the whole screen. What I noticed is that when the screen size is big enough to fill the whole monitor then the AGI pixels look so big that it is as if they are in the traditional zoomed in mode. I don't think anyone would need the pixels any bigger to see what is going on. There was some feedback regarding 1.2.1 that the screen was far too small on big monitors. I guess this new feature addresses both of these areas.... i.e. zooming in and making the screen bigger.
I think I'll play around with the mouse wheel for controlling the screen size feature and see how it behaves. That is a feature I can implement in about 10 minutes. I already have a place holder for the mouse wheel action, so I just need to make it call those same zoom actions.
-
There are a few similar features I'm thinking of for 1.3 that you might see in the next Milestone. One such feature is the ability to move the vertices around by clicking on them and dragging them with the mouse. I was told by a reliable source that Sierra's SCI editor had such a feature. To implement this, it would require the application to recognise what part of the picture is drawn at each point on the screen. So after I've given the application this kind of awareness, then it makes a lot of other features possible, such as being able to delete what you click on, or move vertices around... maybe even introduce new vertices to a line.
This would be fantastic. It is a standard feature of vector editors. This is one of the reasons that I am much better at vector graphics than bitmaps, unless the bitmap is of a high enough resolution to work with, which obviously is not the case with AGI/SCI0 pics.
A mouse over panel that pops open automatically would drive me bonkers. The feature would be a lot more welcome if it was manually opened and closed.
-
A slide away panel might work for SCI. Do you think people would find that strange? The idea is that if they take the mouse cursor below the SCI picture then the panel slides up, and as long as the mouse is then over that panel, it stays visible, which allows them to select something. It would slide away when they move the mouse out of the panel again. I'm worried that the panel might tend to slide up a lot more often than what the user wants though. So it might be better to have a key shortcut for it.
As long as there was a visual indication that the panel was hidden, I think it might work. Use a few directional arrows perhaps.
Along these lines, I didn't find the menu immediately - despite the fact that it is consistent with Sierra's interface. If you are considering highlighting the currently selected function and removing the existing text indication, a 'Menu' button might fill the void in the upper left corner on the screen quite nicely.
-
The menu bar does not always show in AGI games. It is the SCI0 games that always shows it. PicEdit was an AGI tool. That aside, I understand wanting to keep the AGI feel, but functionality is more important. It is a tool, after all. An always visible menu bar does make more sense.
-
A dither fill might be a bit tricky for AGI, but when I've added SCI0 support (which is something that is ongoing in the background), the SCI mode will have all the standard SCI0 fills. A dither fill in AGI would need to use diagonal lines of alternating colours, which is definitely possible but might generate a lot of data. A standard AGI fill, on the other hand, is about 3 bytes. But it does sound like a feature that people would like regardless of how much data it generates. I guess it might restrict games to being run on NAGI though.
We already do that kind of dithering, but in Photoshop, MS Paint, ... and then convert it with Vector :P If Picedit would offer the option to select two colours, then click the area to fill, it would actually be faster than how we do it now.
And yes, it results in NAGI-only games :P
-
The menu bar does not always show in AGI games. It is the SCI0 games that always shows it. PicEdit was an AGI tool. That aside, I understand wanting to keep the AGI feel, but functionality is more important. It is a tool, after all. An always visible menu bar does make more sense.
By "menu bar" do you mean the menu/status combo bar? In SCI0 the menu seems to behave the same as in AGI, where there is a status bar most of the time, unless the menu has been activated, at which point it becomes the menu. I guess I could retain the status bar to continue to make it look like an AGI/SCI game and move only the menu into a proper windows style menu. I think I've convinced myself now to switch to a more modern menu system. It doesn't seem like there is anyone that will miss the current menu system too much.
(In AGI it appears to be possible to move the picture to the top of the screen and give more text lines at the bottom. I noticed that the KQ1 title screen does this)
-
Sorry, faulty memory about the menu bar. Still, most tools have the menu bar visible at all times.