196
Graphics / Re: playing Animations or GIFs
« on: January 25, 2016, 04:52:56 pm »
https://github.com/lucidspriter/SpriterPlusPlus - official implementation
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.
197
SFML projects / Re:creation - a top down action adventure about undeads
« on: January 06, 2016, 03:28:16 am »
Some sort of event/trigger system is the most reusable method I've seen for something like this.
198
SFML projects / Re: Selba Ward
« on: January 04, 2016, 10:15:57 pm »
There you go, make a sw::Quine SFML drawable!
199
Graphics / Re: Access violation when pushing into vector<std::unique_ptr<sf::Text>>
« on: January 02, 2016, 11:42:37 pm »
Can't tell what's going on without a minimal example.
200
General / Re: Linker undefined references
« on: December 26, 2015, 11:56:16 pm »
The SFML version you downloaded is not compatible with the compiler you're using (different versions, 4.x vs 5.x).
For that compiler, you'll need to compile SFML yourself (not difficult at all).
For that compiler, you'll need to compile SFML yourself (not difficult at all).
201
SFML projects / Re:creation - a top down action adventure about undeads
« on: December 17, 2015, 04:29:30 am »
^
Can even take it a step further and make a "game save editor" of sorts. That can help with debugging as well. Set the game to be at a certain level of completion or whatnot, and make sure the game loads and starts/runs fine, etc.
(Though, depending on game format, may be as simple as a bunch of checkboxes!)
Can even take it a step further and make a "game save editor" of sorts. That can help with debugging as well. Set the game to be at a certain level of completion or whatnot, and make sure the game loads and starts/runs fine, etc.
(Though, depending on game format, may be as simple as a bunch of checkboxes!)
202
General / Re: New to SFML, creating my own game and guidelines needed!
« on: December 12, 2015, 11:10:33 pm »
That would create/destroy an std::mt19937 every time that function is called though. Which isn't a very good idea, it's not small by any means. And recreating it generally loses the whole point of randomness.
An explanation: http://www.elbeno.com/blog/?p=1325
An explanation: http://www.elbeno.com/blog/?p=1325
203
SFML projects / Re:creation - a top down action adventure about undeads
« on: December 05, 2015, 11:54:14 pm »
I just always use '\n'. Everything I've used except Notepad (which no one in their right mind uses for programming) parses it just fine.
204
Graphics / Re: Problem when resizing view to be same size as new window
« on: December 04, 2015, 11:41:03 pm »
Are you seeing what I'm seeing?
205
Graphics / Re: Problem when resizing view to be same size as new window
« on: December 04, 2015, 11:18:45 pm »
I'd try modifying the texture to be power of 2 dimensions.
Though, I made an interesting observation.
I ran your example with the image provided. I only changed the std::cout line to view.getSize().* instead, to see if there was something changing in the view.
The even/oddness of the view size is making the effect, and it's reproducible.
When the new width is odd, the sprite/texture gets shifted noticeably to the right a pixel or so.
When the new width is even, the sprite/texture gets shifted noticeably to the left a pixel or so.
If the current width is already even, and the new width is even, there is no movement, and the same goes for odd.
Same goes for the height.
What graphics card and driver do you have?
For reference, I'm on a GTX 970 with the 359.00 driver. (Tested on Windows 8.1, haven't tried it on Linux)
Though, I made an interesting observation.
I ran your example with the image provided. I only changed the std::cout line to view.getSize().* instead, to see if there was something changing in the view.
The even/oddness of the view size is making the effect, and it's reproducible.
When the new width is odd, the sprite/texture gets shifted noticeably to the right a pixel or so.
When the new width is even, the sprite/texture gets shifted noticeably to the left a pixel or so.
If the current width is already even, and the new width is even, there is no movement, and the same goes for odd.
Same goes for the height.
What graphics card and driver do you have?
For reference, I'm on a GTX 970 with the 359.00 driver. (Tested on Windows 8.1, haven't tried it on Linux)
206
General / Re: Linking on Linux
« on: November 15, 2015, 07:20:11 pm »
You've mixed 32bit and 64bit libraries at some point it looks like. Previously at some point though it seems. I'd do a full clean and rebuild.
207
General / Re: Linking on Linux
« on: November 14, 2015, 11:00:47 pm »
gdi and winmm are Windows only.
208
Feature requests / Re: Int32 overloads for sf::Time *, /, *= and /= operators
« on: November 11, 2015, 11:20:26 pm »
Doxygen I can understand. I have some questions about your other points, but it's getting a bit off-topic!
(btw: casts are strictly speaking explicit conversions)
[/quote]
Hmm. True, I guess you guys want sf::Time to be more than just a "unit conversion class" of sorts. Makes sense. (And thank you for the wording correction.)
For now, what about an implicit cast to sf::Int64?That defeats the entire purpose of having a type-safe time class.
(btw: casts are strictly speaking explicit conversions)
[/quote]
Hmm. True, I guess you guys want sf::Time to be more than just a "unit conversion class" of sorts. Makes sense. (And thank you for the wording correction.)
209
Feature requests / Re: Int32 overloads for sf::Time *, /, *= and /= operators
« on: November 11, 2015, 09:47:43 pm »The true solution would be a template based on std::is_integral and SFINAE or tag-dispatching. But I don't really like that for something so simple (and I'm sure Laurent does so even lessWhy would it be an issue for something so simple? It's a simple problem, so why not use a simple solution? (minus the waiting for C++11/14/17 though))
For now, what about an implicit cast to sf::Int64? Though, an overload for operator= (or overloaded constructor) would be needed as well.
Here's what I thought:
Time& operator=(Int64 i);
operator Int64() const;
operator Int64() const;
Then that would allow arithmetic with whatever sf::Int64 can work with, and since sf::Time uses sf::Int64 internally, it should(?) work out.
That would allow people to do sf::Time a(5) and wanting 5 seconds, but I think that would be their fault for not reading the docs on what time unit the constructor expects. And I don't think that this would cause any compatibility issues (correct me if I'm wrong though!).
210
Graphics / Re: How to check video memory statistics?
« on: November 09, 2015, 05:26:30 am »
Either OpenGL vendor extensions or OS system functions. There is no standard.