Activity for freeglut
-
freeglut released /freeglut/3.6.0/freeglut-3.6.0.tar.gz
-
mirh posted a comment on ticket #175
WS_POPUP isn't (well, wasn't) changing z-order lol. It was entering you exclusive fullscreen.
-
-
-
John Tsiombikas modified ticket #241
Undefined symbol fghJoystickRawRead in libglut.so.3.10.0
-
This should no longer be an issue. While trying to fix the freeglut build on freebsd I changed this function to not be static, and moved its declaration to fg_internal.h.
-
I changed the joystick code by following more or less what the freebsd ports patches do. Now freeglut builds properly on current(-ish) freebsd, but the joystick functionality doesn't seem to work. I opened a new issue about this on github, feel free to follow along there: https://github.com/FreeGLUTProject/freeglut/issues/118
-
I changed the joystick code by following more or less what the freebsd ports patches do. Now freeglut builds properly on current(-ish) freebsd, but the joystick functionality doesn't seem to work. Edit: I opened a new issue about this on github, feel free to follow along there: https://github.com/FreeGLUTProject/freeglut/issues/118
-
freeglut_joystick.c doesn't build on FreeBSD-8
-
I changed the joystick code by following more or less what the freebsd ports patches do. Now freeglut builds properly on current(-ish) freebsd, but the joystick functionality doesn't seem to work.
-
I finally got my hands on a SpaceMouse Enterprise, and indeed that's the first device I've seen with gaps in button numbers. I think this strange behaviour is due to there being two different report collections, one with 31 contiguous buttons, and one with 256 buttons with gaps, and apparently linux evdev does indeed report button numbers with gaps. I had to implement a hardcoded remapping in spacenavd to properly support these devices: https://github.com/FreeSpacenav/spacenavd/commit/8a3c9617a507fc5d291f866ca1b66591e8a6b9f0#diff-12a9ed4a3cf62ac26e1aa260cafefc56833fdb435ad08271525dd6544db5b729R465...
-
implemented SUPER key/modifier support on windows
-
Added keyboard demo, and changed the spaceball demo to also build on windows
-
Added GLUT_ACTIVE_SUPER modifier, and corresponding GLUT_KEY_SUPER_L and
-
updated install.php with simple cmake instructions
-
Added an unobtrusive file outside of the source directory (next to dcnieho's
-
web page: added download link for release 3.2.2
-
-
tagging release 3.2.2
-
bump version numbers before minor release
-
Removed the doc directory from the source tree, which contained out of date,
-
Klaus Doll posted a comment on ticket #255
This is a bit late now, nevertheless: I have built freeglut from source, and revision 1868 fixes the crash for me as well. The workaround with creating a dummy window is not necessary any more. It would be nice when new binaries could also be released in due time. Thank you very much John and also the Yade group, thank you Anton, Janek, Przemysław .
-
AntonG posted a comment on ticket #255
Ok, thanks for the update. The patch is applied cleanly and we can proceed with the transition. Best regards Anton
-
I'll have to look through the svn revisions since the previous release to see what has changed, and if it warrants a new release, but it'll probably take some time to get things going. If patching the previous version in debian is an option, I suggest doing that for now to avoid being blocked waiting for this.
-
Dear John, thank you very much for fixing it! I have just patched our packaged version and everything works even without workaround! Really appreciate your help. Are you planning to release a newer version soon? if not, we will patch an older one and push into the Debian/Ubuntu. Best regards Anton Am Mi., 22. Dez. 2021 um 23:01 Uhr schrieb John Tsiombikas jtsiomb@users.sourceforge.net: status: open --> closed-fixed Comment: fixed, svn revision 1868.
-
Freeglut 3.X - regression with glutSolidSphere, fgStructure.Cthe urrentWindow is NULL
-
fixed, svn revision 1868.
-
fix crash when calling primitive drawing functions without creating a window (bug report #255)
-
I didn't even notice we had the filenames at the top of each file. That's bizarre :) Anyway I just fixed that too...
-
minor: incorrect filename at the top of fg_gl2.h
-
Keith Marshall posted a comment on ticket #256
FWIW, I encountered the same issue when attempting to build freeglut-3.2.1 on Arch Linux, with GCC-11.1, and came up with much the same work-around as the OP. I agree that your SVN-1863 update is a much better solution; however, while investigating, I did notice that the src/fg_gl2.h file header incorrectly identifies the file as fg_gl2.c, and that's still wrong in SVN. Not a big deal, I realize, but you may want to correct it some time.
-
Freeglut 3.X - regression with glutSolidSphere, fgStructure.Cthe urrentWindow is NULL
-
Ok now I get it. Let me be frank, I think this is completely innane, using freeglut just to draw spheres. Just write 20 lines of code to draw a sphere instead. But nevertheless, I'll take a look in the primitive drawing code and see if we can facilitate this usage. It should be possible. My guess without looking at the code yet, is that it accesses the window to see if the user requested drawing using custom attribute locations (because the code has been rewritten to support OpenGL core profiles,...
-
Hello, we have had the same crash with a GUI for Molpro. glutInit is called, but the windows are made with gtk ( gtk_window_new ). glut is then used to draw spheres etc (to visualise atoms, bonds). This worked with freeglut 2.8.1-8.4 in openSUSE-Leap-42.3-0 , but crashed from openSUSE-Leap-15.0-1 onwards, with freeglut 3.0.0-lp150.1.8 . It still works on Mac with GLUT.framework instead of freeglut. I was in touch with the YADE group, as I had made a workaround, to open a dummy window with glutCreateWindow...
-
Hello, we have had the same crash with a GUI for Molpro. glutInit is called, but the windows are made with gtk ( gtk_window_new ). glut is then used to draw spheres etc (to visualise atoms, bonds). This worked with freeglut 2.8.1-8.4 in openSUSE-Leap-42.3-0 , but crashed from openSUSE-Leap-15.0-1 onwards, with freeglut 3.0.0-lp150.1.8 . It still works on Mac with GLUT.framework instead of freeglut. I was in touch with the YADE group, as I had made a workaround, to open a dummy window with glutCreateWindow...
-
Hi John, thanks for analyzing it. You are probably right about this conclusion. But the problem is that many codes rely on this behavior, which was before. If you could provide at least a minimal patch which probably fixes the issue in freeglut without committing it into the main branch, we can test it and give you feedback, if it works or not. Thank you Anton
-
Nobody explained what the issue is sufficiently well. Let me make another attempt at understanding it. You call glutInit, but you don't create a window, and then proceed to call the primitive functions? And that leads to a crash due to CurrentWindow being null? What is the point of calling any OpenGL functions without a window? Without a window there is no OpenGL context. Even if freeglut doesn't crash, nothing will happen. Is the so called blocking bug just that freeglut crashes instead of checking...
-
In YADE we have recently merged a workaround [1]. Creating a dummy window to prevent a crash. But it looks like a dirty hack, so the freeglut will probably stay blocked in Debian/Ubuntu for a while due to this issue (with old version 2.8.1). It is still questionable, why it perfectly works with an old version and crashes with a newer one. [1] https://gitlab.com/yade-dev/trunk/-/merge_requests/747/diffs#3798c3f321ec79cf0e481af13db60d6dc2025a8d_29_30 Best regards Anton
-
Have you created a window? If so, please post a minimal compilable program which reproduces the issue.
-
Yathindu Hettiarachchige posted a comment on ticket #255
Hi, I've also bumped into the crash they are speaking about. I'm not using YADE but in my own project. The crash happens in fghDrawGeometrySolid in line 185. fgStructure.CurrentWindow is NULL. We do call glutInit, so I believe this could be a bug in freeglut.
-
Gerard DURAND modified a comment on ticket #254
Hi, I have found that if I replace GL_TRIANGLE_STRIP by GL_QUAD_STRIP at line 267 in fg_geometry.c (in fghDrawGeometrySolid11, used in my case), I obtain, apparently, the same behavior than with freeglut 2.8.1 (or original glut). Of course triangulation is lost and the normal used is still not the real normal of a flat surface, but the look seems better. It's just a workaround, and probably needs other adjustments for other cases. May be adding a specific use for sphere and torus to limit border...
-
Hi, I have found that if I replace GL_TRIANGLE_STRIP by GL_QUAD_STRIP at line 267 in fg_geometry.c (in fghDrawGeometrySolid11, used in my case), I obtain, apparently, the same behavior than with freeglut 2.8.1 (or original glut). Of course triangulation is lost and the normal used is still not the real normal of a flat surface, but the look seems better. It's just a workaround, and probably needs other adjustments for other cases. May be adding a specific use for sphere and torus to limit border...
-
The obvious difference with the cylinder is that columns of vertices have identical normals. I skimmed through the code and I don't have a complete picture of how the strips are formed in this case, but I don't see how we can control the provoking vertex, when each time we can only specify the next vertex in the strip. Maybe some trick with forcing degenerate triangles every two triangles, but then what's the point in using a triangle strip in the first place? Frankly I'm not a fan of triangle strips...
-
shapes demo: added flat shading option (fixed-function only)
-
I understand your remarks, but why does it seems to work with a cylinder ? (and for the quad parts of a cone)... Sure, the normal used is certainly not the right one (a vertex normal is not the real normal of a triangle)... but may be reorganizing the order of the stripped indices (stripIdx array) should do the work for the torus and the sphere... but until now, I have not found a solution (if it exists !).
-
Some ioctl()/fcntl() calls lack error handling...
-
Closing as invalid due to lack of followup from OP. Feel free to reopen if you care to explain what the bug is about.
-
Freeglut 3.X - regression with glutSolidSphere, fgStructure.Cthe urrentWindow is NULL
-
The problematic primitives don't draw quads any more, rather they are rendered as a series of triangle strips. In GL_FLAT mode, for the two triangles of the "quad" to share the same normal and look correct, one of their shared vertices need to be the provoking vertex for both of them (i.e. the first vertex of both triangles). I don't think this is possible with triangle strips. These primitive functions will have to be re-written to fix the issue.
-
Small pop up ... and further remarks. This strange behavior happens only when glShadeModel is GL_FLAT. All is OK in GL_SMOOTH. If I display normals, they look OK, because located at vertices. But when you use GL_FLAT, none of the built normals correspond to the normal of the flat surface. In freeglut 2.8.1 and old glut 3.7, sphere and torus are build as quads face. It's also true in freeglut 3.2.1 but they are triangulated internally if I understand well. May be the problem is somewhere there. More,...
-
Readme and support
-
Closing this as it is unclear what the feature request is about, and explanations are not forthcoming. If the OP wishes to explain further, it will be re-opened.
-
Ok, and what does freeglut do which forces people to download xcode? Freeglut uses cmake, not xcode project files.
-
shriraj dash posted a comment on ticket #93
What I mean by make a version for mac is that people that want to use opengl without downloading xcode as it is a pretty large in size.
-
What are you talking about? Each readme file is for a specific platform. README.win32 is not the main readme file, README is the main one. I have absolutely no idea what you mean by "make a version for mac that people can use instead of xcode", care to elaborate?
-
What are you talking about? Each readme file is for a specific platform. README.win32 is not the main readme file, README is the main one. I have absolutely no idea what you mean by "making a version for mac that people can use instead of xcode", care to elaborate?
-
Readme and support
-
Steve Andrews posted a comment on ticket #259
I just tried to build freeglut on Mac OS 10.14 (Mojave) and got the exact same problem. I'm equally stumped on how to fix it. For what it's worth, I was able to install freeglut successfully using MacPorts, but that didn't include the static library that I was hoping for (it does have several .dylib files though). It also came with several .cmake files which might have been useful, but all of my efforts to include them in my project using CMake failed, so I gave up.
-
John A posted a comment on ticket #259
Thanks John T. for your response. I am using the latest cmake here; something happened it seems during the OpenGL deprecation process with Catalina, at least to the GLX/X11 environment. I futzed with this for hours but haven’t found a solution yet; if and when I do, I’ll update this bug report. It is a shame how Apple has made it so difficult to continue using OpenGL on their platform. I have read OpenGL support is even worse with the new “Big Sur” OS. I guess they really, really want users to abandon...
-
Thanks for the quick response John T. I ended up disabling the build of the shareable library and was able to build the static library. Then, the problem simply shifted to applications trying to use the freeglut static library; i.e., as you pointed out, the GLX/X11 libraries being referenced by libfreeglut.a seem were deprecated by Apple; I haven't been successful yet in getting them restored in the MacOS Catalina version yet. If and when I find a way to get freeglut to work again on the Mac, I'll...
-
It looks like all the GLX functions are missing. What we're linking with when it comes to OpenGL, is whatever the OpenGL cmake module sets to OPENGL_gl_LIBRARY after we do a FIND_PACKAGE(OpenGL). So this probably means that either your cmake OpenGL module is out of date, and something changed in catalina that moved GLX out of an existing library, or it finds the wrong cmake module that attempts to link with the "native" macos OpenGL framework instead of the X11/GLX based libraries. This is all more...
-
Builds fine on Windows; not so on MacOS?
-
The highest numbered button (button index 20 (0-based) in linux evdev) on the space pilot is the "config" button, which is the leftmost in a cluster of 2 buttons right in front of the puck. I also captured the USB traffic from the device while pressing that button, and I got: 03 00 00 10, which indeed looks like a button event with a bitmask with bit 20 set.
-
Shane Saxon posted a comment on ticket #258
Excellent, very helpful details and will proccede accordingly! I can't speak much to how Linux 'maps the HID packets... evdev interface'. Perhaps with the 'HID report descriptors', I started down a similar path with the msw code, but then came across people showing that (on Windows) the 3Dx HID descriptors are sometimes erroneous, (depending on device firmware etc.) Which I found to at least be true for Space Navigator button packet size, hid.dwSizeHid reports 7 bytes for all events (and same issue...
-
I don't have a spacemouse pro or spacemouse enterprise to tell you for sure. But you could set up a GNU/Linux VM, and install spacenavd and freeglut to check. I do have a spacepilot with 21 buttons, and the Linux kernel just sends me button numbers from 0 to 20 without any gaps, which is what I'm sending to applications through spacenavd, and which is what my freeglut code returns after adding 1 to make it start from 1. I have not examined the Linux HID driver to see how exactly it maps the HID packets...
-
The documentation is wrong and needs fixing. I didn't write that section. Just to dispel any doubt about the original GLUT behavior, here's the relevant code snippet from GLUT 3.7: } else if(__glutSpaceball && devbtn->deviceid == __glutSpaceball->device_id && window->spaceButton) { window->spaceButton(devbtn->button, GLUT_DOWN); } It just passes the button field from the XDeviceButtonEvent structure (X input extension) directly to the callback. And that button field is a number from 1 to the number...
-
Now in terms of contiguous buttons, yes let's do this! However, at this point we are scrambling the button id's across models. So regardless of the (below) logic, the X11 behavior should take precedence and be mirrored to maintain cross-platform consistency. So the key question remains, what is the X11 key-map for the SM Pro and/or SM Enterprise? Best I can determine, the SM Pro (original and Wireless) and SM Enterprise are the only 2 devices with gaps in the raw button values. Both have a deviant...
-
In terms of original (forementioned) GLUT API docs, they do say: "The button parameter will be the button number (starting at one)." - original GLUT API It does say 'starting at one', but nothing about the buttons being contiguous. The FreeGLUT API (sec 12.17) added the non-contiguous button constants fore-mentioned, and referenced here: http://freeglut.sourceforge.net/docs/api.php#WindowCallback Now I see no reason to split hairs regarding the original GLUT docs, and the current FreeGLUT ones clearly...
-
Here's the GLUT documentation for the glutSpaceballButton callback: https://www.opengl.org/resources/libraries/glut/spec3/node57.html#SECTION000812000000000000000 It clearly states that buttons are numbers starting at 1. The X11 version of the code which I wrote works that way. If the win32 code which was added later provides bitmasks then it's a bug and it needs to be fixed. But since the win32 code only supported the space navigator which has only two buttons, bitmasks and 1-based button numbers...
-
The contiguous button approach presents a few challenges, which could be considered as follows: 1) It is inconsistent with the (currently) defined FreeGLUT API, which has non-contiguous button defines: GLUT_SPACEBALL_BUTTON_A (0x00000001) GLUT_SPACEBALL_BUTTON_B (0x00000002) GLUT_SPACEBALL_BUTTON_C (0x00000004) GLUT_SPACEBALL_BUTTON_D (0x00000008) GLUT_SPACEBALL_BUTTON_E (0x00000010) 2) It is problematic to the end-user, as different devices will behave differently with the same labelled keys. 3)...
-
The contiguous button approach presents a few challenges, which could be considered as follows: 1) It is inconsistent with the (currently) defined FreeGLUT API, which has non-contiguous button defines: GLUT_SPACEBALL_BUTTON_A (0x00000001) GLUT_SPACEBALL_BUTTON_B (0x00000002) GLUT_SPACEBALL_BUTTON_C (0x00000004) GLUT_SPACEBALL_BUTTON_D (0x00000008) GLUT_SPACEBALL_BUTTON_E (0x00000010) 2) It is problematic to the end-user, as different devices will behave differently with the same labelled keys. 3)...
-
I don't think there's a good way to avoid having different numbers for the same "labeled" buttons on different devices, so I wouldn't even try. GLUT has always been about a simplified API, not necessarilly about providing all the available information. Spaceball button callbacks just provide a button number, with no implied relationship between that number and specific identifiable butotns on the device. It's a simple interface but it's sufficient for most use cases, and it just puts the onus of...
-
I found that my init problem is a bug in glutDeviceGet(GLUT_HAS_SPACEBALL), where it reports zero during startup, even after glutShowWindow() is called. I fixed the bug by modifying fgPlatformHasSpaceball() to include: if (!fg_sball_initialized) fgPlatformInitializeSpaceball(); A small victory that is super helpful, as I have completely unbolted the proprietary 3Dconnexion SDK.... Hurrah for open source! The Good the Bad and the Ugly - special buttons edition: I (just) noticed that the 3DX sdk has...
-
I found that my init problem is a bug in glutDeviceGet(GLUT_HAS_SPACEBALL), where it reports zero during startup, even after glutShowWindow() is called. I fixed the bug by modifying fgPlatformHasSpaceball() to include: if (!fg_sball_initialized) fgPlatformInitializeSpaceball(); A small victory, but super helpful as I have completely unbolted the proprietary 3Dconnexion SDK.... Hurrah for open source! The Good the Bad and the Ugly - special buttons editon: I (just) noticed that the 3DX sdk has a file...
-
Well that sounds sensible. I can think of two possible approaches: 1) A set of lists, one for each PID with button count and all button integer values, (for reassigning them to a contigous set of button id's). For the multi-button devices we would need to create these lists for: Space Pilot, Space Explorer, Space Pilot Pro, Space Mouse Pro and SpaceMouse Enterprise. The rest we can just assume are 2 buttons. 2) Perhaps we can use the MSW (RID_DEVICE_INFO_HID) UsagePage(s), to programmatically determine...
-
Well that sounds sensible. I can think of two possible approaches: 1) A set of lists, one for each PID with button count and all button integer values, (for reassigning them to a contigous set of button id's). For the multi-button devices we would need to create these lists for: Space Pilot, Space Explorer, Space Pilot Pro, Space Mouse Pro and SpaceMouse Enterprise. The rest we can just assume are 2 buttons. 2) Perhaps we can use the MSW (RID_DEVICE_INFO_HID) UsagePage(s), to programaticaly determine...
-
Well that sounds sensible. I can think of two possible approaches: 1) A set of lists, one for each PID with button count and all button integer values for contigous re-assignment (for generating a continous set of button id's). For the multi-button devices we would need to create these lists for: Space Pilot, Space Explorer, Space Pilot Pro, Space Mouse Pro and SpaceMouse Enterprise. The rest we can just assume are 2 buttons. 2) Perhaps we can use the MSW (RID_DEVICE_INFO_HID) UsagePage(s), to programaticaly...
-
The button numbers reported through glutSpaceballButton need to be contiguous from 1 to glutGet(GLUT_NUM_SPACEBALL_BUTTONS). You can't have arbitrary designation bits for special buttons I'm afraid. I can't test on windows myself. When you have a patch ready I'll do a visual code review, make sure it doesn't break the build on UNIX for some reason, and forward it to the list for windows users to test and see if it causes any issues on their side. I don't think there's anyone lurking in the mailing...
-
The button numbers reported through glutSpaceballButton need to be contiguous from 1 to glutGet(GLUT_NUM_SPACEBALL_BUTTONS). You can't have an arbitrary designation bits for special buttons I'm afraid. I can't test on windows myself. When you have a patch ready I'll do a visual code review, make sure it doesn't break the build on UNIX for some reason, and forward it to the list for windows users to test and see if it causes any issues on their side. I don't think there's anyone lurking in the mailing...
-
I have fixed all of the button bugs I could find, (dev testing with the Space Navigator and SpaceMouse Enterprise). Also, enhanced the code to potentially support other (legacy) 3Dconnexion devices using the Logitech VID = 0x046d with support for 3, 4 and 5 byte button data packets. The code has verbose comments documenting the VID, PID, button data packet bits, new (3Dconnexion VID= 0x256f) event types and numerous pecularities. The code assumes that all (multi-axis) devices using VID=0x046d have...
-
Definitely planning to post a patch as soon as the buttons and init issue are resolved. Nice that X11 is fully working, looking into spacenavd project to try and tease out button data packet sizes (across models). With both the Space Nav & Enterprise, I get erroneous button values from glutSpaceballButtionFunc(), with the original code and my new code, ie: 4096,... -2147483648). And yes they are exactly n^2 + 1. Turns out that the Nav device mixes (puck) force data into the upper 16bits of the int....
-
Definitely planning to post a patch as soon as the buttons and init issue are resolved. Nice that X11 is fully working, looking into spacenavd project to try and tease out button data packet sizes (across models). With both the Space Nav & Enterprise, I get erroneous button values from glutSpaceballButtionFunc(), with the original code and my new code, ie: 4096,... -2147483648). And yes they are exactly n^2 + 1. Turns out that the Nav device mixes (puck) force data into the upper 16bits of the int....
-
When you're done with your changes, post a patch in order for the changes to be reviewed properly and merged. The X11 side of the spaceball support works with every device, because it relies on either the official driver or my own free software one, for 6dof events, instead of trying to talk to the devices directly. Supporting input from VR trackers is in my opinion clearly outside of the scope of a GLUT implementation.
-
Okay, I did a quick hack 'fg_spaceball_mswin.c' (attached) and got the SpaceMouse Enterprise working. And (just now) I looked at the heuristic method in your spacenavd project, and will start mulling this over. Also glanced at the X11 'fg_spaceball_x11.c' and it seems that the methods may work there as well (or does it work already?) There are two things that need resolving at the moment: 1) Why it doesn't work without calling the 3DX SDK init function. (Will report back on what I find). 2) How to...
-
Okay, I did a quick hack 'fg_spaceball_mswin.c' (attached) and got the SpaceMouse Enterprise working. And (just now) I looked at the heuristic method in your spacenavd project, and will start mulling this over. Also glanced at the X11 'fg_spaceball_x11.c' and it seems that the methods may work there as well (or does it work already?) There are two things that need resolving at the moment: 1) Why it doesn't work without calling the 3DX SDK init function. (Will report back on what I find). 2) How to...
-
In my spacenavd project, I'm using a heurstic to detect 3Dconnexion devices. It basically matches any device with the new VID, any device with the logitech VID that also has "3Dconnexion" in the vendor name string, and also comes with a short blacklist of devices which would match but are not spacemice. The relevant code is here: https://github.com/FreeSpacenav/spacenavd/blob/master/src/dev.c#L244 A few years ago a "positive match" list of known spacemice ids was also added to make it certain we...
-
Thank you for pointing me to the commit, it helps to know exactly which code was updated. Below are the (older) 3DX models using the main Logitech VID=0x046D which includes various spacemice and the CADman (2D mouse): https://www.the-sz.com/products/usbid/index.php?v=0x046D&p=&n=3dconnexion 3DX was using the logitech VID=0x046D and is now using it's own VID=0x256F with the full list of (newer) PID's here: https://www.the-sz.com/products/usbid/index.php?v=0x256f&p=&n= Some of the PID's are spacemice...
-
Thank you for pointing me to the commit, it helps to know exactly which code was updated. Below are the (older) 3DX models using the main Logitech VID=0x046D which includes various spacemice and the CADman (2D mouse): https://www.the-sz.com/products/usbid/index.php?v=0x046D&p=&n=3dconnexion 3DX was using the logitech VID=0x046D and is now using it's own VID=0x256F with the full list of (newer) PID's here: https://www.the-sz.com/products/usbid/index.php?v=0x256f&p=&n= Some of the PID's are spacemice...
-
I'm having some trouble undestanding what the issue you're reporting is. Is fgStructure.CurrentWindow null after having initialized freeglut and created a window? Or is it simply the case that this program calls glutSolidSphere without having first initialized freeglut? The fist would be a bug in freeglut, the second would be a bug in yade. If this is indeed something wrong with freeglut, please elaborate, and also ideally post a minimal compilable test program which reproduces the bug so that we...
-
I don't think there's any documentation around. But the first commit which added windows spaceball support seems to be rev.1759 and it came from this pull request in the github freeglut mirror: https://github.com/dcnieho/FreeGLUT/pull/26 Looking at the code now, it feels like it only ever was supposed to work with the space navigator. I don't see any VID/PID lists for different devices. Hopefully you can improve the device compatibility situation. I don't remember your stereo question from 2012,...
-
I don't think there's any documentation around. But the first commit which added windows spaceball support seems to be rev.1759 and it came from this pull request in the github freeglut mirror: https://github.com/dcnieho/FreeGLUT/pull/26 Looking at the code now, it feels like it only ever was supposed to work with the space navigator. I don't see any VID/PID lists for different devices. Hopefully you can improve the device compatibility situation. I don't remember your stereo question from 2012,...
-
John, Ok, I will see what I can do and are more than happy to share my results. Do let me know if you have any forum/docs/notes regarding the (freeglut) glutSpaceBall... method updates (guessing 2012-15'ish), it could help. Also you may find the 'Chronological Gallery of Spacemice' of interest: http://spacemice.org/index.php?title=Gallery FYI: You may also recall having helped me with quad buffered stereo 3D (in 2012) and I would like to say thanks once again... and let you know that it is still...
-
John, Ok, I will see what I can do and are more than happy to share my results. Do let me know if you have any forum/docs/notes regarding the (freeglut) glutSpaceBall... method updates (guessing 2012-15'ish), it could help. Also you may find the 'Chronological Gallery of Spacemice' of interest: http://spacemice.org/index.php?title=Gallery FYI: You may also recall having helped me with quad buffered stereo 3D (in 2012) and I would like to say thanks once again... and let you know that it is still...
-
I can't help with the windows code, but if you come up with a patch to fix the issue, it's certainly welcome. If you do, please post it to the freeglut-developer mailing list, to maximize the number of people that might see and test it before it gets merged.
-
I can't help with the windows code, but if you come up with a patch to fix the issue, it's certainly welcome. If you do, please post it to the freeglut-develeloper mailing list, to maximize the number of people that might see and test it before it gets merged.
-
I can't help with the windows code, but if you come up with a patch to fix the issue, it's certainly welcome. If you do, please post it to the freeglut-develeloper mailing list, to maximize the number of people that might see and test it, before it gets merged.
-
Currently, our primary platform is Windows 10 (32-bit app). Though we maintain support for Windows 7 as well. A copy of the app can be downloaded here: http://openantz.com/download/msw/proto/antz-xr_2020-09-29_app.zip Note that these publicly posted files do not include the source code, as they are using the proprietary 3DX SDK (just for the init function). If you like, I am happy to send the source directly to you. In the past (and planned future too) we have supported CentOS & Ubuntu (not for a...
-
Currently, our primary platform is Windows 10 (32-bit app). Though we maintain support for Windows 7 as well. A copy of the app can be downloaded here: http://openantz.com/download/msw/proto/antz-xr_2020-09-29_app.zip Note that these publicly posted files do not include the source code, as they are using the proprietary 3DX SDK (just for the init function). If you like, I am happy to send the source directly to you. In the past (and planned future too) we have supported CentOS & Ubuntu (not for a...