Messages

121

General / Re: My poor SFML games run very slow on 64 bit system

« on: August 06, 2015, 07:45:43 pm »

The frequency of the processor does not determine the performance, and that's not even mentioning core count. You also have to take into consideration other factors like the OS, graphics device, background processes, etc. Your computer could just be really slow or something's wrong with your game. It's unlikely the fault of SFML.

It'd be helpful to know:

- The language(s) you're using
- The compiler (and version) you're using
- The version of SFML you're using
- The compiler options
- The computer's specs (CPU model, graphics device model, OS, etc)
- Benchmark information (use SFML's timers to see the average time spent rendering, average time spent updating logic, etc)
- You're games source

These are a bit general, but based off of wild guesses you could try:
- Updating the drivers
- Stop background tasks
- Turn on compiler optimizations
- Improve your code (not be applicable if it's your computer's fault, but it may be yours)

122

General / Re: Several strange errors while compiling with MSVC 2015

« on: June 13, 2015, 06:12:07 am »

How can I recompile them?

123

General / Several strange errors while compiling with MSVC 2015

« on: June 13, 2015, 05:40:57 am »

I'm trying to compile SFML 2.3 with Visual Studio Community Edition (2015) and I'm getting weird compiling errors. This is limited to this particular version of MSVC as 2013 does not exhibit any compiler errors while trying to compile using the exact same process.

To compile, I went to command prompt, called vcvars32.bat, opened c-make gui, then setup selected the appropriate folders, then generated the project files. It compiles successfully for a few seconds before it starts spitting out errors.

And the errors listed include (but not limited to):
unresolved external symbol __iob_func_referenced in function_output_message
unresolved external symbol __iob_func
unresolved external symbol __vsnprintf_s
unresolved external symbol _vsnprintf_s referenced in function _local_vsnprintf

Here's a screenshot:

124

Graphics / Re: Is it possible to draw fonts without an SFML window?

« on: June 06, 2015, 10:23:54 am »

I want to be able to use it draw to an OpenGL context that is not created with SFML (and therefore doesn't have an SFML window). So I am limited to OpenGL as the API for drawing (no SFML window to draw to).

125

Graphics / Is it possible to draw fonts without an SFML window?

« on: June 06, 2015, 09:35:11 am »

What I mean specifically is, is it possible to draw them with just OpenGL? The tutorials teach how to draw fonts with SFML's window. But I assume they're drawn with OpenGL behind the scenes, but how?

126

Feature requests / Re: Can we make RenderStates and Drawable loadable resources?

« on: May 28, 2015, 01:12:30 am »

Using a 3D format to support 2D geometry is a terrible idea.

3D formats exist because 3D is notably more difficult than 2D, and unless you're creating a voxel engine it would be extremely difficult to create 3D models without some sort of modeling software. And of course, you need a specified format that your modeling software supports and a parser is available for it. Hence such a formats' existence.

2D almost never needs such a system. Pretty much any problem from rendering to collision can be handled without resorting to detailed geometry files. Which would greatly explain why such a format doesn't even exist.

SFML is fairly high level, and mostly is for taking away complexity where it doesn't benefit the developer (such as dealing with OpenGL, OpenAL, the native API, etc), but assumes you can handle everything that is irrelevant to it's libraries (system, sound, graphics, networking, etc). Parsing non-standard formats is one of those things.

You might want to parse X format, the next guy Y format, but we can't parse everything in existence. What SFML can do is utilize formats like PNG and WAV because they're ubiquitous. And A 3D format not utilized properly is still considered, at least by me, to be non-standard.

But I still don't know why you want to do this. If you want your game easily editable, do like I said and just use a scripting language, and if you want to simplify modding/development even more, have your engine work out the exact vertex coordinates on it's own.

After all, wouldn't:

draw.lua

local shader = graphics.getShader("shaders/custombutton.vert", "shaders/custombutton.frag")
function drawButton(button)
    graphics.useShader(shader)
    graphics.setTexture(button_texture)
    graphics.drawRectangle(button:getX(), button:getY(), button:getWidth(), button:getHeight())
end
 

Be easier to edit AND a lot more flexible than this?

button_vertices.obj

v 0.0, 0.0, 0.0
v 0.0, 1.0, 0.0
v 1.0, 0.0, 0.0
v 1.0, 0.0, 0.0
v 0.0, 1.0, 0.0
v 1.0, 1.0, 0.0
t 0.0, 0.0, 0.0
t 0.0, 1.0, 0.0
t 1.0, 0.0, 0.0
t 1.0, 0.0, 0.0
t 0.0, 1.0, 0.0
t 1.0, 1.0, 0.0
 

button_draw_details.txt

vertex_shader=shaders/custombutton.vert
fragment_shader=shaders/custombutton.frag
 

127

Feature requests / Re: Can we make RenderStates and Drawable loadable resources?

« on: May 27, 2015, 09:34:56 pm »

No information in a computer is readable without some kind of editor or viewer. A text editor. A graphics editor. A vertex editor.

A vertex parser would be trivial, and so would the rest of what I suggest. A sprite class is also trivial if all its components have already been implemented, so why make a sprite class a part of the library? Because it makes the library easier to use and the cost of adding it is not high in terms of added complexity or time.

My question is why not make my suggestion a part of the library? It makes skinning GUI and characters easier, and it makes a few other tricks easier too, like loading animation sequences (sequences of changes in vertex and texture information)

Have you considered using a scripting language for doing that? It would add the ability to do more complex graphical effects (beyond simply changing textures and shapes) that can be programmed in while maintaining ease-of-use and editing on the fly.

128

Feature requests / Re: Can we make RenderStates and Drawable loadable resources?

« on: May 27, 2015, 08:54:11 pm »

There is no standard human-readable text format for such information that I'm aware of, but writing your own parser for vertex information and resource paths is trivial. std::fstream, std::stringstream and std::string should be all you need.

129

Feature requests / Re: Send a close event to waitEvent

« on: May 27, 2015, 02:35:57 am »

I hesitated to put a mutex in because I didn't want to get it caught with the waitEvent call, and I made the assumption that it was safe enough since I haven't had a crash directly do to that yet (though, I recognized that it was a problem that should eventually be fixed).

Now that I see that waitEvent is actually just a wrapper around pollEvent with a 10ms timer, I'm just going to start using pollEvent (which at least helped me fix the no mutex issues). I'll just use a bool as a quit flag and check it alongside the pollEvent call. So that problem is fixed.

Anyways, back to the original topic, I see why it wasn't implemented given how waitEvent works. But more importantly, why is that function even implemented the way it is? I can't think of any reason why it wouldn't actually do a system call of some sorts. Seems like not only a potential waste of CPU cycles (if no event is triggered), but a small (granted, virtually unnoticeable) delay up to 10ms between when an event is triggered and when the application gets it.

Regardless, I still think it's a feature that should be in there, as it would still be cleaner than making my own system to do just that.

EDIT:
I just re-read Nexus' post.
With the current implementation, interrupting the blocking call should not be difficult -- but have you researched a bit what it would mean to a true OS-supported event waiting? Is the interrupt even feasible on all operating systems?

I'm no expert in writing these kinds of libraries, but it seems to be supported on others.

130

Feature requests / Send a close event to waitEvent

« on: May 27, 2015, 01:15:35 am »

After many hours of frustration, I found out that trying to close a window from a secondary thread while the primary thread (the window "owner") is waiting for an event will cause the program to abruptly crash due to a segmentation fault caused by SFML. Now I can only mend the issue by polling events every x milliseconds, but it's just not the same.

I'd figure adding the ability to send a close event to a window wouldn't be that difficult. GLFW has something similar that lets me avoid this very problem (an empty event, though, but still gets the attention of the primary thread). I don't know why it's not implemented, but I'd like to see it.

To clarify further, something along the lines of:

window.postCloseEvent();

to cause

sf::RenderWindow::waitEvent

to return a

sf::Event::Closed

when called.

131

Graphics / Can I use SFML to load OpenGL textures?

« on: January 19, 2015, 12:16:40 am »

I'm new to SFML and I'm wondering if it's possible to load an OpenGL texture using SFML? I don't want to draw the texture using SFML but I do want to load textures so I can use them with OpenGL. Is this possible? If so, what do I do to do it?