Thursday, December 15, 2011

Doodle crazy.

I haven't done any programing today... just doodled the heck out of myself.
Enjoy... or not, it's up to you, and your taste for my "style"

There's only 8, some more serious that others




In there tongue, he is Pierre, Dragonpainter!


Victory, messy, painful victory, but victory nonetheless

Just, like... chill, bro.
-Kev

Saturday, December 10, 2011

I love the smell of napalm in the morning.

(Writing on the go, no doodles... yet!)
(Edit, Got a doodle in, scroll down for it, or, you know, read it and then see the picture)

Success, however you choose to measure it, is a fickle beast.  It certainly is no friend of mine.  Most often when I achieve success it isn't enough, and that is where I find myself again today.  After hours upon hours of struggling and using my most abundant resource, stubbornness, almost to exhaustion I finally found a solution to the issue.

The success is in the that my camera system is now fully operational, it works smooth as silk and there are no graphical glitches or processing slow down.  Good news for David, and the system as a whole.  It is now more flexible and powerful than ever.  So why am I not pleased with success?

It doesn't feel mine.  The methods I had built before were of my own doing, my own math and created by me and for me.  The problem was that my old ways were inefficient and messy.  And the fact of the matter is the new system I implemented, which is based off of previously existing systems in XNA (well, not just in XNA, in most graphics programs as a whole), is far better than what I had before, despite my affinity for my own hard work and code.

Work harder, not smarter, a maxim I am still learning to this day.  And it's an unfortunate truth that programmers, like anyone else who creates, get very attached to their creations and can be loathe to abandon all of their hard work even if a better solution is available.

As is, I ended up using an XNA class called RenderTexture2D, which is a separate buffer to draw too, and then used that entire buffer as a single texture and drew that texture according to the dimensions of the camera.  Buffer work is not something I've had a whole lot of experience with, but the solution I came to using the separate buffers feels almost too easy for the incessant slaving away that I've put into the camera system in the past few days.  And what I came up with today was almost too easy, and it took no more than an hour to research and implement.

I'm not sure if finding this solution makes me a good developer because I found the solution, or a bad developer because it took me so long to find this solution.

I guess that remains to be seen.

-Kevin

Endless looping

One of the worst errors you can manage to drum up in programming is that of the endless loop.  It's not the worst in it's difficulty to track or fix (usually) but in that it is a common pitfall that the "get-some" programmers like myself who charge into projects with guts and not a much else fall into.  I'm not saying other programmers who are more careful or intent don't find these nasty errors awaiting for them, but they happen, quite often.  A slip of the fingers while typing or a momentary lapse in logic is all that it takes for your program to decide that it's going to sit and keep doing the same thing over and over and over again because it said so.  Or rather, because I said so.

It breaks your program, without fail, and depending on the location of this error or what your loop was trying to preform, it eats up a heck of a lot of memory on you processor and slows everything else down.

The solutions to these endless loops should be evident.  You forgot to add a good ending condition to your loop, such as saying

do {
//stuff
} (while true);

That, while a very simple case, is usually what happens.  But then you get the times where the solution is not clear, and you spend hours searching through what looks like perfectly good code for a tiny error that renders all of your hard work obsolete.

Especially in the case of linked lists (which is a list of objects that know where the previous object and the next object are in memory, and nothing else) if you don't manage your memory correctly then you can lose your place in the loop, and it will never complete, sitting idle, lost in the maze of your computer's heap memory, unable to find the next link and move on.

That's a bit dramatic, but if you couldn't tell I'm attempting to relate this endless loop to something more than programming.

Endless loops don't just occur within the realm of the nerds, geeks or computationally-proficient-yet-socially-ineffective.  They occur in real life, too.  And they are every bit as bad, if not worse, as the kind that I run into while jumping feet-first into programming hell. (a.k.a. my creative process)

It would seem I'm prone to all kinds of ceaseless loops.  Making the same mistakes, acting in the same manner and preferring to stay in what I know as comfortable instead of stepping out of the hovel I've made for myself in life and doing what I haven't dared to do, and speaking when I have made myself err on the side of caution and kept my words and feelings to myself.

This is what happens when I try and program late into the night, logic leads way to philosophy and pragmatism melts into introversion.  At least let me say I envy the man who can claim to live without regrets, for he must be able to sleep much better than I, or he's a filthy liar but at least he exudes confidence, a point for him.


I guess while I'm here I should also update as to what I've done programming-wise, since this is the purpose of the blog, after all.

Part of the reason why I'm in the melancholy and reflective endless-loop mood is because today I spent far too much time trying to debug some of my old camera code, which I did not comment well and took me forever to add and extra feature.  It was something I had always planned on adding, camera rotation, but I had never gotten around to until David mentioned he would like to use such a feature in his up-and-coming project.  So I got it done.  There's still some stuff to iron out, but that's for tomorrow.  That and trying to finally get my stupid Kinect working with my computer.

Oh, technology.  I just couldn't have been an athlete, could I?
But then, I wouldn't be Kevin, I guess.




-Kev

Sunday, December 4, 2011

Re-do!

Taking more programming classes and learning from, you know, experts, professionals and people who have been doing this for many more years than I have is a good thing, but it has some nasty side effects.

E.G. growing sleazy mustaches

I'm starting to care about things such as efficiency and clarity, and other under-the-hood stuff that I never used to give two thoughts about.

So now that I'm home and I've finally had time to get back to some of my own projects, I'm abhorred by how sloppy my code has been and my driving desire is to make what I have work better.

The result?  Two days of coding delays while I try to merge my new fancy collision system with my old code.
BUILDING PUNCH
What I had been doing wasn't exactly terribly inefficient, per se, it took what needed to be compared and then did the comparisons, but it did so in no organized manner.  Random sections of code in different places all did collision checks by accessing high-level objects in a rather sloppy mess of referencing.  There was no centralized means of checking for these collisions.  Solution?
Pizza.

Well I ended up changing everything around.  I took the collision checking and abstracted it up one level.  What does that mean?  Well I have a super-class called Sprite Object that does most of the heavy lifting of my game objects.  But for the specific game objects I must derive them from the base sprite object, which is like saying a lion is in the cat family, but a member of the cat family is not necessarily a lion.  So instead of doing all of my collision checking in "lion" for all the rest of my objects, I do all of the checking in the "cat family"

That puts all of the collision checking in one place which keeps the checking all very, very simple.  Before, if I wanted to check collisions I was creating new methods in each derived class to do checking against all of the other, different derived classes from the main sprite object.  For a universal necessity I was writing different pieces of code across the spectrum, which makes a bit of sense because an object has to react differently to different collisions.

So I gave the sprite object class a special identifier that marks the object with a certain collision value.  And each object also gets a bitflag value defining which other objects it can collide with.  Once a collision is detected, each object that has a valid collision receives some collision information that stacks up with each overlapping collision.  Then the object, in it's own time, will go through that stack of collision information and decide what to do with each different collision.

This means that, yes, I am still writing code in each derived class for what happens when a collision is registered, but the actually checking for the collision still happens at the surface level without going too deep into the program.
Elephant-charge the cannon-tower!!
This post may be sloppy and hard to follow, but that is my own fault for trying to watch a Christmas movie with family and write at the same time.  I get too focused on one or the other.  But it's vacation, and vacation time must be enjoyed for all it's worth.

I now sit at at the precipice of a very deep and daunting canyon.  It's like the grand canyon, only larger, deeper, and I do not know what's at the bottom.  On the other side lies both what I most desire and fear: completion, finishing, the end, wholeness.



And a face full of FIEAH! (SSB, anyone?)

This may seem like a strange thing to be afraid of, but if you know me well enough you know that I'm prone to incompletion. (Which apparently is not a word recognized by Firefox's dictionary)  I am far from a perfect person, but one of my many faults is the failure to follow through.  I can't begin to list all of the half-finished things in my life.  A million projects, both solo and with friends that I had/still have great faith in and admiration and love for.  Books, games, animations, and even some music, though of all the gifts I've received in my personal life musical ability as I have come to find is most certainly not one of them.  Even simple things such as chores and relationships I will leave undone or put in effort only to eventually retract it.  Especially on the relationship aspect I feel particularly bad, I know a plethora of amazing people on this here chunk of floating space-rock and I feel I have not given enough to them as they deserve.

...but nobody came here to read about that. (..Or did you? How can I know, this is almost like writing a letter to somebody with no pens, paper, and no access to Office Depot?)  So what I wanted to get at was now I have a completely functioning piece of interactive media.  Everything works as I have designed it, now what is left is the small things, adding a Heads Up Display, a menu screen, a means of keeping track of score, adding in controller support, fixing small bugs and polishing the game to make it look better.  I'm the nerdy equivalent of the guy at the gym who lifts a whole bunch of barbells and has massive arms but still has a keg for a stomach because he doesn't want to change his diet or run.  I can jump into a project and do the heavy lifting and feel great when I get the core things finished, but when it comes to the small things they pile up and I feel as if I won't be able to complete all the small tasks, and I don't feel the same rewards as getting a whole system up and running as I do when I add in a HUD or menu screen.  My drive begins to huff and puff, I ran the sprint but making games (and almost everything in life) is won by marathoners, not sprinters.  Anyone can run fast for short distances, it's being able to go the long stretch that counts.  I get interested in other things,  I think of other projects, ideas, or I simply get bored.  There's a good quote (and of course I'm going to paraphrase and not remember who the quote is originally from...) that says (approximately) to never have reasonable goals, as long as you strive to be better than yourself, you will improve.

This, though, I wrote this, I can remember that much.

That must be taken with a grain of salt.  Keep in mind it's easy to distract, discourage, or defeat yourself.  Most of my battles aren't against the world, but are against my own "dark side" which sounds a lot more awesome than the lazy, insecure and instant-gratification-seeking side of myself.

Yeah, I'm done with all the soul searching, my bad.




-Kev
Think I already used this one; not sure, too many doodles cluttering up Blog Space