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

Pages: [1] 2 3 ... 20
1
I use Portable File Dialogs: https://github.com/samhocevar/portable-file-dialogs
It's a single header only library that supports windows, mac and linux.
It can do file open/save and folder selection dialogs, plus message boxes and notifications.

2
Graphics / Re: hello. a question about setTextureRect
« on: March 28, 2024, 04:11:45 am »
OpenGL has the following texture wrapping modes: GL_CLAMP_TO_EDGE, GL_CLAMP_TO_BORDER, GL_MIRRORED_REPEAT, GL_REPEAT and GL_MIRROR_CLAMP_TO_EDGE.
Clamp to edge does what you are seeing, the edge pixels are extended infinitely around the texture.
Clamp to border lets you specify a single colour (like black) to show around the texture.
Repeat makes the texture tile (so it repeats).

SFML however only supports repeat and clamp to edge. It doesn't have clamp to border. (At least in SFML 3, which I'm using).

I don't know if there's an easy way to trick it besides editing texture.cpp to add the border mode in.

3
General / Re: loading/initializing neighbors of a tile in a grid
« on: March 28, 2024, 03:55:16 am »
The problem here is something that a few languages (not just javascript) going to C++ can run into.
Javascript uses references for classes. C++ uses values by default, but can also use references or pointers.

In your Tile class you have: std::vector<Tile> neighbors;
A vector of Tile isn't just references to tiles, it's complete copies of the tiles. So each tile contains a copy of all adjacent tiles, each of which contains copies of their adjacent tiles, and so on. As you process over the map adding neighbors, each new tile is picking up larger amounts of data.

What you'll want to do is have the neighbors either as an index (1d or 2d) that can look up the specified tile, or pointers to tiles. (C++ references aren't like in other languages, they wouldn't fit here as well as a pointer would)

4
Window / Re: Texture error?
« on: March 15, 2024, 06:08:10 am »
When you call setTexture, try adding true as a second parameter. That will reset the texture rectangle used by the sprite (needed if the textures are different sizes).

5
General / Re: How to make a list with a dynamic length?
« on: March 15, 2024, 06:02:29 am »
std::vector is the class you want. It's a dynamic resizable array as part of the C++ standard.

6
Graphics / Re: Optimization of hexagon-grid
« on: March 14, 2024, 08:18:52 am »
The points of a shape are relative to the shape's position (0,0 by default). You can move a shape just like a sprite: call setPosition on it.

7
General / Re: Failed to load image
« on: March 11, 2024, 08:33:09 am »
The default when running from visual studio is to make the working directory where the .vcxproj file is. But this can be changed in the project settings (Change $(ProjectDir) to $(TargetDir) in the working directory to look where the .exe is instead of the .vcxproj)

8
Yep, macros themselves are fine, it's just some of the code thinks Base has a different memory layout to another part of the code.

I tested in visual studio. Base.cpp would think Base is 192 bytes with the shader starting at byte 8. main.cpp thinks Base is 184 bytes with shader starting at byte 0.
Since main.cpp is creating the base object, it only allocated 184 bytes. But func() is in Base.cpp, so it thinks the shader starts later in memory, so all of its data is in the wrong spot and there's 8 bytes missing from the end. Once you try to setUniform on the shader, it tries to access bits of the shader that are in the wrong location.

The same thing can happen when people mix up debug and release libraries. STD classes can be different sizes, debug builds add extra members to some classes (like string). So passing an std::string from debug to release or vice versa is using two different memory layouts for one object.

9
When C++ is compiled, each .cpp is separate. They only understand each other via the include files (well, technically just forward declarations, but that's usually done via includes).
In your code there's two .cpp files. One has definitions of the functions in class Base and the other makes a Base and calls it.
The problem is each .cpp has a different understanding of what class Base is.
Base.cpp does a #define DEFINE_MACRO then includes Base.h, so it's understanding of class Base is it contains a bool, a shader and a function.
main.cpp doesn't define the macro, so when it includes Base.h it understands class Base as containing a shader and a function.
This means Base.cpp and main.cpp think Base is two different sizes in memory. One of them calling the other (main.cpp calling base.func()) will mean the shader member is accessed from the wrong address.

You need to either do the #define DEFINE_MACRO before every time you include base.h, or make it a project setting (eg. in Visual Studio you can set a preprocessor macro once and every cpp will get it).

10
General / Re: Unwanted Motion Blur
« on: March 03, 2024, 02:32:38 am »
This sounds like monitor ghosting. Have a look here: https://www.youtube.com/watch?v=MwfMtfBB07w
Basically pixels don't change colour instantly. It takes time for them to transition between colours. Different monitors will have different ratings, often measured as GTG (Grey To Grey), which is how many milliseconds it takes to change between two different shades of grey. The higher the GTG, the longer the motion trails left behind by moving objects.
The panel type can affect this too. VA panel monitors will have worse ghosting than IPS panels.

Some monitors let you turn on things like pixel overdrive, where they pump higher voltage into the pixels to change them faster, but that can overshoot and give different artifacts.

Another thing you can do is make the background look more like the moving object, the ghosting will be less noticeable.

11
General / Re: VertexArray vs Instancing questions for 2D isometric project
« on: February 22, 2024, 08:42:12 pm »
SFML sprites aren't really instanced once you get to the GPU though. Effectively a sprite isn't that different from a vertex array with 4 vertices. They both end up calling the same internal draw function for an array of vertices.
So if your trees take 4 vertices each, the vertex array style has 100x4 vertices + 1 transform using 1 draw call. The sprite style has 100x4 vertices + 100 transforms using 100 draw calls. SFML is just hiding the sprite vertices from you, they are still being sent 4 at a time for each draw call to the GPU.

There are ways for a GPU to do real sprite instancing with shaders, but SFML doesn't use those.

But the best thing to do would be make a quick mockup of both styles and time them (such as try 1000 simple trees). The difference may not be enough to worry about in the complexity of your scenes.

12
General / Re: C++/SFML: display several shapes simultaneously on screen
« on: February 22, 2024, 08:14:03 pm »
window.draw(vecRec); should be window.draw(vecRec);

But the main issue here is you are making a new rectangle every frame and pushing them into the vector, but every one of them has the same position, size and colour so you will only ever see what appears to be one. The random position, size and colour is chosen once outside of the loop and reused. You'll need to move all of the randoms into the loop so they are recreated for every new rectangle.

13
Graphics / Re: setFrameLimit - curious effect
« on: February 20, 2024, 11:56:03 am »
Maybe try setting the frame limit, but calling the generate function around 20 times in a loop (should use most of the available frame time) and time each call. That might be enough to see the CPU speed up.
(Not suggesting doing that permanently, just to test the hypothesis).
Maybe try some different loop counts to see how much work it needs before it clocks up.

14
Graphics / Re: setFrameLimit - curious effect
« on: February 16, 2024, 12:23:39 am »
I'm getting a feeling your turbo frequency idea might be what's going on.
Turbo does small increments to clock frequency when the workload is high (apparently number of cores in use too) and thermal limits haven't been hit. So a single threaded SFML app doing mostly sleeping for framerate limits with occasional spikes from generate() isn't sustaining the workload long enough for turbo to raise the clock as much.
I don't know if there's an app for intel that can show that. I've got an AMD one for my threadripper (Ryzen Master).

15
Graphics / Re: LineStrip VertexArray and ConvexShape problem
« on: February 15, 2024, 01:08:51 pm »
I'm a little hesitant to mention it (since it is barely documented and you'll be on your own getting it to work), but another way to go for vector art is to use NanoVG. It's kind of like a real time version of SVG using OpenGL.
Here's a pic of your data (the points vector) rendered using this code (in an SFML project):
        nvgBeginFrame(vg, 1920, 1080, 1);
        nvgBeginPath(vg);
        nvgFillColor(vg, nvgRGBA(255, 0, 0, 255));
        nvgStrokeColor(vg, nvgRGBA(255, 255, 0, 255));
        nvgStrokeWidth(vg, 2);
        nvgTranslate(vg, 100,100);
        nvgBeginPath(vg);
        nvgMoveTo(vg, points[0].x, points[0].y);
        for (int i=1; i<points.size(); ++i)
        {
                nvgLineTo(vg, points[i].x, points[i].y);
        }
        nvgClosePath(vg);
        nvgFill(vg);
        nvgStroke(vg);
        nvgEndFrame(vg);
 

It works within SFML fine, but you have to be a little careful. To get concave shapes it needs a stencil buffer, so you need to set the SFML window context to 8 bit stencil. You also need to call resetGLStates() on the SFML window after any NanoVG rendering, because NanoVG messes with opengl states that SFML expects to not be changed.
Performance won't be as good (since its more dynamic remaking the shape every frame, not just a vertex array generated once), but there's a lot of features in it.
https://github.com/memononen/nanovg

Pages: [1] 2 3 ... 20
anything