Grafx2 Art Program

[midiblip]

Brilliant Yrizoud...we look forward to seeing that.
I am going to get a Caanoo now.

 

[Aion]

Hello again!
Here is a small update based on the same source code of editor as previous release.

GrafX2 for GPH Wiz/Caanoo

+ Fast 24->8bit converter to fake 24bit palette with progress window.
Allows you to load truecolor images and do not wait for them to open an eternity.
+ Added pack of sample pictures(from http://artcity.bitfellas.org/).
+ Added Wiz port(different .gpe's!).
* Undo/Redo buttons can't be pressed until there is a windows on the screen.​

 

[yrizoud]

The following is mainly for Aion, but there are some points (in bold) that may interest non-coders:

I compared your sources to the "original" sources, those of revision 1398. I integrated the differences into the main trunk of source code repository as revision 1629. (I work in IT and do a lot of diff/merging, and enjoy it, no problem.) The goal is that you can use and compile the most recent changes: for example, the tools for palette cycling.
Your changes about 24bit loading are still only active on the console port, but I will soon add some #define so that I can see what it does and maintain it, even on Windows.
I assume the real gp2x will define both __GP2X__ and __gp2x__, and that the Caanoo and Wiz don't define either of them.
In revision 1630 I fused a little the modifications to make the code simpler, hopefully without breaking anything.
At the same time I made a change: I removed in input.c the hard-coded "Quit", "Undo" and "Redo". It's a bit buggy to put it there, and anyway Grafx2 has fully redefinable controls, it allows 2 inputs for the same command. Quit Undo and Redo had no associated second shortcuts, so I defined joystick buttons as defaults for them. (ie: Undo is triggered by key U or button "I")
The only defect with this change is for users who have already tested the Caanoo port: They will only receive these defaults if they reset their configuration, for example by deleting gfx2.cfg.
Another oddity is with with HOME: Since you have set it as "ESC", it' the universal "cancel" button and you can't set it as a hotkey: Grafx2 shows "*PRESS KEY OR BUTTON*", and if you press HOME (with no modifiers like "shift" etc.), it assumes you don't want to re-assign the key after all.
So: I've set HOME as the default, but if you uset it, you can't change it back to HOME without resetting the config.

About ergonomy and default key mappings :
Joybutton_shift=X, Joybutton_control=SELECT, etc: You should probably not set them all, because it means the button itself doesn't trigger any shortcut - it can only serve as a modifier, in order to assign different shortcuts.
For example, if you set Y to act as "shift", you can set different shortcuts for "hold Y + press I"
Be careful that the "shift" modifier has an effect while drawing: it forces most tools to align on horizontal or vertical axis. The "control" and "alt" modifiers, however, have no side effects of this kind.
It's a matter of testing and experimenting, to find a configuration that will fit most users.
There's the issue of left-handed versus right-handed users...
We'll probably find that some new settings should be added in Settings screen.
I recommend setting a button for Help (F1 key), because it's from contextual Help screens that you can set and change shortcut buttons.

Can you use SVN to get our changes from googlecode (read-access is free for all) ? Or do you need source archives ?
Do you prefer write access on the SVN, it requires a google account. We can setup any system you prefer, like for example a work branch so you can have all your time to test changes before merging to the trunk.
In any case, I can perform merges as many times as needed, no problem.

(edit: I'll work on the virtual keyboard. Any comments on the designs I started? Are they large enough ?)

 

[hardyx]

(edit: I'll work on the virtual keyboard. Any comments on the designs I started? Are they large enough ?)

I think you need to make the buttons double sized to allow the user push it easily.
Four or five rows of bigger buttons will be ok.

 

[htdreams]

Wow!

I'ven away from wiz for some time, but i'm very pleased to see an update to grafx2 port for wiz that really shines, good work and THANK YOU two :-D

I'm a pixel artist who bought my wiz to use for pixel art (i've made a pixel editor in bennugd with layer support, but it runs slowly and doesn't make fluid strokes), so i'll be using grafx2 from now

@yrizoud: virtual keypad will be a great improvement, i don't know how to connect an usb keyboard to wiz, and making such connection is against having a portable devide for pixel art.

About button size, I like vk2.gif better, as Hardyx said making big buttons will be better as (at least on my wiz) cursor precision is not that great.

Thanks again, you've made a dream come true!

 

[midiblip]

Yes they have both done really well to get this ported over. Such a useful paint program for Amigans and us Dpainters.

 

[yrizoud]

(edit: I'll work on the virtual keyboard. Any comments on the designs I started? Are they large enough ?)

I think you need to make the buttons double sized to allow the user push it easily.
Four or five rows of bigger buttons will be ok.

For the full keyboard, I've checked and in the 2 screens where I'll need it, there's lots of room. So here's a second try, see post: http://code.google.com/p/grafx2/issues/detail?id=389#c3

Wow!

I'ven away from wiz for some time, but i'm very pleased to see an update to grafx2 port for wiz that really shines, good work and THANK YOU two :-D

I'm a pixel artist who bought my wiz to use for pixel art (i've made a pixel editor in bennugd with layer support, but it runs slowly and doesn't make fluid strokes), so i'll be using grafx2 from now

Thanks. Did you know the computer version before? In any case, don't hesitate to report what are the problems. There are many things I can't imagine without seeing it run. For example, with Aion we'll try to define some useful default keys, but if you struggle and find a better config that suits you, please share.
The limited number of buttons really hurts the "hotkey" system of grafx2 (about 170 commands can have hotkeys), but we can find creative solutions... for example shortcuts with "hold button + click and drag up/down/left/right".

The lack of right mouse button is probably very hurtful (touch acts as a left click), I think I should set a key to act as modifier : while held the touches would be right clicks. Users could combine it with the 'right mousebutton picks color' option, if they prefer this mode.

@yrizoud: virtual keypad will be a great improvement, i don't know how to connect an usb keyboard to wiz, and making such connection is against having a portable devide for pixel art.

Exactly. Grafx2 for console makes sense for pixelling "on the run". If you're at a place with a keyboard, you probably have the rest of the computer not far.

About button size, I like vk2.gif better, as Hardyx said making big buttons will be better as (at least on my wiz) cursor precision is not that great.

Now I'll see what I can do with the specific keyboard for numeric entries. Entering number is needed in many screens of various shapes, and you don't want to have the "keypad" hide an important part of the window, like the OK button...

 

[htdreams]

For the full keyboard, I've checked and in the 2 screens where I'll need it, there's lots of room. So here's a second try, see post: http://code.google.com/p/grafx2/issues/detail?id=389#c3

Sweet! it seems keys are big enough to skip the sometimes buggy wiz cursor precission (do the canoo suffer from this too?)

Thanks. Did you know the computer version before? In any case... the complete paragraph above this post

I know grafx2 since it's first steps, but by that time i was already used to work with layers, so i never got too hooked to it, i'm more a "graphics gale" guy (supperb win32 pixel editor with animation capabilites, and near free, you only need to buy it for gif support), so now that grafx2 support layers, and i can use it in my wiz... i'll be putting some time at it and tell you about how it feels

About the keys... i like your idea, i would love to have L button work as a modifier for the cursors so when i'm in zoom mode i could move the view with the cursor keys and L pressed (or when editing images larger than 320x240, btw, is this possible too?) In old DPaint program you could use N key to pan the view towards the cursor position, i dunno if grafx2 implements this feature...

And yes DPaint and clones (like cosmigo promotion) are very shortcut oriented programs so i understand very well the dificult task of a console port

About the right mouse button, what about using also the L key as the modifier for right clicking? it's fast and comfortable (i'm right handed, it would be good to have a "mirror key config" option for left handed people) as you hold the console with the left hand and have index finger for L key and thumb for cursor & menu keys

About the color picker.. it really is a personal option, i would like to have the L act as right click modifier and use the eyedroper icon for that

Another good key config would be having Y or X button to cycle the toolbar position (down, up, hidden)... maybe in the R key and leave Y/X for Undo/Redo?, btw, is Y/X/Select buttons used for anything in this build?

Now I'll see what I can do with the specific keyboard for numeric entries. Entering number is needed in many screens of various shapes, and you don't want to have the "keypad" hide an important part of the window, like the OK button...

That's a good point, i've been thinking only in the filename entry screen, but when choosing image resolution you need a small keypad

I hope to be useful, if you need me to test something don't hesitate to tell me (here or at my email address, adepedro at proyecto-iris dot com)

Thanks!

 

[yrizoud]

(or when editing images larger than 320x240, btw, is this possible too?)

Image size is limited to 9999x9999. To scroll the image, it's the same shortcuts when you are zoomed and when you aren't.
However the joystick is hard-coded to control the cursor; it's redundant when you are using the stylus.
We need to make the touchscreen ports allow the joystick buttons to have different usage, this way you'll be able to assign them 'scroll up', 'scroll right' etc. But Also : L+Up "zoom +" L+Down "zoom -", etc.

In old DPaint program you could use N key to pan the view towards the cursor position, i dunno if grafx2 implements this feature...

No, but you're not the first person who asks. I should probably add the function to the computer version, though N is already taken by default.

About the right mouse button, what about using also the L key as the modifier for right clicking? it's fast and comfortable (i'm right handed, it would be good to have a "mirror key config" option for left handed people) as you hold the console with the left hand and have index finger for L key and thumb for cursor & menu keys

These look like the most usable keys for right-handed people. Should put the most often used shortcuts there.

About the color picker.. it really is a personal option, i would like to have the L act as right click modifier and use the eyedroper icon for that

It sounds like a good adaptation to stylus work. It may be very close to simply using L for colorpicker tool, but a big benefit is that you can use L+touch to activate all buttons' secondary functions, and with modes like Shade, you can shade in 2 directions.

Another good key config would be having Y or X button to cycle the toolbar position (down, up, hidden)... maybe in the R key and leave Y/X for Undo/Redo?, btw, is Y/X/Select buttons used for anything in this build?

Toolbar can't move, sorry :/
In this build, Aion has set Y is the "Alt" key. So you can't plug any shortcut on it, only on "hold Y"+...
Similarly, L and R are the "Control" and "Shift" modifiers - but they are also hard-coded as Undo and Redo, which is pretty hackish.
X is "Cancel" but also hard-coded "Quit".
These hard-coded shortcuts are removed in the source code after my integration, they are replaced by regular shortcut mappings.

In my opinion, only one button should be set for Undo, and then Redo should be L+ that button.
Same for effects : if you dedicate one button for "Effects menu", L+that button could be assigned to "all effects off"

In any case: the current build doesn't really help people set good shortcuts. To really test shortcut mappings, we'll have to wait till Aion's back from vacation.

 

[htdreams]

In old DPaint program you could use N key to pan the view towards the cursor position, i dunno if grafx2 implements this feature...

No, but you're not the first person who asks. I should probably add the function to the computer version, though N is already taken by default.
[/quote]

The N key is usefull using a mouse or pointing device, with stylus it's best to have a key modifier for activating panning with click and drag with the stylus (or a modifier to pan with the joystick) we talked about using L key for right clicking, it could be used also to make the joystick pan the view.

It sounds like a good adaptation to stylus work. It may be very close to simply using L for colorpicker tool, but a big benefit is that you can use L+touch to activate all buttons' secondary functions, and with modes like Shade, you can shade in 2 directions.

Grafx2 has a lot of functionality using right click, so i really think it would be the best use, and also you could alternate paint with two colors by pressing L (draw & erase, for example, or for dithering).

Toolbar can't move, sorry :/
In my opinion, only one button should be set for Undo, and then Redo should be L+ that button.
Same for effects : if you dedicate one button for "Effects menu", L+that button could be assigned to "all effects off"

It's a pity not have the ability to move the toolbar, i suppose it isn't needed if you can pan the view. Is there an option to view the image "fullscreen" (i recall V key for this in old DPaint) to check the entire screen at once?

I'm with you about the undo and effects.

In any case: the current build doesn't really help people set good shortcuts. To really test shortcut mappings, we'll have to wait till Aion's back from vacation.

I'm eager to have a new build wich at least let me write file names

If you two need some help, let me know.

 

[yrizoud]

How could i scroll the view? is there a panning button combination?

Not yet. I don't know if it's evident, but you can change the shortcuts, except what I listed as hard-coded in above posts. Click the '?', then Help. In this help screen, click on any highlighted "key name" to redefine it. This works in every Help screen, and each button of the toolbar and each setting screen has its own contextual help. This is why I recommended setting a button for Help. If you want to see or set a shortcut for Magnifier for example, it's much easier to put the cursor over the button and press "Help", instead of browsing through the complete list of shortcuts.

I used the hand tool, but it moves the content of the active layer, it's not panning.

Yes the hand is a very different tool. I've always wanted to implement a panning tool however.

I wouldn't drop cursor movement with joystick, as it's usefull with some tools, like the curve tool, you can pick two points and then move the cursor with the joystick and configure the curve with preview, this can't be done with the stylus

I don't understand why it can't be done with stylus?

With stylus it's best to have a key modifier for activating panning with click and drag with the stylus (or a modifier to pan with the joystick) we talked about using L key for right clicking, it could be used also to make the joystick pan the view.

I hadn't thought about that (button for right click modifier + button for mouse emulation = also a shortcut when used together) but I guess it would work.

Is there an option to view the image "fullscreen" (i recall V key for this in old DPaint) to check the entire screen at once?

Yes, there is :
1) a shortcut for 'toggle all menus' (F10 on keyboard). It's the same as left-clicking the bottom left icon in status bar. It keeps the 8-pixel tall status bar visible.
2) internal support for full-screen editing. It was the ancestor of 1), before we implemented "strips" of menus (3 independant strips: tools, layers, status line). I was always afraid that a user would trigger it accidentally and be stuck in full-screen mode, so at the moment it's impossible to trigger it on any platform. If it's useful for console port, I can easily bring it back.

I'm eager to have a new build wich at least let me write file names If you two need some help, let me know.

Feedback and report of problems is very helpful. Other than that, what we really lack is a MacOSX coder who can lend us a few hours, so if you know one, please let us know

 

[Jengo]

you guys are awesome!! Mad props!

 

[yrizoud]

You can test Windows version with the virtual keyboard here:
http://code.google.com/p/grafx2/downloads/detail?name=grafx2-2.3wip1637-win32.zip
If you want to put yourself in Caanoo context, resize the window so that it's smallest possible (320x200).
For the virtual keyboard of numeric inputs, I didn't waste time and simply used same buttons as the alarge alhanumeric one:
http://code.google.com/p/grafx2/issues/detail?id=389#c4
Feedback is welcome.

 

[htdreams]

About mac programmers... sorry, i don't know anyone, my pals and myself work with delphi and c#

And about the curve tool, with stylus you can't drag the curve to position it in the desired configuration, you pick curve start point, then curve end point and then a third point to set the curve configuration... but i like to move and preview the curve to adjust it to my drawing, so i pick start and ending points and use joystick keys to choose the curve configuration (A button to finish curve painting).

You can test Windows version with the virtual keyboard here:
http://code.google.com/p/grafx2/downloads/detail?name=grafx2-2.3wip1637-win32.zip
If you want to put yourself in Caanoo context, resize the window so that it's smallest possible (320x200).
For the virtual keyboard of numeric inputs, I didn't waste time and simply used same buttons as the alarge alhanumeric one:
http://code.google.com/p/grafx2/issues/detail?id=389#c4
Feedback is welcome.

I've tested the windows version, i like the virtual keyboards, the main keys (letters and numbers) seems big enough for stylus writing (assuming the lack of precision in wiz touch screen), i feel it works great and fast (at least with mouse), and would love to test on my wiz console.

The keyboard seems natural when focusing text/number boxes, so i thing would be very comfortable to use.

With the source code included can i compile wiz version?

 

[yrizoud]

Thanks for testing.

with stylus you can't drag the curve to position it in the desired configuration

Ah I see... Maybe I should change curve so that you can click and drag for preview of 3rd point, and curve is only made permanent on release.

With the source code included can i compile wiz version?

In theory yes, but you need quite an environment for compiling, especially for the Caanoo. Needs an operational GPH SDK (Not even sure the Windows version works), then use the Code::Blocks project made by Aion in his package (fix the paths according to your machine) and if this version compiles, then you can replace the .c and .h sources by the one in latest package.

 

[htdreams]

Ah I see... Maybe I should change curve so that you can click and drag for preview of 3rd point, and curve is only made permanent on release.

Nice idea! i like it very much, it would be fast that way

you need quite an environment for compiling, especially for the Caanoo. Needs an operational GPH SDK (Not even sure the Windows version works), then use the Code::Blocks project made by Aion in his package (fix the paths according to your machine) and if this version compiles, then you can replace the .c and .h sources by the one in latest package.

I've already have Code::Blocks and GPH SDK (windows version on WinXP) running and fully operational (several demos compiled and so on), i've downloaded last version from the grafx2 repository and also Aion's version

This are my results using Aion's Code::Blocks project revised for my paths:

Aion's version compiles right and runs on my wiz without problems
Updating code to last version(1637) i can compile with host target and it runs fine in windows, but doing so with Wiz target it gets stuck at load screen from Wiz launcher option

¿The changes Aion has made are in the repository? at this moment i can't find the changes Aion has made for runing on Wiz, i'll keep searching from main.c and the init phase. Any clue or advice?

The amusing part is that with last version in host target compiled and forcing the virtual keyboard on i can use it on my tabletpc in slate mode without keyboard (but it's not as portable as the Wiz, of course)

 

[yrizoud]

Maybe it's the resolution : Look in init.c, at beginning of Set_all_video_modes(void) :

  #if defined(__GP2X__)
  // Native GP2X resolution
  Set_video_mode( 320,240,0, 1);
  #else
  // Window mode, with default size of 640x480
  Set_video_mode( 640,480,0, 0);
  #endif

  Set_video_mode( 320,200,0, 1);
  Set_video_mode( 320,224,0, 1);
  #if !defined(__GP2X__)
  // For the GP2X, this one is already declared above.
  Set_video_mode( 320,240,0, 1);
  #endif

Try replacing the first #if by :
#if defined(__GP2X__) || defined(__CAANOO__) || defined(__WIZ__)
and the second one by:
#if !defined(__GP2X__) && !defined(__CAANOO__) && !defined(__WIZ__)

 

[htdreams]

Hi!

I'm afraid i'm very busy with work, with little time to hobby proyects (and drawing :-( ) so i couldn't check more than your advice about init resolution, but it doesn't load up, it also doesn't create any error messages so i plan writing a log file to catch the code that hangs the machine, i hope to spare a little time this weekend

 

[Aion]

Hi!

I'm afraid i'm very busy with work, with little time to hobby proyects (and drawing :-( ) so i couldn't check more than your advice about init resolution, but it doesn't load up, it also doesn't create any error messages so i plan writing a log file to catch the code that hangs the machine, i hope to spare a little time this weekend

Don't worry, i'm still working on Wiz/Caanoo ports, chatting with Yves in PM. I made a new build with 1637 sources, but it has some target device issues. I'm trying to fix it now.

 

[yrizoud]

Reported by Aion:

Icon garbaging appeared only on target device. On host it work perfectly. I think it's a data alignment issue. I'm added into typedefs a GCC related __attribute__((__packed__)) option instead of ignored #pragma pack, but it does not help Using packed data is not a good choice in multi-platform releases. You've get a bit of free RAM but also a HUGE head pain when it comes to porting. Menu drawing function is complicated. Worked with a raw pixel data arrays of skin images. Need a time to understand and debug. So no quick port at this point.

Pointers to bytes should not require starting at aligned address, and 2D (or 3D) byte arrays should require no padding between the bytes or the rows. If some platform requires them, porting will be be extremely hard :/
You probably wonder why it didn't happen on the version where you started porting: Since then, we've changed skins so that they include specific images for selected icons. As a consequence, the "bitmaps" in skin structure (2d array of bytes) now have an extra dimension: they are arrays [3][height][width]. On the first dimension, [0] is all unselected, [1] is all selected; both are not modified after loading. [2] is "current state", and receives modified buttons - copied either from [0] or [1].
After loading a skin, the pointers Menu_bars[0].Skin[0-3] point to gfx->Menu_block[0-3]. They need to point to contiguous 2D array of bytes, otherwise all access to ".Skin[]" will be wrong.
I spent a long time trying to understand what happens in the images you sent, and it really can't be explained by the original source code. I can only deduce that you made big changes, but not everywhere. There must be error in any of the functions that write in skins during execution, such as Pixel_in_menu_and_skin(), Pixel_in_menu()....

For troubleshooting, you may want to add some debug printf to log sizeof(gfx->Menu_block[0]) and sizeof(gfx->Menu_block[0][0])