Just dropping in for the customary exchange of greetings. Except in this case is isn't really an exchange as such, being as it is a blog whose very nature dictates that all communication can only traverse the distance between our computers in one single direction (with that being from myself to you). Unless of course one takes into account the possibility that you, the user, make use of the post commenting function, in which case it could be argued that this does indeed constitute an exchange of greetings. That said, it is one which is rarely consummated - as can be seen from the sparsity of such reciprocations on this very website, precious few internet users are of the commenting persuasion and a page generally needs to have somewhere in the region of a hundred viewers in order to secure a comment. And that's assuming the page is even relevant to the interests of that particular set of users and capable of provoking the thought required to drive them to express views upon it. Sadly these are criteria which have almost certainly gone unmet by this particular work (what with it being a foolishly pedantic ramble), and so it is logically defensible to say that this post does not, in fact, count as an exchange of greetings in any but a few cases. Therefore my first sentence was erroneous. Sorry about that.
Merry Christmas!
Thursday, 24 December 2009
Friday, 11 December 2009
Cambridge raverviews!
So, here's how they went.
First up was the subject-specific interview. This one had moments of awesome and moments of shoddy, but was generally okay. Once again I was surprised by the complete lack of personal statement questions - they began by reading through the main points ("so you've done C++ and python, made a few programs...") and then indirectly asked why I wasn't taking computing. It was posed as something like "Most candidates are normally doing A-level computing, but you don't seem to have done it at all; where does the background in computer science come from?" Thankfully I was prepared for this, and explained that it was something that greatly interested me and which I had mostly learned for fun in my free time. To answer the implied question of why I had no formal computing education I said something vague about the Standard Grade course not being particularly relevant to a degree (which is true), which is what I'd always intended to do (which is mostly true, although I wasn't very certain of what I wanted to do back then - I decided against Standard Grade computing on the grounds that I was already learning it myself). And then they asked about what sort of projects I've done, so I rattled off a big old list of things I've been doing recently. Hopefully it wasn't too disjointed and rambly.
And then came the technical questions.
Firstly, they got me to work out what a piece of code did, which was simple enough but took me a little while as there were a few off-throwing loops. They didn't appear to be too bothered by that though, and I think bonus points were gained on the second part of this one as I worked it out relatively speedily. They then got me to devise an algorithm (I don't think I can say what for), which I luckily managed to do rather quickly - they seemed fairly pleased by this one. I then had a proof by induction, which got off to a terrible start when I mistook the technique they asked me to use for a direct proof. And it went downhill from there. The less said the better, really. Not one of my finest moments. Moving onwards, this was followed up by a question about a finite state machine diagram, and I get the impression that several bonus points were gained when I mentioned that I had seen one before (based on the rather surprised reaction by which this was received). They asked me to add bits to it in order to add extra functions, and there was a bit of to-and-fro-ing here as I made a few mistakes at the beginning and then went about the last part of the question in what was apparently not the intended way. They said it was still correct though, so hopefully the question wasn't too much of a failure.
And that was that. Not too bad really; it could have gone far worse. It was certainly better than the Imperial interview anyway, although I hear that Cambridge interviews are much more important that Imperial interviews when it comes to selecting candidates (Imperial do a lot more pre-interview selection, and so those with interviews are fairly likely to get offers).
This first interview was closely followed by the TSA, or Thinking Skills Assessment. A glorified IQ test really, but with slightly harder questions and a large number of questions that are to do with identifying underlying assumptions, flaws or main conclusions in arguments. The one I did at Cambridge was actually a lot harder than the online practice one, and I ended up using the full hour and a half. I did however answer all but four questions with certainty which varied between definite (for most), and moderate (for about a fifth of them). Not a clue what my results were, and indeed I'll never be told; it'll make a contribution to my application in consummate secrecy. Ominous.
So, tired and mentally worn out as I was, I trudged on to the last event of the day: the Natural Sciences interview. This has to be taken as well because the Computer Science Tripos at Cambridge involves a Natural Sciences portion for the first year (which is rather awesome actually). However, I was slightly worried at the prospect of an interview on the topic as I've done minimal revision for such a thing. And "Natural Sciences" is so ill-defined it could well bring in work I did and forgot in first-year Biology.
Thankfully, however, it was just Physics with a bit of Maths. And IT WAS GLORIOUS! Glorious and victorious. The questions were almost all easy, and I steamed through about seven or eight in the twenty-minute interview. I made a few mistakes, but in general I managed to answer every question with all the speed and accuracy of a well-guided cruise missile. Yes, that's a mild exaggeration. However I do feel rather positive about this last interview, and so it was a nice way to end the (long and arduous) day.
So then I was off, on the six-hour train journey back to here, where I found an offer from Imperial awaiting me. I'm still dancing on the ceiling about that one. And it's making it considerably difficult to type.
First up was the subject-specific interview. This one had moments of awesome and moments of shoddy, but was generally okay. Once again I was surprised by the complete lack of personal statement questions - they began by reading through the main points ("so you've done C++ and python, made a few programs...") and then indirectly asked why I wasn't taking computing. It was posed as something like "Most candidates are normally doing A-level computing, but you don't seem to have done it at all; where does the background in computer science come from?" Thankfully I was prepared for this, and explained that it was something that greatly interested me and which I had mostly learned for fun in my free time. To answer the implied question of why I had no formal computing education I said something vague about the Standard Grade course not being particularly relevant to a degree (which is true), which is what I'd always intended to do (which is mostly true, although I wasn't very certain of what I wanted to do back then - I decided against Standard Grade computing on the grounds that I was already learning it myself). And then they asked about what sort of projects I've done, so I rattled off a big old list of things I've been doing recently. Hopefully it wasn't too disjointed and rambly.
And then came the technical questions.
Firstly, they got me to work out what a piece of code did, which was simple enough but took me a little while as there were a few off-throwing loops. They didn't appear to be too bothered by that though, and I think bonus points were gained on the second part of this one as I worked it out relatively speedily. They then got me to devise an algorithm (I don't think I can say what for), which I luckily managed to do rather quickly - they seemed fairly pleased by this one. I then had a proof by induction, which got off to a terrible start when I mistook the technique they asked me to use for a direct proof. And it went downhill from there. The less said the better, really. Not one of my finest moments. Moving onwards, this was followed up by a question about a finite state machine diagram, and I get the impression that several bonus points were gained when I mentioned that I had seen one before (based on the rather surprised reaction by which this was received). They asked me to add bits to it in order to add extra functions, and there was a bit of to-and-fro-ing here as I made a few mistakes at the beginning and then went about the last part of the question in what was apparently not the intended way. They said it was still correct though, so hopefully the question wasn't too much of a failure.
And that was that. Not too bad really; it could have gone far worse. It was certainly better than the Imperial interview anyway, although I hear that Cambridge interviews are much more important that Imperial interviews when it comes to selecting candidates (Imperial do a lot more pre-interview selection, and so those with interviews are fairly likely to get offers).
This first interview was closely followed by the TSA, or Thinking Skills Assessment. A glorified IQ test really, but with slightly harder questions and a large number of questions that are to do with identifying underlying assumptions, flaws or main conclusions in arguments. The one I did at Cambridge was actually a lot harder than the online practice one, and I ended up using the full hour and a half. I did however answer all but four questions with certainty which varied between definite (for most), and moderate (for about a fifth of them). Not a clue what my results were, and indeed I'll never be told; it'll make a contribution to my application in consummate secrecy. Ominous.
So, tired and mentally worn out as I was, I trudged on to the last event of the day: the Natural Sciences interview. This has to be taken as well because the Computer Science Tripos at Cambridge involves a Natural Sciences portion for the first year (which is rather awesome actually). However, I was slightly worried at the prospect of an interview on the topic as I've done minimal revision for such a thing. And "Natural Sciences" is so ill-defined it could well bring in work I did and forgot in first-year Biology.
Thankfully, however, it was just Physics with a bit of Maths. And IT WAS GLORIOUS! Glorious and victorious. The questions were almost all easy, and I steamed through about seven or eight in the twenty-minute interview. I made a few mistakes, but in general I managed to answer every question with all the speed and accuracy of a well-guided cruise missile. Yes, that's a mild exaggeration. However I do feel rather positive about this last interview, and so it was a nice way to end the (long and arduous) day.
So then I was off, on the six-hour train journey back to here, where I found an offer from Imperial awaiting me. I'm still dancing on the ceiling about that one. And it's making it considerably difficult to type.
Thursday, 10 December 2009
Imperial college verdict
I got an offer! Yaaaaaaaaaaaaaaay, etc. I'm rather surprised actually, as I've spent the last week or so gradually lowering my estimation of how well I did and by the time I opened the letter (which, ominously, was small and white) I was already certain of being rejected. 'Twas a pleasant surprise indeed.
Unfortunately, it's rather harsh:
So, how did Cambridge go? Well, that'll have to wait for tomorrow when I have the energy to write anything of length. I just gave my entire brain-usage quota for the day to Cambridge. It wasn't too bad though; indeed, the second interview was glorious. Returning home to find a nice shiny offer from a university I was already mentally crossing off as a failure topped off the evening nicely, and has killed my short-term memory thus making me forget all the specifics of what went down in Cambridge, so even if I had the energy to write I probably couldn't recount the day's escapades just now. Watch this space, if you can be bothered at this time of night.
Unfortunately, it's rather harsh:
- A band 1 in Maths (Advanced Higher)
- A in Physics (Advanced Higher)
- A in English (Advanced Higher)
- A in History (Higher)
So, how did Cambridge go? Well, that'll have to wait for tomorrow when I have the energy to write anything of length. I just gave my entire brain-usage quota for the day to Cambridge. It wasn't too bad though; indeed, the second interview was glorious. Returning home to find a nice shiny offer from a university I was already mentally crossing off as a failure topped off the evening nicely, and has killed my short-term memory thus making me forget all the specifics of what went down in Cambridge, so even if I had the energy to write I probably couldn't recount the day's escapades just now. Watch this space, if you can be bothered at this time of night.
Wednesday, 9 December 2009
And so it begins...
Today I leave for Cambridge, to be interviewed and multiple-choice-tested tomorrow. Oh dear.
I shall tell of the horrors I faced upon my Thursday return, unless of course I'm too scarred by it all and can't post again until Friday. Either way, watch this space!
I shall tell of the horrors I faced upon my Thursday return, unless of course I'm too scarred by it all and can't post again until Friday. Either way, watch this space!
Sunday, 29 November 2009
Oh noes!!
*annoying popping sound*
MCAFEE WARNING
The program 'McAfee updater' is trying to access the Internet!!! OMGWTFLOL!!
*pause*
*annoying popping sound*
MCAFEE WARNING
McAfee is out of date! Oh noezzz what shall we do?!?!?
I shit thee not. Well, perhaps it wasn't worded quite like that, but that's how I choose to read it. Yes, McAfee SecurityCenter (bloody American spellings) has finally caught up and realised that the most potent threat to my computer is, in fact, McAfee SecurityCenter. And not just because it's designed by people with dodgy spelling skills and space-bar-aversion; no, apparently it's trying to access the Internet. Not only that, but it's antiquated as well! (And for some reason it's of the view that downloading the latest version would solve this.)
Usually, when it starts complaining about updates, the resolution is a simple case of clicking 'install updates.' However, since the latest SuperAwesome McAwesomeUpdate (NowWithEvenFewerSpaces), its very components are at odds with one another all of a sudden, and such an endeavour is obstructed by anti-virus anti-productivity red tape. So what happened? Well, allow me to retell a tale whose horrors shall play upon your very bones like some form of poorly-tuned percussion instrument. Yes, I know that didn't make any sence.
Upon restarting (which I was compelled to do by a big impertinent pop-up which repeated its demand like a child seeking sugar), I was immediately affronted by a torrent of McWhineBoxes. Every single one was from good ol' McAfee, asking for yet another of its components to be allowed access to the Internet. I honestly wasn't aware that it comprised so many discrete processes, but there we go. I suppose it serves as an example of the lengths programmers will go to outrequire the latest hardware.
Now, at least that can be easily dispelled through an hour or so of mindless allowing (during which period I may unintentionally have allowed Internet access to thousands of malwarez without noticing). However, another more pressing issue remains: McAfee SuperFireWallPlus isn't intalled!!! Or, at least, the middle-right portion of the SecurityCenter window believes that. The bottom-left portion knows it's there, but is keeping that to itself. Why? It's simple; the two portions have fallen out:
Now, one question remains. What did this new and glorious update actually add, to counterbalance the inconvenience of having to exhaustively allow every single one of McAfee's myriad sub-processes, and at the expense of the program's capability of determining its own integrity?
A new splash screen.
MCAFEE WARNING
The program 'McAfee updater' is trying to access the Internet!!! OMGWTFLOL!!
*pause*
*annoying popping sound*
MCAFEE WARNING
McAfee is out of date! Oh noezzz what shall we do?!?!?
I shit thee not. Well, perhaps it wasn't worded quite like that, but that's how I choose to read it. Yes, McAfee SecurityCenter (bloody American spellings) has finally caught up and realised that the most potent threat to my computer is, in fact, McAfee SecurityCenter. And not just because it's designed by people with dodgy spelling skills and space-bar-aversion; no, apparently it's trying to access the Internet. Not only that, but it's antiquated as well! (And for some reason it's of the view that downloading the latest version would solve this.)
Usually, when it starts complaining about updates, the resolution is a simple case of clicking 'install updates.' However, since the latest SuperAwesome McAwesomeUpdate (NowWithEvenFewerSpaces), its very components are at odds with one another all of a sudden, and such an endeavour is obstructed by anti-virus anti-productivity red tape. So what happened? Well, allow me to retell a tale whose horrors shall play upon your very bones like some form of poorly-tuned percussion instrument. Yes, I know that didn't make any sence.
Upon restarting (which I was compelled to do by a big impertinent pop-up which repeated its demand like a child seeking sugar), I was immediately affronted by a torrent of McWhineBoxes. Every single one was from good ol' McAfee, asking for yet another of its components to be allowed access to the Internet. I honestly wasn't aware that it comprised so many discrete processes, but there we go. I suppose it serves as an example of the lengths programmers will go to outrequire the latest hardware.
Now, at least that can be easily dispelled through an hour or so of mindless allowing (during which period I may unintentionally have allowed Internet access to thousands of malwarez without noticing). However, another more pressing issue remains: McAfee SuperFireWallPlus isn't intalled!!! Or, at least, the middle-right portion of the SecurityCenter window believes that. The bottom-left portion knows it's there, but is keeping that to itself. Why? It's simple; the two portions have fallen out:
Now, one question remains. What did this new and glorious update actually add, to counterbalance the inconvenience of having to exhaustively allow every single one of McAfee's myriad sub-processes, and at the expense of the program's capability of determining its own integrity?
A new splash screen.
Thursday, 19 November 2009
Imperial postmortem
Straight from the gargantuan sprawling mass of over-urbanisation that is London, I return! Now, allow me to spin for ye a tale of terror, adventure and outright ravery.
To begin with, I was ludicrously early - once again Google Maps has presumed me to be a lethargic snail made of concrete, and the journey from the underground station to Imperial College which it estimated as taking around twenty minutes took a mere five (if that). I planned the journey such that the twenty-minute walk would leave around fifteen minutes cushion-time, which could always be spent faffing around outside the university, but ended up spending a whole half-hour wandering around the area. It was a larf though.
Someone at Imperial has found out about my passion for procrastination, and as such my interview was one of the last. The first three hours were spent being shown super-spiffy demonstrations (including a balancing robot!) and being told how awesome the university is at everything (they might not have been lying here). And then followed the interviews.
Everyone in the group I was in was being interviewed simultaneously; however many the interviewers took a while to get there. And so we were left sitting around a table whilst the interviewers gradually came and picked us off, one by one. That was probably the worst part.
The interview, when it came, wasn't all that bad. Naturally I have to be quite vague about it, however. There were a few questions about my personal statement, but they seemed to be mainly out of interest - for example, "what sort of pieces does your jazz band play?" Two of them actually led into him explaining some of the things they've done at the university. Of course, there was a significant portion of maths in the middle of it all. I was mainly deriving the golden ratio in various ways, and each time I got there with a bit (sometimes a lot) of help from the interviewer. Generally I think I didn't do too badly, although I did make a few shameful mistakes - most notably, when I said two ratios were equal but then spent ages pondering what do do next before the interviewer had to explicitly point out that ratios can be expressed as fractions. And I had actually done just that for the previous question. Aah, mind blanks...
So, to summarise and conclude, the interview was largely not what I'd expected and the maths was fairly-hard-yet-doable-eventually. Not a clue whether I'm likely to get an offer or not; it really could have gone either way in the interviewer's eyes. But I believe offers/rejections come through in around two weeks or so. Thus Time, the omniscient (yet unforthcoming) being that it is, shall eventually tell.
To begin with, I was ludicrously early - once again Google Maps has presumed me to be a lethargic snail made of concrete, and the journey from the underground station to Imperial College which it estimated as taking around twenty minutes took a mere five (if that). I planned the journey such that the twenty-minute walk would leave around fifteen minutes cushion-time, which could always be spent faffing around outside the university, but ended up spending a whole half-hour wandering around the area. It was a larf though.
Someone at Imperial has found out about my passion for procrastination, and as such my interview was one of the last. The first three hours were spent being shown super-spiffy demonstrations (including a balancing robot!) and being told how awesome the university is at everything (they might not have been lying here). And then followed the interviews.
Everyone in the group I was in was being interviewed simultaneously; however many the interviewers took a while to get there. And so we were left sitting around a table whilst the interviewers gradually came and picked us off, one by one. That was probably the worst part.
The interview, when it came, wasn't all that bad. Naturally I have to be quite vague about it, however. There were a few questions about my personal statement, but they seemed to be mainly out of interest - for example, "what sort of pieces does your jazz band play?" Two of them actually led into him explaining some of the things they've done at the university. Of course, there was a significant portion of maths in the middle of it all. I was mainly deriving the golden ratio in various ways, and each time I got there with a bit (sometimes a lot) of help from the interviewer. Generally I think I didn't do too badly, although I did make a few shameful mistakes - most notably, when I said two ratios were equal but then spent ages pondering what do do next before the interviewer had to explicitly point out that ratios can be expressed as fractions. And I had actually done just that for the previous question. Aah, mind blanks...
So, to summarise and conclude, the interview was largely not what I'd expected and the maths was fairly-hard-yet-doable-eventually. Not a clue whether I'm likely to get an offer or not; it really could have gone either way in the interviewer's eyes. But I believe offers/rejections come through in around two weeks or so. Thus Time, the omniscient (yet unforthcoming) being that it is, shall eventually tell.
Tuesday, 17 November 2009
Imperial College London interview tomorrow...
Eep. Fear and pre-emptive terror shall ensue.
Well, I'll be sure to post here afterwards to say how badly it went. And then maybe I can get on with ExeSketch!
Well, I'll be sure to post here afterwards to say how badly it went. And then maybe I can get on with ExeSketch!
Saturday, 14 November 2009
Got an interview for Cambridge
Hoorah!
Quite surprisingly I've got a massive amount of notice for this one - apparently they don't normally tell you until the week before, thus forcing you to spend vast quantities of cash on train tickets. It's not until the 10th of December, a full four weeks after the one at Imperial (which is rapidly closing in!). Now, by D00ve's Law (given a particular timeframe T, the time spent procrastinating is (19/20)T with the remaining period spent actually working) that gives me 1.4 days to prepare, which seems reasonable enough. But firstly, the Next Wednesday interview must be prepared for. Updates to come when it's over!
Quite surprisingly I've got a massive amount of notice for this one - apparently they don't normally tell you until the week before, thus forcing you to spend vast quantities of cash on train tickets. It's not until the 10th of December, a full four weeks after the one at Imperial (which is rapidly closing in!). Now, by D00ve's Law (given a particular timeframe T, the time spent procrastinating is (19/20)T with the remaining period spent actually working) that gives me 1.4 days to prepare, which seems reasonable enough. But firstly, the Next Wednesday interview must be prepared for. Updates to come when it's over!
Sunday, 8 November 2009
Once more out of the gloom
It's time for...
another
UPDATE
So, what's new this time?
Well, to start off with, here's the UCAS application situation:
So even if all four of my other choices reject me, I can at least go to Glasgow!
Annoyingly I have a long wait before I'll hear anything else. Edinburgh and St Andrews have both explicitly said they won't make any decisions until the UCAS application deadline (15th January) at the earliest, and St Andrews is notorious for not telling anyone whether they're in or not until the absolute last minute. I believe Cambridge don't generally send out interview invitations until around the end of November, so it'll be a while before I hear anything from them (I'll update here when I do).
Imperial College, however, have been terrifyingly quick to reply. I added them to my application just last Saturday, and received the invitation to interview on the Wednesday! It's for Wednesday the 18th, which from now gives me around nine days to get ready - master all the maths I've done in school, and be AWESOME at everything I've even hinted at on my personal statement. This as well as working out how to get down to London in time for the early afternoon interview without spending too-many-hundred pounds. Slightly worrying, but it's thankfully being counterbalanced by the still-strong 'yaaaay, I got an interview' feeling.
Once again I'm terribly sorry about the lack of any ExeSketch progress, but at the moment I'm going to have to focus on being able to explain how I did it instead of coding ahead on regular polygons. However, I do have an algorithm for regular polygons worked out in my head. It's just yet to adopt any tangible manifestation.
So, what's new this time?
Well, to start off with, here's the UCAS application situation:
Cambridge - Acknowledged, and allocated to Jesus college
Imperial College London - newly-added choice; invited for interview
Edinburgh - Acknowledged
Glasgow - Unconditional offer!
St Andrews - Acknowledged
Imperial College London - newly-added choice; invited for interview
Edinburgh - Acknowledged
Glasgow - Unconditional offer!
St Andrews - Acknowledged
So even if all four of my other choices reject me, I can at least go to Glasgow!
Annoyingly I have a long wait before I'll hear anything else. Edinburgh and St Andrews have both explicitly said they won't make any decisions until the UCAS application deadline (15th January) at the earliest, and St Andrews is notorious for not telling anyone whether they're in or not until the absolute last minute. I believe Cambridge don't generally send out interview invitations until around the end of November, so it'll be a while before I hear anything from them (I'll update here when I do).
Imperial College, however, have been terrifyingly quick to reply. I added them to my application just last Saturday, and received the invitation to interview on the Wednesday! It's for Wednesday the 18th, which from now gives me around nine days to get ready - master all the maths I've done in school, and be AWESOME at everything I've even hinted at on my personal statement. This as well as working out how to get down to London in time for the early afternoon interview without spending too-many-hundred pounds. Slightly worrying, but it's thankfully being counterbalanced by the still-strong 'yaaaay, I got an interview' feeling.
Once again I'm terribly sorry about the lack of any ExeSketch progress, but at the moment I'm going to have to focus on being able to explain how I did it instead of coding ahead on regular polygons. However, I do have an algorithm for regular polygons worked out in my head. It's just yet to adopt any tangible manifestation.
Friday, 16 October 2009
Updates galore!
This post, in essence, is a being of two halves. Two halves not unrelated, but mutually hateful of one other and perpetually at war. And as such, I think it best to keep them discrete lest they destroy each other in a fiery rain of textual combat. So, here we go:
The ExeSketch half
Béziers are finally implemented! Well, if I'm honest, they've been implemented for about a week now. But, as you will discover if you refer to the other half of this post (make sure you shut the adjoining gate on your way), I've been left staggeringly short of time during which to report said development. Hence this update. Here's a video!
Next up, I believe, is regular polygons. Should be... fiddly. I tried to make a demo once, and the results were an insult to geometry. However, I believe I might know why that happened, and so I might be able to sort it. As usual, I'll end up not-getting-around-to-it for weeks before I get the time to actually do it, at which point I'll implement it in under an hour.
The Everything Else (Excuses) half
So, what horrific debilitating illness have I contracted that's made my post so heavily delayed this time? UCAS.
In case you're not of the British persuasion, UCAS (Universities and Colleges Admissions Service) is the bane of every applicant's life. Well, mainly the personal statement part of it. The aim is to condense the relevant parts of one's entire existence into a mere 4000 characters, a limit which this blog post alone has exceeded. For some reason (not of my own design), mine ended up being *exactly* 4000 characters. Thankfully all that is done now, so all that needs to be done at the moment is a round of the Waiting Game. And the SAQ, but I'll speak more about that in a minute.
Being as I am something of a compulsive programmer and general computer-tinkerer, I'm in the process of applying for Computer Science. The universities? Cambridge ('Bridge), Edinburgh ('Burgh), St Andrews (Drew's) and Glasgow (chav centra- um, Glasgae). I might add in Imperial College London (Imp 'Ledge-don) later on, but those are the initial ones which I sent off on Wednesday.
So, picture the scene: I'm busy doing a week-long victory dance to celebrate having finished the Bloody UCAS Thingy, as one does, and I'm about to go into the 'break-it-down-now' section when suddenly Cambridge are all like 'email!'. And upon opening their email I discover (to my utmost horror) that I'm still not done ( :-( ). As well as the Bloody UCAS Thingy, I also have to fill in a Supplementary Application Questionnaire - the aforementioned SAQ. This throws up many complications.
Firstly, they want to know what bands I got in my exams - that is, how good an 'A' each subject was. And only the teachers know that. And today was the last day before our school goes on holiday. And they want the questionnaire completed by Thursday, which is during said holiday. So up to school I did dash, with all the grace of a murderous lunatic, and still afflicted with the illness which had me stuck in bed for the entirety of yesterday. Thankfully I made it there before the teachers had left, and was able to discover that I got three band 1s (Maths, Physics, Chemistry) and two band 2s (English, Music - the latter being the result of several transient teachers). So thankfully that issue is resolved.
However, as well as this they are also asking for the number of people who were in each of my classes last year and are in my classes this year (not entirely sure why). Although I may be very much a man of numbers, I've never really felt the urge to count and commit to memory the number of people in my class at any given moment - not even during the most boring of pre-school-level music theory lessons. And so I've spent the past hour or so trying to visualise what the classrooms looked like last year, and counting the people present. It's proved surprisingly effective, but it's probably not all that accurate, so hopefully it's not a vitally important part of the application.
However, the worst part is yet to come: they ask for an additional personal statement. This time it's supposed to explain the writer's reasoning in choosing Cambridge (and no, "because it's Cambridge" doesn't count, unfortunately). The bright side is that it's only 1200 characters maximum, 30% of the main UCAS one.
They also ask about how the applicant explores their subject outwith school, but that's only supposed to be up to 300 characters - literally a couple of sentences. The challenge there is compressing a salient obsession with the subject and a passionate eagerness to learn into a concise and presumably stylish set of sentences.
These last two fiddlies are the only things I have left to do before it's sendable, so with any luck I should be finished miles before the deadline. And then I can go back to ExeSketch!
The ExeSketch half
Béziers are finally implemented! Well, if I'm honest, they've been implemented for about a week now. But, as you will discover if you refer to the other half of this post (make sure you shut the adjoining gate on your way), I've been left staggeringly short of time during which to report said development. Hence this update. Here's a video!
ExeSketch Demo 4 from Animatinator on Vimeo.
Next up, I believe, is regular polygons. Should be... fiddly. I tried to make a demo once, and the results were an insult to geometry. However, I believe I might know why that happened, and so I might be able to sort it. As usual, I'll end up not-getting-around-to-it for weeks before I get the time to actually do it, at which point I'll implement it in under an hour.
The Everything Else (Excuses) half
So, what horrific debilitating illness have I contracted that's made my post so heavily delayed this time? UCAS.
In case you're not of the British persuasion, UCAS (Universities and Colleges Admissions Service) is the bane of every applicant's life. Well, mainly the personal statement part of it. The aim is to condense the relevant parts of one's entire existence into a mere 4000 characters, a limit which this blog post alone has exceeded. For some reason (not of my own design), mine ended up being *exactly* 4000 characters. Thankfully all that is done now, so all that needs to be done at the moment is a round of the Waiting Game. And the SAQ, but I'll speak more about that in a minute.
Being as I am something of a compulsive programmer and general computer-tinkerer, I'm in the process of applying for Computer Science. The universities? Cambridge ('Bridge), Edinburgh ('Burgh), St Andrews (Drew's) and Glasgow (chav centra- um, Glasgae). I might add in Imperial College London (Imp 'Ledge-don) later on, but those are the initial ones which I sent off on Wednesday.
So, picture the scene: I'm busy doing a week-long victory dance to celebrate having finished the Bloody UCAS Thingy, as one does, and I'm about to go into the 'break-it-down-now' section when suddenly Cambridge are all like 'email!'. And upon opening their email I discover (to my utmost horror) that I'm still not done ( :-( ). As well as the Bloody UCAS Thingy, I also have to fill in a Supplementary Application Questionnaire - the aforementioned SAQ. This throws up many complications.
Firstly, they want to know what bands I got in my exams - that is, how good an 'A' each subject was. And only the teachers know that. And today was the last day before our school goes on holiday. And they want the questionnaire completed by Thursday, which is during said holiday. So up to school I did dash, with all the grace of a murderous lunatic, and still afflicted with the illness which had me stuck in bed for the entirety of yesterday. Thankfully I made it there before the teachers had left, and was able to discover that I got three band 1s (Maths, Physics, Chemistry) and two band 2s (English, Music - the latter being the result of several transient teachers). So thankfully that issue is resolved.
However, as well as this they are also asking for the number of people who were in each of my classes last year and are in my classes this year (not entirely sure why). Although I may be very much a man of numbers, I've never really felt the urge to count and commit to memory the number of people in my class at any given moment - not even during the most boring of pre-school-level music theory lessons. And so I've spent the past hour or so trying to visualise what the classrooms looked like last year, and counting the people present. It's proved surprisingly effective, but it's probably not all that accurate, so hopefully it's not a vitally important part of the application.
However, the worst part is yet to come: they ask for an additional personal statement. This time it's supposed to explain the writer's reasoning in choosing Cambridge (and no, "because it's Cambridge" doesn't count, unfortunately). The bright side is that it's only 1200 characters maximum, 30% of the main UCAS one.
They also ask about how the applicant explores their subject outwith school, but that's only supposed to be up to 300 characters - literally a couple of sentences. The challenge there is compressing a salient obsession with the subject and a passionate eagerness to learn into a concise and presumably stylish set of sentences.
These last two fiddlies are the only things I have left to do before it's sendable, so with any luck I should be finished miles before the deadline. And then I can go back to ExeSketch!
Sunday, 27 September 2009
Switching to freeglut
As you may know if you follow ExeSketch's launchpad page, I recently decided to use freeglut instead of GLUT for the project. As luck would have it, the process of switching over only really involved replacing a few '#include's - although I had to rename several of my constants as they apparently conflicted with freeglut ones.
This means I can now process events like turning the scrollwheel on the mouse, or click-dragging with a modifier key held down - events which were inexplicably missing from GLUT. However, it turns out GLUT is actually about ten years out of date, so I suppose scrollwheels probably didn't exist when the last GLUT version was released.
In other news, Bézier curves are well and truly on their way! I finally got some code written today, which includes all the drawing functions, some basic event handling, and a sufficient helping of behind-the-scenes faffery. Here's a screenshot:
More next time!
This means I can now process events like turning the scrollwheel on the mouse, or click-dragging with a modifier key held down - events which were inexplicably missing from GLUT. However, it turns out GLUT is actually about ten years out of date, so I suppose scrollwheels probably didn't exist when the last GLUT version was released.
In other news, Bézier curves are well and truly on their way! I finally got some code written today, which includes all the drawing functions, some basic event handling, and a sufficient helping of behind-the-scenes faffery. Here's a screenshot:
More next time!
Friday, 18 September 2009
Well, it wasn't
Last post I mentioned that this week would probably be a quiet one. Well, fate felt tempted and assailed me with a week so copiously endowed with commitments that it ended up being the least productive week ExeSketch has seen so far. So I'm going to have to apologise again. However, all of the open days are now done and the personal statement for university is getting there, so I might be able to stop messing about in the real world and get a Bézier class up and running soon. Until then, cheerio!
Saturday, 12 September 2009
It's excuse time!
Why, you may cry, are the posts so elusive? Well here's an excuse, hopefully not too obtrusive:
School again. Well, this time it's not so much school as the preparation for leaving it: I've been spending a lot of time messing around at university open days (descending on unexpectant cities and causing trouble) and attempting to write a personal statement for applications (playing Tetris and occasionally glancing over at the empty OpenOffice document with a slight twinge of impending doom), and naturally this has slightly impeded my posting prowess.
It's also caused a stagnation in the ExeSketch production line; you may have noticed that the recent commits have mainly been small feature additions and bugfixes. However, do not fear for ExeSketch. My solution is simple: the Bézier milestone shall have to be pushed back by one week, which (shoddy though it may seem) will provide ample time for me to get a perfectly functioning Bézier object working. How can I guarantee this? I can't - I'm the least reliable target-setter on the face of the blogoweb. But next week will probably be a (comparatively) quiet one, and so by setting myself this extended deadline I will hopefully encourage myself to actually get the thing done.
Until then, goodbye!
School again. Well, this time it's not so much school as the preparation for leaving it: I've been spending a lot of time messing around at university open days (descending on unexpectant cities and causing trouble) and attempting to write a personal statement for applications (playing Tetris and occasionally glancing over at the empty OpenOffice document with a slight twinge of impending doom), and naturally this has slightly impeded my posting prowess.
It's also caused a stagnation in the ExeSketch production line; you may have noticed that the recent commits have mainly been small feature additions and bugfixes. However, do not fear for ExeSketch. My solution is simple: the Bézier milestone shall have to be pushed back by one week, which (shoddy though it may seem) will provide ample time for me to get a perfectly functioning Bézier object working. How can I guarantee this? I can't - I'm the least reliable target-setter on the face of the blogoweb. But next week will probably be a (comparatively) quiet one, and so by setting myself this extended deadline I will hopefully encourage myself to actually get the thing done.
Until then, goodbye!
Thursday, 10 September 2009
Icons make programs who they are
Wh00t said I as I finished this little Logo/Icon for ExeSketch. The only thing that made me pause was the lack of any polished surfaces, but then I realised that shiny does not require polished surfaces, a nice matte finish can be just as shiny. So Here I present to you the first Logo of ExeSketch. I have a feeling that the logo might get an update at the first big release, but only time can tell...
Saturday, 5 September 2009
New demo video! (Slightly belated...)
Greetings once more! Apologies for the prolonged absence, other commitments got in the way of updating this blog (they also stole my lunch money). Today I arrive with a video in tow; yes, it's the new ExeSketch demo video:
So, what's new? Well, I've mastered the Sony Vegas 'Light Rays' effect. And I've still not had to illegaly use a piece of commercial music in any of my demo videos (the "Animatinator 2008" folder is serving me well). But what of ExeSketch?
Well, to begin with, all three of the "basic-objects" objects are in (Rect, Polygon and Circle), and working rather nicely. More significantly, however, the program has gained the beginnings of an interface: the shape that will be added on right-click can be selected from a little menu on the left, with spiffy icons drawn by James the Graphics Man (and made pixellated by myself and OpenGL - I intend to fix this, however). This menu is fully customisable (from within the code, anyway) - it can be any size, hold any number of buttons, of whatever size and spacing you (the programmer, that is) feel like applying, and it can run either horizontally or vertically. Its position can also be set, which could potentially allow for draggable menus (although James is advising me against that).
Since the release I've updated the object menu further to turn it into a generic ButtonMenu class which can be used for any selection of radio buttons (ie a list of buttons from which just one is selected at all times), and so it could also be used for creation of a menu that switches between the object view and editing modes, or changes how an object is drawn (alternating between fill, wireframe and points).
And now, with the "basic-objects" release done, the next significant milestone is the implementation of Bézier curves. Which might prove tricky, given that Bézier code made up most of the original CurveDraw source code. But this time, I have the advantage of knowing what I'm doing (or at least being more sure of it than I was last time).
ExeSketch Demo 3 from Animatinator on Vimeo.
So, what's new? Well, I've mastered the Sony Vegas 'Light Rays' effect. And I've still not had to illegaly use a piece of commercial music in any of my demo videos (the "Animatinator 2008" folder is serving me well). But what of ExeSketch?
Well, to begin with, all three of the "basic-objects" objects are in (Rect, Polygon and Circle), and working rather nicely. More significantly, however, the program has gained the beginnings of an interface: the shape that will be added on right-click can be selected from a little menu on the left, with spiffy icons drawn by James the Graphics Man (and made pixellated by myself and OpenGL - I intend to fix this, however). This menu is fully customisable (from within the code, anyway) - it can be any size, hold any number of buttons, of whatever size and spacing you (the programmer, that is) feel like applying, and it can run either horizontally or vertically. Its position can also be set, which could potentially allow for draggable menus (although James is advising me against that).
Since the release I've updated the object menu further to turn it into a generic ButtonMenu class which can be used for any selection of radio buttons (ie a list of buttons from which just one is selected at all times), and so it could also be used for creation of a menu that switches between the object view and editing modes, or changes how an object is drawn (alternating between fill, wireframe and points).
And now, with the "basic-objects" release done, the next significant milestone is the implementation of Bézier curves. Which might prove tricky, given that Bézier code made up most of the original CurveDraw source code. But this time, I have the advantage of knowing what I'm doing (or at least being more sure of it than I was last time).
Thursday, 3 September 2009
Getting rolling
Today I am proud to announce that the first release of ExeSketch is now complete! You can download it here. A demo video should be done shortly, at which time I shall post it here also (hopefully it'll make up for the rushed brevity of this post).
Monday, 31 August 2009
With good software, comes good design
Maybe... I don't know but what I do know is that all my favourite software has good design. So why not have some nice sleek design in our own software? I have been working on icons (and a logo...) for ExeSketch.
This was an idea for radial menus but David is leaving them for the future as they could be a 'mare to code. So we will be having a linear menu along the top or side of the canvas with the icons in a nice neat row.
The icons that you see here (if all goes to plan) should be in the first alpha release of ExeSketch. There is one more icon for Regular polygons too, but I can't find a nice image of it with other icons, so for brevity I will leave it out for now.
More from me later,
-James
This was an idea for radial menus but David is leaving them for the future as they could be a 'mare to code. So we will be having a linear menu along the top or side of the canvas with the icons in a nice neat row.
The icons that you see here (if all goes to plan) should be in the first alpha release of ExeSketch. There is one more icon for Regular polygons too, but I can't find a nice image of it with other icons, so for brevity I will leave it out for now.
More from me later,
-James
Saturday, 29 August 2009
Long time, no see; much coding, however
For some reason I completely forgot to post updates here this week. As a result, they've stacked like a pile of bills, and the mountain is about to collapse - in blog post form! I suppose the best way of introducing the huge volume of updates is by way of another demo video:
So, as you may have ascertained from the video, the most obvious change is that ExeSketch is now possessive of both a fully-functional Polygon class and a hyper-spiffy Circle class. However, that's not all - as well as the new objects I've added several more accessor functions to the existing ones, a generic bounding box drawing function for all objects (noticeable in the video), duplication of objects, and all sorts of items of jazzy miscellany that presently escape my memory.
Now, excuse my recapitulation of Polygon features I may have mentioned before; I'm on the "Create Post" page and can't be arsed going into a new tab to read over my previous post on the topic. All I know is that some of it is new, probably. Well, to begin with guaranteed repetition, the Polygon class defines a polygon as a series of points joined by lines or filled. In edit mode, one can select points and move them (or delete them with the delete key), and add a new point after the selected one by applying pressure through whichever finger happens to lie poised atop the rightmost mouse button. Fairly simple really, and I believe undeserving of further explanation. What's almost certainly new is completely bug-free mouseclick detection (I redid the function and it now has both the advantages of brevity and, you know, working). I also added antialiasing for polygons, something which doesn't work on my system (bloody Intel card) but may well work on others.
The Circle class, being entirely new and shiny, is a different kettle of fish entirely (for one thing, it's circular). This is defined as a position (its centre point) and a single point on its circumference, the latter of which can be moved around in editing mode in order to resize the circle. As usual, fill can be toggled with the F key; the only class that probably won't have this feature is the Bézier curve (ah, how I dread its mathematical curvy complexity).
Before I forget, duplication is done with shift-D. And that's it. Such a piddly description seems hardly worth the hours I spent trying to get the damned thing to work (don't get me started), but from a user's perspective, it really is as simple as that. And on that note, here's the source code again. Good day!
ExeSketch Demo 2 from Animatinator on Vimeo.
So, as you may have ascertained from the video, the most obvious change is that ExeSketch is now possessive of both a fully-functional Polygon class and a hyper-spiffy Circle class. However, that's not all - as well as the new objects I've added several more accessor functions to the existing ones, a generic bounding box drawing function for all objects (noticeable in the video), duplication of objects, and all sorts of items of jazzy miscellany that presently escape my memory.
Now, excuse my recapitulation of Polygon features I may have mentioned before; I'm on the "Create Post" page and can't be arsed going into a new tab to read over my previous post on the topic. All I know is that some of it is new, probably. Well, to begin with guaranteed repetition, the Polygon class defines a polygon as a series of points joined by lines or filled. In edit mode, one can select points and move them (or delete them with the delete key), and add a new point after the selected one by applying pressure through whichever finger happens to lie poised atop the rightmost mouse button. Fairly simple really, and I believe undeserving of further explanation. What's almost certainly new is completely bug-free mouseclick detection (I redid the function and it now has both the advantages of brevity and, you know, working). I also added antialiasing for polygons, something which doesn't work on my system (bloody Intel card) but may well work on others.
The Circle class, being entirely new and shiny, is a different kettle of fish entirely (for one thing, it's circular). This is defined as a position (its centre point) and a single point on its circumference, the latter of which can be moved around in editing mode in order to resize the circle. As usual, fill can be toggled with the F key; the only class that probably won't have this feature is the Bézier curve (ah, how I dread its mathematical curvy complexity).
Before I forget, duplication is done with shift-D. And that's it. Such a piddly description seems hardly worth the hours I spent trying to get the damned thing to work (don't get me started), but from a user's perspective, it really is as simple as that. And on that note, here's the source code again. Good day!
Monday, 24 August 2009
Soon, my friends, there will be polygons...
Today saw a rather large amount of code being added to the Polygon class; it has now reached the point where such objects can be added to the drawing and taken in and out of edit mode. However, you can't actually edit them yet. And the function for testing to see if the mouse is within the polygon isn't done yet either. However, the fact that it draws without crashing the program is a miracle in itself.
As well as this, I messed around with some classes a bit and now, when you zoom the view, the editing handles scale also so that they remain the same size in physical pixels. This means that editing from a great distance is no longer the microscope-waggling affair it once was, and for that reason large-scale doodlers everywhere can breathe a unanimous sigh of relief.
To those still awaiting the slightly-hyped continuation of the ExeSketch Explanation, allow me to unequivocally unshroud the undeniable TRUTH: 'tis no abandoned series; I simply have not yet made my way around to doing it. It's in the works though. I've got the Blogger draft to prove it.
So, with a random fling of today's code changes in the general direction of my reading audience, with the expectancy that someone will grab it and give it to an arbitrary infant as a chew-toy serving as cause for my retention of the more awesome finished Polygon code (to be completed by next post) in my pocket, I take the customary means of leave by the leftmost end of the stage. Good night, or good morning; feel free to substitute a time zone-corrected greeting as it pleases you.
As well as this, I messed around with some classes a bit and now, when you zoom the view, the editing handles scale also so that they remain the same size in physical pixels. This means that editing from a great distance is no longer the microscope-waggling affair it once was, and for that reason large-scale doodlers everywhere can breathe a unanimous sigh of relief.
To those still awaiting the slightly-hyped continuation of the ExeSketch Explanation, allow me to unequivocally unshroud the undeniable TRUTH: 'tis no abandoned series; I simply have not yet made my way around to doing it. It's in the works though. I've got the Blogger draft to prove it.
So, with a random fling of today's code changes in the general direction of my reading audience, with the expectancy that someone will grab it and give it to an arbitrary infant as a chew-toy serving as cause for my retention of the more awesome finished Polygon code (to be completed by next post) in my pocket, I take the customary means of leave by the leftmost end of the stage. Good night, or good morning; feel free to substitute a time zone-corrected greeting as it pleases you.
Sunday, 23 August 2009
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!
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!
Saturday, 22 August 2009
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...
Wednesday, 19 August 2009
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.
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.
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...
ExeSketch demo 1 from Animatinator on Vimeo.
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)