1
Graphics / Re: Texture.loadFromFile("") error
« on: March 07, 2018, 04:37:36 pm »
Are your SFML libs linked to your project correctly?
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.
2
Graphics / Re: Some textures become white square when I'm in release mode.
« on: March 07, 2018, 04:36:01 pm »
Create TextureManager::textures as a private member (consider using a map instead of an array) of your TextureManager class and use your GetTexture accessor to return from it.
3
General discussions / Re: Game stuttering? It could be Nvidia Threaded Optimisation.
« on: January 26, 2018, 06:23:54 am »
FYI, you can use NVAPI to set a custom profile to force disable threaded optimization for your project.
That setting is pretty controversial and has been for while. I'm not a fan of it being enabled.
That setting is pretty controversial and has been for while. I'm not a fan of it being enabled.
4
Graphics / Re: Possible glTexCoordPointer issue
« on: September 30, 2017, 05:26:59 am »
I did a little more snooping, and the level in which I could replicate this bug does have a VertexArray that is not given a texture, so I was incorrect in my original statement. Sorry about that!
5
Graphics / Re: Possible glTexCoordPointer issue
« on: September 30, 2017, 04:03:45 am »
Yup, that fixed it! Very nice job. Thank you.
6
Graphics / Re: Possible glTexCoordPointer issue
« on: September 29, 2017, 06:06:05 am »
I use sf::VertexArrays and append 4 sf::Vertexs to create quads to populate it. I also use sf::Sprites. They all have textures applied. I apply the texture to the sprite prior to drawing, and I draw the VertexArrays by passing them to the draw function of a RenderTexture, along with the texture.
The game is called Turnover. I released it at the end of 2015. Just doing my best to keep it updated and as bug free as possible.
The game is called Turnover. I released it at the end of 2015. Just doing my best to keep it updated and as bug free as possible.
7
Graphics / Re: Possible glTexCoordPointer issue
« on: September 29, 2017, 02:02:59 am »
* Win 10. GTX 1080. 385.69.
* Yes. Restarts of game + restarts of PC. Happened in my Win, Linux, and Mac builds.
* No, it affects a a number of sprites in the game, but these particular sprites I can get happening repeatably. I haven't run into this issue until recently. I was testing some changes when I saw it happening. I keep backup of all of my built library revisions, so I kept stepping back until I came upon this commit. Commented out code and everything is fine.
* Keeps happening on and off with other ones.
* No.
* No.
* I haven't, but I'll look into it if you want.
* Yes. Restarts of game + restarts of PC. Happened in my Win, Linux, and Mac builds.
* No, it affects a a number of sprites in the game, but these particular sprites I can get happening repeatably. I haven't run into this issue until recently. I was testing some changes when I saw it happening. I keep backup of all of my built library revisions, so I kept stepping back until I came upon this commit. Commented out code and everything is fine.
* Keeps happening on and off with other ones.
* No.
* No.
* I haven't, but I'll look into it if you want.
8
Graphics / Possible glTexCoordPointer issue
« on: September 28, 2017, 08:17:30 pm »
Hi.
In reference to this commit: https://github.com/SFML/SFML/commit/973ac8ddcd5eea22a01556405e16c554c7dd9788
With commit: https://i.imgur.com/a1llfMb.jpg (notice incorrect coords with camera and pc console)
Without commit: https://i.imgur.com/4bJX1EY.jpg
When I comment out the code (as seen in pic #2), everything is fine.
The actors that affected are sf::Sprites. Anyone else encounter this issue?
In reference to this commit: https://github.com/SFML/SFML/commit/973ac8ddcd5eea22a01556405e16c554c7dd9788
With commit: https://i.imgur.com/a1llfMb.jpg (notice incorrect coords with camera and pc console)
Without commit: https://i.imgur.com/4bJX1EY.jpg
When I comment out the code (as seen in pic #2), everything is fine.
The actors that affected are sf::Sprites. Anyone else encounter this issue?
9
General / Re: Window xlib event issue? Solus Linux
« on: February 02, 2016, 03:08:55 pm »
I poll the event queue regularly, so it is not that.
That's what is strange. PollEvent is being run AS I get the "Force Quit" dialog. PollEvent, up to that point, had been running regularly leading up to the freeze.
My game takes maybe a second to first load. So the window manager sees it as a freeze that quickly?
That's what is strange. PollEvent is being run AS I get the "Force Quit" dialog. PollEvent, up to that point, had been running regularly leading up to the freeze.
My game takes maybe a second to first load. So the window manager sees it as a freeze that quickly?
10
General / Re: Window xlib event issue? Solus Linux
« on: February 01, 2016, 05:46:12 pm »
The game is actually running fine when it happens.
Thanks for the suggestion, but I tried pollevents on startup and it didn't fix it.
Thanks for the suggestion, but I tried pollevents on startup and it didn't fix it.
11
General / Window xlib event issue? Solus Linux
« on: January 28, 2016, 08:07:07 pm »
Just want to report an issue. I'm using the latest SFML.
I'm experiencing a similar thing this user ran into (since fixed for him):
http://en.sfml-dev.org/forums/index.php?topic=18803.0
I originally had this problem in Ubuntu but it was solved some time ago as you can see with the same patch:
http://en.sfml-dev.org/forums/index.php?topic=18799
A player of my game is having this problem on the Solus Linux OS. https://solus-project.com/
I was able to replicate it. When my game is launched, within 5 seconds I get the "Force Quit/Wait" dialog. Clicking "Wait" allows the game to played w/o problems and everything else seems to work fine. The "Force/Quit" will also popup intermittently for another user. I just experience on first launch.
I feel that this is possibly related to the original issue. No other Linux distro I tested (Ubuntu, Debian, ArchLinux) seems to have this problem. Thought I'd let you know.
I'm experiencing a similar thing this user ran into (since fixed for him):
http://en.sfml-dev.org/forums/index.php?topic=18803.0
I originally had this problem in Ubuntu but it was solved some time ago as you can see with the same patch:
http://en.sfml-dev.org/forums/index.php?topic=18799
A player of my game is having this problem on the Solus Linux OS. https://solus-project.com/
I was able to replicate it. When my game is launched, within 5 seconds I get the "Force Quit/Wait" dialog. Clicking "Wait" allows the game to played w/o problems and everything else seems to work fine. The "Force/Quit" will also popup intermittently for another user. I just experience on first launch.
I feel that this is possibly related to the original issue. No other Linux distro I tested (Ubuntu, Debian, ArchLinux) seems to have this problem. Thought I'd let you know.
12
General / Re: Windows Focus(?) Issue on Ubuntu (8/12 commit)
« on: August 17, 2015, 04:47:23 pm »
This appears to have fixed the problem. Thanks!
13
General / Re: Windows Focus(?) Issue on Ubuntu (8/12 commit)
« on: August 14, 2015, 10:13:07 pm »
Sounds good, thank you.
14
General / Windows Focus(?) Issue on Ubuntu (8/12 commit)
« on: August 13, 2015, 04:56:56 pm »
https://github.com/SFML/SFML/commit/561eb82f14e77f3c9b9e6bd50e59971eef1e9bda
This commit I believe is causing a problem. Running my program, the window will fade to black & white in Ubuntu if you idle for a few seconds. The 8/4 commit prior does not have this problem.
I cannot provide a code example, but I'm certain you can easily replicate it.
Here's a shot of my desktop w/ the fade problem (8/12 commit build).
And here's what the window is supposed to look like (8/4 commit build).
Some background:
* I request focus post window creation, so requesting focus does nothing.
* When I click in the window, it does not fade back in. It remains black & white regardless. Color never comes back.
* None of my code has changed in between each SFML commit above. What worked before no longer works.
If you need more info, I'll provide what I can.
This commit I believe is causing a problem. Running my program, the window will fade to black & white in Ubuntu if you idle for a few seconds. The 8/4 commit prior does not have this problem.
I cannot provide a code example, but I'm certain you can easily replicate it.
Here's a shot of my desktop w/ the fade problem (8/12 commit build).
And here's what the window is supposed to look like (8/4 commit build).
Some background:
* I request focus post window creation, so requesting focus does nothing.
* When I click in the window, it does not fade back in. It remains black & white regardless. Color never comes back.
* None of my code has changed in between each SFML commit above. What worked before no longer works.
If you need more info, I'll provide what I can.
15
General discussions / Forked SFML, merged grab_mouse
« on: December 11, 2014, 07:33:33 pm »
Not certain which forum to post this to.
I wanted to test and play with grab_mouse w/ the latest SFML revision, so I forked everything off and merged the two. I think I did everything correctly and my initial tests (integrated with my project) with Windows, Linux, & MAC OS X have been fine.
Here's the link to my fork if anyone wants to play around:
https://github.com/anthnich/SFML
Honestly, I'm not certain if you guys discourage this type of thing. So, if I made a faux pas, just let me know.
I wanted to test and play with grab_mouse w/ the latest SFML revision, so I forked everything off and merged the two. I think I did everything correctly and my initial tests (integrated with my project) with Windows, Linux, & MAC OS X have been fine.
Here's the link to my fork if anyone wants to play around:
https://github.com/anthnich/SFML
Honestly, I'm not certain if you guys discourage this type of thing. So, if I made a faux pas, just let me know.