1
General / Re: console disable c++
« on: March 31, 2023, 02:07:07 pm »
It depends on your IDE / tool chain. For example in Visual Studio go to your project settings, Linker>System>SubSystem and set the value to Windows.
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.
2
General / Re: Whats wrong with my collision detection?
« on: March 25, 2023, 09:36:41 am »
Collision detection is pretty easy if you break it down into smaller actions - it's only really complicated when you start trying to calculate complex physics simulations.
The basics of a collision involve calculating what's called a 'collision manifold'. This is composed of two things: a normal vector indicating the direction of the collision, and a penetration value - ie how much the two objects overlap. With these, resolving the collision usually boils down to moving the colliding object back along the normal vector by the penetration amount.
For AABB - AABB collision and circle-circle collision, finding this manifold is also really easy. I wrote this blog post for SFML specifically, which explains how to do it. Once you have an understanding of these types of collision then it's much easier to extend the technique to other shapes, although in many cases I've found AABB and circle collision is enough
The basics of a collision involve calculating what's called a 'collision manifold'. This is composed of two things: a normal vector indicating the direction of the collision, and a penetration value - ie how much the two objects overlap. With these, resolving the collision usually boils down to moving the colliding object back along the normal vector by the penetration amount.
For AABB - AABB collision and circle-circle collision, finding this manifold is also really easy. I wrote this blog post for SFML specifically, which explains how to do it. Once you have an understanding of these types of collision then it's much easier to extend the technique to other shapes, although in many cases I've found AABB and circle collision is enough
3
Graphics / Re: Draw sprite to renderwindow automatically
« on: December 23, 2022, 05:39:34 pm »
A simple approach would be to place your sprites in a vector, and loop over it when you draw:
However if you're getting more serious about your code design I highly recommend reading SFML Game Development and Game Programming Patterns - both of which I found invaluable when I was learning SFML.
std::vector<sf::Sprite> sprites;
//insert sprites here
for (const auto& sprite : sprites)
{
window.draw(sprite);
}
//insert sprites here
for (const auto& sprite : sprites)
{
window.draw(sprite);
}
However if you're getting more serious about your code design I highly recommend reading SFML Game Development and Game Programming Patterns - both of which I found invaluable when I was learning SFML.
4
General / Re: VertexArray size impacting gl_Vertex value in Vertex shader
« on: December 14, 2022, 05:21:16 pm »
To be honest that's probably the best work around you'll get. For a while I supplied my own set of matrices to the vertex shader (and did my own funky 3D things with it) but then decided if I was going to put in that much work I might as well just switch to pure OpenGL. Credit to SFML though, I wouldn't have learned enough about OpenGL without it
5
General / Re: Render to several render textures in one draw ?
« on: December 14, 2022, 02:25:46 pm »
I did make an SFML-compatible(ish) MRT some time ago, which you can check out here:
https://github.com/fallahn/xygine/blob/legacy/xygine/include/xygine/MultiRenderTexture.hpp
I say 'ish' it breaks compatibility with the version of OpenGL SFML uses, so while it works on Windows using a compatibility context it won't work on macOS (and I think linux was spotty too, but it's been a while and I don't recall for sure)
https://github.com/fallahn/xygine/blob/legacy/xygine/include/xygine/MultiRenderTexture.hpp
I say 'ish' it breaks compatibility with the version of OpenGL SFML uses, so while it works on Windows using a compatibility context it won't work on macOS (and I think linux was spotty too, but it's been a while and I don't recall for sure
)
6
General / Re: VertexArray size impacting gl_Vertex value in Vertex shader
« on: December 14, 2022, 02:17:51 pm »
This is an SFML optimisation - if a drawable has four or fewer vertices then the positions are pretransformed to world-view coordinates, and the model-view matrix is set to an identity. I came across this when working with a lighting shader and the inverse of the model-view matrix wasn't giving me what I expected.
7
Graphics / Re: SFML and Shaders
« on: November 19, 2022, 02:52:57 pm »Another thing, in general... How do you get the position sent to the shaders in SFML?
I haven't seen any good tutorial on it yet.
Like in "proper" openGL you usually use in vertex shader:
layout (location = 0) in vec3 aPos;
void main()
{
gl_Position = vec4(aPos.x, aPos.y, aPos.z, 1.0);
}
but I'm not sure if this works in SFML like that?
All the examples I've seen use deprecated 1.0 stuff, that is really old.
I mean I try to use 3.3 core, and even that's old, but at least it's a bit modern...
If you're using the graphics module of SFML then up to version 2.5 (maybe 2.6, I've not kept up) you're restricted to GLSL 1.2 / #version 120 without a compatibility context. So, you're probably OK to use other versions of GLSL on Windows, maybe on Linux, and not at all on macOS which only supports core profiles.
The vertex position is provided in gl_Vertex and the world/view/projection matrix in gl_ModelViewProjectionMatrix - see the shader tutorial. It might also be worth noting that SFML drawables with 4 or fewer vertices will have their positions in world space with an identity matrix set for model/world matrix (this has caught me out before when trying to do lighting stuff, trying to take the inverse of it will just give you another identity matrix).
8
Graphics / Re: Render Overlap with TileLayer from tmxlite
« on: October 28, 2022, 11:10:27 pm »
Tmxlite itself doesn't have any particular utilities for this sort of thing - it's designed purely as a way to convert tmx map data into C++ data structures. However some time ago I did write a post about z-ordering with Tiled which might help you set up your maps:
https://trederia.blogspot.com/2014/08/z-ordering-of-sprites-in-tiled-maps.html
There's also this post by Elias Daler which is useful:
https://eliasdaler.wordpress.com/2013/11/20/z-order-in-top-down-2d-games/
And, if you can, check out Titan Souls on Steam. The game includes all the tmx map files in its assets directory which can be very enlightening. (No affiliation, I just like the game
)
https://trederia.blogspot.com/2014/08/z-ordering-of-sprites-in-tiled-maps.html
There's also this post by Elias Daler which is useful:
https://eliasdaler.wordpress.com/2013/11/20/z-order-in-top-down-2d-games/
And, if you can, check out Titan Souls on Steam. The game includes all the tmx map files in its assets directory which can be very enlightening. (No affiliation, I just like the game
)
9
Graphics / Re: How to add a depth buffer to isometric textures?
« on: October 28, 2022, 10:52:25 pm »
It's possible to add depth to SFML drawables, but it depends on your definition of 'hack' It also requires a bit of knowledge about OpenGL, particularly shaders. The gist is that normally in the vertex shader you take the coordinates of each vertex of a drawable and convert them, usually through a world/view/projection matrix, into your display's coordinates so that the drawable is rendered on screen in the correct place. This is done automatically by SFML, but it is possible to override the behaviour with custom shaders. SFML is by nature 2D so it makes sense that at the vertex shader stage only the x and y coordinates of the vertices are provided. However, with a bit of experimenting I was able to store z/depth data in the vertex colour property. Here's the result:
http://www.youtube.com/watch?v=30wvsDwAKHs
Constructing a vertex position from this data in the vertex shader essentially makes the vertex 3D, allowing OpenGL to do the depth testing for you. Of course this doesn't necessarily mean that your game has to be 3D - the 2D output can be maintained using an orthographic projection matrix (see link above). The source is available on github if you're curious (there's a link in the video), with a bit of work it might help sort your drawables if you're willing to give up some of your colour data to depth data
It also requires a bit of knowledge about OpenGL, particularly shaders. The gist is that normally in the vertex shader you take the coordinates of each vertex of a drawable and convert them, usually through a world/view/projection matrix, into your display's coordinates so that the drawable is rendered on screen in the correct place. This is done automatically by SFML, but it is possible to override the behaviour with custom shaders. SFML is by nature 2D so it makes sense that at the vertex shader stage only the x and y coordinates of the vertices are provided. However, with a bit of experimenting I was able to store z/depth data in the vertex colour property. Here's the result:http://www.youtube.com/watch?v=30wvsDwAKHs
Constructing a vertex position from this data in the vertex shader essentially makes the vertex 3D, allowing OpenGL to do the depth testing for you. Of course this doesn't necessarily mean that your game has to be 3D - the 2D output can be maintained using an orthographic projection matrix (see link above). The source is available on github if you're curious (there's a link in the video), with a bit of work it might help sort your drawables if you're willing to give up some of your colour data to depth data
10
Graphics / Re: sf::setTextureRect Not Working As Expected?
« on: September 29, 2022, 12:07:23 pm »
The white square problem is usually caused by some unintentional copy of the texture or accidental memory mismanagement. The usual paradigm in SFML is to keep textures external from the drawable classes which use them, so that copying the drawable won't make a copy of the texture. Often some sort of resource management is used. SFML also provides an interface for creating custom drawables such as a Player class in a consistent way by inheriting sf::Transformable and sf::Drawable, which would look something like this:
How this works is explained in the documentation. Note that the class does not have a texture member. Rather, you would use it like this:
With the texture in its own scope (either as in the example or stored in a resource manager) copying drawable classes like Player can be done safely without accidentally copying any textures they use. There is also no need to use new/delete in this example, everything is fine on the stack. And even if there were a reason to use the heap smart pointers would be the way to go.
class Player final : public sf::Transformable, public sf::Drawable
{
public:
void setTexture(const sf::Texture& texture)
{
m_sprite.setTexture(texture);
}
void setTextureRect(sf::IntRect rect)
{
m_sprite.setTextureRect(rect);
}
private:
sf::Sprite m_sprite;
void draw(sf::RenderTarget& target, sf::RenderStates states) const override
{
states.transform *= getTransform();
target.draw(m_sprite, states);
}
};
{
public:
void setTexture(const sf::Texture& texture)
{
m_sprite.setTexture(texture);
}
void setTextureRect(sf::IntRect rect)
{
m_sprite.setTextureRect(rect);
}
private:
sf::Sprite m_sprite;
void draw(sf::RenderTarget& target, sf::RenderStates states) const override
{
states.transform *= getTransform();
target.draw(m_sprite, states);
}
};
How this works is explained in the documentation. Note that the class does not have a texture member. Rather, you would use it like this:
int main()
{
sf::Texture playerTexture;
playerTexture.loadFromFile("test.png");
Player player;
player.setTexture(playerTexture);
player.setTextureRect({ 2,2,100,100 });
sf::RenderWindow window(sf::VideoMode(800, 600), "My window");
sf::Clock frameClock;
while (window.isOpen())
{
sf::Event event;
while (window.pollEvent(event))
{
if (event.type == sf::Event::Closed)
{
window.close();
}
}
float elapsed = frameClock.restart().asSeconds();
if (sf::Keyboard::isKeyPressed(sf::Keyboard::Left))
{
player.move(-20.f * elapsed, 0.f);
}
if (sf::Keyboard::isKeyPressed(sf::Keyboard::Right))
{
player.move(20.f * elapsed, 0.f);
}
window.clear(sf::Color::Black);
window.draw(player);
window.display();
}
return 0;
}
{
sf::Texture playerTexture;
playerTexture.loadFromFile("test.png");
Player player;
player.setTexture(playerTexture);
player.setTextureRect({ 2,2,100,100 });
sf::RenderWindow window(sf::VideoMode(800, 600), "My window");
sf::Clock frameClock;
while (window.isOpen())
{
sf::Event event;
while (window.pollEvent(event))
{
if (event.type == sf::Event::Closed)
{
window.close();
}
}
float elapsed = frameClock.restart().asSeconds();
if (sf::Keyboard::isKeyPressed(sf::Keyboard::Left))
{
player.move(-20.f * elapsed, 0.f);
}
if (sf::Keyboard::isKeyPressed(sf::Keyboard::Right))
{
player.move(20.f * elapsed, 0.f);
}
window.clear(sf::Color::Black);
window.draw(player);
window.display();
}
return 0;
}
With the texture in its own scope (either as in the example or stored in a resource manager) copying drawable classes like Player can be done safely without accidentally copying any textures they use. There is also no need to use new/delete in this example, everything is fine on the stack. And even if there were a reason to use the heap smart pointers would be the way to go.
11
Window / Re: How to get unicode to be typed through sf::TextEntered
« on: September 24, 2022, 10:47:06 am »
Unicode is complicated - see this post: https://stackoverflow.com/a/50407375/6740859
Broadly speaking std::string is mostly compatible with utf-8 but you may need to convert to/from codepoints when used with sf::String. In my experience I've found it best to try and stick to a unicode aware string class (like sf::String which is, admittedly, not the standard library but supports full 32 bit characters) and only convert when necessary, such as reading or writing a text file.
Broadly speaking std::string is mostly compatible with utf-8 but you may need to convert to/from codepoints when used with sf::String. In my experience I've found it best to try and stick to a unicode aware string class (like sf::String which is, admittedly, not the standard library but supports full 32 bit characters) and only convert when necessary, such as reading or writing a text file.
12
Graphics / Re: Any way to optimize 'pixelsArray to GPU' process?
« on: September 21, 2022, 11:18:12 pm »
You can use this overload of Texture::update() to update only part of a texture. And FWIW it's possible to use a vector for your array so you don't have to worry about memory management with new/delete:
std::vector<sf::Uint8> pixels(640*480*4);
texture.update(pixels.data());
texture.update(pixels.data());
13
General / Re: Function for loading multiple textures?
« on: September 18, 2022, 12:37:37 pm »
If you're using C++17 the filesystem functions will let you parse files from a given directory. eg
You can do your texture loading with file.path() if it's a suitable image. It might also be worth checking out a resource manager if you have a lot of files.
#include <filesystem>
#include <iostream>
for (const auto& file : std::filesystem::directory_iterator("assets/images"))
{
std::cout << file.path() << std::endl;
}
#include <iostream>
for (const auto& file : std::filesystem::directory_iterator("assets/images"))
{
std::cout << file.path() << std::endl;
}
You can do your texture loading with file.path() if it's a suitable image. It might also be worth checking out a resource manager if you have a lot of files.
14
Graphics / Re: Debug .. frame per seconds ..
« on: September 07, 2022, 05:34:05 pm »
Debug builds will always be slower, and this can be particularly noticeable in Visual Studio. If you're using VS, try going to your project properties, make sure you're switched to the Debug build layout, and then go to C/C++ -> Code Generation and change Basic Runtime Checks to Default. It's worth looking at the documentation too, just so you're aware of what the option does which you're changing
15
Graphics / Re: Jittery 98 sprites
« on: August 18, 2022, 10:41:22 am »
Are you testing this in a release build, or is this only in debug?
Also do you have an nvidia card? You could try disabling Threaded Optimisation: https://en.sfml-dev.org/forums/index.php?topic=23708.msg161792#msg161792
Also do you have an nvidia card? You could try disabling Threaded Optimisation: https://en.sfml-dev.org/forums/index.php?topic=23708.msg161792#msg161792