61
SFML projects / Re: InDee Toons - Animated Game Characters
« on: April 02, 2014, 11:08:07 pm »
Here is another image, with the mouth even smaller and less make-up.
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
62
SFML projects / Re: InDee Toons - Animated Game Characters
« on: April 02, 2014, 11:00:33 pm »
Hi,
I think it's the jaw
(and the mouth). In the following image, I moved the jaw up and made the mouth smaller as a result of the copy/paste operation. I fixed the seems a bit, and I think it looks much more friendly now.
I am not an artist, so take it or leave it
I think it's the jaw
(and the mouth). In the following image, I moved the jaw up and made the mouth smaller as a result of the copy/paste operation. I fixed the seems a bit, and I think it looks much more friendly now.I am not an artist, so take it or leave it
63
SFML projects / Re: 3DEE
« on: April 02, 2014, 04:41:07 pm »
Looks really nice! A clean interface, as always 
That said, I do see a few problems with this. I am a "Use OpenGL directly" type of guy, mostly because I try to stay on top of the latest and greatest OpenGL features, so it is quite possible that these criticisms do not apply since it is not what the library is trying to achieve. So, please take this with a grain of salt.
The idea of providing an interface as opposed to an engine is cool, but it is really hard to do for something with a scope like OpenGL has. OpenGL's API is probably as simple as it can get FOR C (DirectX has objects, making it a much nicer to use library )
I do not see how one can maintain the design philosophy of SFML for 3D. SFML's graphics API is great for 2D, but the same design doesn't really translate into 3D IMO. Its going to be really hard to do something like deferred shading in your current setup, since it modifies the entire pipeline to be "Not SFML-style". In deferred shading, all rendered things must have a uniform interface for materials, for instance. Also, you cannot simply add features to a deferred shading pipeline without changing the entire pipleline.
Also, I am sure you are aware of this, but pretty much everything you wrote in OpenGL is highly deprecated.
These criticisms may be wrong, they may be stupid, I need more coffee
That said, I do see a few problems with this. I am a "Use OpenGL directly" type of guy, mostly because I try to stay on top of the latest and greatest OpenGL features, so it is quite possible that these criticisms do not apply since it is not what the library is trying to achieve. So, please take this with a grain of salt.
The idea of providing an interface as opposed to an engine is cool, but it is really hard to do for something with a scope like OpenGL has. OpenGL's API is probably as simple as it can get FOR C (DirectX has objects, making it a much nicer to use library
)I do not see how one can maintain the design philosophy of SFML for 3D. SFML's graphics API is great for 2D, but the same design doesn't really translate into 3D IMO. Its going to be really hard to do something like deferred shading in your current setup, since it modifies the entire pipeline to be "Not SFML-style". In deferred shading, all rendered things must have a uniform interface for materials, for instance. Also, you cannot simply add features to a deferred shading pipeline without changing the entire pipleline.
Also, I am sure you are aware of this, but pretty much everything you wrote in OpenGL is highly deprecated.
These criticisms may be wrong, they may be stupid, I need more coffee
64
SFML projects / Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
« on: March 31, 2014, 05:18:18 pm »
You can. But, it is easier to just draw one quad multiple times rather than change and index buffer.
65
SFML projects / Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
« on: March 29, 2014, 05:00:08 pm »Quote
But I'm pretty sure that modern api use shaders. (Except if they only need to modify vertices component, the using of VBO is certainly more appropriate)
VBO's and shaders are not replacements for one another. Like I said, I would first read a good modern OpenGL book it you really want to get into 3D engines.
Also, please turn down the arrogance a bit. Especially when so far the arrogance seems to be unfounded. Calling yourself "One of the most experienced C++ developers in the world" is pretty obnoxious. I myself have often been called arrogant, and rightfully so, but I hope that I have mended my ways.
66
SFML projects / Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
« on: March 28, 2014, 04:54:45 pm »Quote
Personnaly I prefer use this rather than cube maps, normal mapping and other older techniques.
What exactly do you prefer? These techniques are not really old and don't have many replacements.
Quote
But what if the alpha component of the texture's pixels of the objects is not the same (I've textures with semi-transparent and opaque pixels)
It'll not work and I can't sort the objects by they z component if I have pixel's object which are before and other pixel objects with are after another object.
Your shader will not solve these problems. Also, keep in mind that you cannot read from a framebuffer while you are writing to it.
67
SFML projects / Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
« on: March 28, 2014, 01:43:10 am »
Some suggestions:
- Don't do the depth test manually.
- Try not to use if's in a shader, especially a fragment shader. It is very slow, especially when not branching on a uniform or constant.
- Use custom attributes.
- gl_ModelViewProjectionMatrix and the associated matrix stack are deprecated AFAIK.
- You probably don't need a texture matrix.
- You don't need gl_FrontColor.
- texture2D is deprecated.
- Use VBO's.
- Use deferred shading.
- glFlush is not needed.
- The way your engine is set up will make rendering shadow maps quite difficult, since it keeps swapping the shaders on you. Unless I understand it incorrectly.
I would recommend first reading up on modern OpenGL before making a 3D engine. Something like http://www.arcsynthesis.org/gltut/
- Don't do the depth test manually.
- Try not to use if's in a shader, especially a fragment shader. It is very slow, especially when not branching on a uniform or constant.
- Use custom attributes.
- gl_ModelViewProjectionMatrix and the associated matrix stack are deprecated AFAIK.
- You probably don't need a texture matrix.
- You don't need gl_FrontColor.
- texture2D is deprecated.
- Use VBO's.
- Use deferred shading.
- glFlush is not needed.
- The way your engine is set up will make rendering shadow maps quite difficult, since it keeps swapping the shaders on you. Unless I understand it incorrectly.
I would recommend first reading up on modern OpenGL before making a 3D engine. Something like http://www.arcsynthesis.org/gltut/
68
SFML projects / My Most Exotic SFML Application
« on: March 27, 2014, 03:26:35 am »
Hello all,
I recently got into some robotics with Arcbotics's Hexy, a Kickstarted hexapod robot.
It came with a simple movement controller that cannot combine movements and is very stiff looking.
So I decided to make my own inverse kinematics controller for Hexy. After that, I wanted a way to control it manually.
I had a Xbox controller sitting around, so I decided to make it communicate over serial and send commands dictated by the Xbox controller. It should work with Bluetooth too, haven't tested it yet though.
So where does SFML come in here? Well, I needed some library to handle joystick input, and I love SFML, so I decided to use that. I know, not the greatest and fullest application of SFML, but I felt it was still worth sharing here (especially since it is such a weird application of SFML )
Here's the download: https://sourceforge.net/projects/hexyik/?source=navbar
And here's a video of it in action:
https://www.youtube.com/watch?v=tsYwNmM0OJk
I recently got into some robotics with Arcbotics's Hexy, a Kickstarted hexapod robot.
It came with a simple movement controller that cannot combine movements and is very stiff looking.
So I decided to make my own inverse kinematics controller for Hexy. After that, I wanted a way to control it manually.
I had a Xbox controller sitting around, so I decided to make it communicate over serial and send commands dictated by the Xbox controller. It should work with Bluetooth too, haven't tested it yet though.
So where does SFML come in here? Well, I needed some library to handle joystick input, and I love SFML, so I decided to use that. I know, not the greatest and fullest application of SFML, but I felt it was still worth sharing here (especially since it is such a weird application of SFML
)Here's the download: https://sourceforge.net/projects/hexyik/?source=navbar
And here's a video of it in action:
https://www.youtube.com/watch?v=tsYwNmM0OJk
69
SFML projects / Re: SFML Light System - Let There Be Light
« on: March 22, 2014, 05:15:13 pm »
You must link to OpenGL. Add OpenGL32.lib in to the linker input.
70
SFML projects / Re: d3d (Deferred 3D) - A 3D Engine Using SFML
« on: March 17, 2014, 08:18:07 pm »
@ Nexus: Thank you very much for the tips! I was hoping that you would come by and help me straighten it out 
@ G.: Unfortunately not. I should probably make one
@ G.: Unfortunately not. I should probably make one
71
SFML projects / d3d (Deferred 3D) - A 3D Engine Using SFML
« on: March 17, 2014, 06:29:56 pm »
Hello all,
I originally wrote a 3D game engine with SDL + OpenGL + Bullet + Ogg + Vorbis + OpenAL + LUA. This original version had a lot of features, but was not very user-friendly. So I decided to re-write it, this time using SFML
The new version is especially different in that all game logic can be executed in parallel: there is a thread pool (using C++11 threading) that runs game entities all at once. It double-buffers the game logic and has special buffer-shifting smart pointers to make working in such an engine relatively simple.
The aim is to use only the most modern C++ as well as only the most modern OpenGL. The engine never uses raw new/delete or primitive arrays and only uses OpenGL 4+ features.
Here is an example of voxel terrain (it can do overhangs) with massive amounts of grass rendering.
Here is the engine's real-time global illumination in action:
Finally, here is a link to the bitbucket repository:
https://bitbucket.org/CireNeikual/deferred3d-parallel-game-engine/
I originally wrote a 3D game engine with SDL + OpenGL + Bullet + Ogg + Vorbis + OpenAL + LUA. This original version had a lot of features, but was not very user-friendly. So I decided to re-write it, this time using SFML
The new version is especially different in that all game logic can be executed in parallel: there is a thread pool (using C++11 threading) that runs game entities all at once. It double-buffers the game logic and has special buffer-shifting smart pointers to make working in such an engine relatively simple.
The aim is to use only the most modern C++ as well as only the most modern OpenGL. The engine never uses raw new/delete or primitive arrays and only uses OpenGL 4+ features.
Here is an example of voxel terrain (it can do overhangs) with massive amounts of grass rendering.
Here is the engine's real-time global illumination in action:
Finally, here is a link to the bitbucket repository:
https://bitbucket.org/CireNeikual/deferred3d-parallel-game-engine/
72
SFML game jam / Re: Open GL - Yes/No
« on: January 12, 2014, 06:04:03 pm »
Here is my thinking:
There are no prizes, people would join the jam just for fun. So why the restrictions? I would go with an honor system. There is nothing to win, so there is no reason to be so strict on the rules. Just have a nice get-together where people use SFML because it is good, not because of some rules. We should say "the game should use SFML" of course, and leave the usage thereof to the scrutiny of the community. Let the community rate it down if it doesn't use SFML to their liking.
Some of you said that those using OpenGL would "mop the floor" with the others. I don't understand this. If they are so good with OpenGL, you can bet that they will be good with SFML too. Also, if they are good, then they deserve to get more points! Knowledge should be rewarded! It IS a competition, right?
There are no prizes, people would join the jam just for fun. So why the restrictions? I would go with an honor system. There is nothing to win, so there is no reason to be so strict on the rules. Just have a nice get-together where people use SFML because it is good, not because of some rules. We should say "the game should use SFML" of course, and leave the usage thereof to the scrutiny of the community. Let the community rate it down if it doesn't use SFML to their liking.
Some of you said that those using OpenGL would "mop the floor" with the others. I don't understand this. If they are so good with OpenGL, you can bet that they will be good with SFML too. Also, if they are good, then they deserve to get more points! Knowledge should be rewarded! It IS a competition, right?
73
SFML projects / Re: Alife - Artificial Life Simulation
« on: January 02, 2014, 10:06:04 pm »
@BaneTrapper: It is indeed a 64 bit application, and is made in VS2013 (so it needs the redistributable for that). I can recompile it in 32 bit though. I'll let you know when it becomes available.
Depending on how interested you are, you can also compile it from source. Then you can mod it as well
On a different note, here is an image of the latest version. The textures do NOT belong to me. They will be linked when I release the next version.
I added lava pits as well as mouse controls (drag and zoom in on mouse position).
Will upload it to SourceForge soon.
Depending on how interested you are, you can also compile it from source. Then you can mod it as well
On a different note, here is an image of the latest version. The textures do NOT belong to me. They will be linked when I release the next version.
I added lava pits as well as mouse controls (drag and zoom in on mouse position).
Will upload it to SourceForge soon.
74
SFML projects / Alife - Artificial Life Simulation
« on: December 31, 2013, 06:59:20 am »
Hello,
I made an artificial life simulation just for fun and I thought I should share it. It is still nowhere near done (I only worked on it for 3 days so far), and still quite buggy, but it is already possible to witness some interesting patterns!
So far I have seen simple gathering, competing for food, predators, baby-eating (nerfed), timed grazing intervals (a swarm of creatures moving on a clock), upgrading agility to eat before the rest of the swarm arrives, and lots of dying.
I aim to make one of the most complex artificial life simulations ever (big ambitions I know, I can dream
).
Here is how it works so far:
Each creature gets a fixed number of points. These points can be allotted to 15 different attributes:
The way these points are allotted is evolved over time. Creatures can reproduce either with binary fission or with sex. A creature can lay down pheromones to help remember where things are (stigmergy). Creatures can evolve which pheromone type they lay down as well.
Each creature is controlled by 2 neural networks: A dopamine distributing network that defines the reward that the second actor network receives. The former is evolved, and the later both learns in its lifetime through hedonistic synapse modification and evolution (knowledge is not lost). As inputs, the neural network receives the creature's velocity, the grid around it, the nearest N creatures with information about them (direction, health, size, similarity), and the nearest food source. The creatures then decide how to move, attack, mate, and eat.
For the AI, I used my NNBrain library: http://en.sfml-dev.org/forums/index.php?topic=13449.0
Creatures can evolve to become either carnivores or herbivores. There are no omnivores at the moment.
Right now, there are major balancing issues in the stats. I also want to add construction (block placement), omnivores, and more complex fighting, among other things.
Here is the download link: https://sourceforge.net/projects/alifennplasticity/?source=navbar
Be warned though, it is incredibly processing intensive! I get only like 20 fps on my rig. The reason is that there are simply too many creatures (and I need to add a spatial tree).
There are typically around 1000 creatures at once if I had to guess.
It's not exactly visually stunning, but here is an image of it (each colored square is a creature):
I made an artificial life simulation just for fun and I thought I should share it. It is still nowhere near done (I only worked on it for 3 days so far
), and still quite buggy, but it is already possible to witness some interesting patterns! So far I have seen simple gathering, competing for food, predators, baby-eating (nerfed), timed grazing intervals (a swarm of creatures moving on a clock), upgrading agility to eat before the rest of the swarm arrives, and lots of dying.
I aim to make one of the most complex artificial life simulations ever (big ambitions I know, I can dream
). Here is how it works so far:
Each creature gets a fixed number of points. These points can be allotted to 15 different attributes:
- Health
- Armor
- Main Damage
- Piercing Damage
- Speed
- Agility
- Energy Consumption
- Starting Energy
- Reproduction Rate
- Reproduction Energy Loss
- Range
- Healing
- Max Life Span
- Size
- Attack Rate
The way these points are allotted is evolved over time. Creatures can reproduce either with binary fission or with sex. A creature can lay down pheromones to help remember where things are (stigmergy). Creatures can evolve which pheromone type they lay down as well.
Each creature is controlled by 2 neural networks: A dopamine distributing network that defines the reward that the second actor network receives. The former is evolved, and the later both learns in its lifetime through hedonistic synapse modification and evolution (knowledge is not lost). As inputs, the neural network receives the creature's velocity, the grid around it, the nearest N creatures with information about them (direction, health, size, similarity), and the nearest food source. The creatures then decide how to move, attack, mate, and eat.
For the AI, I used my NNBrain library: http://en.sfml-dev.org/forums/index.php?topic=13449.0
Creatures can evolve to become either carnivores or herbivores. There are no omnivores at the moment.
Right now, there are major balancing issues in the stats. I also want to add construction (block placement), omnivores, and more complex fighting, among other things.
Here is the download link: https://sourceforge.net/projects/alifennplasticity/?source=navbar
Be warned though, it is incredibly processing intensive! I get only like 20 fps on my rig. The reason is that there are simply too many creatures (and I need to add a spatial tree).
There are typically around 1000 creatures at once if I had to guess.
It's not exactly visually stunning, but here is an image of it (each colored square is a creature):
75
SFML projects / Re: NNBrain SFML Demo
« on: November 03, 2013, 04:18:14 pm »
@StormWingDelta: You need the Visual Studio 2013 runtime environment, available here: http://www.microsoft.com/en-us/download/details.aspx?id=40784 (Get the x64 version)
EDIT: I uploaded a better version of the pole balancing demo where the parameters were tuned to prevent the AI from sticking to the walls.
EDIT: I uploaded a better version of the pole balancing demo where the parameters were tuned to prevent the AI from sticking to the walls.