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 - pbortler

Pages: [1]
1
Window / Re: String representation of a sf::Keyboard::Key
« on: September 02, 2020, 06:02:44 pm »
I checked a few versions of Thor and none contain a toString for sf::Keyboard::Key. 
 
To all those looking for it - make your own.

2
General / Re: drawing derived classes
« on: August 31, 2020, 03:09:50 pm »
You generally don't want to derive from any objects in SFML except interfaces like Drawable or Transformable. Your Board shouldn't be a Text or a Sprite object, but instead it should manage Text and Sprite objects and the Board itself will at most be a sf::Drawable. So you want those Text and Sprite objects to be members, and you probably want a draw() function that handles drawing them (encapsulation is good!).

Derive Board from sf::Drawable, then implement a draw() function that draws the text, then the sprite.

Something like:

void Board::draw(sf::RenderTarget& target, sf::RenderStates states) const
{
    target.draw(text, states);
    target.draw(sprite, states);
}

Then you can just pass the Board instance to the draw() on the window like:

sf::Window window(...);
Board board;
window.draw(board);

3
Graphics / Re: VertexArray drawing in wrong location
« on: August 30, 2020, 08:22:06 pm »
Hapax, I think you have the right idea. I'll try to explain my view of it now.

Transformations in SFML will account for translations (movement), rotations, and scaling (making bigger or smaller). This means that if you derive from sf::Transformable and apply the getTransform() while rendering, then you mustn't account for any of these while determining either the texture coordinates, or the object's position.

It's pretty straight forward once you realize what the result of getTransform() is responsible for, and why it would lead to errors trying to account for these factors more than once.

4
Graphics / VertexArray drawing in wrong location
« on: August 27, 2020, 05:19:18 pm »
I've been fighting with this for a few hours now, and I can't figure it out. I ended up making a bunch of debugging textures just to see what was going on, and I finally realized that sf::Sprite and sf::VertexArray think that position (0.f, 20.f) is different.

My vertex array is a 4 vertex Quad where the texture coords are the image corners, and the position coords are the image corners which are supposed to be offset by getPosition(), but when I call setPosition(0.f, 20.f) (which does indeed set the sf::Vertex::position value to (0.f, 20.f) it draws at (0.f, 40.f).

If I set the position to (0.f, 0.f) then it draws at (0.f, 0.f).

The Sprite is as simple as it can be. Load a texture of a small red rectangle, then set it's position to (0.f, 20.f).

The result is the following image (forum image links are apparently broken):

https://imgur.com/a/7Sizy6q

Why is this happening? I'm not using setScale() anywhere in my code. If I set the position of the sf::VertexArray to (0.f, 10.f) then it lines up, so it's screaming scaling error, but I am not setting a scale anywhere at any time.

How do I get sf::VertexArray coords of (0.f, 20.f) to draw 20 pixels down from the top of the window? Thanks.

edit: Apparently if I remove the line "states.transform *= getTransform();" from draw() it puts the vertex array in the correct position. Why would this cause the issue? isn't setting the transform on the renderstate required?

edit2: Apparently removing the aforementioned line breaks all over transformations like scaling, which makes sense. How the hell do you set the position of a transformed entity?!

edit3: Ugh, I finally figured it out. I really wish things like "Don't account for position in your position code" were more clear with SFML.

5
I'm trying to implement a 2d tilemap by using some existing libraries to parse map files so I can figure out what to render from the sprite sheets. I was only using one texture at first, but soon discovered the map files support multiple textures. I had been using one vertex array with one texture, but now I'm trying to use one vertex array with two textures. To draw the tilemap, I iterate over each layer (preserving Z order), then each tileset (minimizing the total number of texture switches), then each tile (configuring quads for screen draw rect and texture crop rect).

The problem I'm having is that the first call to draw(vertexArray, states) which references the first texture is being drawn as though it used the second texture from the second call to draw(vertexArray, states). It seems the changes to vertexArray went through, so the tiles are in the right locations, but what's being drawn is messed up because it's not respecting the changes to RenderStates::texture pointer between subsequent draw() calls.

Is there something I can do to make it draw the pixels from the first texture, then when I switch the texture it draws the pixels from the second texture? It seems like there must be, otherwise you'd never be able to draw two different textures to the screen at once, and I am assuming that's not the case.

edit: I found the solution with the help of someone on reddit. I needed one VertexArray per Texture per call to draw(). Cheers.

6
General / The example for integrating SFML into Qt produces errors
« on: August 22, 2020, 04:26:51 pm »
I'm following some examples of using SFML in Qt, but they are producing errors.

Everything seems to work and the texture displays, but the console is producing the following error during the call to draw():

Quote
An internal OpenGL call failed in Texture.cpp(98).
Expression:
   glFlush()
Error description:
   GL_INVALID_OPERATION
   The specified operation is not allowed in the current state.

Is it okay to ignore these errors?

edit: Event polling isn't supported either. How do you poll events in a SFML render window hosted by a QWidget?I've found a project called QSFML which implements event polling, and I seem to have that working now. QSFML also seems to suffer from the GL_INVALID_OPERATION errors though.

7
General / Re: How do I use these new types of sprite sheets?
« on: August 20, 2020, 02:02:03 am »
So far I've had nothing but bad luck with Spine. None of the examples will load out of the box. Can you recommend an alternative 2d skeletal system for SFML?

8
General / How do I use these new types of sprite sheets?
« on: August 19, 2020, 08:30:02 pm »
I've been playing around with regular sprite sheets for a few days, and I can create animations with them by displaying their frames in sequence. I'm now trying to use some sprites that I bought, but they're in a weird atlas format. Instead of frames to be shown in sequence they contain components that are meant to be connected, like upper and lower arm components meant to be connected by a joint at the elbow.

I can't find any tutorials on how to actually use these types of sprite sheets. There only seem to be examples on how to atlas (as a verb) your sprite sheet to presumably generate the txt/json files I already have.

How do I take txt/json and PNG files of component pieces, and display an animated character with moving arm components that are properly connected at the elbows and shoulders?

Pages: [1]
anything