ExeSketch demo 1 from Animatinator on Vimeo.
More (proper) updates to follow soon...
Tuesday, 18 August 2009
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:
More (proper) updates to follow soon...
More (proper) updates to follow soon...
Sunday, 16 August 2009
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.
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.
Saturday, 15 August 2009
Reworking the spaghetti
Bear with me as I affectedly ignore the fact that two posts on consecutive days constitutes a supernal feat not reached by this blog in almost a year.
Today's coding progress mainly comprises alterations to the ObjectManager class, which is responsible for holding a group of objects and sending them redraw commands and events, and returning to its parent such information as whether or not the mouse is hovering over one of its subordinate objects. As is by now ExeSoft tradition, bugfixes and feature modifications had by this afternoon driven the former beauty of the HandleEvent() function deep into the seething droves of, ahem, faecal matter, which are to be found in the realms of spaghetti-like entanglement and fractallic code-nesting.
And so, driven by the view that CurveDraw's sequel shouldn't face hereditary messiness, I spent some time re-working the code in an attempt to make it legible. And a success it was, for to my eyes at least the code now seems a lot less mucky. It's still verging on a hundred lines for the one function, but that should change as I break some of its tasks up into sub-functions (and perhaps further simplify what it's doing).
However, it's not all invisible behind-the-semi-functional-scenes stuff in this instalment; I also added a new feature. Behold the glorious power of object re-ordering:
This solves an irritating problem frequently encountered when multiple filled shapes conglomerate in an image: now, you needn't bother carefully regulating the order in which you add objects to the scene so as to keep the background at the back, because with a single tap/hammer/rocket-propelled incineration of the arrow keys you can deftly alter the ordering of any objects in the drawing. This is done with a bit of fiddly pointer-juggling - you can see this part of the code here.
For now, I depart, leaving only the (by now dubious) promise of another post in the near future. Although many will be inclined to incredulity, I assure you that unless major difficulties are encountered, this blog should now continue as it once did (before the recurring failures to update). If I don't post again within a week or so, do feel free to provide a text-based kick via the comments section.
As before, the source code for the entire project is available at exesoft.awardspace.co.uk.
Today's coding progress mainly comprises alterations to the ObjectManager class, which is responsible for holding a group of objects and sending them redraw commands and events, and returning to its parent such information as whether or not the mouse is hovering over one of its subordinate objects. As is by now ExeSoft tradition, bugfixes and feature modifications had by this afternoon driven the former beauty of the HandleEvent() function deep into the seething droves of, ahem, faecal matter, which are to be found in the realms of spaghetti-like entanglement and fractallic code-nesting.
And so, driven by the view that CurveDraw's sequel shouldn't face hereditary messiness, I spent some time re-working the code in an attempt to make it legible. And a success it was, for to my eyes at least the code now seems a lot less mucky. It's still verging on a hundred lines for the one function, but that should change as I break some of its tasks up into sub-functions (and perhaps further simplify what it's doing).
However, it's not all invisible behind-the-semi-functional-scenes stuff in this instalment; I also added a new feature. Behold the glorious power of object re-ordering:
This solves an irritating problem frequently encountered when multiple filled shapes conglomerate in an image: now, you needn't bother carefully regulating the order in which you add objects to the scene so as to keep the background at the back, because with a single tap/hammer/rocket-propelled incineration of the arrow keys you can deftly alter the ordering of any objects in the drawing. This is done with a bit of fiddly pointer-juggling - you can see this part of the code here.
For now, I depart, leaving only the (by now dubious) promise of another post in the near future. Although many will be inclined to incredulity, I assure you that unless major difficulties are encountered, this blog should now continue as it once did (before the recurring failures to update). If I don't post again within a week or so, do feel free to provide a text-based kick via the comments section.
As before, the source code for the entire project is available at exesoft.awardspace.co.uk.
Friday, 14 August 2009
ExeSketch (and yes, I'm still alive)
In an intermission to the vapid vacuousness of a presumably perpetual hiatus, I write this posting to once again acknowledge my own failure to maintain any sort of consistency in update frequency, and simultaneously to reveal to you a new project which serves as a sort of culmination of the long period I have spent attempting to gain some basic understanding of the syntactical intricacies and idiosyncrasies of C++ (which I hitherto had only the most rudimentary of aptitudes at). This, I may add, has proved rather successful, as that language, which was once as alien to me as this slightly ridiculous writing style I've chosen to adopt today may seem to any sane person, now seems as natural as the aforementioned ludicrously lavish lexicon usage (which I must at this point apologise for) does to myself at this particular moment.
So, with one hundred and forty-one words wasted on wanton waffling, and this post's 'ramblings' tag quite successfully earned, the time has come for me to take the next logical step in post-writing and endow upon you, the reader, the purpose of the bandwidth this page consumes.
The process of ExeSketch's development began quite some time ago, at my discovery of Beziér curves. The Wikipedia page linked to by the end of the last sentence provides the best explanation I've yet read of how they work, and armed with the provided understanding I set about implementing them in Python, using Pygame (naturally). The result can be found here.
From there, I took the concept further and developed a small drawing application, CurveDraw. It used discrete Bézier curve
objects, each of which was made up of a series of joined curves, which could be used to build up drawings. The program grew to incorporate linear transformations such as rotation, and it came to the point where the code represented a toy car modified to transport cities of people to the Moon - in essence, a mess of awkward modifications and additions. So, at the point where someone suggested adding different types of shapes, a concept unthinkable with the program's existing code base, I decided that the program would have to be coded anew with a full drawing program as the intention from the outset.
Such a program would fail to take shape for some time, and in the intermittent weeks I set about learning how to *properly* code in C++ (split infinitives included at no extra charge). I commenced to swiftly seek out tutorials, which I went on to carefully follow until the time came when I was to gradually procure an appreciation for the language whose documentation I was to systematically peruse.
So
, that done, I went on to learn OpenGL - a graphics library which turned out to be much simpler to use than I had previously anticipated. Within a relatively small period of time I had managed to create an only semi-glitchy camera lookaround demo, with various cubes spinning around in the sky (about their own individual axes, after a bit of fiddling!). And after deciding that I probably lacked the mathematical calibre needed to make a full 3D game engine with cutting-edge graphics and high-tech shaders, I thought I might as well have a go at 2d for a bit.
Which led me to ExeSketch. It seemed as good a time as any to write the fatalistic sequel to CurveDraw, and as good a way as any to test whether I actually knew enough C++
to do it properly. This particular project involved a large amount of planning (well, in comparison to the thirty-seconds-ish I've put into other coding projects in the past), and some of the largest compiler error outputs I've ever seen (I tried to compile it all before I had written the Vector2d class which I had promised the compiler, and it spent a good five minutes vomiting forth garbled attempts at explaining what was wrong). However, after a few weeks of coding I've finally managed to get a basic version of the program running.
The program works in two modes: Object View, and Editing (as inspired by Blender 3D, a program which provided ideas for much of the user int
erface of CurveDraw). In object view, one can select objects and drag them around, (ultimately) add/delete objects, and possibly apply linear transformations (that's still waiting on implementation). In edit mode, you can drag the points which form whatever object you're editing - currently the only object implemented is a Rect, which has four corner points which can be dragged to resize it (you can also press F to toggle whether or not the rectangle is filled). Panning and zooming are done with the mouse: click-and-drag and middle-click-and-push-in-or-pull-out, respectively.
The current source code is available from exesoft.awardspace.co.uk, and requires OpenGL and GLUT to compile. According to a line-counter script I wrote, it's 1136 lines so far, which I believe is an ExeSoft record (fair enough, given that I've mainly used Python up until this point). More updates are to come (if all goes well), and I might post an explanation of how ExeSketch works in the near future; for now, however, I must take my leave. Ta-ra!
So, with one hundred and forty-one words wasted on wanton waffling, and this post's 'ramblings' tag quite successfully earned, the time has come for me to take the next logical step in post-writing and endow upon you, the reader, the purpose of the bandwidth this page consumes.
The process of ExeSketch's development began quite some time ago, at my discovery of Beziér curves. The Wikipedia page linked to by the end of the last sentence provides the best explanation I've yet read of how they work, and armed with the provided understanding I set about implementing them in Python, using Pygame (naturally). The result can be found here.
From there, I took the concept further and developed a small drawing application, CurveDraw. It used discrete Bézier curve
objects, each of which was made up of a series of joined curves, which could be used to build up drawings. The program grew to incorporate linear transformations such as rotation, and it came to the point where the code represented a toy car modified to transport cities of people to the Moon - in essence, a mess of awkward modifications and additions. So, at the point where someone suggested adding different types of shapes, a concept unthinkable with the program's existing code base, I decided that the program would have to be coded anew with a full drawing program as the intention from the outset.Such a program would fail to take shape for some time, and in the intermittent weeks I set about learning how to *properly* code in C++ (split infinitives included at no extra charge). I commenced to swiftly seek out tutorials, which I went on to carefully follow until the time came when I was to gradually procure an appreciation for the language whose documentation I was to systematically peruse.
So
, that done, I went on to learn OpenGL - a graphics library which turned out to be much simpler to use than I had previously anticipated. Within a relatively small period of time I had managed to create an only semi-glitchy camera lookaround demo, with various cubes spinning around in the sky (about their own individual axes, after a bit of fiddling!). And after deciding that I probably lacked the mathematical calibre needed to make a full 3D game engine with cutting-edge graphics and high-tech shaders, I thought I might as well have a go at 2d for a bit.Which led me to ExeSketch. It seemed as good a time as any to write the fatalistic sequel to CurveDraw, and as good a way as any to test whether I actually knew enough C++
to do it properly. This particular project involved a large amount of planning (well, in comparison to the thirty-seconds-ish I've put into other coding projects in the past), and some of the largest compiler error outputs I've ever seen (I tried to compile it all before I had written the Vector2d class which I had promised the compiler, and it spent a good five minutes vomiting forth garbled attempts at explaining what was wrong). However, after a few weeks of coding I've finally managed to get a basic version of the program running.The program works in two modes: Object View, and Editing (as inspired by Blender 3D, a program which provided ideas for much of the user int
erface of CurveDraw). In object view, one can select objects and drag them around, (ultimately) add/delete objects, and possibly apply linear transformations (that's still waiting on implementation). In edit mode, you can drag the points which form whatever object you're editing - currently the only object implemented is a Rect, which has four corner points which can be dragged to resize it (you can also press F to toggle whether or not the rectangle is filled). Panning and zooming are done with the mouse: click-and-drag and middle-click-and-push-in-or-pull-out, respectively.
The current source code is available from exesoft.awardspace.co.uk, and requires OpenGL and GLUT to compile. According to a line-counter script I wrote, it's 1136 lines so far, which I believe is an ExeSoft record (fair enough, given that I've mainly used Python up until this point). More updates are to come (if all goes well), and I might post an explanation of how ExeSketch works in the near future; for now, however, I must take my leave. Ta-ra!
Wednesday, 7 January 2009
The Final (Dimensional) Frontier
Today, I set foot where no Exesoft member has gone before, to a dimension so complex that few dare even to speak its name. Indeed, it has been rumoured that if you were to enter its abstruse domain, you would surely be smashed apart by the mass of gigantic matrices.
Of course, it is impossible for us mere mortals to ascertain whether or not it would pan out that way, but one thing is certain: to think of it is to lose one's sanity.
Yes, the dimension of which I speak is none other than THE THIRD DIMENSION.
Consider yourself forewarned, as the image which you are about to behold will almost certainly strike cold terror into your very soul, drive madness into your being and enshroud your sleep in a dusky cloak of raw horror. This is no time for feigned bravery. No amount of courage nor strength of will could possibly prepare you for the nightmarish sights you will see in... that place.
All hope abandon, ye who enter here.
Perhaps I was excessively grandiloquent. But still, it's a feat which I once didn't think I would accomplish. The cube you see is animated - it spins about its x and z axes, under the command of a 3*3 matrix. What I intend to add to it now is a means of also translating the cube (4*4 matrices, to be precise), so that multiple cubes can be spinning around all over the screen (each spinning around its own axes instead of the global ones, as happens now). Also, it needs to be modified so that the camera can be moved - I'm still not sure how to project the vertices onto an arbitrary camera plane. But that's for the future.
I apologise for any mental scarring you may have incurred whilst looking at the image. You were warned.
Of course, it is impossible for us mere mortals to ascertain whether or not it would pan out that way, but one thing is certain: to think of it is to lose one's sanity.
Yes, the dimension of which I speak is none other than THE THIRD DIMENSION.
Consider yourself forewarned, as the image which you are about to behold will almost certainly strike cold terror into your very soul, drive madness into your being and enshroud your sleep in a dusky cloak of raw horror. This is no time for feigned bravery. No amount of courage nor strength of will could possibly prepare you for the nightmarish sights you will see in... that place.
All hope abandon, ye who enter here.
Perhaps I was excessively grandiloquent. But still, it's a feat which I once didn't think I would accomplish. The cube you see is animated - it spins about its x and z axes, under the command of a 3*3 matrix. What I intend to add to it now is a means of also translating the cube (4*4 matrices, to be precise), so that multiple cubes can be spinning around all over the screen (each spinning around its own axes instead of the global ones, as happens now). Also, it needs to be modified so that the camera can be moved - I'm still not sure how to project the vertices onto an arbitrary camera plane. But that's for the future.
I apologise for any mental scarring you may have incurred whilst looking at the image. You were warned.
Subscribe to:
Posts (Atom)