Messages

76

SFML projects / Re: Selba Ward

« on: February 16, 2021, 05:37:08 pm »

You need to treat your render texture like a window - that is, create it only once, then call renderTexture.clear() before you draw on it, followed by renderTexture.display() when you've finished drawing.

sf::RenderTexture rt;
sf::RenderWindow rw;

rt.create(w,h);
rw.create(w,h);

while(rw.isOpen())
{
    rt.clear();
    //draw stuff
    rt.display();

    rw.clear();
    //draw other stuff
    rw.display();
}

 

77

General discussions / Re: How up to date are the books in the Learn section?

« on: February 14, 2021, 12:06:22 pm »

My personal recommendation is, as eXpl0it3r said, SFML Game Development (not 'by example'). It concisely runs through a game project from beginning to end, and is written by authors who are on the SFML development team or closely associated with it, so, in my opinion, have a better understanding of SFML's design goals and how it is intented to be used.

sf::Text::setColor() has indeed been deprecated in favour of setFillColor() and setOutlineColor(). The deprecation notice should only be a warning (setColor() still exists for compatibility), however Visual Studio treats deprecation warnings as errors. To change the behaviour you can disable the warning.

78

Graphics / Re: Shaders

« on: January 25, 2021, 05:19:03 pm »

Try turning off the smoothing on the render texture, it may be causing it to get sampled outside the texture's area, which would create artifacts.

My personal favourite for learning not just shaders, but almost all aspects of SFML, was SFML Game Development:

https://www.packtpub.com/product/sfml-game-development/9781849696845

79

Graphics / Re: Shaders

« on: January 23, 2021, 11:59:35 am »

uniform float frag_LightAttenuation;

is a float

shader->setUniform("frag_LightAttenuation",100);

is attempting to set an int. (You can tell from the error by looking up glUniform1i())

You probably want

shader->setUniform("frag_LightAttenuation",100.f);

It pays to be specific with your constants, instead of relying on implicit conversion. In this case it's not being converted because an overload for setUniform() is available for integers.

Also as a side note: there's no reason to 'new' your shader, especially as you don't even delete it. Place it on the stack with your other resources and it'll be fine. 

80

General / Re: Unresolved external symbol error

« on: January 02, 2021, 12:09:50 pm »

Did you define SFML_STATIC ?

81

Graphics / Re: Shader in SFML

« on: January 02, 2021, 12:07:53 pm »

Some thoughts:

You should include a version directive: https://www.khronos.org/opengl/wiki/Core_Language_(GLSL)#Version

SFML uses GLSL 1.2 so you'd need

#version 120

GLSL 1.2 doesn't support smoothstep() https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/smoothstep.xhtml
This is easy to implement it yourself, the link even gives an example.

GLSL 1.2 provides gl_TexCoord so you can do this with SFML:

vec2 st = gl_TexCoord[0].xy;

although this is removed in GLSL 1.3 and higher.

82

Graphics / Re: Texture loadFromFile every frame.

« on: December 07, 2020, 03:08:18 pm »

An sf::Image has its data stored in RAM already, so when you do loadFromImage() the graphics data is copied from RAM to video memory which, as you've noticed, is reasonably fast - fast enough for your use case at least. Loading an image from a file is slower because it has to read from storage rather than RAM (although SSDs appear to be rapidly closing that gap), be decoded if it's a compressed format such as png or jpg, then finally get copied into a section of RAM ready to be uploaded to the GPU.

I probably wouldn't recommend trying to load from file every frame, but as a more general rule I tend to not worry about these things too much until they present a measurable problem, in which case I'll investigate more and look for ways to improve performance.

83

General / Re: How to draw a cubemap on SFML with OpenGL

« on: November 29, 2020, 12:20:03 pm »

glew is also an option (it's an OpenGL function loader) but is perhaps a bit out of date. A quick search reveals a few options:

https://github.com/google/galogen
https://glad.dav1d.de/
https://github.com/skaslev/gl3w

and of course glew. There's a wiki page on the kronos site dedicated to opengl loaders: https://www.khronos.org/opengl/wiki/OpenGL_Loading_Library

Choose one whichever one best suits your project 

84

General / Re: How to draw a cubemap on SFML with OpenGL

« on: November 28, 2020, 10:37:16 am »

SFML only provides the most basic OpenGL functions via OpenGL.hpp. You can load the others yourself with a loader such as GLad : https://glad.dav1d.de/

Note that if you're using pure OpenGL you can target any version your hardware supports - however if you want to mix your OpenGL with the SFML graphics module you require a compatible version (this is what SFML uses: https://github.com/SFML/SFML/blob/master/extlibs/headers/glad/include/glad/gl.h)

From there you should be able to load your cubemap using standard OpenGL calls, as per any tutorial 

85

Window / Re: Enter key from Numpad not working (contrary to "main" Enter key)

« on: November 17, 2020, 09:47:49 pm »

I've tested this, and it works for me. I'm using Visual Studio 2019 with the latest revision of SFML. Can you share which platform you're using (OS/compiler etc) so other people can try and reproduce the problem? Also, what's your keyboard layout?

86

Pull Requests & Testing / Audio effects: Reverb, chrous, delay etc

« on: November 10, 2020, 08:03:11 pm »

https://github.com/SFML/SFML/pull/1708

Implements OpenAL sound effects for reverb, chorus and delay. Can be easily extended to more types supported by OpenAL.
This was discussed some time (10 years!) ago here: https://en.sfml-dev.org/forums/index.php?topic=2245.0 the conclusion being that available OpenAL implementations were not capable. Thankfully things have changed somewhat in the last decade. I've tested this on platforms using openal-soft (windows and ubuntu) and on macOS using Apple's OpenAL library. I was pleasantly surprised to find that the effects are supported by the Apple library, although they are audibly rendered differently - particularly the delay which sounds much softer. However it seems openal-soft is supported on macOS and building SFML against that makes the effects sound consistent across tested platforms. I'm unable to test on mobile platforms.

I'm putting this here to gauge interest - if there's enough feedback I'll add high/low/band pass filters.

87

General / Re: Is fading a single tile of a tilemap in and out efficient?

« on: November 09, 2020, 02:14:30 pm »

There's no need to recreate the entire array. Assuming you have 4 vertices per tile you'll have something like

std::vector<sf::vertex> verts(800);

To update the transparency of a single tile do

verts[8].color = sf::Color::Transparent;
verts[9].color = sf::Color::Transparent;
verts[10].color = sf::Color::Transparent;
verts[11].color = sf::Color::Transparent;
 

You can easily find out your starting index by looking at the grid index of the tile you want to modify and multiplying it by 4. It can even be simplified to

for(auto i = gridIndex; i < gridIndex + 4; ++i)
{
    verts[i].color = newColour;
}
 

88

Graphics / Re: Little help with 'getPixelPtr()'

« on: October 23, 2020, 06:21:54 pm »

You're welcome, I hope it's helpful. I haven't studied ray tracing techniques before, it was interesting to learn about 

89

General / Re: Turning values into pixels for perlin noise

« on: October 23, 2020, 06:20:27 pm »

int pixel_w = (int)(noise[y * SCREEN_HEIGHT + x] * 12.0f);

probably ought to be

int pixel_w = (int)(noise[y * SCREEN_WIDTH + x] * 12.0f);

Also it's more memory access friendly if you loop like this:

for (int y{ 0 }; y < SCREEN_HEIGHT; ++y)
{
    for (int x{ 0 }; x < SCREEN_WIDTH; ++x)
    {

    }
}
 

as you're not skipping SCREEN_WIDTH values at a time, you'll be accessing your array sequentially. If you print pixel_w to the console you'll see what I mean 

90

Graphics / Re: Little help with 'getPixelPtr()'

« on: October 19, 2020, 03:21:30 pm »

Hi,

So I've had a look at this and here are a few comments:

Firstly the fact that you use sf::Image to load the textures is a good thing. It means that the images are automatically in RGBA format and no conversion is being done on them. In fact when I looked to see how often the conversion function was being called there were only two places: here and here. The fact that the colour values are called explicitly on them makes it easy to remove the conversion - just change 0xff777777 to 0x777777ff! Hopefully my previous explanations should make this obvious as to why this is.

Elsewhere I noticed this function which doesn't appear to be used anywhere, but should you decide to use it will have the bytes of the colour value in the wrong order. However this should be trivial to correct so I shall leave this as an exercise for you

As for performance the only potential bottleneck I noticed was here. If you change colorBufferTexture->loadFromImage() to colorBufferTexture->update() you're likely to get an improvement as loadFromImage() probably recreates the texture each time, instead of updating the existing one.

I also noticed this line which doesn't actually do anything to affect the output and can be removed completely, as the output of generate3DProjection() overwrites everything done by it. static_cast<sf::Uint8>(0xFF000000) is also somewhat redundant - you merely end up truncating a 32bit value to 00.

Overall, having run the program through visual studio's profiler (Debug->performance profiler), the hottest function appears to be generate3DProjection() - which is fair enough as that's where the pixel by pixel copies are happening. My benchmarks in release mode showed ~150fps or average of 6ms per frame. This seems reasonable considering most games target 60 or even 30fps, but without anything to compare it with, for example the performance of the original SDL version, I couldn't say if this is a really good benchmark or not.