On Mon, 2010-12-20 at 16:47 +0100, Reimar Grabowski wrote: > On Mon, 20 Dec 2010 15:50:52 +0100 > <dhkblas...@zeelandnet.nl> wrote: > > > > But why is it not possible to integrate this with the regular fpGUI ? > > > Can you explain in a couple of sentences ? > > > > Thats not all however, there are minusses. By using glut, you limit > > yourself to the supported platforms/targets. So if new platforms/targets > > come along then there is no way (unless you supply patches to the > > project) to add them. With the current approach you're free to do it > > yourself. Also the API is plain rigid. This means you'll have to adapt > > to that and live with it (notice it's a plus and minus depending on how > > you look at it). (That is why I would like to see a fpGlut some day ;) > > and believe me it will come to that eventually!)
> First of all good work, but I hope to never see any abominations like > fpGlut around. Glut is just a major PITA and should not be used by > anybody for anything serious. It was developed to make it easy to I wouldn't use the same words as you do, but I agree it's sub-optimal ;) > write SIMPLE OpenGL DEMOS in a cross plattform way. Since then it has > been used for all kinds of stuff although it has some big limitations > namely its mainloop and the callback shenanigans. Both interfere with > the nature of a GUI framework and therefor I don't really understand > why you based your work on glut. OpenGL is a graphics lib and glut > includes window creation, mouse and key handling, etc which should be > separate. You don't need glut to use OpenGL you just need a valid > context. I don't know anything about the inner workings of fpGUI but > if you think that a fpGlut would help you then I am sure a > fpOpenGLContext would help even more and perhaps make it possible to > merge the code back to regular fpGUI. Benefits of custom context > generation are that you have more control over its options > (ColorBuffer-, DepthBuffer-, OtherKindOfBuffers-Resolution, double-, > triple-, quadbuffering, etc.), no mainloop or callbacks (the > TOpenGLContext of the LCL works with the standard LCL event system and > application mainloop) and no need for glut support on the target > platform (every OpenGL capable platform exposes a way to create a I should have chosen my words more carefully. With fpGlut I actually did not mean to port freeglut to pascal, but actually create a platform independent context handling library (as you describe). > context). The drawback is that context generation is a little more > complex than using glut and that it is platform dependend. I haven't This is the reason why I started using GLut. Just as proof of concept. > looked into the new OpenGL stuff > 3.0 but I know there was talk about > simplifying context generation and to try to make it more similar on > the different platforms. So IMHO getting rid of glut and integrating > an OpenGL context into fpGUI should make it possible to just use > OpenGL as a standard backend for fpGUI. I am not really interested in Totally agree > doing this myself but if you need help I will do what I can. If I get enough help I could be interested in starting a new project. Darius _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
