Monday, May 23, 2011
Addiction 2.0
Can't post...Must...play...Terraria...such a....great...gaaaammmeeeee aHAHHHAAAA
Tuesday, May 3, 2011
Thoughts about 2D animations.
I know that I shouldn't think of such things like animation systems (considering that I'll write my final exam tomorrow) but it's just something that got to my mind yesterday while I was falling asleep.
Actually I'm using a fairly simple approach for animations.
To create a animated graphic in my engine you got to use the following syntax (The parameters should be self explanatory):
When the graphic gets drawn, only the current animationframe will get drawn.
Example:

This System works great for a normal walkcycle like this, but if you have an animation like this:

The system isn't the best solution.
The reason for that is the bounding box (bounding boxes are used for collision detection and are almost always as big as the animation frame) of each animation frame. In the walkcycle example the size of each frame never changes (its always 24x32), but if you see at the second example, especially this frame:

you'll might notice that this frame (109x49) is way bigger than the other frames (62x44 and 80x44).
If the above mentioned system is used, the bounding box of each frame is equally to the bounding box of the biggest frame. (I hope you get what I'm trying to say)
This is a big disadvantage IMHO because if a bounding box collision is detected, the collision system goes into pixel perfect collision deteciton (at least in my engine), which is way more expensive than the bounding box collision.
To avoid this problem I thought of the following approach.
At the point where the user determines the amount of animation frames, the size of each animation frame is known. (Width of the graphic / amount of animation frames = size of the biggest animation frame).
The next step would be to check each pixel of each animation frame for its color value to determine the real bounding box of each animation frame by comparing the color value of the current pixel with the color value of the images color key (The color key is the color in the image that is invisible later in the actual game).
After that step, each animation frame can be packed into an array, so you get a nice animation with perfectly fitting bounding boxes for each frame :)
Actually I'm using a fairly simple approach for animations.
To create a animated graphic in my engine you got to use the following syntax (The parameters should be self explanatory):
GraphicsFactory::createAnimatedGraphic(Uint32 animationStepTimeInMilliseconds,Uint8 animationSteps,bool autostart)
After you created the object you can add a graphic to it via: animatedGraphicObject.loadGraphic("graphic.png");
(I know its a strange way, but I'll stick with this for now)When the graphic gets drawn, only the current animationframe will get drawn.
Example:

This System works great for a normal walkcycle like this, but if you have an animation like this:

The system isn't the best solution.
The reason for that is the bounding box (bounding boxes are used for collision detection and are almost always as big as the animation frame) of each animation frame. In the walkcycle example the size of each frame never changes (its always 24x32), but if you see at the second example, especially this frame:

you'll might notice that this frame (109x49) is way bigger than the other frames (62x44 and 80x44).
If the above mentioned system is used, the bounding box of each frame is equally to the bounding box of the biggest frame. (I hope you get what I'm trying to say)
This is a big disadvantage IMHO because if a bounding box collision is detected, the collision system goes into pixel perfect collision deteciton (at least in my engine), which is way more expensive than the bounding box collision.
To avoid this problem I thought of the following approach.
At the point where the user determines the amount of animation frames, the size of each animation frame is known. (Width of the graphic / amount of animation frames = size of the biggest animation frame).
The next step would be to check each pixel of each animation frame for its color value to determine the real bounding box of each animation frame by comparing the color value of the current pixel with the color value of the images color key (The color key is the color in the image that is invisible later in the actual game).
After that step, each animation frame can be packed into an array, so you get a nice animation with perfectly fitting bounding boxes for each frame :)
Sunday, April 17, 2011
Facepalm
Sunday, March 27, 2011
Graphic creation technique finished!
The content of this video is just me testing the AbstractAnimatedGraphic class.
The graphicfile used for this animation is the following:

The animation is just yoshi, turning around his own axis.
In the video you can see that it is possible to regulate the animationspeed by
key pressing (well you can't see the actual key press).
This feature could be used for fancy slow-motion effects ;)
I also just finished the graphic creation factory.
My engine will support 2 different graphic modes.
- Pure SDL (DirectDraw under Windows)
- OpenGL
the engine will check specific configuration flags (which you can change on runtime)
to determine the derived type of the returned AbstractGraphic object (AbstractGraphic is the class that SDLObject and OpenGLObject inherit from).All created graphicObjects are saved to an list to support easy conversion on the fly if the user wants to switch the graphics mode during gameplay.
It's time to sleep now.
I had to work the whole weekend and didn't got much sleep.
Labels:
2D Engine,
2D Graphic,
Game,
Game Engine,
Graphic,
OpenGL,
SDL
Thursday, March 24, 2011
Character designer ready!
Sunday, March 20, 2011
Rendering of levels complete!
Wednesday, March 16, 2011
Qt Base64 encoding in non Qt application
Hello internet!
Today I'd like to share my experience with you I made today while trying to
decode an Base64 encoded (via Qt) string in a application that does not use Qt (and so does not use Qt for Base64 decoding).
After trying 3 Base64 libraries I though that I have to write the Base64 decoding on my own. Fortunately I found this library a few minutes ago.
Turns out that this library is capable of decoding Base64 string which were created with the Qt Base64 encoding function.
Today I'd like to share my experience with you I made today while trying to
decode an Base64 encoded (via Qt) string in a application that does not use Qt (and so does not use Qt for Base64 decoding).
After trying 3 Base64 libraries I though that I have to write the Base64 decoding on my own. Fortunately I found this library a few minutes ago.
Turns out that this library is capable of decoding Base64 string which were created with the Qt Base64 encoding function.
Subscribe to:
Posts (Atom)


