Invisible Progress, everybody!

Invisible progress you say?

Why, yes! I do say so!  How so? More image manipulation! Muwahahaha!

Not THAT kind of image manipulation...

I had big plans for today... Finishing my paper, getting my reading done, going to bed early and programming! And lo and behold, I've achieved all! ...except for getting to be early.

Drat.

Well I got my reading done, drafted out the paper and did some programming, but made no visible progress with the game.  Instead I fiddled around with image-linking.  What is image-linking you ask?

Excellent question.  I have no idea if this is a valid concept or just something that I've come up with out of necessity.  Either way, I hope image-linking has more applications that to just my current game!  What image-linking is, in the context of my programming, is connecting two separate images (and separate game objects, say a player and an enemy) together so that they move with the same velocity, and no matter when one image is changed or modified the same effect is applied to the second image.

What? (All rights reserved on this idea, btw)

What that means is I needed a method for images to move together, get offset together, rotate together and scale together.  How does one go about doing this?

Well I delved back into my SpriteObject class (which is a FRIGGIN MONSTER DUDE) which is the basis of all my drawn images in the game.  Each sprite object has a list ready to hold other sprite objects, this is the linked-list.  When I want, I can link two sprites together and then they are added to each others linked list.  This means I can add a whole Lotta sprites onto each other if I really want to (don't get me started on this, I don't even know what would happen... oh gosh)

But having sprites (or images, If I forgot to mention this I apologize: 2D images in games are known as "sprites") know about other sprites they have been linked too is not enough.  In each function I've created that modifies a sprite (every function that moves, displaces, rotates or scales an image) the function checks the list of linked sprites, and if another sprite is in the list it applies a similar change to that linked sprite.  The key here is each image uses the same functions, and if they both know of each other in their own, private lists then the functions would call it self infinite times, since each image would check it's own list to see if it was linked, and then make a change to the other image, which would check it's own list... and etc.)

The solution here is pretty simple, just include a replica function of each image-modifying function, give it another name (i.e. SetVelocity() becomes SetVelocityUnlinked()) that doesn't check the linked-list which prevents a programing-freezing infinite recursion loop.

TOO MANY STRANGE CONCEPTS!!

So that wasn't so hard, what took up most of my night tonight was just working with finding "equations" to adjust the offset.

...the offset?  Yes, the offset.  See, when I link images they don't have the same center.  For instance, say I have a little bug that lands on my player.  The bug's center is not equal to the player's center, so when I go to rotate the player... the player image rotates around the center, but if I just rotated the bug around IT'S center then they would both rotate independently and it wouldn't look like the bug was stuck on the player, it would just look stupid.  Or perhaps like they are both breakdancing independently.  Depends on how you look at it.

So first I needed to find the distance (think x and y, distance formula from HS, remember?  the square-root of blah-blah-blah? yeah, it comes in handy! imagine that) and translate the x and y co-ordinates (or the center) of that bug in relevance to the player.  So when I rotate the player, I needed a way to move the center of the bug as if the bug was stuck to the player.  And if I was to scale the bug and the player, I need to also scale the distance between the two to keep the distance between the two consistent.  If I didn't the player and the bug would both get smaller around their own centers, instead of both around the player's center.

I won't bore you with the particulars (Particularly because I'm not even entirely sure how I did it myself...) but that's what I've been working on!

Congrats, you've sat through another lengthy jargon-filled update!

Kudos to you, my friend!

Enjoy your reward!  I know, I know, it's not much.  But I'm effectively broke, so, yeah.

Good... morning!?!

Well, yeah I guess,
Good morning Internet!
I'm going to bed, busy/long day tomorrow.

-Kev