Messages

181

General / Re: SFML doesn't work with my Qt Creator

« on: March 19, 2016, 09:41:46 pm »

Have you tried debugging to see where your program is getting stuck at? (ie, put a breakpoint at the first line of your main() and step through until you find the issue.)

182

Feature requests / Re: Get Monitor Refresh Rate.

« on: March 18, 2016, 08:08:22 pm »

Daniel, I think you're confusing what you're talking about with a mix of double-buffering (which SFML already does for you) and vsync (which is an option in SFML).

183

Graphics / Re: Codelite and SFML

« on: March 12, 2016, 10:10:30 pm »

If you want to compile SFML, you simply get the SFML's source code and build it with whatever compiler you want.

If you don't want to compile SFML, you need to get a version that was built with the same compiler you want to use.

184

SFML projects / Re: Blind Jump: Space Themed Adventure Game with Roguelike Elements

« on: March 10, 2016, 11:14:22 pm »

I know it's not that different what others have already said, but, I absolutely love how the game looks.

That smooth-pixelated look is just awesome.

185

General / Re: ExMa2D [C++14] (feedback)

« on: March 06, 2016, 08:44:04 pm »

I initially used .inl, but I ceased to do so for two reasons. The first one is that the different extension doesn't really bring anything. I don't and won't use non-template files, so it doesn't help in differentating template from non-template implementations. I also make clear in README the library is header-only. Second one is that a great number of editors don't support c++ syntax highlighting for .inl nor .tpp rightaway, but they do it for .cpp. I know this is changeable, but I don't want to make potential contributors to go find that, just because this library is header-only.
Those are the things I have considered when doing this decision, if there's more to this, I'll be glad to hear you out!

For what it's worth, I was a bit confused as to why the extension was .cpp at first. The reason I make the extension for template implementations is for compilers. A compiler will try to compile a .cpp unless set otherwise, which would give a fair amount of errors! That reason alone is why I would give a different extension, plus it's almost an unwritten rule to do so (if that's the correct wording...).

Otherwise, I like it! Looks well done to me!

186

Feature requests / Re: Vulkan Support

« on: February 19, 2016, 07:35:23 pm »

I don't know why people think Vulkan will run on OpenGL 1.1 hardware. Desktop wise, the only drivers for Vulkan right now are Nvidia 6xx+, Intel 5th Gen+ (Broadwell and up), and AMD (I didn't realize they supported this large of a range of hardware) actually goes back to R7 200+, including a fair amount of APUs.

The one benefit that stands out to me if SFML were to use Vulkan is easier use of SFML in multithreaded applications (not just multithreaded drawing, loading of graphical resources on a different thread would be easier).

However, SFML wants to support older hardware and OSX. Apple does not support Vulkan. There is a Vulkan wrapper around Apple's Metal in development, but that's it (for now at least).
In addition, using Vulkan would incur a lot more work for SFML devs. For instance, a hello triangle sample is almost 800 lines (it does include code for running on multiple OSs, but that's still a lot compared to OpenGL!).

Unless SFML's goals and ideals change (I doubt it, nor would ask for it), I don't think Vulkan-backed SFML will bring more pros than cons right now. Maybe once Vulkan has matured a bit, and the drivers actually leave beta, it may be worth looking at again.

Also, given that SFML tends to be used by newbies or those who want something that just simply works to get something working quickly, Vulkan doesn't bring much benefit there either.

Yes, Vulkan is a great thing, and very cool. I'm starting to play with it on the side. For SFML, I don't think it's a plausible option yet.

EDIT: I guess I just basically restated what has already been said. Oops.

187

Feature requests / Re: function to create/delete/take list directory contents of folder

« on: February 12, 2016, 06:21:47 pm »

Haha, I figured it was just a mistake! I just wanted to clear things up, just in case.

188

Feature requests / Re: function to create/delete/take list directory contents of folder

« on: February 11, 2016, 10:06:51 pm »

Cereal is a serialization library, right? That's nothing like Boost.Filesystem, that's like Boost.Serialization. That's not what he asked for.

But making your own isn't too much work if you don't want to use Boost.

For example, Vittoreo Romeo has one in his Utils library: https://github.com/SuperV1234/SSVUtils

I made my own once, though it does not have OSX support because I don't have OSX to try it with: https://github.com/dabbertorres/gfs

Or you can use something like PhysFS (https://icculus.org/physfs/) with a virtual filesystem.

189

General / Re: sfml with gcc 5.2

« on: February 05, 2016, 04:06:18 am »

You're probably not linking to the newly created libraries.

You're not showing your compile/link commands.

Also, why are you using gcc 5.2? 5.3 fixes bugs in 5.2.

190

General / Re: text doesn't draw

« on: February 03, 2016, 06:12:17 pm »

Calling glBindBuffer(..., 0) fixes it because you forgot to call it in the first place. You bound your vboID buffer. It's still bound when SFML goes to draw text, so OpenGL then tries to use the vboID buffer for drawing text.

Generally, once you are finished with a buffer (after drawing, pushing data to it, etc), you unbind it with a call to glBindBuffer(..., 0).

191

Graphics / Re: Problem with RenderTexture's Position

« on: January 31, 2016, 08:58:51 pm »

Runs fine here. Ideally, it's a bit big for a minimal example. But oh well.

Only thing I ran into was a NullPointerException when disposing Sounds.music1. (In Level.OnKeyPressed. Simple fix of checking if it isn't null before calling Dispose)

I also didn't get any messages about optimal resolution. Though, I have a different system spec than you.

Does it still happen if you don't run in Fullscreen? (ie, Styles.Default)

You have quite an old graphics card. My best guess is you're running out of graphics memory. Unfortunately, the only thing you can do is load less really, as far as I am aware.
Since it's old enough, you could try making sure your textures are all power of 2 in size. I would also change to windowed mode, or change your window's resolution to 1366x768.

Unfortunately, without more information about the crash, I'm only guessing at this point.

192

Graphics / Re: Problem with RenderTexture's Position

« on: January 30, 2016, 03:14:37 am »

Glad to hear progress has been made!

If it got that far, I'm going to assume that you got the right driver. Could be wrong, but let's assume you got the right one for now.

Without code, I can't say anything though. I would start by setting a breakpoint around where in the code the app stops responding, and step through until you find what function call, etc causes the issue.

When you figure that out, see if you can put together a minimal example that reproduces the issue like before. That will be helpful.

I think you're close too!

193

Graphics / Re: Problem with RenderTexture's Position

« on: January 29, 2016, 12:30:42 am »

You're using the built-in Microsoft graphics driver. That's probably the cause of all your problems, including your game running slow.

To get the correct driver, you'll want to look through here: https://downloadcenter.intel.com/product/81507/Graphics-Drivers-for-Mobile-Intel-4-Series-Express-Chipset-Family

194

Graphics / Re: Problem with RenderTexture's Position

« on: January 27, 2016, 08:31:55 pm »

The grey background (and also square outlines) is because the application is not responding.

Oh. Goes to show my familiarity with Windows. Haha.

I think everything will be correct after yuo insert event loop

Well, not necessarily... It worked fine on my machine without an event loop, and I presume his actual game has an event loop. This is a minimal example.

195

Graphics / Re: Problem with RenderTexture's Position

« on: January 27, 2016, 06:03:12 am »

Well that IS odd. Especially the gray background, as your code does not specify that gray anywhere that you've shown.

What kind of graphics card are you using?