Reflection

I've been busy doing my thesis work the last few months.

I'll try to do some kind of sum-up of lessons learnt;

• for-loops are precious things. One of the worst kind of bugs are buffer overruns. This is since they corrupt the real time code of the program, or data structures, causing seemingly random crashes, at locations often different from where the bug actually is, also rendering debugging features of the development environment useless. The primary cause for buffer overruns are off-by-one errors, in for-loops. That's why beeing extra careful when writing the loop control code pays back bigtime. Mindstate: Which is the easiest way to express this loop? What is the natural index variable? Is it more natural with a count of loop iterations, or a start- and endvalue? A pen and paper sketch of the "structure" of the loop is probably a good idea, sadly that's not a very common situation for me.
• Debug mode is evil. See earlier post "A lesson learned the hard way". To use assert even in release mode development, redefine the assert macro using __FILE__, __LINE__ and exit() (won't display the expression at bail, but this is visible given the file/line of the assert..)
  

New horizon

After taking some inspiration from the wonderful pixelart drawing program GraFX2 and having come to terms with the lackings of the drawing tools of pixelate, I've decided to develop my own graphics primives, in the following manner:

• There will be two fundamental types of primitives, 1D and 2D I call them for technical reasons
• 1D are for eg. the line, pencil, outlined rectangle and outlined ellipsis tools
• 2D are filled rectangle & filled ellipsis

On the technical side, 1D tools will be completely independent of the specific surface type and such - they will only output a sequence of absolute coordinates given a set of parameters, specific for each 1D tool, ie. they are "purely" geometric. That way, I can save the underlying pixels in the caller - instead of as pixelate does it right now, save the whole underlying surface (slow!). Then, when the user releases the mouse button, the actual "pixel" he is using for the moment - be it a 1x1 color pixel or 5x5 rectangle, or even an air brush, is drawn at every coordinate given from the tool.

On the other hand, 2D tools will use 1x1 pixel outlines while the user is dragging, and fill it in upon release, a la GraFX2.

As I've been thinking about software engineer -- experiencing the last weeks' "brownout" -- I've formulated a little mantra to follow:

• Software systems could be viewed as directed graphs (digraphs) with an arrow from one software "component" A to another B, if A depends on B
• In pixelate, the graph would at the moment not be acycling ie. it would not be a tree structure, because of interdependence, edges, all over the place
• Mantra: any software components complexity or engineering weight is proportional to the number of edges leaving it (the number of dependencies it has). Cycles in the system graph are evil. (Some voice in the back of my head tells me a system with a tree graph is called cybernetic..?)
  

/Olof

A lesson learned the hard way

I'm currently working on two major projects; my computer science thesis work within image analysis, and pixelate. In both projects, I've done development in MSVC's debug mode. This week I switched to Release mode in both projects -- and they've both bailed out with no information of where/when/how -- since obviously it's not a debug run anymore. This led me to do printf("1\n"), 2, 3, recompile, run, repeat procedure to find where the programs died. A very tiresome and frustrating way to spend your time. The lessons learned are these rules-of-thumb:

• Never develop anything in debug mode for any longer period, especielly not from grounds-up. Debug-mode can be used for tracking down problems found when running the release version, whenever the need arises.
• Bugs are better found early than late - assert is an economic test-driven way of programming - and testing is the way to convince yourself of the correctness of a program. If you've done your deal of programming you realize this. I did not enjoy going through 1.000 lines of code looking for the bugs - better take 10 lines at a time which early testing/unit testing achieves when used throughout development.
  

So long,

/Olof

Update

• Graphical widgets for the tools
• Show/hide toolkit and palette
• ToolTip information line at top of screen

Right now these things are being considered:

• Color shades
• Hot spots
• Variable sized pencils/lines
• Air brushes

Some habits to get used to

1. Add a '// TODO: blah blah' comment everywhere there's something I'm not putting attention to for the moment
2. Use assert() on input parameters to functions
3. Use constructors/destructors for any class/struct with a allocation/deallocation pattern!

New screenshot!

There are three new things, two of which are visible.

1. First off, you can see a preview-area upright. This is very useful when editing a sprite close-up, and wanting to see the result immediately instead of the tiresome zoom-in/zoom-out procedure.
2. There is a small left-pointing arrow just above the palette, it's used to hide the palette (or show it again - then pointing right). This is the first graphical widget. Earlier, only rectangles and text widgets have been seen! (yes, they're graphical too, but you catch my meaning)
3. The color slides are working, even if the mouse pointer leaves a slider's rectangle.

That last improvement took some time to engineer, due to the design of the gui-system.

Coming up:

• Toolbar with all-graphical widgets and the now have-to-have show/hide button
  
• ToolTips text line, probably at top line of screen, used as an online help system (but cannot replace current help since it's only displaying messages for widgets, and not all actions of pixelate are due to widget interaction of the user, eg. ESC quits pixelate. Maybe try to add buttons for every action possible..?)
• Color shading as mention below
  

Next step

The previous plan is complete: color manipulation is there via slides, loading&saving is working and animation has begun (screenshots coming tonight..). The next steps include

• Palette shading. Creating "linear shades" from one color to another using a sequence of the palette. Interface: user clicks "shade tool" then the palette color to shade to, and pixelate creates a shade from the current color to the clicked one.
• Preview-widget. When zoomed, you want to see the 1-to-1 version of the area you're editing simultaneously. Problems include: what to do when editing a large image?
• Icons. The tools need their icons, and they're coming up. Also show/hide icons for the different widget-sets (palette / toolset / load-save.. ).

That's short term progress, read this week. The next major step is the stencil. This needs some afterthought to make realtime, so I'm congesting the idea for the moment. Another major step is to create my own low-level graphics drawing tool implementations, line, rectangle, ellipsis etc. Why? Well for one thing the one's I'm using are less than bugfree. At least some of them don't clip making pixelate die hard sometimes, and also the ellipsis function doesn't draw in the rightmost column of a surface, which kinda sucks. Moreover, if I ever want to enable user-sized pencils or airbrushes, this is the way to go.