Welcome, Guest. Please login or register. Did you miss your activation email?

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.

Messages - EatMyShorts

Pages: [1]
Window / Re: Incorrect handling of multiple controllers events
« on: August 28, 2022, 08:35:36 pm »
2.6 does not work

In file JoystickImpl.cpp is wierd logic:
    // Remove devices that were not connected during the enumeration
    for (std::vector<JoystickRecord>::iterator i = joystickList.begin(); i != joystickList.end();)
        if (!i->plugged)
            i = joystickList.erase(i);

As you all know erase() invalidates iterator used there.
Moreover, there is a problem with indexing connected controllers.

I have two controllers, lets call them red and blue.
Application starts, and red is indexed as 1, and blue is indexed as 0.

When I push red button it is registered as controller 0 button press
When I push blue button it is registered as controller 1 button press

I have tried to debug it on my own, but i have failed... I have not time for it.
I do not care ... I am out.

Window / Incorrect handling of multiple controllers events
« on: August 10, 2022, 04:06:45 pm »
I am using SFML 2.5.1.

I have two Xbox One Controllers connected to my PC. Obviously they will have two ids, 0 and 1.

When I disconnect the one with id 0 (the first one) bad magic happens.

First of all, I can see a weird sequence of JoystickDisconnected/JoystickConnected events.
The 0 controller gets disconnected, and a new 0 controller gets connected.

Secondly, once the 0 controller is disconnected, events for connected controller are reported with id 0 and 1.

I wrote a simple code for tracing Joystick events.
      sf::Event event;
      while (m_window.pollEvent(event))
         switch (event.type)
         case sf::Event::JoystickMoved:
               Diagnostics::Trace::Write("Controller move: Id:[{0}]\n", event.joystickMove.joystickId);
         case sf::Event::JoystickDisconnected:
               Diagnostics::Trace::Write("Controller disconnected: Id:[{0}]\n", event.joystickConnect.joystickId);
         case sf::Event::JoystickConnected:
               Diagnostics::Trace::Write("Controller connected: Id:[{0}]\n", event.joystickConnect.joystickId);

This is the output after disconnecting 0 controller and moving a thumbstick on other, still connected controller.
Controller disconnected: Id:[0]
Controller connected: Id:[0]
Controller move: Id:[0]
Controller move: Id:[0]
Controller move: Id:[0]
Controller move: Id:[0]
Controller move: Id:[1]
Controller move: Id:[1]
Controller move: Id:[1]
Controller move: Id:[1]
Controller move: Id:[0]
Controller move: Id:[0]
Controller move: Id:[1]
Controller move: Id:[1]

As you can see:
1. Controller 0 gets somehow connected
2. Events are reported for both controllers 0 and 1 even there is only one controller connected.

This seems to be a bug in SFML library.
I have found two topics about similar problems, but there is no explanation what is going on.


Graphics / a tree of geom transforms
« on: November 08, 2010, 08:27:01 pm »
I have 3 objects (A, B, C)
Objects A and C are using same texture i.e. Wall.png and object B is using different texture i.e grass.png

Now, drawing objects like this: A->B->C will be inefficient (2 texture changes). To increase performance you will need to sort your objects by texture to have this drawing order A->C->B (1 texture change).

I do not know if the SFML 2.0 is using some internal batching mechanism to minimize device state changes.

I think I will run the test my self.

Graphics / a tree of geom transforms
« on: November 03, 2010, 08:09:18 pm »
I understand this part, but what about sorting your objects by i.e. Textures or Shaders? Changing these assets often will decrease your performance significantly.

I was thinking about creating my own Matrix class. I want to avoid it, but this would allow me to:

1. Update all scene nodes
2. Gather all visible objects
3. Sort them by Texture or Shader
4. Draw in one single loop

Generally I need to create a scene graph and want to know if proposed earlier solution (with extended Drawable class) is OK and how complicated scene can be managed with it.

Graphics / a tree of geom transforms
« on: November 03, 2010, 07:31:14 pm »
I know I am digging this up, but did you bother to do any kind of soring draw queues? IS performance OK?

I am working on similar solution with extending Drawable class and I am not sure if this will not be an issue.

I know that SFML 2.0 had something like render queue, but AFAIK this was removed.

Graphics / SFML 2.0 - Freetype library linking in graphics module
« on: November 03, 2010, 02:13:00 pm »
I agree with you. I will reconfigure my project as posted earlier and everything should be fine.

Thanks for fixing previous problem :D

Graphics / SFML 2.0 - Freetype library linking in graphics module
« on: November 03, 2010, 10:53:08 am »
No, I ended up with linking both Debug and Release Runtime libs to one exec. It is caused by linking SFML (using release runtime libs) and debug zlib and zziplib (using debug runtime libs).

I am using Debug version of zlib just to be able to debug it. It is useful sometimes, but rarely.

Graphics / SFML 2.0 - Freetype library linking in graphics module
« on: November 02, 2010, 10:31:16 pm »
Everything worked fine until i linked zlib and zziplib libraries. Before that i had no linker problems, even with LIBCMT conflict.

I think the second problem (MSVCRT and MSVCRTD conflict) is not so important as the first one with LIBCMT at least for now, because it affects only Debug config and I can still run my program by switching from debug zlib and zziplib to release dependencies.

Graphics / SFML 2.0 - Freetype library linking in graphics module
« on: November 02, 2010, 10:05:42 pm »
Sorry for my late reply. I have checked new version of SFML 2 and it works perfect only in Release version in Debug build it crashes. Last time I did some research about this problem and managed to compile whole SFML 2.0 project.

Here's what I had to do in order to link SFML 2.0 with my project in both configurations. (BTW: if you need a project that shows this problem let me know i will try to spare some time to prepare a sample mini project)

1. FreetypeLib  recompilation with /MD adn /MDd option
From what i saw in the latest SVN branch you are using the same freetype.lib for Release and Debug configs. This causes problem in Debug builds. There is a confilct between MSVCRT.LIB and MSVCRTD.LIB (as a result program craches ). I think you will have to include debug libs for FreetypeLib

2. JPEGLib
Here is similar problem to previous one. You have to include debug version of lib

Check this site: http://leptonica.org/vs2008doc/building-zlib-libjpeg-libpng.html. Here you can read about building this library. There is a problem because the library does not have Debug config so you have to add it yourself.

Similar situation to FreetypeLib problem. You will have to include also Debug libs.

Hope this helps :D

Graphics / SFML 2.0 - Freetype library linking in graphics module
« on: September 27, 2010, 08:33:36 pm »

I have started using SFML 2.0 in my application. Recently I have added 2 new libraries to it zlib and zziplib to be able to read zip archives. Once I linked them as static libraries I received couple of linker errors

1>LIBCMT.lib(dosmap.obj) : error LNK2005: __errno already defined in MSVCRTD.lib(MSVCR90D.dll)

All my projects are supposed to link Multithreaded Runtime libs from DLL (/MD option in VS2008), but from what I saw in dumpbin.exe reports sfml2-graphics-s-d.lib uses freetype.lib which is compiled with /MT Runtime Library option and this is not good.

Is it going to be changed in near future ?


I have more problems with my application now. I cannot compile it even if i have recompiled FreeType library.

Can you tell me what version of freetype lib are you using. Maybe I have compiled wrong wersion.

//EDIT 2

I have managed to compile it correctly. I have downloaded lates version of Freetype lib. Compile it it /MD[d] option and recompile SFML 2.0

I think this issue should be fixed in SFML 2.0.[/b]

Pages: [1]