Ubuntu Repositories do suck!

So i just tried to link against lua5.2 with the QtCreator and... well lets just say it was true pain.

In the respositories there is a liblua5.2-dev version that seemingly provided all the needed headers but if linked at failed at finding even the lua.hpp. I still don't know why it didn't worked. But to fix it I had to uninstall my full lua installation and to compile and install the whole thing manually. At least lua came with a nice readme and fully preconfigured. So all one had to do was use 'make linux' and 'sudo make linux install'.

Also had an similar issue with the json spirit library where there was a whole header(!) missing in the Ubuntu repository. So in the installation was pretty much unusable. It's a shame because one easily looses track of what one does have installed, which version and so on. For the moment switched to the jansson library instead that seems to be working through the repositories.

At least a spark to not giving up on the whole thing...

Maybe I should start my own repository one day. God sooooo much stuff I need to do...

Git Useful Commands

This was very enlighting!

Stack Overflow: "git add -A", "git add ." & "git add -u"

Undeads do never die!

Hello World!

Back from a break that felt like a life time. Anyway rough time lays behind me for the moment and i finally got myself into my game project again.

Today and yesterdays work were a lot of debug feature that just display the bounding boxes (blue) of all sprites, there weight points (yellow dots - they are just the center of each sprite - no weight based on amount of opacue pixels or something like that so far), the weight point one get if all points are combined (yellow circle connected with to weight points via lines) and all anchor points that connect the individual sprites (red dots).

I also added a small lib of vector calculation i hoped SFML would already provide but no...

Anyway now i also got to implement the Graham Scan that builds me a convex hull from the weight points... Makes no sense? Yeah kinda. But i will be able to use that on any cloud of points to transform it into a convex polygon! Beside i kinda like the idea of having a collision area for missiles and such that is smaller then the object. Currently looks good on the walker... sadly a bit awkward on the player character.

The good part! I'm finally closer to having actually things in my world... that... that will be able to interact! Yea!

Next will be a very rough MUR Bounding Box and as said the first collision tests.

And after that... maybe first test together with terrain!

Also good a few more idea how to handle the terrain! =)

Hope i will have more result a lot sooner...

Byebye!

Branching with Mercurial (and comparison to Git)

I'm about to mess with the robbie GUI we are using for the roboCup and i'm kinda afraid it could disable my teammates so i was thinking about using a branch.

I never did something like that so far but stumbled over a pretty useful tutorial.[1] And it isn't limited to branching on Mercurial. No it also comes with a good comparison and visualisation of your repository!

I at least think that i pushes me a bit forward in understanding mecurial!

[1 - A guide to branching in mercurial]

Code diet

Source now a lot cleaner!

main.cpp lost at least 50% of it's source to other classes! The remaining code isn't run at all at the moment. So the main.cpp will be more then slim after i'm done with it.

It's just the start hook for the game.

Sadly still no fancy loading screen for you folks... i'm sorry. Need to do some graphics to work with first!

Also moved Call of the Sirens to bitbucket! 3 more coding projects i can assign to remaining... Let's hope for the best!

Arc.

Bones of "I"

As i was thinking about the loading screens i realized that i would like my stuff to be a lot more organized.

Currently it is a lot of stuff shoved into the main method and i really need to clean it up! I'm going to create different modules that control the visual environment.

It's a good thing to finally empty the main method and to clean it up.

The most basic stuff now stand in the Game class that allows access to the global game timer, width and height of the current window, mouse position and so on.

Modules and/or Interfaces as they are called currently are more specific and actually load and manage data. A lot of stuff again one can't really see.


Just another random link for you about writing your own particle system: 4 - Particle Systems

Nice Flames - Scaled Sprites making up Strokes

Mmmhh this looks pretty interessting... It's a good, easy and nice idea.

Finally something i can work on without feeling bad stucking at my terrain.

Endless changing terrain code...

Terrain is chaning again. Seems like i will go with something like a quad tree to organize my terrain and use sprites to represent it that get tinyer to the edges of the terrain.

First version looks like this:

Good thing is that i can scale it up with easy... and i like the style itself a lot more. Hope this finally get me going on "I" again.

Terrain breaks my mind...

Worked more on the terrain and tryed out the idea with tossing every single pixel on the texture to the GPU as a vertex...

First i had moderate FPS of 160 but no color information on them, so i looked up how SFML organizes it's stuff and made my terrain class extend the Drawable one.

I used the included Vertex class to generate my Colored Vertices... but it failed horrible. FPS dropped down to barely 60!!!

So I'm back to the old generation system.

I don't know it's not going into the direction i want it to be. The graphic style is too different from my other content and next try will be to convert the binary image to a hexagonal map that draws terrain sprites.

...

That should at least push the terrain in the right graphic style and maybe save me some performance...

I will also need to use the x,y coordinates as randomseeds for the used sprite... I'm kinda too spoiled by the MC Random class. It's so easy to use and so simple to get a random number in a given range... I wish that would be availible for C++ by default!

Tower is Power

Just build "I" on my tower and found out it runs at about 160 fps without any problems.

I was thinking about using a different approach on the terrain but under that circumstances i will maybe leave it that way.

One approach would been to use marching squares for the terrain.

The other one would been to just draw a cloud of 1 pixel vertices where i need them.

Not sure if either of those approaches will work a lot better but they would save me at least from swapping the texture to the GPU each single frame.

Fixed Bugs and CleanUp2013

Hello everyone!

Sleepy... zZzZz

I know this week was rather eventless... but i finally got my mind up and running again! And by that i was able to fix the weird terrain generation error i was messing around with earlier.

Hanging on the invisible wall.

Beside that i mold all the "fake model"s into real ones and clean up a few methodes in the Model.cpp. The only thing that borders me about the current state of the model class is that i got type the name of a given ModelPart too often. I should probably modify how Hooks work or should add some intelligent search before adding a part to the full model.

To show you something funny i present you the updated character model! (Now with two arms and legs!)

*head scratch* "Is this a good idea?"

 Also i got to practive a little more on git. I merged the first time successfully and fixed the name of my branch which was "HEAD". Seems to be a stupid beginner mistake...

By that i wish you all a very good night! Sleep well little critters and enjoy the amazing terrain that uses a texture now!

Future plans are the implementation of a collision class and entities that will take care of stuff like taking damage, collision checks, moving around... health... and other useless stuff. In the end everything that has to do with a living thingy.

See ya. -Arc.

Textured Terrain

So here i am again!

I rearranged some stuff in the terrain class and split it up into a binary image, a normal image containing the texture for the terrain and a third one that is the merged result of the two others.

Sadly restructuring broke the generation of terrain and i only got the simplest methods working so far but the more difficult ones fail currently...

On the upside it doesn't seem to take up more power then before and by that runs pretty well. I hope i can get you a nice picture of it soon as it looks so much better with texture!

Also it will allow us to turn off the texture if needed or to merge with another one easily if we want to!

I will also expose some terrain generation variables to the framework so we will be able to modify the shape of the generated terrain on the fly!

Stay awake all night! -Arc.

Dark is the night...

I'm sorry!

Yes i realize that i haven't posted anything yesterday but i just didn't got to something. I just got home and i'm feeling pretty tired...

I guess the only things i can tell you about is that Enie is probably going to make some glow and darkness shaders for "I" while i will keep on doing terrain and collision.

I'm already pretty happy how terrain generation turned out... the only bad thing is it's size so far. I hope i can experiment with scaling it up a little bit and with exporting it to a binary image and merging it with a texture.

I also hope we can drop RapidXML anytime soon as it raises a good bunch of warning for my IDE and even Errors for Enie. Beside that it doesn't supports any way of type converting by itself and is probably too fast to be really useful... for me at least. As those model and animationSet loading will only be one time calculations per startup of the whole game it would be worth to drop some speed for comfort!

Speaking of comfort those pillows look pretty soft.

I will write more when the sun sets. -Arc.

Segment Fault!

Was continuing on my terrain generation today and it kept crashing a lot more often...

...i took that opportunity to hunt it down with gdb but weren't able to locate the error inside my code. But at least it hinted me a method were the error occured.

Normally i was writing some color values in the sf::Image i had there so i commented it out and discovered some weird blue and green pixels that shouldn't be there as the image was initialised fully transparent.

I changed the initial color to solid blue and watched my image.... it turned out that only 1/2 of the image were actually blue! Now i init the image with double the size and haven't run into another segment fault so far. I hope i get one of the developers of SFML on there IRC. It looks like a serious issue! If already an image of a size 30x30 has such issues i don't want to know what my 1024x1024 terrain image is currently doing!

Current status of the terrain generation.

Back to terrain i got with erosion something that almost looks like it could become terrain. Sadly the scale is a kinda to tiny for a character to wander through. Maybe i'm going to scale and blurr it up or i will need to improve the algorithm a lot more to handle terrain of bigger size!

I guess thats it already... i was going to tell you a lot about biologic neural networks compared to simulated ones... but it seems kinda off topic and now i already got enough to show you. So it will have to wait until i run out of stuff to tell or you asking me directly.

Cheers! - Arc.

P.S: Okay! I'm sorry guys! Indeed i was being pretty dumb and childish there! SFML is working all right! It was me making the mistake there. I just forgot to reset the j counter for every i.... So yes SFML is still save to work with!

Hope i wasn't too rude.

Fatality!

So today is/was friday! - That means it is a free day!

By that i done nothing beside chilling around and playing video games... well okay...

Yes i did something because i just can't leave my fingers off my project.

Island of terrain in the ocean of noise.

Well the terrain made some progress. It is now of infinite size (which means you can go as long in any direction as you want...) and the noise now grows into more terrain shaped forms.

It's not really melting into those and it just generates a huge blob in the middle of a ocean of noise - if you stand still, else you are getting a nice white snake like.. thingy. But that will change soon! I already have my stumbs for the other needed methods ready!

And now about the bad news....

...well there is seems to be an error with freeing an variable that is still in use i can't backtrack so far. It crashed my game a few times already, but every time i try to hunt it down with gdb it doesn't occures anymore! I will ready through the code a few more times tomorrow and how i will find it there.

It's a pretty heavy one crashing the whole application so yeah... pretty important to be fixed.

Wish me luck with it! - Arc.

"I" of Sauron

Greetings everyone!

The power supply of my laptop broke today but who would i be if i wouldn't be able to fix it?! Exactly.

So here i am with a now even better working power supply. (It was nothing too serious just a broken cable...)

Today i learned... mmhhh... well i got a little better with my qtCreator. Found out why a build directory wasn't working anymore and were able to fix it.

But now lets focus on "I"!

Sadly it was a pretty busy day... but still i got to do a few more terrain experiments and in my last build today i got 80-100 fps! I think i'm on the right way there.

I started out with a different manipulation as i avoided manipulating every single pixel of the whole image each frame and just drawn a few dots of random size on the image.

That rewarded me with a similar effect to the noise already but also got me bigger "chunks" of material. Actually a lot better base then merging single pixels into terrain!

Halos of might around the "I" of Sauron

After that i started generating them in a circle, but sadly i was to focused on it to take a screenshot! When i experimented with random arcs and lengths to generate my x and y coordinates for the drawCircle method... my mind started drifting away a bit.

Doesn't it look like the eye of Sauron?!

Seems like i accidently brought Mordor into my game...

Next step was moving the terrain around while keeping the drawCircle method based on the center of the screen. I think the result isn't too far away from what i want!

Fixed int iterations to random floats!

Hope i can merge some those small random chunks into bigger ones tomorrow!


Cheers, -Arc.

Snow flake white terrain noise in all it's beauty!

Tiny bits on a lot of ends...

It's disappointing... but maybe i shouldn't be to hard with myself there.

The more i think about it the more it feels like it wasn't that few i done.

First i fiddled around with git a little more and found out that it isn't too similar to mercurial. I was used that a simple "hg commit -m <insert message here>" would add all changes done to the files in my local copy to the commit and by that make them ready to be pushed... well git works a little different. One has to add all changed files first before creating a commit.
I'm not yet sure if this is an upside or a downside compared to mercurial. At least one is able to watch at all changed files via "git status -u".

And while i was searching through the net for help i stumbled over a very nice summary of the most useful git commands on siteground.

The second thing i was messing around with was the exporting of model XML were i run into a very odd error that made all output floats equal. Pretty sure it has to do with some weird pointers.

Indefinitly changing noise based on distance to center.

After leaving that topic out of frustration i worked a little further on the terrain generation and got a solid noise that gets denser the further it is away of the center. You can watch at the result to the right.

But just when i finished it (and seen that the performance was still bad) i realised that the whole thing i done was wrong! All i need is adding and subtracting a few small circle shaped dots - in an amount of maybe 30 or so per frame with a weighted chance of occurany based on the distance to the center. By that i should already get constantly shifting terrain without the need to change all pixels of the image! Well i will let you know if it turned out better or worse...

And finally i created a new cover that fits the format of a screen and animated it a little bit. Pretty sure it's going to make up a nice main menu background!

Good night, - Arc.

Git-Repository

"I" is now on a git repository!

You may wonder why this is amazing news for a one person project... (beside I'm not so sure if it will stay to be one...).

Just yesterday when i was taking a bus ride and thinking of nothing bad the belt of my laptop bag broke (again) and the edge of the whole thing hit the floor before i was able to grab it.
Lucky no harm was brought to it but it alarmed me about the fact that i don't have a backup of my project so far!

At the evening of the same day +Enie Weiß hinted me that Bitbucket is a great thing to create a git repository for small projects.

I was a little worried first as i never used git before... and we only used mecurial and svn at the university so far. But everything turned out well and my source code is now backed up. Also all the commands for git look pretty similar to the ones for mercurial.

So yeah that should be enough about git so far...

I also got to do some first test on the terrain, sadly it seems that already a constant shifting salt and pepper noise on a 1024*1024 picture is bringing down the fps from 200 to an average of 10!

I hope i can get a lot more performance out of it if i limit the noise to the other border of the terrain as that will be the only area that will be shifting indefinitely. It was planned that the very edge of the terrain will be noise that will create more or less organic shapes as the player approaches via image processing filters like opening and closing which a usually used on binary images.

Well we will see what i can do. Sad thing is that i can't access the image directly as it lifes on the graphic card and i need to copy it every time over from the cpu to the graphic card... maybe fixing this will also boost the fps by a good bit.

Mmhh... That should it be for the day!

Until time, - Arc.

Animations - 2 & Further plans.

There we go!

Fixed a few more bugs, so animations interpolate right now. I stumbled over a few more issue when i edited the walk animation of my walker but finally it is working.

You can look at the result at the right.

It turned out pretty nice and i think i can finally move to the next part of my project what will either be generation of terrain or collision between entities and other things...

The more visual parts of glow and light will be something for later... even if i would like them to be realized. Maybe i will work on them if i need something that gives me a nice visual effect in a very short period of time.

About the animation part... I'm a little sad about the way my animations work at the moment and i would have prefered a rather organic way to do it, but it just got too messy when i started working on it. What i dreamed of was a system that would blend from any pose into another without any problems and that only trys to approach a given pose as close as possible based on the environment.

Well that dream is not dead yet but i feel like i focused too much on animations already and i really need to get some progress on some of the other parts of the game! I mean... there is no surface or terrain yet one can walk on!

A good while ago i had a few tries of generate polygons that would make a nice terrain but my first generation tries weren't any pleasing. Beside that it had too sharp edges and didn't come with a resolution close to what i wanted to work with.

The terrain in "I" will be a very dynamic part of the game as it will only have a clear shape while it is inside the sight-range of the player.. everything outside lying in the dark area of the game will be a neverending changing area that freezes into a clear shape as the player approaches.

I was talking with a good friend a while ago how to do that best and she came up with using an image for that purpose and i loved that idea! Only sad thing about that is that SFML only supports RGB images but that won't slow me down too far. I can't wait to get my hands on it.

Another bad thing is that i need to get a good bunch of other things done before the month ends... but i still hope i can show off some prototypes soon!

With all that said it is "until time" again.

So long, -Arc.

Animations

I was struggeling with animations and animation blending for days and was finally able to get all those ease types to work.

That reminded me that one should already test pretty small parts of code intensive. Most animation buys should be fixed now and there should only be one remaining that occures on some rather normal timings for keys of an animation. Currently any set of a key at 2500 and 5000 in a animation that lasts 5000 milliseconds works all good. Not sure why the same animation with keys on 1250 and 3750 works out... pretty odd.

But it doesn't seem to be a issue of the ease functions themself!

On the upside of all those problems i were able to include an update functions that allows me to reload an animation XML on a simple push of a key. So i'm pretty close to the animation editor i was going to develop for my characters. I hope i will be able to post you my first animated results later this day or the next...

Meanwhile you can look at the the structure of my AnimationSet Xml's here if you missed it on my google+. I was also able to fix a few errors on it. As "0" is currently a forbidden value for Key values.

See ya later! - Arc.