#misc code

So I've spent a large portion of the past few days working on a new iteration of my portfolio website so it's easier to use, not as difficult for me to work with personally as far as content is concerned, and is also compatible with browsers that don't have JavaScript enabled.

Though frankly I'm bewildered as to why you feel it necessary to disable JavaScript at all, unless you're browsing some really dodgy areas of the net, but I won't judge you.

So at first I thought about sticking largely with the previous design I'd been using where I'd had a box in the middle of the page. This box and its contents would resize themselves to fit the dimensions of the browser window; on smaller screens and down-sized windows, all the content would fit, whereas on larger screens it would make use of the entire window without leaving a bunch of unused space.

This seemed like a good idea at the time, but I realise now that it would be both a pain for me to make happen - certainly without use of JavaScript - but would also mean that below certain screen resolutions the content would become increasingly difficult to read, at the very least.

With this in mind, I decided I'd just go back to the more traditional design of a large central content column; incidentally, a name I feel should be adopted more commonly for such a design. Alliteration always accrues awesomeness.

Anyway, advancing awkwardly, I didn't want to stick purely to a design involving straight edges everywhere, but also didn't want to have anything too "out there" thematically speaking, so after toying with the ideas of either jagged polygons or curved edges and rounded borders, amongst other things, I came to settle on "disorganised" rectangles - simple, easy to make work, and also conveniently open to a simple layout without having to compromise and have too much unnecessarily unused space.

At this point I got into the HTML and CSS, which as always is where you start having problems with your design. I wanted to add a menu to the site, rather than having to use a navigation bar in the traditional sense, so thanks to the miracle of the :hover pseudo-class, a few tricks with display: none; and display: table; I was able to make the menu look good without having to make either it or the individual menu options fixed-width or have to mess around with JavaScript - which I've so far avoided having to touch at all.

I then plonked this into a header bar affixed to the top of the viewport, without having to affix it to either side (thanks again to the miracles of CSS, specifically position: fixed; by default not affecting the offsets of elements) and added text on the right for a page title display.

The next part of the design involved making the center column look like it had these jagged-rectangle edges; I thought about placing the main content inside one <div> element and having the background image be one large image behind the entire thing, but decided against this as it'd force me to make a large PNG for this background, which would make the page load time rocket on slow connections, and it would mean having the whole page display empty space for a large count of pixels on a smaller screen and make scrolling around it awkward, which I also wanted to avoid.

In the end I came up with the idea where the backing design and the content were separate, so the content could be scrolled independently on smaller screens, with the added bonus of the background on a smaller screen not being forced onto it pointlessly.

Then finally the content itself had to be able to have images per-piece as thumbnails, but have the content wrap around them in the case where I'd be writing a lot of description text.

First off, in the case where the description were smaller than the thumbnail(s) height-wise, it would mean having to force the image to float on the left of the text inside the element, which as most web developers will know, means that the parent element naturally ignores the size of the floated element.

The commonly-used and sadly accepted solution WAS to add an extra element and use a CSS trick utilising the clear attribute - but instead you can instruct the parent element, using overflow: auto;, to handle overflowing content including floating elements, it will achieve the same thing in a much neater manner.

Coming up with ways to make your own code easier to use can be a pain in the back-end, but obviously as it serves to simplify your life later on, the sooner you do it the better.

Where a lot of mathematics-based class design is concerned, particularly when using C++, a common practice is to overload operator functions; for example, I have a class called "Float3" that contains three floating-point values - this could be used in 3D space to determine a position, the scale of an object, an offset, and so on - that I could just define as being the three values, and from then on manually perform calculations as and when I need to by directly modifying said values.

But that's boring, and would be more to type in the long run, so naturally something must be done.

If you overload an operator, it makes things like... Float3_A = Float3_B + Float3_C; ...possible, rather than forcing yourself to type... Float3_A.x = Float3_B.x + Float3_C.x; Float3_A.y = Float3_B.y + Float3_C.y; Float3_A.z = Float3_B.z + Float3_C.z; ...every time you wanted to, in this case, add the values in two objects of your own classes together.

I never used to like overloading operators, I never really understood either how to do it or how it should be carried out in an optimal fashion, since obviously if you're going to do something like this, you should in such a way that makes it no slower than it would be otherwise.

My course taught me a lot of things, this clearly being one of them, but I'm the type of person that (generally speaking) wants to make sure they know what they're doing before jumping in head-first and finding they dun goofed - so up until now I've left this stuff to those in group project work who were either confident enough, or arrogant and lucky enough, to do so where necessary; thankfully I've also never actually needed to make any op-overloads for my parts in said work specifically, so that helped - however, again this evening in working on SAGE, I wanted to actually get to grips with it properly since it's probably one of the most basic things you should know how to do as a C++ programmer and it's about bloody time I fully got to grips with doing it regardless; so off to Google I went.

There are some helpful answers to questions on Stack Overflow that explain roughly how to go about doing it, but of course being as full of competent programmers as it is incompetent ones, it was difficult to filter through the bad advice for the good, and usually you end up having to read an entire debate about something seemingly irrelevant before you get anywhere with SO's solutions.

The various C++ reference websites have some pretty decent info, quite obviously, but admittedly I found it hard to sift for any decent examples of how op-overloading should be done properly, instead finding rough guides as to what it was and why you'd need to do it.

I then stumbled across this page of 2007 origins that went over in detail not only how each overload should be done, dividing them into categories to show which can be written the same and specifying the "function signature" of each, but also covered some techniques for giving yourself even less code to write by re-using operators you've already overloaded.

So that was cool, and now I actually know I had the right idea to begin with, I can add this usefulness to future code projects with confidence.  Which is something. :)

Okay, so I didn't really know how to start this off, therefore I'm just jumping right into what I'm working on at the moment.

A fair while ago during my time at Uni, part of our coursework was to develop an, albeit basic, game engine; we did this in groups, but at that point I was already thinking of how I would go about making one if I did so independently.

At that point of course I was even less experienced than I am now, but regardless I thought it would be a great project to work on in free time - which of course I quickly found out I'd have practically none of, so that plan was fast shot down in flames - or possibly as a post-degree project once the year was over, assuming I would pass... that too was a close call, but let's not go there.

Anyway, I started to work on it near the end of the second-to-final year during the exam period, for some short spans of time where I wasn't either asleep or eating, and sometimes even when I was doing the latter, and made a bit of headway; this I have obviously since scrapped in favour of a different design, but that's all part of the process of development and learning.

Initially, and this was way back when we were first given the aforementioned group coursework, I'd had it in my head that I'd just make it the same way I'd made the other games we'd been tasked to create for previous assignments, which was as I know now pathetically daft, being told not long after concocting the first mental designs that making an engine using a component-based model would be a far more logical method than trying to create a more or less fixed-structure type of program, also known as a hacked-together mess, which it would have been.

However having grouped myself up with friends who were and still are all brilliant and highly talented programmers, the component-based model was suggested for our group engine, and so I scrapped the entirety of my own engine design from the brainplaces in my face once we'd gone over what it meant and how we'd implement it for the group work.

Already-long story short; I've been working on the designs mentally ever since, occasionally jotting down bits of code and taking things I've learned from the group work and adapting them to suit the project as I've played with it - sometimes direct-copying, admittedly, but since a large part of the code I'm copying was mine, that's probably a non-issue (plus it's likely that I'll change it at some point in the future anyway) - and I've come to give the project the name of "SAGE", Simplistically-Adaptable Game Engine, which also admittedly is because at first I just wanted the initials to spell SAGE as a reference to the delightful thread-wreckers I've encountered in my many years spent being a 4channer... which really has nothing to do with game development at all, but I'm just that kind of twat.

As far as the logic goes, I guess I thought of it as being like trawling through something you enjoy doing while a bunch of problems surface to hinder your progress, lower your morale if you will, so it seemed sort of fitting that given all of the times I've had to effectively "404" previous versions of this project and start from scratch, a name suited to the process of repeatedly adding to it and having it get nowhere made sense at the time.  I can always change the name, I suppose, but I like the acronym as it is.

This afternoon I thought I should properly start from scratch with the most recent plans I had in mind, and given that I had yet to put anything with a point to it on this blog, I've chosen to start with this; so here I am.

I hope to keep this updated at least moderately regularly as I work on it further, but I make no promises, not that it's likely for anyone at this stage to be reading (or probably caring, either) about it. I guess this is more for me than anything else, but we'll see where it goes.