Messages

1

Graphics / Optimizing sf::Text

« on: December 31, 2016, 08:41:02 pm »

Hello! I have been poking around with sf::Text recently and discovered that rendering sf::Text objects can be a little slow. Rendering 150 sf::Text object is taking about 200IS from what I can see. The UI I'm planning will end up being a bit text intensive so I am looking at optimizing sf::Text some.

From what I can tell sf::Text uses a sf::VertexArray for rendering normal text and an extra sf::VertexArray for outlined text. What I am thinking of attempting is potentially condensing these sf::VertexArrays into a single one since the sf::Text will not be changing outlined thickness much.

Another possible change I was thinking is making some sort of overlord sf::VertexArray that could be shared between many sf::Text objects. If the geometry does not need to be recalculated much (static text) then this would obviously save a great deal on the drawing.

This is all theoretical right now and I haven't made a real plan yet. Before doing that I wanted to see if anyone here had any thoughts or suggestions on how to go about this. Thanks!

2

General discussions / [PAID] Looking for C++ developer

« on: July 11, 2016, 07:36:40 pm »

Hello! I am looking to hire a C++ developer to work with me on continuing development of Crea (http://store.steampowered.com/app/280520), which is a 2D RPG Sandbox game that just released on Steam. Full details are provided in this Google Document. This includes full pay and some rev share. I am currently only looking to work with someone locally so you must be willing to relocate to Portland, OR.

If you have simple questions then you are free to ask them here but be sure to email me your application.

3

Graphics / Re: Shader crash on some Intel GPUs

« on: January 21, 2016, 08:49:30 am »

I was able to track someone down and dig into this some. I discovered that it is being caused by the RenderTexture substitute that I'm using. Another dev here, eigenbom, shared with me a FBOTargetImpl class that he wrote which provides a framebuffer that uses the same context as the window.

These intel cards do have support for framebuffers but they crash when attempting to bind the shader. I'm currently think that the context state is somehow getting messed up and the shader doesn't like that. FBOTargetImpl is not doing anything too special and after using it I always ensure that the framebuffer is reset as well as the GL states.

Any suggestions on what I could do to fix this? If needed I can post a bunch of the code. Just let me know. Thanks!

4

Graphics / Re: Shader crash on some Intel GPUs

« on: January 15, 2016, 09:46:35 pm »

I'm guessing this is on Windows?

Extension loading was overhauled between 2.2 and 2.3 in 3e397bff4b206cdaad9e1e52a75dfacb8676be31. Context management was gradually overhauled between 2.3 and now. I remember those changes fixing a bunch of weird bugs (including crashes), especially on Windows.

You might want to try out an experimental build using 2.3.2 and see if the problem persists.

Sure I can try the latest and see if that resolves the issue. I looked over what I exactly have in my fork and I am actually on 2.3.0. I have that massive extension overhaul and pulled this one in, 7c179193e6acf0c3fed97964ebcd1fabcd69dcd7, which fixed another intel gpu crash that was occurring. Thanks for the quick reply!

5

Graphics / Shader crash on some Intel GPUs

« on: January 15, 2016, 09:26:24 pm »

Hello! Several players for my game using intel GPUs are running into a crash inside sf::Shader. I have looked around for similar issues and to see if something like this has been fixed but I have not seen anything. I am using SFML 2.2~ with a few things pulled into it from 2.3. I do check if sf::Shader::isAvailable() and it is on these systems.

Here is what one of the stacktraces looks like:

Code: [Select]

ig7icd33
ig7icd32
ig7icd32
ig7icd32
crea!sf::Shader::bind
crea!sf::RenderTarget::draw
crea!sf::Sprite::draw
crea!sf::RenderTarget::draw
Another one:

Code: [Select]

ig7icd32
ig7icd32
ig7icd32
ig7icd32
crea!sf::Shader::setParameter
Unfortunately I do not have line numbers to go with these. To start with I was just curious if this been seen before or perhaps even fixed. If I can get one of these players to work with me I'll try coming up with a minimal code repro if that would be helpful here. Cheers!

6

Graphics / Re: Completely Resetting GL States

« on: January 09, 2016, 07:07:02 pm »

Hey Binary, you are always so helpful! Thank you! What you said did just the trick. <3

7

Graphics / Completely Resetting GL States

« on: December 30, 2015, 05:33:01 am »

Hello! I am currently working on upgrading my UI library (Coherent GT) and am running into a problem with rendering SFML stuff after calling the UI rendering function. I am passing a SFML created texture to the UI library, it renders to the texture and then I use that texture with a sf::Sprite. At least that is how it should work.

Right now it doesn't render anything after calling the UI paint function; however, I have verified that it correctly rendering to the texture (saved it to file). This has lead me to believe that there is something wrong with the GL state after the paint func. I am calling resetGLStates() after the paint func but it seems to be missing something. One really interesting thing about all of this is that sfml rendering works with the next frame.

The UI documentation is pretty good and they list out which GL states are changing but I'm not sure which ones SFML truly cares about. I was hoping I may get some guidance here. If not that is ok. I appreciate the help regardless. Thanks!

Coherent GT Rendering Documentation

8

Graphics / Re: Optimizing Rendering

« on: July 16, 2015, 05:23:15 am »

Yes to both of those. My rendering is taking up a great deal of time and so I was investigating if it is possible to slim that down.

9

Graphics / Optimizing Rendering

« on: July 16, 2015, 01:27:35 am »

Hello! I was wanting to see if anyone had any idea on how I can go about optimizing my rendering. I've been profiling my code and have found that a great deal of time is spent with GlContext::setActivate(). I am using several RenderTexture that I render to, display() and then pass to a shader. Because of this the program is constantly switching what it's rendering to which, from what I understand, is what calls setActivate().

Some possibilities might be:

• an amazing optimization that makes switching the context not so expensive (I can dream, right?)
• Rework my shaders so they don't need this. Although I'm not sure that is possible...
• I'm being stupid
• Something else?

One thing I have done so far is to try to minimize the switching by grouping the use of a RenderTexture together.

I can post code here however it is quite spread out. I'm mostly looking for ideas at the moment and/or seeing if I'm just doing something completely wrong. Thanks!

(Oh, and I'm on either SFML 2.1 or 2.2. I can't remember but it is fairly recent. I think from Sept. 2014.)

10

General / Re: SFML 2.3 OSX Dependency Linking Issue

« on: June 14, 2015, 06:16:42 pm »

I've done an otool -L on all of the extlibs and I find no mention of the dylib otherwise I'd do a install_name_tool -change on it, which I've done on many other things. Here's the output exactly as you said it'd be.

Jassons-MacBook-Pro:frameworks jmcmorris$ otool -L /Users/jmcmorris/crea/Crea.app/Contents/Frameworks/FLAC.framework/Versions/A/FLAC
/Users/jmcmorris/crea/Crea.app/Contents/Frameworks/FLAC.framework/Versions/A/FLAC:
        @rpath/../Frameworks/FLAC.framework/Versions/A/FLAC (compatibility version 12.0.0, current version 12.0.0)
        @rpath/../Frameworks/ogg.framework/Versions/A/ogg (compatibility version 9.0.0, current version 9.2.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)

I'd suggest recompiling them myself but I imagine you'd like to get this fixed since it is likely others will eventually run into this once they start upgrading to SFML 2.3.

If you'd like you can add me on skype (baskinein) and we can work on this together.

Cheers!

11

General / Re: SFML 2.3 OSX Dependency Linking Issue

« on: June 13, 2015, 06:08:08 pm »

Hey Hiura, I honestly don't know of the original intent for those options. I removed them and it does compile correctly but upon running the game app it is failing with a image not found mentioning the same thing but with a bit more information at least.

Dyld Error Message:
  Library not loaded: /Users/m/Prog/Projects/SFML/build_deps/libogg-1.3.2/build/1.3.2//i386/root/lib/libogg.0.dylib
  Referenced from: /Users/jmcmorris/crea/Crea.app/Contents/Frameworks/FLAC.framework/Versions/A/FLAC
  Reason: image not found

Here's the crash report that includes everything: http://pastie.org/private/05bodjqt3hcrllx6fbosa

I've looked through them with otool and cant find any mention of this libogg.0.dylib. Let me know if you want me to try anything. Thanks for the help!

12

General / SFML 2.3 OSX Dependency Linking Issue

« on: June 12, 2015, 06:50:55 pm »

Hello, hopefully this is a quick one to resolve. I just forked SFML 2.3 and made a few edits (https://github.com/jmcmorris/SFML) and then proceeded to compile without any issues. I was also able to compile my game but once it got to the linking stage it ran into a snag that I just cant seem to resolve.

ld: file not found: /Users/m/Prog/Projects/SFML/build_deps/libogg-1.3.2/build/1.3.2//i386/root/lib/libogg.0.dylib for architecture i386

Here is the full output (minus the plethora of .o files):

make: Circular standalone <- standalone dependency dropped.
c++ -O3 -arch i386 -headerpad_max_install_names -mmacosx-version-min=10.6 -stdlib=libstdc++ externals/frameworks/libboost_system.a externals/frameworks/libboost_filesystem.a externals/frameworks/libboost_python.a externals/frameworks/libboost_regex.a externals/frameworks/libboost_thread.a externals/frameworks/libboost_signals.a externals/frameworks/libRakNetLibStatic.a externals/frameworks/libfreetype.dylib externals/frameworks/liblog4cplus.dylib externals/frameworks/libCoherentUI.dylib externals/frameworks/libsteam_api.dylib -Fexternals/frameworks/ -Fexternals/frameworks/ -framework Python -framework Foundation -framework AppKit -framework IOKit -framework Carbon -framework OpenGL -framework ogg -framework FLAC -framework vorbis -framework vorbisenc -framework vorbisfile -framework OpenAL -framework sfml-audio -framework sfml-graphics -framework sfml-network -framework sfml-system -framework sfml-window -dynamiclib -undefined suppress -flat_namespace <all of the .o files>
ld: file not found: /Users/m/Prog/Projects/SFML/build_deps/libogg-1.3.2/build/1.3.2//i386/root/lib/libogg.0.dylib for architecture i386
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [siege.so] Error 1

Any help is appreciated. Thanks!

13

Graphics / Re: Shader Unavailable when it should be

« on: May 05, 2015, 02:01:11 am »

Tried that context_version branch to no avail. I added in logging AFTER the creation of the window and here's what we're getting now.

Context Settings: version=1.4 anti=0 depth=0 stencil=0
Shaders are not supported on this system.
Vendor: NVIDIA Corporation Renderer: GeForce GTX 460/PCIe/SSE2 Version: 1.4 (2.1.2 NVIDIA 331.113) Extensions: GL_ARB_depth_texture GL_ARB_draw_buffers GL_ARB_fragment_program GL_ARB_fragment_program_shadow GL_ARB_framebuffer_object GL_ARB_imaging GL_ARB_multisample GL_ARB_multitexture GL_ARB_occlusion_query GL_ARB_point_parameters GL_ARB_point_sprite GL_ARB_shadow GL_ARB_texture_border_clamp GL_ARB_texture_compression GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_crossbar GL_ARB_texture_env_dot3 GL_ARB_texture_mirrored_repeat GL_ARB_texture_non_power_of_two GL_ARB_texture_rectangle GL_ARB_texture_rg GL_ARB_transpose_matrix GL_ARB_vertex_program GL_ARB_window_pos GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_equation_separate GL_EXT_blend_func_separate GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_draw_range_elements GL_EXT_fog_coord GL_EXT_framebuffer_blit GL_EXT_framebuffer_multisample GL_EXT_framebuffer_object GL_EXT_framebuffer_sRGB GL_EXT_multi_draw_arrays GL_EXT_packed_depth_stencil GL_EXT_packed_pixels GL_EXT_point_parameters GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_specular_color GL_EXT_shadow_funcs GL_EXT_stencil_two_side GL_EXT_stencil_wrap GL_EXT_texture3D GL_EXT_texture_compression_dxt1 GL_EXT_texture_compression_s3tc GL_EXT_texture_edge_clamp GL_EXT_texture_env_add GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_EXT_texture_filter_anisotropic GL_EXT_texture_lod GL_EXT_texture_lod_bias GL_EXT_texture_mirror_clamp GL_EXT_texture_object GL_EXT_texture_rectangle GL_EXT_vertex_array GL_ATI_draw_buffers GL_ATI_texture_float GL_ATI_texture_mirror_once GL_IBM_rasterpos_clip GL_IBM_texture_mirrored_repeat GL_INGR_blend_func_separate GL_NV_blend_square GL_NV_copy_depth_to_color GL_NV_depth_clamp GL_NV_fog_distance GL_NV_fragment_program GL_NV_fragment_program_option GL_NV_fragment_program2 GL_NV_light_max_exponent GL_NV_multisample_filter_hint GL_NV_packed_depth_stencil GL_NV_point_sprite GL_NV_texgen_reflection GL_NV_texture_compression_vtc GL_NV_texture_env_combine4 GL_NV_texture_rectangle GL_NV_vertex_program GL_NV_vertex_program1_1 GL_NV_vertex_program2 GL_NV_vertex_program2_option GL_NV_vertex_program3 GL_SGIS_generate_mipmap GL_SGIS_texture_border_clamp GL_SGIS_texture_edge_clamp GL_SGIS_texture_lod GL_SGIX_depth_texture GL_SGIX_shadow GL_SUN_multi_draw_arrays GL_SUN_slice_accum

This is with me specifying the version in sf::ContextSettings.

m_window->create(mode, "Crea", style, sf::ContextSettings(0, 0, 0, 2, 1));

14

Graphics / Re: Shader Unavailable when it should be

« on: May 03, 2015, 04:43:03 pm »

Oh yeah, you're right haha! It has been awhile since I messed with this side of the code. I remember now that there is a create method or the constructor will call create if I pass in the parameters for it. Well, then. Now I feel a little silly.

15

Graphics / Re: Shader Unavailable when it should be

« on: May 03, 2015, 04:21:33 pm »

Not silly at all. But yes, the settings is coming from RenderWindow::getSettings(). Here is the code that's logging.

m_window = boost::make_shared<sf::RenderWindow>();
Int32 maxTextureSize = sf::Texture::getMaximumSize();
LOG_INFO("Maximum Texture Size: " << maxTextureSize);
const sf::ContextSettings& s = m_window->getSettings();
LOG_INFO("Context Settings: version=" << s.majorVersion << "." << s.minorVersion << " anti=" << s.antialiasingLevel << " depth=" << s.depthBits << " stencil=" << s.stencilBits);
if (!sf::Shader::isAvailable()) {
    LOG_INFO("Shaders are not supported on this system.");
}

Shaders are indeed a requirement for playing the game and I even say so on the store page. I hadn't realized I could specify the required context version. Thank you very much for your help. Let me know if we can look into anything else for you since this seems to be such a special case. Cheers!