openglean-devel Mailing List for OpenGLEAN (Page 2)
Status: Beta
Brought to you by:
rkrolib
Menu
▾
▴
openglean-devel — Development (plans, problems, status...)
You can subscribe to this list here.
| 2005 |
Jan
(1) |
Feb
(1) |
Mar
(2) |
Apr
(5) |
May
(6) |
Jun
|
Jul
(2) |
Aug
(14) |
Sep
(12) |
Oct
(1) |
Nov
|
Dec
|
|---|
|
From: Richard R. <sf...@ol...> - 2005-08-01 01:26:31
|
Just a heads-up that I expect a new release in a day or so. The changes include fixes to better support GNU/LINUX systems, such as Red Hat GNU/LINUX. Some of the changes just missed being part of 0.4.1, and make GNU/LINUX support significantly better, but again, this is simply maintaining the 0.4 release so it is expected to be 0.4.2. -- "I probably don't know what I'm talking about." http://www.olib.org/~rkr/ |
|
From: Richard R. <sf...@ol...> - 2005-08-01 00:53:11
|
[Sorry if this is a duplicate post; it looks like SourceForge is rejecting email. I am trying to send this a little differently as a test. If this is also---for at least the short term---rejected, I'll try something else. As of now, the below message still has not been accepted to the project mailing list.] Just a heads-up that I expect a new release in a day or so. The changes include fixes to better support GNU/LINUX systems, such as Red Hat GNU/LINUX. Some of the changes just missed being part of 0.4.1, and make GNU/LINUX support significantly better, but again, this is simply maintaining the 0.4 release so it is expected to be 0.4.2. --=20 "I probably don't know what I'm talking about." http://www.olib.org/~rkr/ |
|
From: Richard R. <sf...@ol...> - 2005-07-16 04:47:32
|
Oh, one of the things that 0.4.1 includes is resolution of some minor warnings under GCC 4.0.1. Given the messy things that freeglut was doing to get around their problems with GCC 4.x, I expected to spend a bit of time fixing things. My concerns were groundless. OpenGLEAN had a few issues with GCC 4.0.1, but by and large it compiled smoothely. I think that the main issues were signed/unsigned botches. I also found a few problems with 32-bit/64-bit potential problems and fixed those. (Note that OpenGLEAN is primarily maintained on an AMD64 system, while still getting fairly frequent builds on a 32-bit i386 system or few...plus its herritage of OpenGLUT and freeglut have given it a well-tested 32-bit foundation. I'm not sure that I've ever seen a genuine 32-bit/64-bit misbehavior in running freeglut/OpenGLUT/OpenGLEAN code. But it's good to eliminate the little potential buglets before they get bigger and bite you hard...) --=20 "I probably don't know what I'm talking about." http://www.olib.org/~rkr/ |
|
From: Richard R. <sf...@ol...> - 2005-07-14 07:21:01
|
OpenGLEAN 0.4.1 has just been released. See the files section of the SourceForge page for information. Fingerprints for the files are: (General source tarball; ready to build by hand!) MD5 (openglean-0.4.1.tar.bz2) = 6018f3a3f143434de0651cb3367950e2 SHA1 (openglean-0.4.1.tar.bz2) = 9693d23681a43a803d9981ba796c37f358139ed1 RMD160 (openglean-0.4.1.tar.bz2) = 3e26754af81dfd9345437db8d19f9225e8278242 (Pre-built documentation tarball) MD5 (openglean-0.4.1-doc.tar.bz2) = 9464b2ea2f7c37315a7cfbdac36c3d6e SHA1 (openglean-0.4.1-doc.tar.bz2) = add4bfa9e97cb0c2788175cee3c5152086e2bb33 RMD160 (openglean-0.4.1-doc.tar.bz2) = 022c12b0047d26aa935b12814db15c49379917fd (Platform-independent pkgsrc package; should work on most UNIX-like environments, including BSD, GNU/LINUX, Solaris, Interix, ...) MD5 (OpenGLEAN-pkgsrc-0.4.1.tar.bz2) = cfd82eb81725c69479dddd220e98f9ed SHA1 (OpenGLEAN-pkgsrc-0.4.1.tar.bz2) = 03ec1099b75513e5e9871a3c2074736210dc0e2d RMD160 (OpenGLEAN-pkgsrc-0.4.1.tar.bz2) = 3989b5204514e4eeb66399ff42a11fec32aac7c7 (Pre-built WIN32 .dll and related files; all you need---and perhaps then some---to support already-written applications that require OpenGLEAN.) MD5 (OpenGLEAN-win32-0.4.1.zip) = ca5436b78478bd046842538424fd9482 SHA1 (OpenGLEAN-win32-0.4.1.zip) = 2fbb1f091b9cc77abef214d697da93328f8e313c RMD160 (OpenGLEAN-win32-0.4.1.zip) = 47afa731a6f62abecb90b41ca0dd7bce69ef5dad Note that several of the more obsolete fingerprint types are no longer provided. They do add some security, I suppose, but that is likely to be marginal. Including 5 or 6 fingerprint tags per file definitely adds a lot of clutter, though. Please NOTE: the WIN32 binaries (OpenGLEAN-win32-0.4.1.zip) should include everything that you need to use OpenGLEAN (or programs that require OpenGLEAN). However, I'm not sure what the minimal subset is; these files are most of the material that MSVC produces in the target directory. Most users will probably only want to grab the DLL file in the Release directory. The upshot is that the binary-only archive for WIN32 is much larger than one might expect. -- "I probably don't know what I'm talking about." http://www.olib.org/~rkr/ |
|
From: Richard R. <sf...@ol...> - 2005-05-31 12:28:59
|
I'm sorry to say that OpenGLEAN took a little longer to get out than initially promised, but it's out now. -- "I probably don't know what I'm talking about." http://www.olib.org/~rkr/ |
|
From: Richard R. <sf...@ol...> - 2005-05-26 11:00:40
|
At this point, the upcoming release is mostly a maint. release: * I see that freeglut has picked up the OpenGLEAN use of a macro to define the string-to-function-pointer translation in ext.c. OpenGLEAN did this only to ensure that the string names matched the symbol names (ensuring that the symbol name and the string were exact matches such that a typo in the string name would cause a compile-time error). I held back previously from building the table at run-time, but now will probably do so. The reason to do so is to work around a bug in MinGW in the creation of WIN32 ".dll" shared libraries. I don't know if the bug is somewhat inherent in the PECOFF spec, but MSVC never had a problem with the code. I held off doing this obvious workaround because it is still (IMHO) a compiler bug, and it was not certain that the workaround would actually *work* *around* the compiler bug. I don't actually have MinGW set up, so thanks to the freeglut people for testing this. (They will probably include this fix in their release, set to occur sometime perhaps in early June.) * A minor bug in the wheel event "button-up" event on WIN32 is corrected. * Found and closed a memory leak in X TextProperty handling. * Generally improved documentation. * Added the "cuboctohedron" that John Fay promotes (so much so that he has also snuck an implementation into the freeglut "shapes" demo, though the demo is supposed to be demonstrating the library shapes, and freeglut does not include the cuboctohedron shape). * Code cleanup for the demos. * Improved clock granularity. Maybe. * Minor ensurance of glReadBuffer()/glDrawBuffer() invocation at window creation (not sure if this really matters). The short summary is: More bug fixes, more documentation refinements, and a new solid/wire shape. --=20 "I probably don't know what I'm talking about." http://www.olib.org/~rkr/ |
|
From: Richard R. <sf...@ol...> - 2005-05-24 23:04:37
|
Just a heads-up, there will probably be a new release later this week. --=20 "I probably don't know what I'm talking about." http://www.olib.org/~rkr/ |
|
From: Richard R. <sf...@ol...> - 2005-05-09 20:24:30
|
I had previously hoped to look into supporting buildtool as an alternative (perhaps even as the main) way to build OpenGLEAN. A few weeks ago, I started to look at it more closely, and quickly found that buildtool's author has declared the current line of buildtool development to be dead. He sees no future in a Bourne shell-like syntax, and thinks that a completely rewrite in C or C++, using XML to define the build instructions, is the way to go. Far be it from me to question his wisdom in this. However, for now the old buildtool is dead. If and when it is rewritten (the author says he'd like to work on it, but it's not clear how that will work out for now), it will be incompatible with the current buildtool. Hence, OpenGLEAN is dropping the idea of buildtool support for now. I am a bit sorry to say that, as I find the GNU auto* and libtool suites to be a bit of a mess. While they perhaps avoid centralizing too much, at least in theory, in practice most people view them as black boxes with little or no understanding (IMHO), leading to the suite collectively being one big block of software---one which, alas, has more than one syntax and separate pieces of documentation, and which seems a bit formidable on first encounter. Anyway, onward to other things! --=20 "I probably don't know what I'm talking about." http://www.olib.org/~rkr/ |
|
From: Richard R. <sf...@ol...> - 2005-05-03 11:33:38
|
Well, partly I'm writing this email since a couple of posts to another list have bounced (possibly). Another reason that I'm writing this post is to share some reflections that I've had about error handling. (See the recent OpenGLEAN API proposal for allowing glut* functions to fail, where GLUT traditionally either succeeded to crashed your program.) When starting to mix libraries (e.g., an add-on menu library), it would become relavent to know which error handler was called first if, e.g., a menu window could not be opened. The menu code almost certainly would want to control that (for opening menu windows) to simply return. But what if the main client application has registered its own error handler? Whose gets called? What if we call the main application's handler, how can it invoke the menu handler? It would seem desirable to have the ability to cascade callbacks in some way. One solution is to define glutGetfptr(enum FptrName), and allow one to retrieve error handler function pointers (and other types, for that matter, such as keyboard and mouse handlers). This appears to solve the problem, but can result in a bit of a mess for cascading handlers. (And the order in which handlers are registered would still be and issue. E.g., a menu system would want to get mouse events before the main application can see them, in case the menu library is expected to devour the event and produce a menu.) Perhaps a cooperative environment between client application and, e.g., menu library, is reasonable. It just seems to be straying rather far from the ideal of simplicity. In any case, because of the issue of cascading callbacks, a final API decision hasn't been reached for graceful failures, so there is no implementation at this point. -- "I probably don't know what I'm talking about." http://www.olib.org/~rkr/ |
|
From: Richard R. <sf...@ol...> - 2005-05-03 11:30:18
|
Okay, there was a hiccup in mail delivery---I think because I have enabled = an external aliases file on my own server. Let's see if this works any better, now. --=20 "I probably don't know what I'm talking about." http://www.olib.org/~rkr/ |
|
From: Richard R. <sf...@ol...> - 2005-04-23 11:07:17
|
Keeping abreast of freeglut and OpenGLUT: There are no substantive changes from freeglut that seem to be worth importing. Some minor changes of variable names, a different implementation of my old idea to reduce code duplication between main.c and cursor.c on WIN32, and some minor changes to purely internal comments. The last of tho= se seemed worth doing, but are not substantive. There were also changes to gamemode. As the OpenGLEAN position is that the fundamental concept of gamemode is broken (from an API perspective and from a user-interface/-experience perspective), gamemode remains on the chopping block; it will be useful as a reference for a better API destined to replace gamemode, but fixes to gamemode itself are not likely---especially when the= ir merit is dubious. (freeglut seems to be implementing some patches directly which Nigel Stewart had filtered and applied more thoughtfully to OpenGLUT many months ago. Nigel's changes predated the OpenGLEAN fork, so presumably the OpenGLEAN gamemode works---up to the limits of the API design---at least as well as the latest freeglut gamemode.) As with the recent OpenGLUT changes, the recent freeglut changes are being monitored with vigilence for positive enhancements that may be of interest to OpenGLEAN. --=20 "I probably don't know what I'm talking about." http://www.olib.org/~rkr/ |
|
From: Richard R. <sf...@ol...> - 2005-04-23 10:39:58
|
OpenGLEAN continues to track developments on both freeglut and OpenGLUT. The latest OpenGLUT development seems to be a push towards deleting more and more window-system events from the queue and calling the client callback with a summary. As with the original OpenGLUT notion of doing this just for mouse motion events, there is no current indication of any value to this feature. OpenGLEAN is generally informed by the philosophy of giving people rope to hang themselves with, if it can also be used for other purposes. It is not clear that summarizing resize events is in any way harmful, but no one has proposed any way in which it is helpful, either---and it complicates the event processing. OpenGLEAN remains committed to providing useful features and enhancements, but these latest trends from OpenGLUT do not seem to be useful. See the freeglut discussion (and the even earlier initial OpenGLEAN reaction to the mouse-motion summarizing). Re. the OpenGLUT hack of using the tiny 8x13 fixed width font, instead of Helvetica, for menus: Were OpenGLEAN planning to retain the menus, certainly 8x13 is not the right choice, as it is visually unpleasant. Old GLUT used a nicer italicized Helvetica, I believe (well, the system fonts on X generally did); the UNIX_X11 build of current freeglut, older OpenGLUT, and all versions (to date) of OpenGLEAN used an upright Helvetica, which was about as close, and nice, as one can get within the limited GLUT fonts. Also, the 8x13 font is very small. In all likelihood no change at all will be made to the OpenGLEAN fonts used for menus prior to the menus being excised to a separate library or left to the client's responsibility. But certainly not to a uniform choice of the 8x13 font. OpenGLEAN is concerned about legibility and aesthetics issues, which the 8x13 font undermines. A couple of very minor changes from OpenGLUT have been adopted, but basically the OpenGLUT changes since the fork do not appear to be in line with OpenGLEAN's goals of producing a lean, flexible, simple, flexible API nor with the sound software design principles of keeping the software as simple as possible (but no simpler, right?). -- "I probably don't know what I'm talking about." http://www.olib.org/~rkr/ |
|
From: Richard R. <sf...@ol...> - 2005-04-11 10:03:47
|
OpenGLEAN 0.3 has been released. Mostly this is only releaed since there is no public repository at this time. There were some bug-fixes and other changes, so... The version bump would not have been so major except that there won't be too many really big changes until I get to 1.0. So in the relative scale of pre-1.0, this was a fairly big change in some ways. The larger portion of the near-term work will probably be soaked up by the process of creating the satellite libraries (still unnamed) to house the code that is to be excised from OpenGLEAN. Those changes won't necessarily parallel any OpenGLEAN releases, and certainly won't require changes to the core library. --=20 "I probably don't know what I'm talking about." http://www.olib.org/~rkr/ |
|
From: Richard R. <sf...@ol...> - 2005-04-11 01:52:53
|
OpenGLUT has observed that some X servers can produce large numbers of events in response to mouse motion. OpenGLUT has proposed hiding most of these events from the client to avoid "flooding" the client. The suggested case is an application that is drawing updated displays when the mouse move= s. The OpenGLEAN position is that almost all (one hesitates to say all) cases can be handled by proper use of glutPostRedisplay(). Posting a redisplay is cheap and throttles actual redrawing events. Meanwhile, some programs may defensibly want to know about the mouse position with as fine a granularity as the window system will provide. Unless a clearer case is made for dropping mouse events, OpenGLEAN will not take up the changes that OpenGLUT has been discussing. --=20 "I probably don't know what I'm talking about." http://www.olib.org/~rkr/ |
|
From: Richard R. <sf...@ol...> - 2005-04-11 01:46:31
|
The recent, confused spate of emails on the freeglut developer list suggested at first that freeglut would not compile under GCC 4.x (at least for some snapshots of GCC 4.0). Current claims are that it in fact compiles with no changes. =46rom the description, the OpenGLEAN code should compile with the GCC 4.0 snapshots in question. Other reports suggested that this may have changed between versions. Several conflicting patches---ulatimately including conditional compilation for different compilers---were provided, before the issue was dropped. The OpenGLEAN position on this is to wait and see what GCC 4.0 actually winds up being. There is some reason to hope that the code will "just work". --=20 "I probably don't know what I'm talking about." http://www.olib.org/~rkr/ |
|
From: Richard R. <sf...@ol...> - 2005-03-27 02:14:22
|
On Mon, Mar 21, 2005 at 03:47:02PM -0600, Richard Rauch wrote:
[...]
> fixed, and new bug reports were opened on them. I think that I'll
> try to do a version bump after I fix those (unless more problems show
> up), and provide a binary WIN32 release.
As of March 23, OpenGLEAN 0.2.1 is out. A significant new feature
is auxiliary buffers for OpenGL rendering. This is the first
GLUT-family member to offer a release with this feature, I believe.
freeglut has an unreleased version of this feature. Before releasing
this in OpenGLEAN, I tried to discuss the API with them, but they would
not ("do what you want", said one of the freeglut devlopers, effectively
closing the discussion---there was no interest in exploring the alternative=
s,
such as OpenGLEAN's approach).
I'd rather have one source-level API for this to ease transition
between the libraries, but the freeglut API seems a fundamental abuse
of the idea of bitflags, and will invite further problems down the
road. If freeglut releases an API implementation of this as their
unreleased code stands, I may add the freeglut API to OpenGLEAN,
strictly as an up-to-1.0 compatibility feature (post-1.0, such
cruft will not be part of OpenGLEAN unless someone is willing to
explain to me why the freeglut API was the right one this feature).
The core library is probably fairly close to what it will be for 1.0.
The biggest change that I expect before 1.0 will be implementation of
the individual features that, taken together, can replace "gamemode".
--=20
"I probably don't know what I'm talking about." http://www.olib.org/~rkr/
|
|
From: Richard R. <sf...@ol...> - 2005-03-21 21:47:06
|
OpenGLEAN development has slowed considerably, but not stopped. I spent more time than I cared to hunting down a bug that proved to come from the OpenGLUT days. (It only affects WIN32; this is not surprising as WIN32 has been largely neglected in OpenGLUT for some time before OpenGLEAN was forked.) I've found two more problems with OpenGLEAN, now that that bug is fixed, and new bug reports were opened on them. I think that I'll try to do a version bump after I fix those (unless more problems show up), and provide a binary WIN32 release. <rant>The WIN32 API is a royal pain. It seems that there are two ways you can get messages from WIN32: One is by polling a message queue, and the other is by callbacks that WIN32 directly does to client code. (At least, that's my current understanding.) The result is that when a window is first created, long before the OpenGLEAN main event loop is set up and running, WIN32 may presumptively call into the event callback code. In fact, as OpenGLEAN then calls WIN32 API functions which in turn may further call back OpenGLEAN, we can get at least 2 or 3 levels of recursion in the event handler. Since this is happening before the WIN32 API call for window creation has returned a window handle, there is no way for the client to have registered callbacks, and other OpenGLEAN state may not be prepared for handling events. This is really nasty. However, maybe we can store the WIN32 events in a linked list and process them on our own time. If we can force WIN32 to not do direct callbacks when we are not prepared for them, that would also be good.</rant> --=20 "I probably don't know what I'm talking about." http://www.olib.org/~rkr/ |
|
From: Richard R. <sf...@ol...> - 2005-02-11 03:17:50
|
I wanted to mull over a change about flushing X message queues, so I let the library sit for a few days. Now I may be a bit too busy to work much on the code for a little while. Since there was an incomatible ABI bump (hopefully the last before 1.0), it seemed appropriate to call this 0.1. We'll see how it goes. The fingerprints for the new files are: 2562614632 511020 openglean-0.1.0-doc.tar.bz2 2339517594 645365 openglean-0.1.0.tar.bz2 12562 500 openglean-0.1.0-doc.tar.bz2 42508 631 openglean-0.1.0.tar.bz2 MD2 (openglean-0.1.0-doc.tar.bz2) =3D 3e32e9420e77ebc1b5b68532fc35f8a9 MD2 (openglean-0.1.0.tar.bz2) =3D 26b681364f40f772de5071df35bd3e5f MD4 (openglean-0.1.0-doc.tar.bz2) =3D 4518a2d0a1a63dff49014a179da87216 MD4 (openglean-0.1.0.tar.bz2) =3D abd62602f1f5b2260fdc07177c64305b MD5 (openglean-0.1.0-doc.tar.bz2) =3D ff4fe83f358b00c059b2adb49d65651e MD5 (openglean-0.1.0.tar.bz2) =3D 37f5a5987590e80dd1222f5fbe06a2ec SHA1 (openglean-0.1.0-doc.tar.bz2) =3D 4e12106c222ac4622bbe351dacea904c3707= b21f SHA1 (openglean-0.1.0.tar.bz2) =3D 5a582b13363542cc17cf44b055b62bf0577538e0 RMD160 (openglean-0.1.0-doc.tar.bz2) =3D c795d4f02db1bf05de4c27f13d8d687713= c5b726 RMD160 (openglean-0.1.0.tar.bz2) =3D eebdbf9ac4ab484a472401f1562277bfb3c4c2= c4 --=20 |
|
From: Richard R. <sf...@ol...> - 2005-01-28 09:24:22
|
Well, with luck, the OpenGLEAN development mailing list now exists. I don't expect any immediate traffic, but wanted the list to be available. This message is really a test message for the list... -- "I probably don't know what I'm talking about." http://www.olib.org/~rkr/ |
