Pixel app for Mobile Phones, programmer wanted! :D

[ilkke]

WHAT IS IT?
A coupla years ago I was spending hours riding the bus everyday to work, and wished there was a pixelling app for my mobile phone. One evening it occured to me how to make a really good use of the phone's interface and I scribbled it on a piece of paper. Last night I decided to dig out that old sketch and make a mockup, as it might increase my chances of ever finding a person willing and apple to help me make it a reality.



This is a mockup in 176*208, possibly the lowest usable resolution. The app would ideally be able to detect the phone res and adapt, or if that is too complicated then separate versions could be made for 176*208, 240*320, etc.
Note that the canvas size here is only 9x9 pixels, but larger sizes would be supported as well.
The feature set is rather basic, yet the interface is designed to be very rapid to use.

WHAT DOES IT DO?
-Tools: draw and fill
-Foreground and background colors
-Zoom: x1 to x16 (possibly x32 or more on larger screens?)
-Palette editor
-Loading and Saving

I am not sure wether limiting palette size or canvas size would make sense. Probably 256 colours would be too many to plow through comfortably. For starters let's say
-16 color palette
-320*320 max canvas size

HOW DOES IT WORK?
Let's have another mockup, this time with the help overlay turned on (an actual feature, hopefully)



I've been looking at various phones and I tried to stick to the most common buttons.

-The joystick (or it's equivalent) moves the large rectangle (upper right in mockup) around the pic. The rectangle moves in steps of three pixels (unless you choose otherwise in the prefs) to keep things rapid.
-Clicking the joystick switches the tool between draw and fill.
-Digit buttons 1-9 place the fg colored pixel at the respective position within the rectangle. Pressing the same button again switches the pixels color to bg color. Flood fill tool selects the 'target pixel' in the exact manner.
-Left and right softkeys scroll through the palette.
-* and # keys increase and decrease the zoom level.
-Digit 0 brings up the menu with palette editor, save/load, help, options, etc.

This is the basics, there are more details, but probably not that important to most of you.

WHAT NOW?
Since pixel art is not a mainstream niche, let alone on mobile phones, I doubt that this app would ever be commercially viable. If you like the idea and want to support it, then feel free to c&c, and please, please, please...

HELP ME FIND SOMEONE TO CODE IT!

I think JAVA (J2ME) would be ideal, but I guess symbian is also okay. I imagine this is not too complicated to make for someone who has experience with the platform.
Thanks in advance

[VisMaior]

If oyu want device-independent app, MIDP only defines buttons 0-10, # and *. It will be hard to do t your way...

[Gil]

There's ways to make the "return" button, the "OK" button and the "C" button work too. Joystick control is always translated to numerical values though, so no way to differentiate between "joystick right" and "6" for example.

[ilkke]

@Vis: Thanks for the info! I'll try to see if it's possible to be 100% device independent and if it's worth it.

@Gil: If that is true, then there would need to be a button to switch between drawing and moving the rectangle. Not as pleasant but still usable.
On the other hand, on both phones I currently have with me, I can see that for example in phonebook the joystick scrolls the list, whereas number keys have a different function.

[Gil]

Yes, but the phone book is programmed native to the phone, so that obviously works.

I had a look for you and it seems that it is possible to make the distinction in Java.

MIDP calculator seems to do it just fine. This is a calculator and the numbers definately react differently from the joystick. If you have a compatible phone, I advise you to try it out. Very good calculator, excellent control scheme (might give you ideas on what's possible).

http://midp-calc.sourceforge.net/Calc.html
http://sourceforge.net/projects/midp-calc/ (source)

[PypeBros]

I have some experience with a similar interface i developed when i was a kid, on my mouse-less PC.
Very honnestly, drawing pixels with a keyboard proved to be the ultimate pain. It might be better with the interface you suggest, but i still doubt it. On the other hand, I managed to do a few interesting sketches for sprites in the bus on my DS, though it's hard to be precise both with pixels and with colours in such an environment.

[ptoing]

How is it harder to be precise with a keyboard or a joypad (or joystick for that matter)? I know people who made pictures on a C64 with a keyboard and they look brilliant. The tools never are the ultimate limit, but the patience of the user.

[ilkke]

Gil, thanks for your trouble, I'll check it out!

@Pype: It's true that mousing or tableting beats keyboard for comfort, but keeping your color counts down always dramaticly decreases time you have to spend pixelling.

The interface should be tangible, in a sense that it makes you feel that you are very close to your work, and in control. Some software makes you feel like painting with a brush tiled to the end of a fishing rod, and it makes no difference if you are using a mouse or a keyboard, it just sucks. I think keyboard pixel programs can be just as great as keyboard music trackers, which is pretty much what Ptoing had said.

[PypeBros]

Some software makes you feel like painting with a brush tiled to the end of a fishing rod, and it makes no difference if you are using a mouse or a keyboard, it just sucks.

Well, if you really feel like this is something that could get handy for you ... why not. After all, a good app arise when someone meets the workflow. Many little satisfied people makes less sense than a handful of enthusiasts.

I think keyboard pixel programs can be just as great as keyboard music trackers, which is pretty much what Ptoing had said.

True when the keyboard music tracker is great (e.g. Fast/Scream/Impulse tracker), though i've seen terrible things such as C64's Music Processor ... Probably just *my* keyboard-based graphic editor s**ked big times.

Sorry if it sounds like i miserably tried to get one more user. I shouldn't be diminishing your project.

[Gil]

If you find no one to program it, I'm willing to give it a go Ilkke. I was hoping someone with tangible MIDP experience would come along, but if you find no one, I'm graduating as a Java programmer soon, so I'm sure I could do it.

Keep searching for a while though, I'm sure there's better people out there.

[ilkke]

Gil, that would be great!
I have one volunteer for making a symbian version, but he will not be able to get on it for months. The only other offer I have is much less noble since I'd have to pay for the favor in pixels, and I am too busy to accept that anytime soon.
I'd rather do this with someone who is interested in the subject The program can only benefit from that.

Tell you what, I will make a rough 2-color prototype in flash, so we can see if the concept is any good. In the meantime if no one else comes forth, you can decide if you're still interested.

[Gil]

Sounds good

[ilkke]

Here's the flash test!

http://ptoing.net/ilkke/flash/pikCell.swf

FOR SOME REASON FLASH EMBEDDING FAILS MISERABLY

Keyboard handling is by default a bit 'ropey' in flash, I couldn't be really arsed to try to make it more decent.
Also, you have to click inside the flash movie to be able to use the keys.

controls:
cursors = move marker
numeric 1-9 = toggle pixels
numeric 0 = toggle marker step

Seems to work better with marker step set to 1, because you can place the marker exactly whre you like, and thus don't have to move it around as much.

[Gil]

I'd definately provide marker steps 1 and 3, seems like they both have their merrit. Actually I'd offer a marker step 3 and a 1px marker, so you can choose between fast marker stepping with 9 keys to draw pixels and the easier to use single pixel marker. Marker step 1 doesn't seem as useful as the combo of those two.

I'll have to see if I can devise an easy way to prototype java apps on a cellphone. Is there a MIDP emulator? I know I didn't find decent MIDP emulators a few years ago, I'll have to look...

edit: Yep, MicroEmulator seems to be a good option

[ilkke]

I'm not sure I understood the idea behind a single pixel marker. What's the difference between using that and using a 3x3 marker with a 1pixel step?

btw, my mail on yahoo is ilkkke. I guess we could use a more direct communication.

[Helm]

I'm not sure I understood the idea behind a single pixel marker. What's the difference between using that and using a 3x3 marker with a 1pixel step?

you can draw to the corners of the screen without having to press any other numeric button besides 5.

[Gil]

Yes, you'd basically have one finger on the joystick, one on the 5. Works a little faster for certain parts, marker works faster for others.

[ilkke]

Ah, ok then
I wouldn't completely give up on 3x3 1step marker, tho. I find it quite useful, at least in the prototype. We'll see if single pixel marker combo really makes it redundant.
I'll try to come up with a control scheme that uses only the standard keys, so we can maximize compatibility.

[ilkke]

Probably not that relevant, but I accidentaly found this emulator, thought I'd share:
http://jademula.kontechs.de/

[Gil]

I'll have a look this weekend. Have you thought about maximum picture size? Rigth now your preview allows for an 8x9 image, I was wondering what the maximum image size would be? I imagine that zooming in would be out of the question (zoom with which buttons? :p) and scrolling wouldn't allow you to view the whole image at a time easily.

[ilkke]

It'd have to have zoom, to be of any real use. (btw the pic in preview is 9x9 ). Not all levels of zoom would be practical for work, tho.

If I uderstand correctly, we have 0-9, #, *, plus softkeys (OK and CANCEL) plus C. That's like 15 buttons. I'd use a pair (like softkeys or # and *).
Even if we don't/can't use all those buttons, there are ways to implement it in a usable manner. Let's say you press 0 for menu, and then you have 9 more functions readily available in a 3x3 grid. Two can be zoom in and out, the rest can be for those marker functions or draw/fill etc.

As for the canvas limit, we could go for 320x240 (or 240x320)  or something. 16 colors also sounds ok, tho I guess 32 is nice as well.
These limits should not be cast in stone, because it's very hard to tell in advance what would be practical. Also I guess phone memory can have an impact as well.

[Meko]

Hi there, I'm interested in undertaking this project. I'm writing a mobile web browser (Meko web browser), not sure if you've heard of it, but I think this would be an excellent side project. I'll make a Java mobile demo, it should be finished in a few days.
Contact me at jan.ramon.martin(at)gmail.com if you wanted to discuss it.

[Gil]

I've got some lists of application states and proposed control changes lying around, shall I post them Meko? I'll go dig them up, been a bit busy lately.

[Meko]

Sounds like a plan, I'll post the jar+jad links in a few hours.

Alright, it's not much, but it should scale to any size pretty well: http://www.tinychan.org/pixla/

[Gil]

First off: great progress so far. The only thing I didn't like is that if you keep pressing a directional button, the cursor keeps moving rapidly, making it jump two squares at once sometimes when you press the key for slightly too long (this was in an emulator, going to try it on a phone later)

Here's the notes I made so far ([J] is four directional joystick):

Application states:
- Draw mode
- Palette mode
- Menu mode?

Draw mode
Tool states:
- 3 step marker, 1 step marker (marker state, as explained by Ilkke)
- pencil tool, fill tool (1 pixel selector, set to flood fill or fill-one-pixel, selector state)

Marker state:
1-9: place pixel on marker position in selected color
[J]: move marker in either 3 or 1 steps
0: Turn color selection on: choose palette row with 9, select color on row with (1->8)

Selector State:
1-8: place color with index of (1->8) on selected palette row on position of brush (or flood fill)
9: change palette row
[J]: move brush
0: switch between flood and pencil mode

Palette mode:

A screen for changing the palette (RGB, HSV, color wheel, that kind of stuff). Haven't got further info for that yet.


Extra notes:
- In terms of abstraction, color selection in selector state is the same as color selection in draw mode after pushing the "0" key
- I moved the keys around a bit, so now the left/right/OK buttons and stuff are free to use for other purposes. I propose that the OK button shows the menu and that the left button shows the palette mode. Right button could switch between draw and selector state, but the # key might be better for that



Is that helpful? It's a little more structured and thorough in terms of preparing to program it.

[Meko]

Heh, the limitations of mobile phones become very apparent when you start working on these kinds of applications. I've released an update, mostly compatibility. I'm also working on touch screen usability, should release the next build tommorow.

[ptoing]

Btw, just wanted to let you guys know that ilkke is on holiday atm, but he will be back in a bit less than 2 weeks. I am sure he will be very happy

[ilkke]

Heh, the limitations of mobile phones become very apparent when you start working on these kinds of applications. I've released an update, mostly compatibility. I'm also working on touch screen usability, should release the next build tommorow.

Hello Meko.

Great to see more people are intereswted in the project.
From the screenies on your site I see that you have not understood the editing method intended for the program. You move the 3x3 rectangle on the grid with your joystick, and use digits 1-9 to put a pixel on the respective place in the rectangle. This speeds up the process drastically.
I can write more detailed specs if you are interested.

[ilkke]

This is all very exciting 

While I was in Egypt another person took up the idea and made a prototype. I corresponded with him via email but I was unaware of the events taking place on this thread.

It's still a very early prototype, but we've already realized that some of the controls need changing. I will post the new ideas here for public scruptiny, as soon as I get home from work. Also I will give Meko's prototype a whirl.
Gil, do you have a WIP to show?

It seems kinda funny that the program now has 3 branches, but I think it can only facilitate getting the controls right, since many things have to be tested out.

Does anyone have an idea of what would be the best way to get the images from the phone? Ideally they'd be saved into phone's system folders and then you could bluetooth them or whatever, but I understand access to these folders is actually not an option.

[Gil]

I ran into the same input problems probably, so you'll see that the documentation a few posts above has a different layout. I stopped the programming, because I saw Meko was doing something, but he kinda dissapeared. I'll restart the programming if you want, or I could help the work on the prototype your friend is doing. Both are fine by me.

I was also wondering about the file saving/loading, but it should be possible, as I run several apps on my phone that allow me to save/load. I don't know if they are MIDP, so I'll have to look into that. As far as prototyping goes, I also have some stuff made that would allow animation in a very basic crude way. I didn't post these yet though, since this would be an extra to add if the thing works.

[Gil]

illke, I found out that JSR-75 has the proper specifications for device file loading. You can relay that to the other programmer if you want.

[ilkke]

Thanks a lot! I will.

[a3um]

Hi guys!

I'm the mysterious 3rd programmer on pixla and I have a question to other programmers. How do you think, how to export images from application on devices which doesn't support JSR 75?

Btw, minimal screen res should be 128x128 otherwise I can't use it ):

Cheers!

[Gil]

As far as I know, the options with phones without JSR 75 support are extremely limited. The only other option might be sending through bluetooth to a PC or another JSR 75 compliant phone.

Basically, if the phone doesn't support it, don't supply file saving/loading (which makes the tool a bit useless, but still fun to work in?)

[a3um]

There're still phones without BT

We can [save/load] image data [to/from] record store. In this case we have access to images only from midlet and we can't set image as wallpaper or send it to someone but still we can work on it

I was thinking on extracting record store files from the phone and converting them to png. It works on my old Nokia 5140 which doesn't have BT or JSR 75 support