Welcome, Guest. Please login or register. Did you miss your activation email?

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.


Messages - Glocke

Pages: 1 ... 3 4 [5] 6 7 ... 20
61
SFML projects / Re: Faux Car
« on: May 18, 2016, 02:05:42 pm »
This looks awesome! Reminds me of the good old days with Lotus Turbo Challenge :)
I'm looking forward to a native linux version ;-)

62
System / Re: Loading resources using thread
« on: May 13, 2016, 11:43:21 am »
Hi, is it correct that calling XInitThreads isn't necessary anymore for v2.3.2?

63
SFML projects / Re: Rage - a coop dungeon crawler
« on: May 09, 2016, 02:01:25 pm »
Hey guys!

despite the obvious inactivity in this thread ... the project itself is still alive! In the recent past, I was struggling some issues referring Pathfinding and the AI's Lua Api. But those problems are solved and I'm looking forward working on the actual game again :)

As brief update: The upcomming steps are some respawn implementation and building up the player's HUD (supporting splitscreen with a dynamic number of players etc.). Furthermore, I plan to work on a "room editor".

Since the dungeons are generated completly random, the corridors and rooms look like badly procedurally generated: unexciting, empty, boring! To solve this, I plan to add random vegetation on the corridors and hand-crafted rooms, which will be randomly distributed (including rotating and/or mirroring them) over the dungeon. I'm really curious about this ... hope you're curious too!!

64
SFML projects / Re: Rage - a coop dungeon crawler
« on: January 29, 2016, 06:47:23 am »
I love roguelikes! 
Nice to see things up and functional in Rage.

The background art is obviously pretty barren still, but I agree with getting the core mechanics up and running before dealing with the window dressing.

Thannks man! But yes, the arts (in general) are pretty easy at the moment.. Gonna overhaul this once the game is in a release-near state :)

65
SFML projects / Re: Rage - a coop dungeon crawler
« on: January 28, 2016, 04:59:01 pm »
Meanwhile, I finished the initial AI-Implementation using customizable Lua Script via LuaBridge!

Short video:
https://www.youtube.com/watch?v=62WzeasgQLU

  • [ Done ] Basic Gameplay (Combat, Leveling etc.), I spare you further details^^
  • [ Done ] Local Coop (including Gamepad support)
  • [ Done ] Character classes: Warrior, Rogue, Wizard
  • [ Done ] Savegame Management
  • [ Done ] Random Dungeons
  • [ Current ] Random Enemies and Loot
  • [ Planned ] Powerups (Life/Mana) dropped by Enemies
  • [ Done ] Basic Enemy AI
  • [ Planned ] Enemies: Thief, Giant Spider, Skeleton, Ghost
  • [ Planned ] Game Menus
  • [ Current ] Available for Windows and Linux systems (32 and 64 bit versions)

66
SFML projects / Re: Rage - a coop dungeon crawler
« on: January 21, 2016, 02:05:48 pm »
Hi guys!

since I started this project, I always compiled on a x86 computer using Ubuntu 14.10. Since my new laptop arrived, I was curious about compiling on other systems. So I setup my laptop with a Windows 7 and Ubuntu 15.04 (both 64 bit versions). Yesterday I spent time to setup the build environment on my Ubuntu 15.04 and finally made it!

Today, I'm very happy to successfully compiled my project on Windows 7 using MinGW. This sounds simple, but is a huge step towards on of my milestones. So I'm looking forward to a playable tech demo!

  • [ Done ] Basic Gameplay (Combat, Leveling etc.), I spare you further details^^
  • [ Done ] Local Coop (including Gamepad support)
  • [ Done ] Character classes: Warrior, Rogue, Wizard
  • [ Done ] Savegame Management
  • [ Done ] Random Dungeons
  • [ Current ] Random Enemies and Loot
  • [ Planned ] Powerups (Life/Mana) dropped by Enemies
  • [ Current ] Suitable Enemy AI
  • [ Planned ] Enemies: Thief, Giant Spider, Skeleton, Ghost
  • [ Planned ] Game Menus
  • [ Current ] Available for Windows and Linux systems (32 and 64 bit versions)

67
SFML projects / Re: Seegurke - A Naval Minigame
« on: November 02, 2015, 01:16:57 pm »
Just wanted to mention it, maybe you didn't encounter it because your driver has vsync enabled by default.
On my computer it goes so fast, you just see a giant flickering for a split second.
Yeah, my graphics driver is vsyncing by default. So I just added a frame limit, thanks!

Will do, at the moment I only can set the ship moving and rotate it :D
Ah right, you're doing AI as you mentioned before :D

68
SFML projects / Re: Seegurke - A Naval Minigame
« on: November 02, 2015, 10:13:07 am »
From the first looks at the code and the game running you seem to be framerate dependend in some parts.
If the game runs to fast, the cannonballs just scale up to infinity until they are slow enough to be deleted.
Yeah, it's just a prototype, yet :D

At the moment I'm trying to build something out of it in conjunction with chaiscript :D
Feel free to notify us about your results :)

69
SFML projects / Re: Rage - a coop dungeon crawler
« on: October 30, 2015, 11:29:59 am »
I'm currently working on a (at least semi-well-tested) playable demo. To be able to release the demo, I reduced the subset of gameplay functionality to the following features:
  • [ Done ] Basic Gameplay (Combat, Leveling etc.), I spare you further details^^
  • [ Done ] Local Coop (including Gamepad support)
  • [ Done ] Character classes: Warrior, Rogue, Wizard
  • [ Done ] Savegame Management
  • [ Current ] Random Dungeons, but pre-generated Enemies
  • [ Planned ] Powerups (Life/Mana) dropped by Enemies
  • [ Planned ] Suitable Enemy AI
  • [ Planned ] Enemies: Thief, Giant Spider, Skeleton, Ghost
  • [ Planned ] Game Menus
  • [ Planned ] Available for Windows and Linux systems (*)
(*) I haven't compiled the game under windows, yet. But I'm looking forward to do this as the demo is near completion.

70
SFML projects / Seegurke - A Naval Minigame
« on: October 29, 2015, 01:12:48 pm »
Hi,

I just started a mini project about naval combat. The major inspiration was the third chapter of "The Curse of Monkey Island", which offered a very fun naval combat system. So I started a small prototype, because I'd like to build such a minigame as standalone application. The project's name is taken from the German version of Monkey Island 3; the name of Guybrush's ship is "Seegurke".



The code and art can be found on GitHub: https://github.com/cgloeckner/seegurke - it's build with C++11, SFML 2.2 and Thor 2.0, a CMake script is contained.

The current features are very limited, because I just started: Moving (W/S) and stearing (A/D), as well as shooting (Space) are implemented. Another ship is moving, but no collision is implemented yet (neither between ships nor between ship and cannonball).

Hope you like it anyway ^^ As I have enough time, I'll enhance the code. So keep in mind: It's only a prototype.

71
SFML projects / Re:creation - a top down action adventure about undeads
« on: October 29, 2015, 08:17:38 am »
Why not embed the assertion into get()? Makes code safer and more readable on call site.
I placed an assert into both: get() and call site. This is because I faced problems while unit testing. My assertion macro expands to throwing a special exception in case of building the unit tests. Unfortunately I didn't get the configurations for boost test right (I'm not quite sure whether they even exist) to produce a call stack when an untested exception was thrown. So I get something like `AssertionFailed` thrown in component.hpp at line XY (that's the file which defines an abstract component system), which doesn't help my to find the right spot where I accessed an invalid object. When I move that assertion into the actual function (which is directly called by the corresponding unit test, so I don't need a callstack here), I'm able to figure out where my precondition has failed.

72
SFML projects / Re: In Soviet Russia
« on: October 26, 2015, 12:01:56 pm »
omg it loots awesome ;D

+1 for linux binaries - I'm looking forward to!

73
SFML projects / Re:creation - a top down action adventure about undeads
« on: October 26, 2015, 11:56:00 am »
for assertions... I've been using them from time to time, but I was using console output for errors mostly. I think I need to use them more to make my game more stable and to prevent some stupid bugs in the future. :D

Personally, I prefer "testable" assertions (which to not abort while unit testing, but throw a specific exception that can be expected and caught) to guarantee (during unit testing) that specific conditions do not happen.

For error logging, I wrote a minimal wrapper using some operator<< and an assign() operation, which adds a logging target. So I can create a "Logger"-instance debug which can be used like
std::ofstream file{"debug.log"};
Logger debug;
debug.assign(file);
debug.assign(std::cout);
// ...
debug << "Position is " << myVector << "\n";
(with additional overloads for e.g. sf::Vector<> etc.) and write this to a specific log file and stdout. Both are some kind of basic output streams, so each call to debug's operator<< calls each assigned ostream's <<.

(My previous approach is part of my SfmlExt Lib, the new approach will be added as I have enough time to do it.)

74
SFML projects / Re:creation - a top down action rpg about undeads
« on: October 24, 2015, 11:06:56 am »
Is this a good way to do things? Is there a better way to do it? Maybe returning the pointer to component is fine?
Personally, I'm using a pure get without extras! My getter returns a reference (or const reference if suitable), and I use a has()-Operation to query existence. Its great for readability: Prefering references over pointers (where pointers have to be non-null) is always good. So I always branche !has() to return early (e.g. no damage calculation if no health component) or do something alternative (e.g. writing to a log that the component is missing but shouldn't be ^^). Personally, I also use lots(!) of assertions, which help readability, "understandability" and "refactorability", as well as "debugability" ...
So the separation of has and get makes sense for my coding, because I'm asserting stuff anyway. But the separation can also be used without asking for the actual component, e.g. to check for logical paradox.. maybe an object has either a FooComponent or a BarComponent (not both, not none) ... this can be tested without asking for the actual components - if required.

So my code looks similar, like this:
assert(movesys.has(actor_id)); // ignored in production code
auto& movedat = movesys.get(actor_id); // safe in dev code
++movedat.pos.x; // etc.
or
if (!animationsys.has(actor_id)) { // also evaluated in production
    log << "Object << " << actor_id << " cannot be animated\n";
    return;
}
auto& anidata = animationsys.get(actor_id); // always safe
// do whatever

My getters have some assertions, too - to avoid memory violation. But they do not check anything in production code.. just deliver the component as fast as possible. If the code needs to change using existence, I use has additionally before querying a component.

75
SFML projects / Re:creation - a top down action rpg about undeads
« on: October 18, 2015, 09:44:16 am »
Okay, I'll try something out. Do you know any great tutorials on GLSL? :)
Sorry, I don't :D

But here are my shaders for rendering a sprite with some brightness and saturation (I use it for blinking animations)
sprite_shader.loadFromMemory(
        "uniform float brightness, min_saturation, max_saturation;" \
        "uniform sampler2D texture;" \
        "void main() {" \
        "       vec4 pixel = gl_Color * texture2D(texture, gl_TexCoord[0].xy);" \
        "       pixel = vec4(clamp(pixel.rgb, min_saturation, max_saturation), pixel.a);" \
        "       gl_FragColor = vec4(pixel.rgb * brightness, pixel.a);" \
        "}",
        sf::Shader::Fragment
);
and for rendering a lighttexture (which is a major part of my lighting implementation).
light_shader.loadFromMemory(
        "uniform vec2 center;" \
        "uniform float radius;" \
        "uniform float intensity;" \
        "void main() {" \
        "       float dist = distance(gl_TexCoord[0].xy, center);" \
        "       float color = exp(-9.0*dist/radius);" \
        "       gl_FragColor = vec4(gl_Color.xyz * color, 1.0);" \
        "}",
        sf::Shader::Fragment
);
Setting up the sprite_shader before rendering looks like this:
sprite_shader.setParameter("brightness", brightness);
sprite_shader.setParameter("min_saturation", min_saturation);
sprite_shader.setParameter("max_saturation", max_saturation);
sprite_shader.setParameter("texture", sf::Shader::CurrentTexture);
Prerendering a light texture is shown here:
sf::RenderTexture buffer;
buffer.create(size, size);

// prepare shadeable object
sf::VertexArray array{sf::Quads, 4u};
array[0].position = {0.f, 0.f};
array[1].position = {size, 0.f};
array[2].position = {size, size};
array[3].position = {0.f, size};
for (std::size_t i = 0u; i < 4u; ++i) {
        array[i].texCoords = array[i].position;
        array[i].color = sf::Color::White;
}

// render lightmap
buffer.clear(sf::Color::Black);
light_shader.setParameter("radius", radius);
light_shader.setParameter("center", {size / 2.f, size / 2.f});
buffer.draw(array, &light_shader);
buffer.display();
Later the resulting texture is applied to the scene using a suitable blend mode. The lighting texture is attached (so you can see the result).

Maybe those shaders can help to when experimenting.

Pages: 1 ... 3 4 [5] 6 7 ... 20
anything