Messages

91

Graphics / Re: Using map.emplace with sf::Shader

« on: May 04, 2017, 01:02:01 pm »

You're still copying.

I think you want:

m_shaders.emplace(rName);

That isn't valid syntax; it's an std::map/std::unordered_map

Ah, you're right, I was thinking of C++17's try_emplace.

92

Graphics / Re: Using map.emplace with sf::Shader

« on: May 03, 2017, 10:49:05 pm »

You're still copying.

I think you want:

m_shaders.emplace(rName);

93

Window / Re: Preventing window resize on Linux?

« on: April 29, 2017, 12:58:58 am »

In my experience with tiling window managers (such as i3, as you mentioned specifically), they take a "the user is always right" approach, often ignoring size requests from windows (except for dialog boxes and the such, although this is often configurable).

A "classic" floating window manager should behave the way you expect. If a user is using a tiling window manager, (in my opinion) it can be assumed the user knows what they want.

I'm not 100% certain, but a workaround might be to have your application provide a floating hint of some sort (I don't recall the API to do this).

94

Graphics / Re: A simple question of resolution problem

« on: April 21, 2017, 08:01:52 pm »

Does your image have any alpha values less than 0xff? That's what it looks like to me - you're clearing white, and the somewhat transparent areas are showing the white through.

EDIT: Yep, took a look. Your background is transparent, hence the white showing through.

95

SFML projects / Re: Need ur help! You have a 4K monitor or any other "weird" resolution? -> Free key

« on: April 21, 2017, 08:00:01 pm »

I have ultrawides (21:9, 2560x1080), landscape and portrait.

96

SFML development / Re: Clipboard Support

« on: April 07, 2017, 09:23:45 am »

For what it's worth, I don't think an example could hurt at all! At least, I've never seen "too much documentation"; professional or open-source.

97

Audio / Re: Music Play

« on: March 27, 2017, 03:40:58 am »

Well you aren't ever calling death.play() inside of the if statement checking p.life == true, so it won't ever play.

98

Graphics / Re: What is the limit of how many textures you should have ?

« on: March 17, 2017, 02:54:29 am »

It's going to depend on the amount of VRAM available, and supported API levels.

So the best solution would be to find numbers on the average amount of VRAM a computer has, and target that with your max.

Based off your numbers (rounding up, and simplifying):
256x512 * 16 * 4                       = 8,388,608 bytes, or ~8 mebibytes. Unless you're targeting hardware from the 90s, you're fine.
(size)          (#)   (bytes per pixel)

99

Graphics / Re: What is the limit of how many textures you should have ?

« on: March 16, 2017, 06:52:44 pm »

It's going to depend on the amount of VRAM available, and supported API levels.

As for maximum texture size, that can be acquired via sf::Texture::getMaximumSize()

100

General / Re: Is there anything I need to know before migrating my project to SFML 2.4.2?

« on: March 13, 2017, 03:34:38 am »

/usr/local/* isn't always in your PATH variable by default.

I'd double check that.

101

General / Re: Float precision and pixel accuracy

« on: March 11, 2017, 06:15:05 pm »

Ah yes, I was incorrectly assuming the whole parts of both values would be the same, like in Elias' image.

Another solution would be to just embrace it.
I mean, how often do things stay perfectly still on top of moving things?
Of course, that depends on the amount of jittering.

102

General / Re: Float precision and pixel accuracy

« on: March 11, 2017, 05:15:46 am »

std::round rounds up for 0.5 >=, and rounds down for < 0.5.
That could be the cause.

I'd be surprised if std::ceil/std::floor/std::trunc has the same issue.

103

Graphics / Re: Is there some way of collision different than pixel perfect and getGlobalBounds?

« on: March 04, 2017, 04:35:57 am »

If you're doing just circle-circle collision, the simplest method is:

• Get the difference vector between the centers of both circles
• Subtract the length (or length squared) of the difference vector by the radius (or squared radius) of both circles.
• Negative result is collision, positive result is no collision

104

System / Re: Embedded image using resource

« on: March 03, 2017, 05:14:28 am »

It's still in beta, so maybe just up for future consideration, but Steam Audio was released recently.

105

Audio / Re: Continuous sound stream from generator function

« on: February 17, 2017, 08:19:45 pm »

Your fillBuffer function is copying your pointer (activeBuffer_m in this case), so it's not changing activeBuffer_m like you want. You want fillBuffer to take a reference to a pointer, or a pointer to a pointer.
So you actually have a memory leak (paramBuffer is never deleted).

BUT, since it's a member function, you don't need to do that. In fact, I'd get rid of fillBuffer. onGetData should be doing what fillBuffer is currently doing in my mind.

Furthermore, the two buffers is complicating things more than helping, I think. Personally, I'd make a static sized array of size SOUNDSAMPLES and just reuse it every time onGetData() is called (SFML makes a copy of what you give it, so this if fine).
Then, you don't have to do any manual memory management, and it technically would be more efficient as well, since you won't be allocating and freeing memory every SOUNDSAMPLES samples.

Doing this stuff would also make implementing onSeek() easier to implement when you get around to it too (just a change of t_m).

Other design stuff:
If you're not ever changing x_m, I'd make it a constant.
load() should really be a constructor.
x_m and x_t don't indicate to me their meanings without context, I'd rename them to something that indicates their meaning better (I'm actually not 100% sure what x_m is. I'd rename t_m to something like "currentTime", "timePosition", etc).

Hope this helps.