Messages

1

General discussions / Re: Effective Studying Method?

« on: October 10, 2018, 12:41:52 am »

My experience is that programming books are - in many cases - completely redundant. SFML is really well documented, and the API reference has examples for quite a lot of the classes. There are also a lot of good tutorial, both on the webpage and on the github wiki for SFML.

And don't spend time copying the code in the book. Whenever you write something yourself, you are more involved in the process, and your memory will benefit from it. You may read a section ten times, but writing you own code once or twice may give more insights. Also, writing ready made code robs you of the experience of reading compiler errors. The more errors you make, the more you learn. You might pull out more hairs from your head, but you will be wiser in the end.

2

Graphics / Re: Copy of view in a second smaller control

« on: October 09, 2018, 10:27:30 am »

I'm only making a guess here, as I have not tried it yet.
But SFML has a feature called RenderTexture, which you can draw onto instead of the window. By doing this, you should be able to draw your scene onto the render texture, use it as a texture and render onto a larger rectangle and then render onto a smaller rectangle.

Again, I'm not sure, but these forums are not heavy on activity. If I'm completely off track here, try the IRC or Discord channel 

3

Feature requests / Re: Position Forward Up from Transform

« on: October 09, 2018, 12:09:07 am »

The transform you retrieve from a transformable is a composition of several transforms. If I understand you correctly, what you want is to easily extract information such as position, scaling and rotation from a matrix. However, in general, there is no one to one correspondence between the transformation matrix and any combination of position, scaling and rotation.

If you look at the translation matrix itself, then yes, the position is perfectly retrievable. However, composite matrices (such as those constructed by sf::Transformable) are more complex. The matrix entries in the composite matrix corresponding to those of a translation matrix are very different. The composite matrices are a composition of translation (for setting origin), rotation, scaling and translation (for positioning), so the matrix is a lot more "mixed" up, than you would like. I suggest trying it out on paper so you can see for yourself.

In short: In general, you cannot extract information from a transformation matrix, as composition of transforms are not commutative.

EDIT: This is what the Transformable class is for. It precomputes the matrix and the inverse matrix for you, and it already gives you methods such as getPosition and getScale 

EDIT 2: Another point is that the transformations are affine. Let's say a point (1, 0) is transformed by some matrix T to produce the point (2, 0). What did the transformation do? Did it translate the vector, or did it scale the vector? Affine 2D transformations carries an extra column for the translations, so the transformation can also be seen as projecting 3 dimensional vector onto 2D space. This results in a loss of information.

4

Graphics / Re: Animation "flickering" when using float position.

« on: October 08, 2018, 10:31:25 am »

By looking at the spritesheet, you can see that there are white edges, which coincidentally looks very much like the white lines you consider a problem here. I would suggest measuring the sprite dimension again and consider the offset between the sprites. This is definitely not a bug 

Also, the position of your sprite should not change the texture coordinates of the undrlying vertices.

Show us instead the code that handles the animation itself, not the position of the sprite. Right now, I can only base my guess of off the video and the spritesheet.

5

Graphics / Re: A question about VertexBuffer::update

« on: October 08, 2018, 10:25:05 am »

Thanks. This clears it up!

6

Graphics / Re: A question about VertexBuffer::update

« on: October 07, 2018, 11:24:28 pm »

Thanks for the reply.
I need some extra clarification though. Does the update method itself copy to the GPU, or does it do the copying during the draw call?
Let's say I have a lot of vertices stored, and I call update on non-continuous sets of vertices - will this cause a copy to GPU on each call, or is it queued until the draw call?

7

Graphics / A question about VertexBuffer::update

« on: October 07, 2018, 08:56:36 pm »

I'm not into OpenGL coding, so I'm not able to find the answer on my own.

I'm using the VertexBuffer class for a Tilemap system, as I understand that VertexBuffer allows me to make changes to selected vertices, as opposed to VertexArray which copies all the vertices for each draw call.

My question is:
Is the update method an expensive method? If I update one vertex and the draw, I understand that this is much better than updating one vertex in a VertexArray and making a draw call.
But what if I update N vertices of a VertexBuffer, K times? What does the update method really do?

8

SFML projects / (SSML) Simple & Slow Multimedia Library

« on: October 05, 2018, 12:44:09 pm »

(SSML) Simple & Slow Multimedia Library

I have been working on a hobby project, with the aim of using it for developing simple games using SFML. Currently, it is a collection of unfinished features and some working features. There is nothing that this library can do, that other solutions don't do better, but for me it has been an incredible learning experience so far.

https://gitlab.com/tomvidm/ssml

If you feel interested, I believe the README.md explains how to compile. Tested using VS17 on windows and gcc on Ubuntu. Compilation requires CMAKE.

Documentation:
https://tomvidm.gitlab.io/ssml/

Currently, the project includes a showcase of the CompositeTilemap. I am continually updating the project and adding features and fixes.


The image showcases the CompositeTilemap class, but with colors instead of texture rects. The red rectangle shos the visibility bounds, and all tilemaps whose bounds intersect with it, will be visible. The subtilemaps are stored in a hash map, so "holes" are allowed.

SSML classes and functions are in the namespace ss::graphics, ss::system, ss::math and so on. Some SFML objects are aliased to look like part of SSML , because I want the public interface to be as clean as possible.

I would love to hear suggestions for improvements. And I do not shy away from criticism. This has been worked on as a personal project without input, and it is only healthy to have someone point out the smelly stuff.

Below is a non-exhaustive list of features and planned features. A more ambitious list of planned features is found in the README.md in the git repository. The GitLab reposity also has a list of issues detailing some of the design process and things I need (or just want) to do.

Graphics
Current features:

• Custom sprites with built in sprite animation system.
• Tileset, allowing the user to add texture rects to a vector, with additional string mapping for comfortable use of spritesheets. Possibility to load tilesets using JSON with a specific format. Undocumented! Yay!
• Tilemaps which maps indices to the corresponding texture rects in a Tileset, with no member methods to do so yet!
• Composite Tilemap, to let the user compose a world from individual tilemaps. Only renders the visible submaps.
• An abstract class Renderable which inherits from both sf::Drawable and sf::Transformable, with added methods for obtaining local and global bounds. Good for visibility checks.
• Simple renderer. Simply attach a sf::drawable or a ss::Renderable to the renderer and tell it to renderAll().
• A TextureManager to keep your rectangles non-white, textures safe and accessible through a string alias

Planned features:

• Implement ordered rendering layers, allowing easy switching of what is rendered. For example for pause menus or other things.
• Automatic resolution of draw order per render layer
• Built in GUI and
• Support isometric tilemaps! Ok, they are just transformed rectangular tilemaps, but the SFML transform class does not provide methods for isometric transforms.

Math module
Current features:

• Convenient functions for dealing with vectors and computational geometry.
• Linear and bilinear interpolation (Lerp and blerp!).
• Heightmap. A 2d array of values that can be operated upon. Slow and badly named.

Planned features:

• Bezier curves and B-splines for drawing curves and interpolation
• Simple graphs with implementations of the usual algorithms
• Whatever is needed to do what I want.

Event system
Current features:

• Translating SFML input events into SSML input events. SSML input events have sligthtly more detail that SFML events and makes it easy to check for hold time, last position of a press or release and to check the distance dragged while holding a button.

Planned features:

• To allow the user to define keystrokes and allow other objects to listen for these events.
• To allow the user to optionally track button mashing or mouse shaking.

[/list]

9

Graphics / Re: Vector Of Calsses with textures / White Rectangle Problem

« on: July 19, 2018, 09:52:52 pm »

verdog is correct. The texture will be destroyed as soon as the method quits. When you use the built in setTexture method for sprites and rectangles, they store a pointer to said texture. When the method quits, the temporary texture objects is destroyed, and the assigned texture pointer will point to free memory.

I want to comment on the method you are writing: It is called setTexture, but you are trying to do two things with it; to load a texture and to set a texture. Imagine you are working on this project in a team - you are new to the project and you want to know how to load a texture, but the documentation does not document any "loadTexture" method. What do you do? Yes, you start spending a lot of looking through the code to understand what is going on. A good principle to keep in mind is the principle of single responsibility - when you name a function to have some purpose, try to limit it to that purpose and let the name reflect what it does. It is good practice and will help you as the project grows - inevitably, you will forget the details of older parts of your code and you will start pulling your hair out

Keep in mind, this is not a criticism - everyone does this in the beginning. 

10

Graphics / Re: Cannot get sprites to draw in order

« on: July 17, 2018, 05:17:52 pm »

In your code, you draw the crocSprite before newSprite. As far as I can see, newSprite is supposed to be the "tile" sprite. Just switch their ordering.

window.draw(crocSprite);
window.draw(newSprite);


You said you are new to SFML, so I want to give you a few handy tips.
1. You have declared bools that check if a mouse button has already been pressed, disallowing further clicks during that frame. This is a non-problem, and you should skip this bool checking completely. You already use the sf::Mouse interface, and a frame is most likely too fast for it to be possible to click twice during it.

2. Encapsulate. You already encapsulated parts of your code (Like the Grid object). However, you should continue encapsulating it, as it will make each block of code easier to read and debug. Identify parts of the code that can be written as a function. Avoid nested if-for-if-for blocks. It will make everything a lot easier for you

Good luck!

11

Graphics / Re: Do I really have to use std::vector<sf::CircleShape> ?

« on: July 17, 2018, 04:00:06 pm »

You can make a vector std::vector<sf::Transformable>. Instead of iterating through a vector of circle shapes, iterate through the transforms. For each transform T, you call draw on the circle shape, pass a sf::RenderStates with T.getTransform() as the transform parameter. (Look at the declaration of sf::RenderStates structure)

This way, the vertices defining the circle itself does not change. The CircleShape itself is logically in the same place all the time, but the vertices are transformed and sent for rendering in turns.

12

Graphics / Re: A question about Transforms sent in a states structuer

« on: July 17, 2018, 03:47:40 pm »

Thank you for pointing the way and clearing up a misconception I had.

13

Graphics / Re: A question about Transforms sent in a states structuer

« on: July 17, 2018, 03:36:28 pm »

Thanks for the answer.

I explained myself poorly. Considering that the draw call itself is a relatively slow operation for sprites, I want to implement sprites using the VertexBuffer class, to measure the difference between:
N draw call for individual sprites with transforms being left as work for the GPU
At most 4*N transforms on the CPU and one draw call

I am disregarding culling of any kind here. I just want to make a comparison between the two cases

14

Graphics / A question about Transforms sent in a states structuer

« on: July 17, 2018, 01:59:02 pm »

As I understand, when calling draw with a transform in the RenderStates structure, the transform is applied on the GPU. Is this true?

I want to benchmark the point where large number of draw calls breaks even with a large number of transforms applied on individual vertices of a VertexBuffer with a single draw call. Knowing where the transform is performed will help me understand what is going on.

15

Graphics / Re: Std::Map texture not wokring

« on: July 17, 2018, 01:53:12 pm »

Assuming the object Card is a Sprite, then what eXpl0it3r says is true.
sf::Sprites only stores a pointer to the sf::Texture instance, meaning that whenever the address of the sf::Texture instance changes. the sf::Sprite will not be able to access that texture again. You must ensure that the Texture is stored in an manner, such that the address won't change and that the sf::Texture is not a temporary that goes out of scope before a draw call.