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 ... 17 18 [19] 20 21 22
271
General / Re: Strange problem with sprite collision
« on: June 04, 2021, 03:06:43 pm »
This:
   int i = 0, j = 0;

    while(i < vectorHeroes.size())
    {

        while(j < vectorHeroes.size())
        {

Should be:
   int i = 0;

    while(i < vectorHeroes.size())
    {
        int j = 0;
        while(j < vectorHeroes.size())
        {
So j gets reset to zero every time i increments.
Otherwise this would happen... (let's say vectorHeroes.size() is 4)
i is 0
   j is 0
   j is 1
   j is 2
   j is 3
i is 1
   j is 4 so while loop is skipped
i is 2
   j is 4 so while loop is skipped
i is 3
   j is 4 so while loop is skipped




272
General / Re: Strange problem with sprite collision
« on: June 04, 2021, 01:14:10 pm »
You aren't resetting j to zero when the while(j < vectorHeroes.size()) loop is started again.

Or for a bit of a saving, you can halve the comparisions by starting the j loop with the value of i+1, then do the collision response to both objects. This makes it so the loops won't do (for example) object 5 vs 10 and 10 vs 5, only the first happens and does the work of both.
(Hope that made sense, just got home from a VERY long day at work)

273
It definitely makes it easier when what is happening that isn't correct is stated.

But at a guess, it looks like your animation update function isn't using deltaTime, so the animation doesn't advance frames. Probably a totalTime+=deltaTime; should be in there.

274
so what should I use to get the binary without corrupting the data?
As Stauricus said, the easiest way to get stuff into SFML is to use the open/load functions. Music::openFromFile can load wav, ogg and flac. Texture::loadFromFile can load bmp, png, tga, jpg, gif, psd, hdr and pic.

But if you do want to open a binary file yourself (handy for things not part of SFML like save files, maps, etc), here's an quick example.
#include <fstream>
#include <filesystem>

int main()
{
    // Path to file
    std::filesystem::path p = "raw.dat";
    std::error_code ec;
    // Get the size of the file
    auto size = std::filesystem::file_size(p,ec);
    // Make sure no errors happened when getting the size
    if (!ec)
    {
        // Allocate enough memory for it
        char* data = new char[size];
        // Open the file for binary reading
        std::fstream in("raw.dat", std::ios::binary | std::ios::in);
        // If it opened...
        if (in.good())
        {
            // Read in the file
            in.read(data, size);
            // You now have the entire file sitting in data
        }
        // Release memory now that we are done
        delete[] data;
    }
    return 0;
}
 
This is using C++17, it added the file system stuff that can check the size of a file.
Also some may prefer to use a vector or something for the data, but I just stick to simple new/delete (yeah, I learned C++ long before std existed)

275
That loop is corrupting the data.
Wav files are binary data, they don't have lines as such. The getline function looks for end of line characters (which will be coincidental, since there's no lines to end) and strips them away. So the result in file will be missing bytes.
Wav is just waveform data, so you probably won't notice, but more complex formats like compressed textures will be corrupted.

Anyway, Texture has loadFromMemory, which is the equivalent of Music's openFromMemory.

276
Graphics / Re: How to optimize multiple draws
« on: May 21, 2021, 09:22:07 am »
What does a cell look like? If it's just a solid colour representing it's status, then you could use a texture. Set it's pixels to represent the cells. Then you can have any size (well, up to 8192x8192, maybe 16384x16384 depending on gfx card and if sfml lets it) with a single draw call.

For example:
                sf::Texture tex;
                tex.create(64, 64);

                sf::Image img;
                img.create(64, 64);

                img.setPixel(10, 20, sf::Color::Red);
                tex.update(img);
 
This makes a texture (which you'd use for a sprite or quad, etc) and an image. You can change the cells in the image using setPixel, then when all cell statuses are up to date, call tex.update(img) to upload the current image to the texture.

If the cells aren't simple blocks, something more complicated might be needed. (Shader, or multi pass blending)

277
Graphics / Re: SOLVED SFML can not open window.hpp
« on: May 21, 2021, 09:04:32 am »
Edit: Oh, I see the thread is now titled as solved. Cool. Ignore the below then. :)

No, there is a window.hpp include in graphics.hpp (line 32 in my version).

What did you set your include path to in your compiler? The graphics.hpp one is explicitly <SFML/Window.hpp> so it's looking in the include path for that. So you'd need to have External\include as part of the include path.
In visual studio c++, the addition includes setting is either relative to the project (where the .vcxproj file is) or an absolute path. If you are using mingw or something, that's not my area. :)

If you aren't sure how to get the correct include path, let us know the absolute path of where your window.hpp file is (for example c:\sdks\External\include\SFML\window.hpp) and the absolute path for your project file (for example C:\Users\kojack\source\repos\ConsoleApplication24\ConsoleApplication24.vcxproj).


278
Graphics / Re: SFML can not open window.hpp
« on: May 20, 2021, 10:24:52 pm »
You are missing the .. on the window.hpp include line.
..\ means go back one directory. Just a \ at the start means go to the root directory of the hard drive, which is a very different location.

279
Graphics / Re: Overriding sf::Drawable::draw
« on: May 16, 2021, 02:08:06 pm »
To override the draw function in an inherited class, you need to exactly match the function's signature.
The Drawable class has:
draw(RenderTarget& target, RenderStates states)
But yours is
draw(sf::RenderWindow& window, sf::RenderStates states)
(The sf namespace bit is fine)
A RenderTarget can refer to a RenderWindow or a RenderTexture.

280
Graphics / Re: Invisible vertical padding on text
« on: May 16, 2021, 01:18:45 pm »
    std::cout << "gb_box.left = " << text.getGlobalBounds().left << std::endl;
    std::cout << "gb_box.top = " << text.getGlobalBounds().left << std::endl;
    std::cout << "lb_box.left = " << text.getLocalBounds().left << std::endl;
    std::cout << "lb_box.top = " << text.getLocalBounds().top << std::endl;
The second line is printing the global bounds left again as the top value.

281
The Y part looks right, it's checking if the test point is below the top of the entity and above the bottom (so within the vertical range of the entity).
The X part is only checking if the test point is to the left of the entity.

Changing the X code to match the Y code should fix it.
if (Position.y > Entity->GetPosition().y && Position.y < Entity->GetPosition().y + Entity->GetSize().y) {
            if (Position.x > Entity->GetPosition().x && Position.x < Entity->GetPosition().x + Entity->GetSize().x) {
                return true;
            }
        }
The bottom return true should probably be return false though, since it fell through there because no entity overlapped the test point.

282
Ok, I was slightly wrong there. SFML does allow you to query how many buttons are really on a joystick, but clamps the value to 32 max. But there's no way to query how many axes or POVs there are.

Another issue, it sets up the Direct Input format for 4 groups of analog values, each having 6 axes and 2 sliders (so 4*(6+2)=32 total). Plus there's 4 POVs. But then says there's only 8 axes possible, and returns a single POV as the 7th and 8th axes, which should be the first 2 sliders.

An example of a common device that would break this limit if fully supported: Playstation controller. A DualShock4 controller has 16 analog axes:
- left thumb x
- left thumb y
- right thumb x
- right thumb y
- left trigger
- right trigger
- touchpad finger 1 x
- touchpad finger 1 y
- touchpad finger 2 x
- touchpad finger 2 y
- IMU gyro pitch
- IMU gyro yaw
- IMU gyro roll
- IMU acceleration x
- IMU acceleration y
- IMU acceleration z

Of course DirectInput only shows the first 6, but the rest are there if you go down to the HID level like I do. :)

Anyway, you got your issue working, I'll stop ranting now. :)

283
Yay.

I guess the issue with the change is that other platforms might not support it (I don't know, I only do windows dev). It's only in the windows specific implementation that the higher number is used, maybe linux/mac/android/etc wouldn't like it.

Ideally, SFML wouldn't use one set of constants for all joystick devices, but query the devices for exact numbers.

Soon I should receive a Wooting Two Lekker Edition keyboard. It has over 100 analog axes (every key is analog). So even 32 axes can be a little limiting. :)

I haven't checked on the first poll issue. It might depend on the device as to whether it sends initial state of everything on startup or only changes. That's one thing that really annoys me with MIDI programming. There's no way in MIDI to ask a device something like "what is the value of this slider?". Instead you have to wait for the slider to move, then you get an event saying the new value. So you can't get initial state of all controls.

284
Support for 128 buttons came out in 1997 in DirectInput 5.
But we still have games like Elite Dangerous that refuse to support it.
(It's a pet hate of mine, I've got Virpil hardware with more than 32 buttons and have to use software like Joystick Gremlin and vJoy to redirect my throttle through multiple virtual 32 button devices)

Looking at the SFML joystick code, it seems at least for Windows they may have forgotten to update the counts. Currently it's set to 8 axes and 32 buttons (and 4 POVs, but they don't get a count constant).
But the setup code is using a custom format structure with 32 axes, 32 buttons and 4 POVs.
But then the setup code says the number of objects in that struct is 32 axes, 128 buttons and 4 POVs (with 96 buttons undefined) by saying the format was the same size as DIJOYSTATE2 afterall.

So by the look of it (haven't tested) changing ButtonCount to 128 and AxisCount to 32 in joystick.hpp (and recompiling SFML) should be enough. The joystick setup code is ignoring AxisCount and is hard coded to 32 anyway (just won't let you look at them due to AxisCount), while it does use ButtonCount to set up the buttons.

On a side note, since nothing dynamic is being done there (like allocating exactly the number of axes/buttons on the device by enumerating all controls), the 80+ lines of format setup could be replaced with:
result = m_device->SetDataFormat(&c_dfDIJoystick2);
(c_dfDIJoystick2 is the already set up by DirectInput 32 axis, 128 button, 4 POV format)
Unless I missed something it's doing in there.

I might test it later if I get time.

285
System / Re: sf::Thread error
« on: May 04, 2021, 04:38:16 pm »
It seems to dislike the type of mouse_pos_loop.
How exactly is mouse_pos_loop declared? Also what exactly are au and Window? Namespaces or classes?
For example a free function in a namespace is different to a member function in a class when it comes to binding them to things like threads.

Pages: 1 ... 17 18 [19] 20 21 22