Messages

1

SFML projects / Re: Let There Be Light 2

« on: January 28, 2017, 06:43:57 pm »

Uploaded it here: https://github.com/Ung0d/light_ungod/tree/master

However, its fully integrated in my engine (uses my quad-tree, depends on my signal system to emit signals when a light of an entity is changed, depends on my logger ect...) so this is not intended to compile in any way. I dont want to make my whole engine open source, hope you understand

I merged the things together I liked most of the different reimplementations of LTBL2 posted in this thread and added the stuff I usually have in systems in my engine (component-support, signals ect). I biggest changes I made are:

1) I introduced LightAffectors. Thats basically a std::function-wrapper that refers to a specific PointLight. The affector code is called every frame. Maybe its note noticeable in the gif, but you can realize light-flickering and other neat stuff this way. See LightSystem::update and LightAffector class

2) In (I think) all other versions of ltbl, a Light and a LightCollider were rendered (and all heavy calculations were computed) even if their bounding boxes did not collide and thus the light was not affected by the collider at all. I changed that behavior. Now the LightSystem checks for collision of the bounding boxes (which is cheap in compare) and light-colliders that do not collide with a light are ignored. See LightSystem::renderLight

2

SFML projects / Re: Let There Be Light 2

« on: January 28, 2017, 05:22:28 pm »

I use ltbl2 in my game "Last of the Ambaras" now   Just wanted to share some impressions. I refactored the framework to support my own quad-tree and modified the interface. I didnt see ltbl2 in a top-down-game before, so I guess some of you might be interested in how it could look.

3

SFML projects / Re: Last of the Ambaras

« on: January 24, 2017, 09:18:23 am »

Looks neat! You can check out Re:creation and ping Elias, he's not so long ago implemented his own shadow system.

Thanks! As it looks like, Elias' system works with vertex arrays to stretch the shadow instead of rotations, which is better. However, the system just works well for small sized shadows. At least in my engine the z-ordering would give strange results if I render the shadows of big objects (as regular entities) and than have some smaller entities walking "on" that shadow.

Here is how it could look:



The shadow is drawn flat on the ground and thus drawn always behind objects that walk on it. Looks okay.



The shadow is rendered as an regular entity with z-ordering. This looks weird in some situations.

It would be better if the shadow would affect the dude walking on it somehow, but not as awkward as in the second pic.



Best! But I'll have to think about how to implement it.

A lot depends on whether you need dynamic lighting that your shadows must respond to.  Or if you want a day-night cycle.

Thats true. Hand drawn shadows seem not to be an option at all. I fact, i'm currently using an altered version of Let There Be Light 2 to have dynamic shadows during nighttime. My plan is to disable this lightning during daytime and draw dropshadows according to the above approach. Those dropshadows may move from left to right, that shouldnt be the problem at all. Dropshadows are not drawn during nighttime.

4

SFML projects / Re: Last of the Ambaras

« on: January 21, 2017, 05:32:21 pm »

I just posted an example of the state of the games art-design somewhere else and got the feedback, that there is not enough distinction between object and background. So I quickly edited in a shadow and it looked quiet better.

Here is what I'm talking about:



Did anyone implement a shadow system like this in the past and can share some experiences? How did it work? Color the sprite down to black, make it transparent, rotate it a bit and draw it behind its object? Or would you actually handpaint the shadows a load them in as a predefined resource? I would really like to hear some ideas. (Nice visuals > efficiency at the moment)

5

Graphics / Re: Problem with sf::Shader and async texture load (since SFML 2.4)

« on: January 12, 2017, 10:20:32 pm »

This fixes my above example, as well as my original code. Great, thanks!

Is this branch safe to use until the merge took place?

6

Graphics / Problem with sf::Shader and async texture load (since SFML 2.4)

« on: January 12, 2017, 07:21:41 pm »

Hi guys.

After upgrading to SFML-version 2.4.1, I noticed that existing code doesnt work anymore. More specific: Code in my asset-manager that loads sf::Textures via std::async in another thread. It took me some time to realize, that the problem isnt the loading itself. Strangely the error occurs, if I load a sf::shader (sync load) before I load the texture (async load).
Note that the following error did not occur with my previous version (2.3.2).

Whats the error: When opening a window after doing the above initialisations, the window freezes/does not react instead of showing the loaded texture.

This freezing does not occur when i remove the line where the shader is loaded. It does also not occur if I create a sf::Context at the begin of the load(...) method that is called async. However, an empty window is opened in that case and the sprite isnt shown.

How to reproduce (simplest example I could figure out):

#include <SFML/Graphics.hpp>
#include <future>

void load(sf::Texture& tex, sf::Sprite& sprite, const std::string path)
{
    tex.loadFromFile(path);
    sprite.setTexture(tex);
}

int main()
{
    sf::RenderWindow window;
    sf::Texture tex;
    sf::Sprite sprite;
    sf::Shader shader;

   //load shader in the main thread
    shader.loadFromFile("shader.vert", sf::Shader::Vertex);

    //load the texture in a secondary thread
    std::future<void> future = std::async(std::launch::async, [&tex, &sprite] ()
                                          { load(tex, sprite, "test.png"); });

    window.create( {800,600,32}, "async_testing" );
    window.setFramerateLimit(60);
    while (window.isOpen())
    {
        sf::Event event;
        while (window.pollEvent(event))
        {
            if (event.type == sf::Event::Closed)
                window.close();
        }

        window.clear();

        if (future.wait_for(std::chrono::seconds(0)) == std::future_status::ready)  //test if async loading is done
            window.draw(sprite);

        window.display();
    }
    return 0;
}
 

To test it use an arbitrary png file and a simple pass-through vertex-shader. If you have non by hand:

void main() {
    gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;

    gl_TexCoord[0] = gl_MultiTexCoord0;

    gl_FrontColor = gl_Color;
}
 

Please tell me whether you can reproduce that and how I could fix it.

7

SFML projects / Re:creation - a top down action adventure about undeads

« on: October 06, 2016, 11:23:41 am »

That was indeed an oversight of mine. The reason is, that I didnt see those comment myself.
If you are lucky, most other people wont read them either and just take a short glace on the gifs.
(I dont know what the 9gag community is like).

Anyway, I totally understand your distaste about that stuff, I just try to find positive aspects - and I think there
are some.

8

SFML projects / Re:creation - a top down action adventure about undeads

« on: October 05, 2016, 11:02:16 pm »

Wow, internet is sometimes so ridiculous...

While I was shocked at the first time, I now - 5 mins later - think that you pretty much benefit from that. I mean 3k comments and they are mainly positive. Wow.

To be serious: All in all just a very nice advertising and you had zero effort yourself. I mean what danger could result from this? Even if he keeps posting stuff, he just makes your gifs more famous.

I think you should see it like that: People will remember the art-style and the gameplay-mechanics. They will not remember and at all they do not really care WHO posted the gifs.

9

SFML projects / Re: Last of the Ambaras

« on: August 23, 2016, 09:06:24 pm »

Hey guys!

no, the project isnt dead! I just have literally no time to make a showcase and even if...
Well there was definitely huge progress in the last half year, but just a little part of it is the "visual" kind of progress like the stuff shown in the new video:

https://www.youtube.com/watch?v=ChQVWp4Wd5g&feature=youtu.be

Believe me, there is no much time to write some things down . Instead take a 1min-long "tip of the iceberg".

I currently think about publishing some parts of my code (things that could be used as mini-frameworks and are not dependent on the bigger scope of the project like my quad-tree-implementation, my serialization framework and other things). Is there something I have to know about licensing that stuff?

10

SFML projects / Re: A promising future

« on: July 15, 2016, 09:55:43 pm »

Aren't there several issues with SFML resources being loaded from other threads, especially textures? Since Thor is almost always used together with SFML, this is something I have to keep in mind.

I use (my own) multithreaded-ressource loader for (sfml-)textures and it works quiet well until now, but its unfinished. It works with callbacks, instead of futures, means that the method that requests a resources gets a lambda-expression that is invoked for the texture once its loaded (you can attach the texture to a sprite in there or something like that).

Post any progress in terms of multitreading you may make here, if you like. I would appreciate it.

11

SFML projects / Re:creation - a top down action adventure about undeads

« on: July 06, 2016, 08:04:35 am »

Use something capable of storing multiple entries, such as a vector?

The result would be a datastructure where just (in most cases) very few vectors have more than one element. Not that aesthectic. Just wondered how one could solve that "better". 

12

SFML projects / Re:creation - a top down action adventure about undeads

« on: July 05, 2016, 07:50:29 pm »

Decent work so far!

So what you basically do is store a callback function together with a button/key and invoke that callback when the appropriate inputEvent is catched? What if you want multiple callbacks to be invoked on the same keypress?

Btw I think I saw you posting at Sol2 on GitHub (the world is small), is that right? I recently started using it and I think its pretty decent. Do you use it?

13

SFML projects / Re: Rage - a coop dungeon crawler

« on: July 02, 2016, 10:31:24 am »

If you have a appropriate lore background name it after your main hero (in case there is one) or the world the game is settled in. If you want to title it according to the style of gameplay, just find a synonym for rage.
But in general, I think I like story-based names more.

14

SFML projects / Re: Rage - a coop dungeon crawler

« on: July 01, 2016, 10:12:46 pm »

No, no! You know your game best. You put countless hours in its development. The name must be something that comes from yourself. Something that important cant grow on the responsibility of someone else.

15

SFML projects / Re: Screenshot Thread

« on: June 07, 2016, 09:17:57 am »

@ scellow
So you are the dev of realm of the mad king? Nice too meet you here.

I played it some time ago (is it still free of steam?) and thought it was a funny little game.