Messages

1

Graphics / Re: Loading a shader: pre-mature EOF parse error

« on: July 26, 2016, 03:47:46 pm »

Your code should work without comments [...]

You would think so, but apparently it didn't:

If I remove all of the comments, line breaks and empty lines, I get the same exact error.

2

Graphics / Re: Loading a shader: pre-mature EOF parse error

« on: July 26, 2016, 02:28:48 pm »

I'd hazard a guess that the GLSL parser has problems reading certain code fragments when they're all munged together: since no newline character appears inside of the quoted strings, the expression used to initialize 'shaderdata' evaluates to a single line of text.

Try using C++11 raw string literals (or, if you're stuck with an older compiler, place a \n on the end of each string):

const std::string shaderdata = R"(
uniform sampler2D objtexture;
uniform sampler2D fogtexture;
uniform sampler2D lighttexture;

void main()
{
    // Load textures into pixels
    vec4 objpixel = texture2D(objtexture, gl_TexCoord[0].xy);
    vec4 fogpixel = texture2D(fogtexture, gl_TexCoord[0].xy);
    vec4 lightpixel = texture2D(lighttexture, gl_TexCoord[0].xy);

    // Draw objects if a lighttexture pixel is fully-transparent
    // Otherwise, hide objects behind fog
    bool changealpha = bool(ceil(lightpixel.a));
    objpixel = vec4((lightpixel.rgb) * float(changealpha) + objpixel.rgb * float(!changealpha), lightpixel.a * float(changealpha) + objpixel.a * float(!changealpha));
    objpixel = mix(objpixel, fogpixel, fogpixel.a);

    gl_FragColor = objpixel;
})";
 

3

SFML projects / Re: Game Development Design articles

« on: May 25, 2015, 03:37:34 am »

Bullet point number one should have been 'Understand the hardware'. You almost touch on that right at the start by pointing out that it's slow to jump around in memory, but why is it slow? What is it about modern computer architectures that makes memory access patterns such a big deal when it comes to performance? You get the idea

4

Graphics / Re: Drawing a vertex array with a variable alpha level? .NET

« on: May 25, 2015, 03:04:26 am »

Nobody is going to teach you how to program shaders in a forum post Don't mind whipping one up though:

bool CreateCutoutEffect(sf::Shader& InShader, float InRadius, float InSharpness)
{
    // Vertex shader.
    const char* Vs = R"(
        varying vec2 v_Position;
        void main()
        {
            v_Position = (gl_ModelViewMatrix * gl_Vertex).xy;
            gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
        })";

    // Fragment shader.
    const char* Fs = R"(
        uniform sampler2D u_Texture;
        uniform float     u_Radius;
        uniform float     u_Sharpness;
        uniform vec2      u_Origin;
        varying vec2      v_Position;
        void main()
        {
            vec2 To = v_Position - u_Origin;
            float Percent = dot(To, To) / (u_Radius * u_Radius);
            float Modulation = smoothstep(u_Sharpness, 1.0, Percent);
            vec4 Color = texture2D(u_Texture, gl_TexCoord[0].st);
            gl_FragColor = vec4(Color.rgb, Color.a * Modulation);
        })";

    bool Result = InShader.loadFromMemory(Vs, Fs);

    if (Result)
    {
        InShader.setParameter("u_Texture", sf::Shader::CurrentTexture);
        InShader.setParameter("u_Radius", InRadius);
        InShader.setParameter("u_Sharpness", InSharpness);
    }

    return Result;
}
 

Only thing you have to do is update the view-space uniform u_Origin whenever your player moves (e.g. shader.setParameter("u_Origin", PlayerPosition). Being in view space means that you'll need to transform the parameter (i.e. PlayerPosition) by the render target's view. The sharpness parameter is in the range [0.0, 1.0] and defines how sharply the circle fades out at the edge.

Doing it with a RenderTexture would be equally simple. You'd just need to clear the render texture with an alpha of 0, render all the to-be-faded elements, then, with alpha blending turned off, render something that has an alpha of (for example) 0 over the area you want faded out, and finally render said RenderTexture over the screen.

EDIT: Totally forgot the whole .NET thing. It should be pretty much identical though.

5

Feature requests / Re: Way to draw using normalized coordinates via sf::RenderTarget

« on: January 05, 2015, 05:28:15 am »

I also requested this feature some time ago. It was deemed 'too specific' at that time.

http://en.sfml-dev.org/forums/index.php?topic=7243

6

Graphics / Re: Light and Shadow Blending

« on: July 01, 2014, 01:06:15 am »

Simplest to implement:
http://en.sfml-dev.org/forums/index.php?topic=14154.msg99530#msg99530

Complicated but potentially more efficient:
Use the shadow geometry to clip the light geometry and accumulate the lights in a single render texture using additive blending, then apply that render texture to the scene using multiplicative blending.

http://www.redblobgames.com/articles/visibility/

7

General discussions / Re: Baffled by problem and need help

« on: March 28, 2014, 02:24:44 pm »

After the value of 'i' had been set to:

Code: [Select]

interactiveElements[i].size()
what do you think happens to the termination condition of the inner loop on its next iteration?

8

SFML projects / Re: d3d (Deferred 3D) - A 3D Engine Using SFML

« on: March 18, 2014, 08:35:21 pm »

Looks like you have a potential deadlock in your thread pool implementation.

mutex mut_worker;
mutex mut_pool;

thread1:
ThreadPool::destroy() {
    std::lock_guard<std::mutex> lock(mut_pool);
    // mut_pool is now locked.

thread2:
ThreadPool::WorkerThread::run(...) {
    std::unique_lock<std::mutex> lock(mut_worker);
    _conditionVariable.wait(lock, ...);
    // mut_worker is now locked.
    _pPool->onWorkerAvailable(...); // takes lock on mut_pool.
    // thread2 is now blocked until thread1 unlocks mut_pool.

thread1:
    std::lock_guard<std::mutex> lock(mut_worker);
    // thread1 is now blocked until thread2 unlocks mut_worker.
 

At this point, there is a deadlock; neither thread can make progress.

I've only recently started seriously looking into multithreading so it's quite possible that I've misunderstood something, though.

9

Graphics / Re: Colouring coloured tiles using sf:color

« on: March 09, 2014, 11:32:13 pm »

Dividing 255 by any number less than 1 results in a value above of the range supported by sf::Uint8 (e.g. 255 / 0.5 = 510).

Another thing to consider is that the colour passed to sf::Sprite::setColor is applied to the texture by a multiplication. You should generally think of it as if it were named 'setColorModulation'. The implication is that in order to make the texture appear 'more blue', it actually has to be made 'less red and green'.

sf::Color waterTint(float saturation, sf::Uint8 value = 255)
{
    // Implicit hue of 240.
    return sf::Color(
        static_cast<sf::Uint8>(255.0f * (1.0f - saturation)),
        static_cast<sf::Uint8>(255.0f * (1.0f - saturation)),
        value,
        255
    );
}

int main()
{
    float saturation = 1.0f;
    sf::Color colour = waterTint(saturation);
    return 0;
}
 

This code assumes that 0 = minimum depth, 1 = maximum depth. The colour it generates should be applied directly to the tile being rendered, not to some overlay. It's completely untested but it looks right to me I came up with it by playing with the sliders on this site:

http://www.rapidtables.com/convert/color/hsv-to-rgb.htm

EDIT: Although there are blend modes for additive blending.

10

Graphics / Re: SFML and Box2D

« on: March 09, 2014, 09:34:18 pm »

I believe Box2d used the object's centre of mass as its position. sf::Sprite use the top left corner by default, so you should use sf::Sprite::setOrigin to correct for that.

11

Graphics / Re: Help with Tile collisions

« on: February 11, 2014, 05:19:03 pm »

I am not assuming pTiles is a 2D array. I am assuming that your screen is 2D. You're converting 2D screen coordinates into 2D grid coordinates (the grid is conceptually 2D) and then into a 1D array index.

12

SFML projects / Re: Feather Kit - A C++ Game Framework

« on: February 11, 2014, 05:03:38 pm »

Am I allowed to assimilate your example code with minor changes? In that case, do you wish to be credited in comments at the top of the file?

Sure. You may do whatever you like with it. I don't require any credit.

But I don't see where is the utility to use a template to move the entities. (for exemple)

It was just an example to show the process. Perhaps I should have used names like 'foo' and 'bar'. Although having said that, you have picked up on something:

Combinate the inheritance (to store the common entities attributes) and the templates (to store specific attributes)  shouldn't it better ?

I did originally implement a mechanism for the templates to be combined (i.e. inherit from one another), hence the name 'moveable' in the example. I removed that mechanism for a number of reasons, but left the example as-is. However, combining language level inheritance with an entity system is a big mistake. That is exactly what they're designed to avoid.

13

Graphics / Re: Help with Tile collisions

« on: February 11, 2014, 12:02:05 am »

There is nothing wrong with that line of code. That is a well known method to convert from a 2D coordinate into a 1D array index. But hey, you just know that all your other code is producing the correct values, right? :/

Edit: except that it shouldn't be a floating point value...

14

Graphics / Re: Help with Tile collisions

« on: February 10, 2014, 11:10:53 pm »

The code is everywhere? Lemme just grab my ethereal debugger :/

15

Graphics / Re: Help with Tile collisions

« on: February 10, 2014, 10:32:45 pm »

it appears the issue hasn't been resolved and am convinced that this has definitely something to do with the way tileNo is calculated [...]

There doesn't seem to be anything wrong with how the tile number is calculated. It's probably the input values to the calculation that are wrong (i.e. you're returning something funky from 'map.getTileSize()' and/or 'map.getDimensions()').

Have you tested the code to see if you can detect the issue?

Where is the code? :/