I just wanted to say that I changed my blog. I won't be posting here anymore, I'll be doing it at
Well that's all! I also changed my Twitter to @posva
Jul 10, 2013
May 27, 2013
Catimg
Hello again! I have really been busy for the past few months and couldn't work on Kill da Ducks too much but I guess I'll be able to very soon.
Other than that I have been working on little projects that doesn't take too much time and I should have written something when I did them but I didn't... So now as it's too late I'll be speaking about my last little project: catimg
Some of you may know the command line "cat" to print files into the standard input. Well catimg also print files but it actually print pictures. Sounds funny right? Here is a little screenshot:
That's actually a console and as you can see I'm printing a Mario picture.
You may be asking yourself why would I code such a stupid thing. Well actually it's just for the fun but I'm pretty proud of the result as it's quite beatifull.
How it works:
In order to make this work I needed to use a 256 colors shell. Well I already have one as I use zsh and love to have colors everywhere cause it makes my life happier :). Then I needed to read the pixels from an picture and I knew I was going to use convert (ImageMagick). The problem was "How do transform the picture to fit the terminal colors?". Searching a bit on the internet I found an option called remap. This option takes a picture and convert another picture to fit the pallette of the given remap picture. So I took this website: http://www.calmar.ws/vim/256-xterm-24bit-rgb-color-chart.html to pick up the colors. The problem was that the text was creating residual colors and I needed to kick them out. I saved the webpage and modified the code source with many sed in vim to get a nicely drawn pallette with no text:
Finally I just removed a black space to create the alpha0 color aka transparence. Then I copied the codes on vim and parsed them to get them nicely listed as below:
Then I just needed to adapt the size of the picture to the console size using tput cols. I used double spaces to make image aspect ratio looks better... and voilà! Some grep to seek the code 1..256 corresponding to each color and print them with echo and some colors escapes characters!
The only thing I don't like is how slow it is but I cannot find what to do in order to improve it other than using a programming language to seek the color code (using a hashing table would be so faster....)
For those who would like to use it, you can get the code at GitHub.
Have a nice day!
Other than that I have been working on little projects that doesn't take too much time and I should have written something when I did them but I didn't... So now as it's too late I'll be speaking about my last little project: catimg
Some of you may know the command line "cat" to print files into the standard input. Well catimg also print files but it actually print pictures. Sounds funny right? Here is a little screenshot:
That's actually a console and as you can see I'm printing a Mario picture.
You may be asking yourself why would I code such a stupid thing. Well actually it's just for the fun but I'm pretty proud of the result as it's quite beatifull.
How it works:
In order to make this work I needed to use a 256 colors shell. Well I already have one as I use zsh and love to have colors everywhere cause it makes my life happier :). Then I needed to read the pixels from an picture and I knew I was going to use convert (ImageMagick). The problem was "How do transform the picture to fit the terminal colors?". Searching a bit on the internet I found an option called remap. This option takes a picture and convert another picture to fit the pallette of the given remap picture. So I took this website: http://www.calmar.ws/vim/256-xterm-24bit-rgb-color-chart.html to pick up the colors. The problem was that the text was creating residual colors and I needed to kick them out. I saved the webpage and modified the code source with many sed in vim to get a nicely drawn pallette with no text:
Finally I just removed a black space to create the alpha0 color aka transparence. Then I copied the codes on vim and parsed them to get them nicely listed as below:
#000000Actually I needed to make some modifications because two of the codes were wrong.
#800000
#008000
#808000
#000080
#800080
#008080
#C0C0C0
#808080
#FF0000
#00FF00
#FFFF00
#0000FF
#FF00FF
#00FFFF
#FFFFFF
#000000
#00005F
#000087
#0000AF
#0000D7
#0000FF
#005F00
#005F5F
#005F87
#005FAF
#005FD7
#005FFF
#008700
#00875F
#008787
#0087AF
#0087D7
#0087FF
#00AF00
#00AF5F
#00AF87
#00AFAF
#00AFD7
#00AFFF
#00D700
#00D75F
#00D787
#00D7AF
#00D7D7
#00D7FF
#00FF00
#00FF5F
#00FF87
#00FFAF
#00FFD7
#00FFFF
#5F0000
#5F005F
#5F0087
#5F00AF
#5F00D7
#5F00FF
#5F5F00
#5F5F5F
#5F5F87
#5F5FAF
#5F5FD7
#5F5FFF
#5F8700
#5F875F
#5F8787
#5F87AF
#5F87D7
#5F87FF
#5FAF00
#5FAF5F
#5FAF87
#5FAFAF
#5FAFD7
#5FAFFF
#5FD700
#5FD75F
#5FD787
#5FD7AF
#5FD7D7
#5FD7FF
#5FFF00
#5FFF5F
#5FFF87
#5FFFAF
#5FFFD7
#5FFFFF
#870000
#87005F
#870087
#8700AF
#8700D7
#8700FF
#875F00
#875F5F
#875F87
#875FAF
#875FD7
#875FFF
#878700
#87875F
#878787
#8787AF
#8787D7
#8787FF
#87AF00
#87AF5F
#87AF87
#87AFAF
#87AFD7
#87AFFF
#87D700
#87D75F
#87D787
#87D7AF
#87D7D7
#87D7FF
#87FF00
#87FF5F
#87FF87
#87FFAF
#87FFD7
#87FFFF
#AF0000
#AF005F
#AF0087
#AF00AF
#AF00D7
#AF00FF
#AF5F00
#AF5F5F
#AF5F87
#AF5FAF
#AF5FD7
#AF5FFF
#AF8700
#AF875F
#AF8787
#AF87AF
#AF87D7
#AF87FF
#AFAF00
#AFAF5F
#AFAF87
#AFAFAF
#AFAFD7
#AFAFFF
#AFD700
#AFD75F
#AFD787
#AFD7AF
#AFD7D7
#AFD7FF
#AFFF00
#AFFF5F
#AFFF87
#AFFFAF
#AFFFD7
#AFFFFF
#D70000
#D7005F
#D70087
#D700AF
#D700D7
#D700FF
#D75F00
#D75F5F
#D75F87
#D75FAF
#D75FD7
#D75FFF
#D78700
#D7875F
#D78787
#D787AF
#D787D7
#D787FF
#D7AF00
#D7AF5F
#D7AF87
#D7AFAF
#D7AFD7
#D7AFFF
#D7D700
#D7D75F
#D7D787
#D7D7AF
#D7D7D7
#D7D7FF
#D7FF00
#D7FF5F
#D7FF87
#D7FFAF
#D7FFD7
#D7FFFF
#FF0000
#FF005F
#FF0087
#FF00AF
#FF00D7
#FF00FF
#FF5F00
#FF5F5F
#FF5F87
#FF5FAF
#FF5FD7
#FF5FFF
#FF8700
#FF875F
#FF8787
#FF87AF
#FF87D7
#FF87FF
#FFAF00
#FFAF5F
#FFAF87
#FFAFAF
#FFAFD7
#FFAFFF
#FFD700
#FFD75F
#FFD787
#FFD7AF
#FFD7D7
#FFD7FF
#FFFF00
#FFFF5F
#FFFF87
#FFFFAF
#FFFFD7
#FFFFFF
#080808
#121212
#1C1C1C
#262626
#303030
#3A3A3A
#444444
#4E4E4E
#585858
#626262
#666666
#767676
#808080
#8A8A8A
#949494
#9E9E9E
#A8A8A8
#B2B2B2
#BCBCBC
#C6C6C6
#D0D0D0
#DADADA
#E4E4E4
#EEEEEE
Then I just needed to adapt the size of the picture to the console size using tput cols. I used double spaces to make image aspect ratio looks better... and voilà! Some grep to seek the code 1..256 corresponding to each color and print them with echo and some colors escapes characters!
The only thing I don't like is how slow it is but I cannot find what to do in order to improve it other than using a programming language to seek the color code (using a hashing table would be so faster....)
For those who would like to use it, you can get the code at GitHub.
Have a nice day!
Oct 21, 2012
Game Engine, Lua, Box2D and other things
Hi there, it have been a long time, I apologize...
Well as You can imagine the game engine progressed a lot, well YOU'RE WRONG! I started it over again (this is the last time, I promise) and I did it like pi times better! I rewrote how the depth is handled, added Lua support and added Box2D for physics and better collisions.
But before talking about the new engine I need to say that someone joined the team, even is he's not always active :P, he participates in the game design, the programming and ideas. He's named Senryoku over the net, here is his GitHub page.
I talked about Lua, well, he was the one who introduced the idea in the game, we talked about it and decided that adding an interpreted language to the game would make it easily expansible allowing for example to create dynamic levels or even to create your own enemies, weapons or objects, and this is quite exciting because we want to provide a big amount of functions and classes to let Lua get acces to everything someone will need to make a custom story. Yes, I picked that name from Amnesia, it's almost the same concept but even more customizable, we will allow you to prevent the player from playing and moving thing around, adding text, creating bodies, trigger functions to make things happens under some conditions etc. And that simply mean AWESOMENESS TO THE MAX!
I also implemented Box2D as the physics and collision engine for the game. I'm currently wrapping code to allow Lua to create joints between bodies. It's not difficult but it takes time to warp correctly because I have to test everything and well, I also have fun doing senseless things that move, destructibles joints, etc.
I already implemented the particles to Lua, meaning that you can create any kind of particles and particle modifiers (emitters, destructors, attractors). I may create more things to add more fun and customization but with these tools you can already create complex effects. The things runs quite smooth at the moment, even with large amount of particules but they're not thought to be use a lot so you wouldn't be able to have more than 2000 of particle, I may optimise this later using a direct OpenGL drawing instead of using my own Sprite class based on SFML (which relies on OpenGL but it's not the same ^^) What's interesting about these particles is that they are actually textured and well that obviously makes it
slower...
The particles and the bodies are created through Lua code like that:
This will create a simple dynamic Circle. The particles code is a bit more complicated because it involves attractors and emitters ^^.
As you can see there is nothing specific to KDD for the moment, that's the purpose, an engine optimized for games like KDD that will allow to develop other games in the same style. And well that will be all for the moment! I'll try to write more often from now on!
Well as You can imagine the game engine progressed a lot, well YOU'RE WRONG! I started it over again (this is the last time, I promise) and I did it like pi times better! I rewrote how the depth is handled, added Lua support and added Box2D for physics and better collisions.
But before talking about the new engine I need to say that someone joined the team, even is he's not always active :P, he participates in the game design, the programming and ideas. He's named Senryoku over the net, here is his GitHub page.
I talked about Lua, well, he was the one who introduced the idea in the game, we talked about it and decided that adding an interpreted language to the game would make it easily expansible allowing for example to create dynamic levels or even to create your own enemies, weapons or objects, and this is quite exciting because we want to provide a big amount of functions and classes to let Lua get acces to everything someone will need to make a custom story. Yes, I picked that name from Amnesia, it's almost the same concept but even more customizable, we will allow you to prevent the player from playing and moving thing around, adding text, creating bodies, trigger functions to make things happens under some conditions etc. And that simply mean AWESOMENESS TO THE MAX!
I also implemented Box2D as the physics and collision engine for the game. I'm currently wrapping code to allow Lua to create joints between bodies. It's not difficult but it takes time to warp correctly because I have to test everything and well, I also have fun doing senseless things that move, destructibles joints, etc.
I already implemented the particles to Lua, meaning that you can create any kind of particles and particle modifiers (emitters, destructors, attractors). I may create more things to add more fun and customization but with these tools you can already create complex effects. The things runs quite smooth at the moment, even with large amount of particules but they're not thought to be use a lot so you wouldn't be able to have more than 2000 of particle, I may optimise this later using a direct OpenGL drawing instead of using my own Sprite class based on SFML (which relies on OpenGL but it's not the same ^^) What's interesting about these particles is that they are actually textured and well that obviously makes it
slower...
The particles and the bodies are created through Lua code like that:
w = 15
h = 25 body = Body:new(x, y)
body:setAsCircle(w, dynamicBody);
body:setTexture("mini");
body:setAnimation("s_box.png");
body:setSpriteScale(w/4, w/4);
body:setSpriteOrigin(4, 4);
This will create a simple dynamic Circle. The particles code is a bit more complicated because it involves attractors and emitters ^^.
As you can see there is nothing specific to KDD for the moment, that's the purpose, an engine optimized for games like KDD that will allow to develop other games in the same style. And well that will be all for the moment! I'll try to write more often from now on!
Jun 9, 2012
Jump'n'Run
What's up!? It has benn a while since my last post, but I'm still here, and I'm still programming!
I really had no time to work on Kill da Ducks as I was working on a University project with a friend. We put a lot of effort on it and did new things we never did before like physics (realistic one) behaviour.
We used the verlet integration to solve vertex movement and using rigid and elastic (more like springs) constraints we were able to create polygons. The using the SAT theorem we detected collisions and finally using some more complex formulas I don't know we implemented the collisions behaviours. Then we implemented a grid to minimize collisions detections and optimize the whole thing. Benchmarks were really nice. Alowing us to create very big worlds with more than 200 dynamic boxes and running at 60+ fps
We then created a Level Editor that allowed us to place vertex, polygons and constraints and then save them and load them too. We needed that in order to create levels for our game. We then started with the player and the GUI for the editor.
We wanted to implement a realistic behaviour on our player but we realized that it was way more difficult that I thought and that we were not in time to do such a thing so we kept things simple and created a Box for the player. Changing the mass and teh size of the base we created some kind of stable player. We tried lot of things before that, there were all more difficult, using constraint to make the player stand-up but then the physics behaviour was incorrect. In fact we wanted to still have the world have an impact on the player, in order to make gameplay more difficult than just being a physics actor that cannot be pushed by other bodies.
In order to have an animated player we introduced a simple Animation based on angles or position to determine the different body parts positions (Neck, arms etc)
After lots of test and hours of work, we came up with something playable. And I must say the result was really nice, not only graphically but also because the game offered a gameplay that could be way simple or ultra hard. All of this depends on the level, and this allow people to create easy levels or really hard levels only playables by people who have mastered the player controls.
The Final result is that:
This level is hard for example. It may look simple but it's not.
Finnally I will say that you can go and take a look at the code and even compile it by yourself. All the dependecies are explicitily mentioned on the page and a Makefile is provided to have an easy compilation.
http://code.google.com/p/jump-n-run/
I really had no time to work on Kill da Ducks as I was working on a University project with a friend. We put a lot of effort on it and did new things we never did before like physics (realistic one) behaviour.
We used the verlet integration to solve vertex movement and using rigid and elastic (more like springs) constraints we were able to create polygons. The using the SAT theorem we detected collisions and finally using some more complex formulas I don't know we implemented the collisions behaviours. Then we implemented a grid to minimize collisions detections and optimize the whole thing. Benchmarks were really nice. Alowing us to create very big worlds with more than 200 dynamic boxes and running at 60+ fps
We then created a Level Editor that allowed us to place vertex, polygons and constraints and then save them and load them too. We needed that in order to create levels for our game. We then started with the player and the GUI for the editor.
We wanted to implement a realistic behaviour on our player but we realized that it was way more difficult that I thought and that we were not in time to do such a thing so we kept things simple and created a Box for the player. Changing the mass and teh size of the base we created some kind of stable player. We tried lot of things before that, there were all more difficult, using constraint to make the player stand-up but then the physics behaviour was incorrect. In fact we wanted to still have the world have an impact on the player, in order to make gameplay more difficult than just being a physics actor that cannot be pushed by other bodies.
In order to have an animated player we introduced a simple Animation based on angles or position to determine the different body parts positions (Neck, arms etc)
After lots of test and hours of work, we came up with something playable. And I must say the result was really nice, not only graphically but also because the game offered a gameplay that could be way simple or ultra hard. All of this depends on the level, and this allow people to create easy levels or really hard levels only playables by people who have mastered the player controls.
The Final result is that:
This level is hard for example. It may look simple but it's not.
Finnally I will say that you can go and take a look at the code and even compile it by yourself. All the dependecies are explicitily mentioned on the page and a Makefile is provided to have an easy compilation.
http://code.google.com/p/jump-n-run/
Mar 3, 2012
Some Verlet
Working with my friend in the game engine I talked last post, we got something really nice and fun using Verlet integration. He wrote that part of the code and I added the display with OpenGL, I also created a cloth using constarint and mapped a texture on it.
The game engine is going well, even if we already have a working collision system and some basics physics that only works with AABB (non rotaed rectangles), integrating something better could be cool. Weeks ago I implemented a SAT collision detection that allow to detect collision between any polygons in a fast and easy way. Yesterday, my friend implemented the SAT with verlet, having some kind of simple physic engine (which is pretty fast too!). There are still some corrections to do but work is going very well!
Here I let you a video showing the clothes in action:
The game engine is going well, even if we already have a working collision system and some basics physics that only works with AABB (non rotaed rectangles), integrating something better could be cool. Weeks ago I implemented a SAT collision detection that allow to detect collision between any polygons in a fast and easy way. Yesterday, my friend implemented the SAT with verlet, having some kind of simple physic engine (which is pretty fast too!). There are still some corrections to do but work is going very well!
Here I let you a video showing the clothes in action:
