Things are starting to happen

Now loading/saving is working reasonably, and animation has started coming around. Up next is color manipulation and then graphical widgets, instead of just text and rectangles. And guess how I'm going to draw them. Yep, with pixelate, what else :)

Plan

Right now pixelate is in a discomforting phase; there are lots of 'loose-ends' and lots of drastical changes stands in line:

• The first version presupposed a single workarea, not multiple as is needed for the animation
• The first version supposed a load-via-command-line, save-on-exit procedure for handling files - to simplify away the need for load&save dialogs. The latter is obviously not a problem any more, so I've decided to obsolete that kind of usage pattern and use the more traditional and flexible load&save dialogs (but probably without a fancy point-and-click-through-catalog-tree interface -- it'll be a single-line-input interface..)
  
• The first version's tools are a bit buggy and unwieldy right now. Eg. they don't shift the beforementioned pixel-beneath-cursor color upon user clicks on the palette

What I need is a plan for progression, hence this blog post. Here it is:

1. Enable loading and saving. First make sure the Sprite to/from SDL_Surface functions are working correctly, and their companions read/writePalette. These functions could be placed in a SpriteSDL module. Then integrate these functions with pixelate's work structure
2. Enable color manipulation via slides. Make sure all pixels onscreen affected gets updated: palette, work area, pixel-beneath-cursor.. Also make sure the load/save functions reflect the changes.
3. Enable multiple work areas: animation. The immigration could be done in steps: first add a button that copies the current image and inserts a new frame last with same content. Saving/loading should reflect this change. Then enable PageUp/Down to shift current frame - a static text widget to show the current / total number of frames would be approprite.

That'll have to be enough for now.

pixelate screenshot!

I've begun implementing the interface of pixelate, using the design idea presented earlier. As long as I keep the "contract" of no overlapping widgets, everything works out fine. Though I've found it somewhat limiting not beeing able to overlap widgets (after all windows do overlap each other quite often), so in a future design I would try to make the system a bit more general, but it will do for pixelate at this time.

Here is a screenshot of pixelate in action so far:

Notice the flashy semi-transparent message box at the top of the screen :)

/Olof

Simplicity is king

After having done some more thought on the GUI subject, I've come up with a minimalistic design for the GUI system. I asked myself the following question: "What is the simplest possible design for a GUI system that

1. Given a coordinate (x,y) returns the widget on that window location
2. Given a rectangle, draws the widgets intersecting it"

.. and of course both operations should be fast, at least faster than O(n) in the number of widgets. (of course impossible for 2. given the whole window but that is hopefully not the case in many more instances than program boot).

I choose the following two basic classes:

Code snippet

The key idea I got was that any event handling could be completely managed by the application developer -- no handleMouseDown etc. etc. here! Since this is also very application specific, it feels nice to remove it from this somewhat more general code.

Til next time,

/Olof

GUI solution found..

.. I'll create my own.

After having done some SDL-libraries research, I've taken the decision to create my own, simple GUI for pixelate. The most tasty GUI of the things I looked at was a thing called Guichan, which seems like the thing I would want but I've found I'm too lazy to read online documentation. Instead, I'll create a minimalistic GUI system featuring only mouse interaction. I'm hoping to come up with code in the style

GUI gui;
gui.addWidget(new WColor(i,r[i],g[i],b[i]), 50, 50, 10, 10);
gui.addWidget(new WMyQuitButton(), 100, 100, 10, 10);
gui.draw();
...
while(pop_event(&e)) {
switch(e->type) {
case EVENT_MOUSEDOWN:
if(!gui.handleMouseDown(e->x, e->y)) {
// do other handling if GUI doesn't..
}
case EVENT_MOUSEUP:
...
case EVENT_MOUSEMOTION:
(and mouse down => mousedrag)
...
}
}
...
gui.markForRedraw(r); // mark the widgets in this
// rectangle - tell the gui that they need to be redrawn
gui.redraw(); // draw anything that wants to be redrawn
// the gui keeps track of which widgets wants to be
// redrawn, in the form of a bool per widget (bool
// needsRedraw) for example if a button wants to
// change appearance
...
gui.hide(ptrWidget); // does NOT clear draw surface beneath
gui.show(ptrWidget); // only a bool per Widget; does not
// change 'find'-tree-structure

class WMyQuitButton : public Widget {
void handleMouseDown(int localX, intlocalY);
void handleMouseDrag(int localX, int localY);
void handleMouseUp(int localX, int localY);
void draw(int xmin,ymin,xmax,ymax); // inclusive
// a widget might
};


That's hopefully, I'll see where it ends. After this GUI system is up and running, maybe I can continue the actual pixelate project.

Something I've tried to avoid

I simply must face it: I need widgets to proceed in the pixelate development. The palette needs sliders, the file management needs it's dialogs, and maybe those tools need their buttons. So right now I'm in search for a GUI toolkit for SDL that doesn't take too much control over the application - ideally I still keep everything and it only has features for drawing itself and responding to events as I please.

pixelate

pixelate is all about having the tools I need to draw the graphics I need; I've grown quite tired of learning new advanced tool-sets and interfaces (read PhotoShot and others) and also I want the power to customize exactly the information I need in a pixel art creation program, eg. hot spots.
I'm strongly influenced by the legendary DPaintIV painting program for the 80's Amiga computer.
Features:

• Fullscreen editing in the resolution of the target game
• 8-bit palletized images
• BMP (and maybe PNG) importing
• Hot spots
• File format supports animated sprites with preview
• Zooming
• Current editing color shows not only in the palette, but also beneath the mouse cursor, ON the edited image which is great for pixel-editing! I can't image why "professional" programs like PhotoShop and PaintShopPro lack this hard-to-live-without simple feature
• Any dimension images, different for each animation frame
• Stencil editing
• Airbrushes a la DPaintIV
• All the basic geometric tools: lines, rectangles, ellipsis (filled and nonfilled)
• Undo/redo at least one tool-editing step
  
• Grab and move the surface w/ right mouse button
• Control key select the color beneath mouse cursor as current color
• Palette with "linear shading": create shaded series of colors easily

Right now, about half of the above features has been implemented. What is lacking is:

• Hotspots
• Animations
• Airbrushes
• Palette
• Stencil
• File format
• BMP import

I'm working on the file format for the moment. After that, the palette is probably the first thing I do.

Chatproject

The basic idea is having a more fun-to-use chat/filesharing program than ICQ and the likes. Right now I'm thinking of something featuring this:

• OpenGL rendered window
• World consisting of some kind of walkable environment: block-based or more general I've not decided yet
• Symbolic objects in world represent files which are shared
• Chatting via either global chat-console a la Unreal Tournament or as placards above players heads
• Players may modify world and their own visual appearance
  

Ongoing projects

Right now I'm basically working on the following programming projects:

• pixelate: a 2d-platform game developers sprite drawing/animation program
• chatproject: a 3d-chat/file sharing program
• K.F.K.: Kung Fu Kitsch, a 2d-platform arcade/action kick-ass game featuring Zombies
  

I will keep posting progress here at this blog.