In equal scale weighing delight and dole

Which would you like first: the good news or the bad news?

Well, I'm afraid you're bound by my ordering. I'm not psychic, you know.

Every post needs to open with some kind of positivity (it's an unwritten blogging axiom (probably)), so to begin with, I'd like to point out that you can now delete objects in ExeSketch. The code is far from beautiful, but it works, and that's all that really matters - certainly when there's only one person working on the code. If you'd like to gaze upon its awesomosity, you can check it out at the Launchpad page (changes since the last version of the code are highlighted). As well as this, I modified main.cpp to handle F-key events and things like page up and home. The code can be seen on the same page (scroll up!).

Now, on the more ill-inclined surface of this two-sided post, a rather problematic bug has sprung up. When the window is maximised, the display is immediately stretched and mouse clicks no longer hit the parts of the screen they should. Restoring does not solve the problem; indeed, it makes it worse, as the display then shrinks and the mouse clicks hit targets even further from those aimed at. The problem is illustrated in the image to the right (click to view it full-size).

The bug report can be found here. I'll update that page with any progress I make, but at the moment the problem is looking close to unsolvable, unfortunately (unlike a similar problem with minimising which was fixed with one line of code). I'll see what I can do though.

And on that negative note, I end. That's the difficulty with two-sided coins: you either start badly (breaking the ExeSoft Blogging Law) or end badly. And in this case, I choose the latter. However, all is not lost: click here to regain your former joy!

ExeSketch: Now on Launchpad!

As of today, ExeSketch now has a Launchpad project page for hosting its code and managing updates and changes - you can find it at launchpad.net/exesketch. Thanks go to James for setting it up, and providing assistance for those of us who don't have a clue about how to use that sort of thing (i.e. myself).

From now, the Launchpad page will be used to store the source code, as well as to manage bugs ("Bugs" tab) and intended features ("Blueprints" tab). Meanwhile, this blog will continue to be the place to go to for development news, updates and the occasional ramble (inevitable, I'm afraid).

And, shockingly, that's all there is to say on the matter. I suppose this must be some sort of milestone, being as it is the shortest post in rather a long time, so to celebrate, here's a LOLcat:


Happy short-post day!


EDIT: It turns out that this being a short post isn't the only thing worth celebrating - at some point whilst my back was turned, the hit counter over in the right-hand column of the page surpassed 4000! Perhaps a worthwhile blog somewhere has an easily-misspelt url like "exefost" or something...

ExeSketch Explanation: The Display

Welcome to the second instalment in The ExeSoft ExeSketch Explanation Series of Presently Undefined Length. This particular informational outpouring concerns the item of code positioned directly adjacent to the EventHandler in the chronological stream of linear storytelling. That is to say, it was the next thing I wrote. (I'm endeavouring to eschew bombastic grandiloquence. Aagh, dammit.)

This is another class whose inspiration stems from difficulties I faced implementing requested features into CurveDraw's code. The problem with CurveDraw was that the view was completely static - if something went off-screen unintentionally, it was effectively lost. The edges of the screen served as that point in a sofa where the seat-cushions meet the back-cushions, except in CurveDraw there was a bottomless pit underneath, and the cushions were sewn on meaning that any attempt at catching something was rendered impossible. And the sofa was made of spikes. Probably. Similarly, editing a curve of more than moderate intricacy would be a case of pressing your face right against the screen, magnifying glass in hand, moving the mouse as accurately as possible with both hands so as not to drag the wrong point or make a mess of the curve handles. (EDIT: Yes, I know I just filled three hands. Get a friend to hold the magnifying glass or something.) The obvious void to be found in its existing feature set was one which might have been comfortably filled by zoom and pan features; unfortunately, to code such a thing was a concept standing quite without the realms of possibility.

The issue was that points in objects were stored as pixel co-ordinates instead of co-ordinates in arbitrary 2D space, and pan/zoom would involve adding appropriate variables to the code for offset and scale and then setting up transformation functions for each object's individual points and for object centres, all of which would amount to a lot of messy coding and awkward global variable usage.

These issues are resolved in ExeSketch by defining all points in arbitrary 2D space (referred to in ExeSketch as real co-ordinates), as suggested above. Each object has a centre point defined in real co-ordinates, and the object's points are defined relative to that centre point (in local co-ordinates). When it comes to drawing, a single redraw command is sent from the main program through to the display class, ObjectDisplay, which sets up an OpenGL transformation matrix using variables it stores for the camera offset and the zoom factor. It then simply sends a redraw call to each object registered with it, and Bob's your teapot.

Another advantage of having this class to handle the display camera is that zoom and pan can be handled by event handling functions within the class, thus clearing potential clutter from the main file. (That's the reason for the EventHandler having a reference to the display object, as mentioned in the previous post explaining the event system.)

And that, as far as I can tell, is pretty much all there is to know about the display. You may have noticed I'm not going into much detail about the code that makes this stuff happen in this series; it's simply an explanation of how the myriad classes interact and why. For those interested in the code itself, the project is of course open-source; ye who seek it shall be rewarded, should you incline your browsing hither. And once again, my (transient few) readers, I bid thee goodbye.

Quick ExeSketch demo video

As I haven't had much time for continuing the explanation of ExeSketch over the past two days (or, indeed, to code anything for it), I've done a quick video of what exists at the moment to fill the update-gap. It demonstrates the creation of a rather spiffing smiley face (with a fetching rectangle for a mouth to compensate for its lack of a nose) using the Rect primitive (because it's still the only one implemented...). Behold:

ExeSketch demo 1 from Animatinator on Vimeo.

More (proper) updates to follow soon...

ExeSketch Explanation - Events

Welcome to the first in a series of posts intended to explain the ExeSketch code I've written up to this point. As lining up the beginning of a retelling with the corresponding point in temporal space seems logical, I'll begin with the EventHandler and Event classes, which (odd though it may seem) were the first things I coded.

In truth, the event system in place wasn't made specifically for ExeSketch - initially it was just an idea I had for getting around GLUT's way of dealing with events. Having spent quite some time coding in PyGame, I've become accustomed to an event loop in which I first procure a list of all the new events with pygame.event.get(), then process them one by one, sending each one to the appropriate point in the code. In this way all the events are handled by one central function (normally just in the mainloop), which I find relatively simple to maintain. However, in GLUT, there is no user-defined mainloop - the code you write is entirely driven by GLUT events, and the way you get your code into the program's mainloop is by writing it into special functions and binding them to GLUT events.

This is actually fairly simple - to take the window repainting event as an example, you begin by writing a function RedrawScreen() (or whatever you choose to name it) and bind it to the GLUT call to redraw with glutDisplayFunc(RedrawScreen). And this works rather well for situations similar to the above. However, this system of stuffing code into designated orifices isn't particularly helpful for user events that need to be passed to several different objects, as for a fairly average application you would need to register glutMouseFunc, glutMotionFunc, glutPassiveMotionFunc, glutKeyboardFunc and glutSpecialFunc and then have every one send its events to all the appropriate objects with its own version of the event handling code. Each object would then have to have specific functions for each type of event, as each event has different arguments - mouse position, key, whether the buttom is going in or out - making event handling a process liable to wear your CTRL and C-keys out with the haste and enthusiasm of an industrial belt sander.

Being rather fond of the aforementioned keys (they really come in handy when you're writing an essay on something well-documented by Wikipedia...), I decided an alternative had to be found. And when, after much pondering, this alternative eventually came, it did so in the shape of the ExeSketch EventHandler class.

To put it simply, each registered glutFunkyFunc creates an object of type Event, which stores all the appropriate information for the event, and then passes that to a central EventHandler object. On a call to EventHandler::ProcessQueue(), any events that may have accumulated in the event handler's buffer are processed by the much-coveted single event-handling function, which does what it needs to the events before sending them off to all the objects registered with it.

However, as mentioned before, different events have different parameters supplied with them. To resolve the problems this would cause, I created an enumeration of all possible user events, which you can see here. Essentially it is written as a branched tree: At the root is EVENT, which splits into MOUSE and KEYBOARD. MOUSE then splits into UP (button up), DOWN (button down), and MOTION, with UP and DOWN splitting further into individual buttoms. KEYBOARD splits into all the possible key events, each preceded by K_. An item in this imaginary tree structure is translated into a variable name by joining its branches with underscores, for example EVENT_MOUSE_DOWN_LEFT (when the user left-clicks) or EVENT_KEYBOARD_K_S (when the 's' key is pressed). The enumeration simply defines these as numerical constants, and so they can be used to define an event type throughout the code. An Event object stores its event type as the appropriate integer, as well as two other integers: xpos and ypos. These are used to store the mouse position parameters for mouse functions, and when not needed are simply set to the integer constant NA.

Meanwhile, the EventHandler class stores a collection of these objects in an STL queue, chosen because it provides basic FIFO queue functionality and no more, which is all that is needed in this case (having nifty functions to swap/juggle/tightrope across individual items in the container would be slightly overkill). It holds a pointer to the ObjectDisplay class (to be explained in a later post) and an STL vector of pointers to ObjectManager objects (again, to be explained in a later post), to which it sends events. ObjectManagers are registered with it using a RegisterClient function which accepts the pointer to register.

The ObjectManager and ObjectDisplay objects which receive the events need only provide a HandleEvent function to deal with the Event objects the event handler sends them, as well as making themselves known with the event handler's RegisterClient function. From then on, control over user input is entirely given over to the EventHandler.

You'll have to excuse the boundless prolixity of this post, I didn't really intend for it to end up as long as this. It was alyways going to be the longest in the series anyway; the next ones should be shorter. If you stuck with it as far as here, congratulations! You have a God-like attention span. To the rest of you, I'd like to take this opportunity to recommend a nifty online utility I found a short while ago for reading long things incredibly quickly - Spreeder. Essentially you copy the text to read into the box, and it displays it word by word at several hundred words per minute (you can set the speed to whatever is readable). By this approach you avoid problems like being slowed down by line breaks, unintentionally casting your eyes backwards along a line and the dreaded subvocalisation, which means that you get through the text a lot faster whilst still retaining almost as much as you would normally.

It's useful for quickly digesting blog posts written by people who need to learn the art of brevity.