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.
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!
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.
Recently I have been attempting to learn the maths required for 3D graphics, and am currently learning matrices. As a way of testing my knowledge, I wrote a quick pygame program which transforms a funky collection of lines with a matrix. It's only two-dimensional at the moment, but the same principles demonstrated here apply in 3D as well. The only difficulty is projecting 3D points onto the camera (which apparently requires a 4*4 matrix, to include translation as well). So, before my incessant ramblings completely vanquish your interest, here's a screenie of the aforementioned program:
The matrix is displayed in the bottom-right corner. Thanks go to James for coding the nifty grid-drawing section (I only had two grey axes to begin with!).
You may have noticed a cycle of sorts developing here recently. Like a sunny day in Scotland, or perhaps like the Blue Screen of Death (depends on your point of view), I have once again returned from out of nowhere.
But this time, I'm not going to optimistically promise to increase the frequency of my postings - funky though a stuck record may be, I'd prefer not to sound like one myself and so I'm going to inform you that the posting frequency here will vary inversely with the amount of other shizzle I have to do.
And at the moment, that formula would produce a value so close to zero that any self-respecting calculator would simply round it down and save you the hassle of counting decimal places, so being self-respecting (and possessing a calculator - I suppose that counts) I'm going to admit that I won't be updating here until the New Year. Perhaps then, when compulsory festive activities are finished and I still have some holiday time remaining, updates might come more often. Who knows? But for now, I'll leave you with the compulsory Christmas greeting:
