Horde3D

Next-Generation Graphics Engine
It is currently 23.11.2024, 04:26

All times are UTC + 1 hour




Post new topic Reply to topic  [ 17 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: glfw-lite
PostPosted: 15.10.2009, 18:27 
Offline

Joined: 22.11.2007, 17:05
Posts: 707
Location: Boston, MA
I would like to suggest that we move to glfw-lite for the samples. glfw-lite is an official branch of glfw, maintained by the glfw team, and as well as being a lighter library (removes threading and image loading), it also is much more up-to-date.

In particular, glfw-lite has support for 64-bit on Mac, which the main glfw is unlikely to support in the near future. We need this because as of Snow Leopard, the Mac development toolchain is 64-bit by default.

I have a (large) patch against the community branch which will make this change, but I want to get input from all of you before I make such a large change.

_________________
Tristam MacDonald - [swiftcoding]


Top
 Profile  
Reply with quote  
 Post subject: Re: glfw-lite
PostPosted: 16.10.2009, 00:45 
Offline

Joined: 08.11.2006, 03:10
Posts: 384
Location: Australia
Sounds good to me. The samples don't need threading or image loading.


I'm actually using GLFW threading in my hobby engine, but I've been meaning to switch over to boost::thread or pthreads for a while anyway :wink:


Top
 Profile  
Reply with quote  
 Post subject: Re: glfw-lite
PostPosted: 17.10.2009, 10:44 
Offline
Engine Developer

Joined: 10.09.2006, 15:52
Posts: 1217
Basically that sounds good to me as well. We definitely don't need the image loading, the only thing that might be interesting at some point in the future is the threading support. This would be required for a streaming sample or when Horde should get some more parallelization.

Another idea is to create our own little sample framework. Window creation and basic input would be enough for the beginning. This should be quite easy and quick for Windows, and Linux as well. The only problem for me and Volker is OSX, so we would definitely need help there. The advantage of the custom sample framework is that we could support DX and other platforms (like cell phones) more easily.


Top
 Profile  
Reply with quote  
 Post subject: Re: glfw-lite
PostPosted: 17.10.2009, 13:40 
Offline

Joined: 22.11.2007, 17:05
Posts: 707
Location: Boston, MA
marciano wrote:
the only thing that might be interesting at some point in the future is the threading support. This would be required for a streaming sample or when Horde should get some more parallelization.
glfw's threading support is not particularly good - we might be better using boost::thread, OpenMP, or something similar.
Quote:
Another idea is to create our own little sample framework. Window creation and basic input would be enough for the beginning. This should be quite easy and quick for Windows, and Linux as well. The only problem for me and Volker is OSX, so we would definitely need help there.
I should be able to whip up a Cocoa/MacOSX sample framework in a couple of days (currently doing the same for pyglet).
Quote:
The advantage of the custom sample framework is that we could support DX and other platforms (like cell phones) more easily.
Ja, and the iPhone might be a nice platform to support, as soon as I get my hands on a GLES2.0-enabled iPhone 3GS ;)

_________________
Tristam MacDonald - [swiftcoding]


Top
 Profile  
Reply with quote  
 Post subject: Re: glfw-lite
PostPosted: 18.10.2009, 16:35 
Offline
Engine Developer

Joined: 10.09.2006, 15:52
Posts: 1217
swiftcoder wrote:
I should be able to whip up a Cocoa/MacOSX sample framework in a couple of days (currently doing the same for pyglet).

That's great, thanks! So we can think of the best way to create that little sample framework. I would propose to have something really simple and minimal. A single main file per platform that creates the window and handles the input events should be enough. The keyboard and mouse state data is passed to a small application interface (similar to the Application class we already have) from which a sample app can be derived.


Top
 Profile  
Reply with quote  
 Post subject: Re: glfw-lite
PostPosted: 20.10.2009, 00:42 
Offline

Joined: 19.11.2007, 19:35
Posts: 218
Quote:
glfw's threading support is not particularly good - we might be better using boost::thread, OpenMP, or something similar.

Concurred.


Top
 Profile  
Reply with quote  
 Post subject: Re: glfw-lite
PostPosted: 26.10.2009, 02:34 
Offline

Joined: 09.09.2009, 18:58
Posts: 107
I am currently using GLFW's input functions to develop the input subsystem of my Pet-Project game engine. I honestly think that all anybody seriously uses GLFW for is the window creation functionality. I might use its input callbacks to make the input components if I don't find a separate library (can anyone recommend one other than SDL?)


Top
 Profile  
Reply with quote  
 Post subject: Re: glfw-lite
PostPosted: 26.10.2009, 06:12 
Offline

Joined: 08.11.2006, 03:10
Posts: 384
Location: Australia
Just to clarify -- this decision doesn't mean that you can't still use GLFW and Horde together. It just means that Horde wouldn't come bundled with GLFW out of the box.


Top
 Profile  
Reply with quote  
 Post subject: Re: glfw-lite
PostPosted: 05.12.2009, 19:37 
Offline

Joined: 26.03.2008, 02:58
Posts: 160
why not use glfw-lite as basis?

I have code to create and handle input of mobile windows from powerVR SDK.
I still don't have a mac or mac clone to test it on the iphone SDK.

Any developments in terms of abstracting the engine to be API agnostic, so we can add backends with ease?

I see that there is new developments in terms of resource managment :) very cool!


Top
 Profile  
Reply with quote  
 Post subject: Re: glfw-lite
PostPosted: 06.12.2009, 12:33 
Offline
Engine Developer

Joined: 10.09.2006, 15:52
Posts: 1217
We switched to glfw lite now. It was very easy to do. Windows is working fine and Linux is compiling (can't run horde on my linux netbook though).

Maybe some work on the OSX side is necessary. swiftcoder, maybe you can help out with your patch :)

DDd wrote:
Any developments in terms of abstracting the engine to be API agnostic, so we can add backends with ease?

The abstraction layer is not really required for a GL ES 2 version. It would be nice to have a clean API abstraction layer but to make it work with all current APIs, a lot of effort is required and neither me nor Volker have the time for that at the moment. And an API abstraction is just one approach. The downside is that you always have to find the lowest common denominator for all APIs, so it is difficult to make use of specific features. That's why some people prefer doing the abstraction at a higher level (in horde terms that could be the scene nodes). Basically, that's what we already have right now so the current situation is not too bad.


Top
 Profile  
Reply with quote  
 Post subject: Re: glfw-lite
PostPosted: 24.12.2009, 01:42 
Offline

Joined: 15.06.2008, 11:21
Posts: 166
Location: Germany
I need this to compile Horde3D now as the include file is missing on this machine:
Code:
From c986f6987d22f7a6bd373e6fab8e060ad29dd1bb Mon Sep 17 00:00:00 2001
From: Mathias Gottschlag <mathias-go@web.de>
Date: Thu, 24 Dec 2009 01:31:44 +0100
Subject: [PATCH] Fixed compiling under Linux.

---
 Horde3D/Dependencies/Source/glfw/x11/platform.h |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/Horde3D/Dependencies/Source/glfw/x11/platform.h b/Horde3D/Dependencies/Source/glfw/x11/platform.h
index 1902baf..a04ded3 100644
--- a/Horde3D/Dependencies/Source/glfw/x11/platform.h
+++ b/Horde3D/Dependencies/Source/glfw/x11/platform.h
@@ -45,7 +45,6 @@
 #include <X11/Xatom.h>
 #include <GL/glx.h>
 #include "../../Include/glfw.h"
-#include "x11_config.h"
 
 #if !defined( GLX_VERSION_1_4 )
  #error "GLFW requires GLX version 1.4 or above"
--
1.6.3.3


Ubuntu 9.10, amd64


Top
 Profile  
Reply with quote  
 Post subject: Re: glfw-lite
PostPosted: 24.12.2009, 16:43 
Offline

Joined: 21.08.2008, 11:44
Posts: 354
I'm not sure, perhaps required driver or OpenGL headers are not present, try to install them through the package manager. Search for the glx-dev and similar keywords and make sure that essential build tools are installed.


Top
 Profile  
Reply with quote  
 Post subject: Re: glfw-lite
PostPosted: 27.12.2009, 14:27 
Offline
Engine Developer

Joined: 10.09.2006, 15:52
Posts: 1217
Thanks phoenix. The problem seems to be that some CMake files are missing in the glfw/x11 directory.


Top
 Profile  
Reply with quote  
 Post subject: Re: glfw-lite
PostPosted: 11.01.2010, 18:39 
Offline

Joined: 15.06.2008, 11:21
Posts: 166
Location: Germany
I am currently getting some weird problems with GLFW:

Sometimes the mouse position changes for 200 pixels (horizontal, vertically it's something else, see below) in one frame. Sometimes it then even changes back and forth again. This only seems to happen with low frame rates, and probably only affects the X11 code as noone else currently has seen it here.

This is where I inserted debug printfs into glfw:
Code:
diff --git a/Horde3D/Dependencies/Source/glfw/x11/x11_window.c b/Horde3D/Dependencies/Source/glfw/x11/x11_window.c
--- a/Horde3D/Dependencies/Source/glfw/x11/x11_window.c
+++ b/Horde3D/Dependencies/Source/glfw/x11/x11_window.c
@@ -519,6 +519,7 @@
             {
                 if( _glfwWin.MouseLock )
                 {
+                    printf("1 (%d, %d): ", event.xmotion.x, event.xmotion.y);
                     _glfwInput.MousePosX += event.xmotion.x -
                                             _glfwInput.CursorPosX;
                     _glfwInput.MousePosY += event.xmotion.y -
@@ -526,9 +527,12 @@
                 }
                 else
                 {
+                    printf("2: ");
                     _glfwInput.MousePosX = event.xmotion.x;
                     _glfwInput.MousePosY = event.xmotion.y;
                 }
+                printf("Mouse movement: %d/%d\n", _glfwInput.MousePosX, _glfwInput.MousePosY);
                 _glfwInput.CursorPosX = event.xmotion.x;
                 _glfwInput.CursorPosY = event.xmotion.y;
                 _glfwInput.MouseMoved = GL_TRUE;
@@ -1538,6 +1542,8 @@
     // is not used, so I decided to use it.
     //XSync( _glfwLibrary.display, False );
 
+    printf("Events:\n");
+
     // Empty the window event queue
     while( XPending( _glfwLibrary.display ) )
     {
@@ -1562,6 +1568,7 @@
         if(_glfwInput.CursorPosX < minx || _glfwInput.CursorPosX > maxx ||
            _glfwInput.CursorPosY < miny || _glfwInput.CursorPosY > maxy)
         {
+            printf("Resetting mouse.\n");
             // Move the mouse pointer back to the window center so that it
             // does not wander off...
             _glfwPlatformSetMouseCursorPos( _glfwWin.Width/2,

( Patch shortened a bit so it maybe won't apply)

What these changes print are 1) the position data I get from X11 (event.xmotion.x) and 2) the data glfw stores internally (_glfwInput.MousePosX).

This is what GLFW outputs with my changes:
Quote:
Events:
1 (201, 290): Mouse movement: -199/-10
1 (199, 290): Mouse movement: -201/-10
Resetting mouse.
Events:
1 (197, 290): Mouse movement: -404/-20
Resetting mouse.
Events:
1 (399, 300): Mouse movement: -405/-20
1 (397, 300): Mouse movement: -407/-20


This is what I think happens:
First, the cursor leaves the area glfw wants it in (for a 800x600 window the 400x300 center, therefore x = 200). GLFW now sets the mouse position back to the center and changes the internal variables. Now a X11 event is received though which still contains the old position as it probably was issued before the change. GLFW now compares it with the internal value and thinks, hey, the mouse just moved 200 pixels to the left. It of course adjusts the mouse position again (because it thinks the mouse is out of the center area), but this time everything will work well because of the large difference between the next event and the first time changing the mouse position.

Anybody has ever met that issue? Anyone knows how this could be fixed?

EDIT: Huh. Reenabling the XSync over the printf("Events:\n"); seems to have fixed it. Weird.


Top
 Profile  
Reply with quote  
 Post subject: Re: glfw-lite
PostPosted: 12.01.2010, 20:48 
Offline
Engine Developer

Joined: 10.09.2006, 15:52
Posts: 1217
Although XSync is commented out by default, there is this comment above it which you have probably seen:

Code:
// Use XSync to synchronise events to the X display.
// I don't know if this can have a serious performance impact. My
// benchmarks with a GeForce card under Linux shows no difference with
// or without XSync, but when the GL window is rendered over a slow
// network I have noticed bad event syncronisation problems when XSync
// is not used, so I decided to use it.


Maybe you could post a message on their forums or their mailing list: http://glfw.sourceforge.net/community.html


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 17 posts ]  Go to page 1, 2  Next

All times are UTC + 1 hour


Who is online

Users browsing this forum: No registered users and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group