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 ... 14
Graphics / Re: sf::Angle not working?
« on: January 22, 2023, 06:08:08 am »
Using a number like 180 directly doesn't let the angle class know if you are referring to degrees or radians. So it doesn't allow directly setting the value, you need to use one of the helper functions that build an angle for you:
sf::Angle angle = sf::degrees(180.0f);
sf::Angle angle2 = sf::radians(3.14f);


General / Re: How can I make a background repeat infinitely?
« on: January 19, 2023, 02:41:01 pm »
Here's a little one I made.
Let's say the window and the background texture are 1920x1080.
It uses a single sprite of the background set to 3 times the width of the texture (so it repeats 3 times).
It then snaps the sprite to positions that are multiples of the width (1920). So as the camera pans to the side, the background will ocassionally jump 1920 pixels so it's always filling the window.

It can actually be done with a 2 time repeating texture, but handling -X positions becomes a little trickier, so I just used 3 repeats.

Some code fragments
// Make a sprite with the background texture like normal.
// Then set it like this:
sf::Vector2u texSize = tex->getSize();
sprite->setTextureRect(sf::IntRect(sf::Vector2i(0, 0), sf::Vector2i(texSize.x * 3, texSize.y)));

// Later in your rendering code do this:
sf::View view = window.getView();
sf::Vector2f pos = view.getCenter() - view.getSize() * 0.5f; // Find top left corner of the view
pos.x = int(pos.x / texSize.x) * int(texSize.x)-int(texSize.x); // Snap the X coord to multiples of width

Or if I was doing it for myself, I'd probably do a shader version.

Graphics / Re: Maximum Image size?
« on: January 16, 2023, 03:17:12 am »
I'm assuming you are doing a 32 bit build of the project.
SFML's Image class uses a Vector2u to store the resolution. This can theoretically handle 4 billion x 4 billion resolution. But it uses an std::vector of bytes to store the pixel data. In 32 bit projects, std::vector is limited to 4 billion (roughly) items. At 1 byte each, that's 4GB of ram.

A 30000x30000 image at 4 bytes per pixel is 3.4GB. That sounds ok, but 32bit apps have only 4GB total address space for everything, not just the image. Plus if you are on windows, 32 bit apps are only allowed to access 2GB normally, or a bit over 3GB if you enable the large address aware flag.

In a 64 bit project, I just made an 80000x80000 SFML Image and it was fine, which is 24GB of ram (I've got 32GB on my PC).

There's another issue though.
SFML uses STB Image (3rd party library by Sean Barrett) for image loading/saving. From what I can see, STB Image is made for 32bit. For example its PNG saving code returns the total size in memory of the data to save as a signed int, so it would be limited to 2GB size before things go wrong. It also has to allocate more ram as part of the saving on top of the already large amount in SFML.
I can get a PNG to save with 20000x20000. At 25000x25000 and above it fails with an error. At 40000x40000 and above it crashes the program.

So... doing a 64bit build will fix the image class. But you'll need to add alternative saving code to handle those sizes.

General discussions / Re: Including OpenCV
« on: December 30, 2022, 12:06:15 pm »
I recently added OpenCV to an SFML project to do video processing (working on a motion detection thing for security camera footage).

From a code point of view the setup was basically (this is for visual studio):
#include "opencv2/opencv.hpp"

#ifdef _DEBUG
        #pragma comment(lib, "opencv_world460d.lib")
        #pragma comment(lib, "opencv_world460.lib")

The usual stuff needs to be set up as with any library: includes path, library path and dlls next to the project exe.

Of course OpenCV's images aren't directly compatible with SFML, you'll need to convert them if you need images. So far the only easy way I've found is manually looping over each pixel and converting them.

General / Re: [SOLVED] Static linking in MS VS2019
« on: December 27, 2022, 10:40:15 pm »
When a static library like sfml-graphics-s.lib is built, the full linking process isn't performed. It takes the compiled obj files and bundles them together. The dependencies of sfml-graphics-s.lib (like opengl32.lib) aren't included.
So adding a static library to your project is like adding all of the cpp files, except the compiling bit is already done. The final link step to make the executable still needs to be told about the dependencies.

A dynamic library has complete working code in the dll, it had the full link process so its dependencies were used. Adding the dynamic library to your project doesn't require libraries like opengl32.lib unless you wanted to access it directly yourself.

By default, getPosition works in desktop (screen) coordinates. If you aren't using a fullscreen window, the mouse coordinates will be off by a bit.
You can make the mouse position relative to the window by passing the window to getPosition().
See if this helps:
sf::Vector2f p = win->mapPixelToCoords(sf::Vector2i(sf::Mouse::getPosition(*win).x, sf::Mouse::getPosition(*win).y));

Graphics / Re: Vertex array with a texture is invisible
« on: November 29, 2022, 12:03:23 am »
You're setting the position twice. The second block of code should use texCoords instead of position.

General / Re: Screens goes black after some time
« on: November 25, 2022, 03:37:46 am »
I haven't tried running it, but looking through the code there's one possibility I noticed:
In Player::update you have this line:
float gradient = (startX - xTarget) / (startY - yTarget);
If startY (player pos) and yTarget (mouse coords) are the same, then that will cause a divide by zero, and gradient will be a NaN (not a number).
The NaN will then spread to everything gradient is used with, which will set the player position to NaN. That position is then used (back in Engine::update) to move the view, which will also become a NaN and break the rendering.

General / Re: Having trouble statically linking SFML for Windows (MSVC).
« on: November 23, 2022, 07:02:57 am »

Looking again...
I missed that the last 3 errors in the first error list are for registry functions. Those need Advapi32.lib.

General / Re: Having trouble statically linking SFML for Windows (MSVC).
« on: November 23, 2022, 04:01:10 am »
All of the errors (well, the ones I googled for) appear to be functions from user32.lib.
Try adding -luser32 \ to your linker flags.

Audio / Re: Playing sound outside the main function doesn't work.
« on: November 13, 2022, 04:07:29 am »
When the end of the say function is reached, all local variables made in say are removed. This means the sound buffer and the sound are removed. So the sound is deleted nanoseconds after it starts playing.
Both the soundbuffer and sound must be kept alive for the duration of the sound.

Using pointers in a map as you mentioned is how I do it. But you need the sound stored as well, not just the sound buffer.

I use a map of strings (filenames) to sound buffer pointers and a vector of sound pointers. Each update I loop over the sounds checking if their status is sf::SoundSource::Stopped, in which case I delete them.

Network / Re: Code using udp socket not working
« on: November 09, 2022, 06:17:51 pm »
Hard to say, but might well be that they're filtering certain UDP traffic. Depending on which two computers you've tried, that they're in separate networks.
I've run into that at my work (college) in the past when teaching network programming.
The IT department decided to block all local UDP except a couple of ports for certain software. It took a while to get them to give me some unblocked ports (they gave me 1300-1399).

Also there were 2 different ethernet networks in the building that weren't routed to each other. My classroom had maybe 6 computers (including the front teacher PC) on one network, and the other 19 on the other network.

Graphics / Re: settexturerect seems offset.
« on: November 09, 2022, 04:07:59 am »
When you give loadFromFile an IntRect, it creates a texture only big enough to fit that rectangle.
So your ffhead texture is only 40x32, the rest was cropped away during loading. This means the setTextureRect can't go to 40,0,40,32. It seems SFML uses clamp texture addressing by default, so trying to go off the edge of a texture results is duplicating the edge pixels.

Try this instead:
Sprite sprite2;
That should load the full texture, but set the region that renders to the top left 40x32.

Graphics / Re: Incorrect object collision
« on: November 08, 2022, 01:42:39 am »
At a quick guess (without testing the code) it looks like the collision test is assuming the bullet has an origin of the top left corner, but the sprite has an origin of the centre, and the sprite is set to the position + double the width and height.

Try changing the loops to:
        for (int i = (y - 4) / 32; i < (y + 3) / 32; i++)
            for (int j = (x - 4) / 32; j < (x + 3) / 32; j++) {
and change the sprite positioning to:
sprite.setPosition(x, y);

Graphics / Re: Failed to load image x vcrutime140.dll
« on: November 06, 2022, 03:55:55 pm »
The first image shows you are running in a directory called debug.
The second image shows you are using the sfml-graphics-2.dll library, which is a release build.

Release and debug components shouldn't be mixed (they can be, but you need to do it carefully and know where it will break). If you are doing a debug build of your project, you should use a debug build of SFML.

(In particular, passing std::strings between debug and release will break, the string class has slightly different internal formats depending on build type. Your filename is showing as corrupt, so that was my first clue)

Pages: [1] 2 3 ... 14