Re: [Lazarus] New widgetset
> This seems to indicate that you use an older version of OpenGL (1.5). AFAIK > GLSL was included from OpenGL 2.0. So this suggests you should try to update > your libraries. GLSL is also available for older OpenGL 1.x, through OpenGL ARB extensions (ARB_shader_objects and friends). But I don't know if nvidia-widgetset uses it. But in this case, the problem is most likely Mesa. You need the latest Mesa (>= 7.9) to have any chance of GLSL shaders, and they are still quite unstable (for now). For now, the advised way to get really advanced OpenGL version, with full shader support etc., is to enable proprietary drivers, which can give you OpenGL even > 3 on newer graphic cards. Since you have Ubuntu, this is trivial, just use System->Administration->Hardware Drivers. You can easily enable, and later easily disable (if you feel unclean :) proprietary drivers from there. HTH, Michalis -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] RE : New widgetset
Ludo Brands wrote: > Tried the example but it crashes with a segfault at line 31 in > nvShaderUtils. It appears that the address of glCreateShader is nil. I tried > to break into any of the Load_GL_VERSION_x_y or glext_LoadExtension in > glext.pp but no success. When are functions like glCreateShader supposed to > be initialised? > > Ubuntu 10.04 OpenGL 2.1, shading language version 1.2 > glCreateShader is initialized by Load_GL_version_2_0 (also, higher Load_GL_version_x_x call Load_GL_version_2_0). Darius: nvidia-widgets/src/nvwidgets/nvglutwidgets.pas calls Load_GL_version_2_0, but the result is not checked. You should abort the program (probably it would be nicest to raise an exception) if Load_GL_version_2_0 returns false (meaning that some entry points are not defined). Since the rest of the code seems to assume that GLSL functions are initialized. Ludo: Are you sure you have OpenGL 2.1? Some OpenGL implementations unfortunately lie, claiming in glGetString(GL_VERSION) that they support higher version than in reality. You can try adding Writeln(Load_GL_version_2_0) into any OpenGL example program, and you will probably see that it answers false. For example, you can add Writeln(Load_GL_version_2_0) inside the FPC demo packages/opengl/examples/glutdemo.pp, near the other writelns. Michalis -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] RE : RE : New widgetset
Ludo Brands write: > The all or nothing approach in Load_GL_version_X_Y (all functions are > present or fail) is simple but has its disadvantages when working with third > party libraries. Fe Synapse uses a more elaborate method of loading > functions at runtime. It defines for every function a wrapper that checks if > the function pointer is assigned and then calls it or raises a meaningfull > exception. > When an entry point is nil, the error message is more or less clear if you can read the backtrace :) The real trouble is that defining such "stub" versions for all the functions would be unmaintainable IMHO, as there are a *huge* number of GLExt functions, with various parameters. That's a lot of work, only to deal with inferior OpenGL implementations. Maybe all the Assigned() checks could be moved lower, so that everything possible is still loaded, even when Load_GL_version_x_x returns false. Although this will still be risky: the programs that want to play safe should just assume that you really don't have (correct) OpenGL 2, and just don't use any of it's functions, if some entry point failed, IMHO. GLSL shaders are also available through ARB extensions, and this is a good fallback that works in practice, in my experience. (For example, my fglrx lies about OpenGL 2 too, but it has valid ARB_shader_objects and friends.) So using GLSL shaders even with these broken implementations is possible. However nvidia-widgetset doesn't use ARB_shader_xxx. Understandably, nvidia-widgetset assumes a correct OpenGL implementation, and I have indeed never seen nvidia OpenGL lying about it's version (fglrx, and some latest Intel, lie all the time on the other hand..) Michalis -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] Change default component name
Hi, When you drop a component on a form, by default the name of the component is derived from the ClassName with leading 'T' removed (and number suffix added). Now, I'm wondering about registering a class named T3DScene as a component, and this causes problems: when you drop this component on a Lazarus form, the default name is "3DScene1", which obviously isn't a valid Pascal identifier. Lazarus shows an error message "Error setting the name of a component :T3DScene to 3DScene1" and refuses to add the component to the form. 1. Is there a solution for this? Is there maybe a virtual method like TComponent.GetDefaultName that I can override, or some other way to tell Lazarus that the default name for T3DScene class should be like "Scene1", "Scene2" etc.? 2. Or do I just have to rename the class (to e.g. "TScene" or "TScene3D") to make it work without problems with form designer? Browsing the Lazarus sources, I didn't see any such way (it seems that the logic to remove 'T' from ClassName is just hardcoded in some places), so I'm guessing it's 2., but wanted to make sure :) Thanks, Michalis -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Change default component name
Michalis Kamburelis wrote: > Browsing the Lazarus sources, I didn't see any such way (it seems that > the logic to remove 'T' from ClassName is just hardcoded in some > places), so I'm guessing it's 2., but wanted to make sure :) > To answer my own question, the logic is inside TCustomFormEditor.CreateUniqueComponentName, and there doesn't seem to exist a reasonable way to change it. In theory, I could try assigning my own Name in constructor looking at my Owner, but then I also need to make sure myself that the name is unique (add unique number suffix), opening a can of worms (since I would have to replicate part of TCustomFormEditor.CreateUniqueComponentName implementation then, and fear that it can change one day :). I guess the class should just be renamed. Michalis -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Change default component name
Mattias Gaertner wrote: >> To answer my own question, the logic is inside >> TCustomFormEditor.CreateUniqueComponentName, > > I added a check. Please test. New ClassNameToComponentName works fine :), tested with Lazarus trunk compiled by FPC 2.4.4. The default component name is now "T3DScene1", which makes it a valid identifier. >> >> I guess the class should just be renamed. > > Yes, that would be nicer for many users. > Will do. (I want to support at least Lazarus 0.9.30 anyway, so even if Lazarus trunk will get nicer solution, I still have to workaround it for existing stable Lazarus version.) Thanks, Michalis -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Generics type as parameter
Leonardo M. Ramé wrote: Without generics, I can use, for example, a TObjectList, or a TCollection, without any problem. Is there a way to do this using Generics?. All generics in FGL unit descend from non-generic TFPSList class. It can be used if you need to treat them in a uniform manner. Michalis -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] Patch to add multi-sampling (anti-aliasing) to T[Custom]OpenGLControl
Hi, For those using TOpenGLControl component in Lazarus: I just submitted a patch that adds new property MultiSampling that allows to easily turn on anti-aliasing for OpenGL contexts. The patch and description is on http://bugs.freepascal.org/view.php?id=22026 The patch is by Jan Adamec and me. The new TOpenGLControl.MultiSampling property also happens to be compatible with my TCastleWindow.MultiSampling property in my "Castle Game Engine" :) Michalis -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] Responding to #22170 comments: adding more properties to TOpenGLControl
Hi, I recently submitted a patch to TOpenGLControl to add AlphaBits, DepthBits and StencilBits properties, see http://bugs.freepascal.org/view.php?id=22170 . The patch is already applied to Lazarus SVN, thanks to Juha Manninen :) In the comments, there is a question about AuxBuffers and ColorBits. Indeed, I agree they would be useful. I personally don't have a need for them now, so I will not prepare a patch for them (at least not right now), but I would be glad to test the patch if somebody else does. I created a wiki page with a bunch of links and information, that may be helpful for anyone wanting to add AuxBuffers, ColorBits or similar properties to TOpenGLControl. It's here: http://wiki.freepascal.org/Extending_TOpenGLControl I hope this is helpful :) I can't add a comment to the bug report on http://bugs.freepascal.org/view.php?id=22170 , so I'm posting the info here and on wiki. I am relatively knowledgeable about OpenGL (you can google for my Castle Game Engine using FPC :) and interested in keeping TOpenGLControl in good shape, so you're welcome to ask me for details, and I'm very willing to test related patches (on Linux and Windows) :) Regards, Michalis -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] TOpenGLControl.DepthBits default value
Reimar Grabowski wrote: Hi, the in the topic mentioned property defaults to a value of 16. Is there any special reason for it? IMHO the default value should be 24. After all it's 2013 and not 1998. It's not really a problem, I just want to know the reason why this value was chosen. Before my patch on http://bugs.freepascal.org/view.php?id=22170 the depth bits were hardcoded (16 on WinAPI and 1 on GLX). So I set the default value for TOpenGLControl.DepthBits at safe 16. The general idea is that TOpenGLControl has safe default values, that are guaranteed to work (and be fast) even on really really ancient graphic cards or when the system is running under virtual machine (which often means you don't get hardware-accelarated 3D until you explicitly install/enable something). For the same reason e.g. TOpenGLControl.StencilBits is by default 0, even though all modern GPUs can give you at least 8-bit stencil buffer. Other APIs to get OpenGL context, like GtkGLExt or Glut or low-level WinAPI or GLX follow the same convention. The defaults are very conservative. That said, I would be personally fine with changing this default to 24, if others think it's a good idea. A developer can always lower it to 16 when that's enough. So, I don't really have a strong preference about it. Michalis -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] TOpenGLControl.DepthBits default value
Kostas Michalopoulos wrote: AFAIK even if you ask for 24 and there is no support for it, you'll get a 16bit buffer anyway. No. This is a required minimal value, at least for GLX and modern wglChoosePixelFormatARB. It was *possibly* treated in more relaxed way by the old ChoosePixelFormat, but you should not depend on that. Links to relevant docs are on http://wiki.freepascal.org/Extending_TOpenGLControl . Michalis -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] [Announcement] Castle Game Engine 4.0.0 release for FPC game developers
Hi, I would like to announce a release of Castle Game Engine 4.0.0, an open-source cross-platform 3D game engine for Object Pascal (only FPC/Lazarus): http://castle-engine.sourceforge.net/news.php?id=release-4.0.0 I'm letting myself post an announcement to lazarus and fpc-pascal mailing lists, as this engine release is really directed at ObjectPascal developers: we finally have a nice high-level game engine API, it's possible to make a 3D game really trivially easy, and everything is also very flexible. We also have a lot of new engine documentation (tutorial, classes overview etc.) and useful examples. The engine reads many 3D model formats, focusing on VRML/X3D standards (so you can make 3D models in pretty much every 3D modeling software), but also supporting Collada and other popular formats. We use OpenGL for graphics, and we have many eye-candy features (shadows, mirrors, bump mapping, screen effects, shaders etc.). The engine is basically integrated into Lazarus (you can drop TCastleContol, and a couple of non-visual components, on the Lazarus form), although it can also be used without LCL (we have our own TCastleWindow). The engine license is modified LGPL (same license as FPC RTL), so you can make both open- and closed-source games with it. We welcome developers that want to use our engine, and/or contribute of course :) If you want to make a game using our engine, give it a try :) Links to downloads and documentation are on http://castle-engine.sourceforge.net/engine.php Links to our tools and old games are on the main page, http://castle-engine.sourceforge.net/ . Regards, Michalis -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] TOpenGLControl: multisampling not working (Linux/GLX)
Reimar Grabowski wrote: Hi, as the title says multisampling does not work for me. I was testing TOpenGLControl.MultiSampling on Linux (with Radeon GPU), it worked fine for me. Note that there is a fallback (documented in TCustomOpenGLControl interface): if the requested MultiSampling is not available, we fallback to non-multisampled context (that's because for most applications anti-aliasing can be just an optional feature). I guess you already checked that this didn't happen in your case? The code is pretty straightforward, in glgtkglxcontext.pas LOpenGLCreateContextCore gets called with given MultiSampling value, and then CreateOpenGLContextAttrList adds to the attributes this: Add(GLX_SAMPLE_BUFFERS_ARB); Add(1); Add(GLX_SAMPLES_ARB); Add(MultiSampling); The GLX_SAMPLES_ARB is the minimal required value (as http://www.opengl.org/registry/specs/ARB/multisample.txt says "...accepts GLX_SAMPLES_ARB in , followed by the minimum number of samples that can be accepted in the multisample buffer"). So it should work... Well, unless GLX is just lying to us. Can you check what list was created in your case by CreateOpenGLContextAttrList, did it contain appropriate GLX_SAMPLES_ARB and MultiSampling items? Michalis -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] TOpenGLControl: multisampling not working (Linux/GLX)
I was testing TOpenGLControl.MultiSampling on Linux (with Radeon GPU), it worked fine for me. I just did some more testing, and things look a little weird. TOpenGLControl.MultiSampling works fine for Radeon GPU, but silently fails with NVidia GPU (GeForce GTS 450 with propriatary NVidia OpenGL). On NVidia GLX behaves like we have multi-sampling config, but the actual context doesn't have multi-sampling. Both systems (Radeon and NVidia) run Linux (recent Debian testing version). What is weirder is that I can get multi-sampling on both these systems (both Radeon and NVidia) with a very similar multi-sampling code inside my Castle Game Engine TCastleWindow class (that directly uses GTK and GTKGlExt, without Lazarus TOpenGLControl, to create window with OpenGL context). Seems like there is something specific in Lazarus/TOpenGLControl that causes (some?) drivers to just ignore multi-sampling (even though glx seems to behave like we found multi-sampling context correctly, just like Reimar describes). Not really sure what is wrong at this point. Michalis -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] TOpenGLControl: multisampling not working (Linux/GLX)
Mattias Gaertner wrote: Reimar sent me a patch that allocates a simple colormap, instead of the "sophisticated" gtkglext colormap. That seems to be enough for multisampling. :) I can confirm that it also fixes the issue for me: now I can get multisampling in TOpenGLContext on both Radeon and NVidia on Linux (previously only Radeon was working for me). Thank you!, Michalis -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] OpenGL with Lazarus
Mattias Gaertner wrote: On Fri, 10 May 2013 11:47:54 +0300 Tommi Prami wrote: Hello, Is there any abstraction of OpenGL for Lazarus/FPC. I am not that interested on learning OpenGL at low level, but rather use what it can provide, a bit higher level? Similar to GlScene... (Or is there Port of GlScene for Lazarus(FPC)... ) See here http://lmgtfy.com/?q=glscene+lazarus You can also try Castle Game Engine, an open-source 3D game engine for Lazarus/FPC, see http://wiki.freepascal.org/Castle_Game_Engine and http://castle-engine.sourceforge.net/engine.php :) Michalis -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Resolved: Carbon Application: Unable to open file "-psn_0_....."
Schindler Karl-Michael wrote: I finally found it. The problem was that the program accepts a file for opening from the first command line parameter. That's where the -psn_0_ came from. And the -psvn... option is under the hood passed to your programs when you run them from Finder on Mac OS X, see http://forums.macrumors.com/showthread.php?t=207344 and http://stackoverflow.com/questions/10242115/os-x-strange-psn-command-line-parameter-when-launched-from-finder . When programming Mac OS X GUI programs that interpret command-line, you have to be ready to detect (and usually ignore) the -psvn... options. Michalis -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] Castle Game Engine 5.0.0 release
Hi everyone, We're proud to announce the release of Castle Game Engine 5.0.0 :) Castle Game Engine is an open-source (LGPL) 3D and 2D game engine, of course for modern Object Pascal (FreePascal / Lazarus). We support many 3D formats and various graphic effects. The main engine site, with detailed list of features, links to downloads and documentation, is on http://castle-engine.sourceforge.net/engine.php The main feature of 5.0.0 release is the support for Android and iOS (iPhone, iPad) platforms. We use OpenGLES 2.0 renderer underneath, and our engine can render on Android/iOS almost the same things as on normal desktop systems :) Thousand thanks go the FPC team for making it all possible. Other new engine features include nice 2D API (although the engine started as a 3D engine, it's very comfortable now to make pure 2D games too) and new font reading and rendering (using FreeType). Check out also "Darkest Before the Dawn" http://castle-engine.sourceforge.net/darkest_before_dawn.php , our first game done for Android :) The details about new engine features are on http://castle-engine.sourceforge.net/news.php?id=2014-05-01 . There is also a wiki page documenting Android specifics: https://sourceforge.net/p/castle-engine/wiki/Android%20development/ and iOS specifics: http://sourceforge.net/p/castle-engine/wiki/iOS%20Development/ . Engine usage tutorial is on http://castle-engine.sourceforge.net/tutorial_intro.php and API reference is on http://castle-engine.sourceforge.net/apidoc/html/index.html . Have fun! Michalis -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] copy from Topenglcontext
Andrea Mauri wrote: > Dear all, > > Is it possible to copy the content of OpenGLContext to the clipboard? > How can be done? > You could also copy the contents of OpenGL context (created by TOpenGLContext or any other similar control) using glReadPixels, and then convert the resulting bytes into a TBitmap instance. Then you can copy TBitmap contents to clipboard like Anton shows, using Clipboard.Assign (see http://wiki.lazarus.freepascal.org/Clipboard#Load_from_clipboard ). Using glReadPixels and then converting the result will be cross-platform, as opposed to Anton's solution using Windows.CreateCompatibleBitmap . Michalis -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Tool to convert a multiline text to a pascal string constant
Luiz Americo Pereira Camara wrote: > Hi is there any tool for Lazarus to convert a multi line text (xml > snipet, SQL) to a string constant? > > Currently i'm using the following regular expression > > http://regexr.com/3cna5 > > If some one knows a better regular expression that handles putting ';' > instead of '+ LineEnding +' in last line would help also > As part of PasDoc project we have developed simple file_to_pascal_string utility for this purpose. Just get http://svn.code.sf.net/p/pasdoc/code/trunk/source/tools/file_to_pascal_string.dpr and compile it. Alongside, there's also file_to_pascal_data that converts anything to an "array [0 .. Xxx] of Byte" (good to include binary data in the same way). See http://svn.code.sf.net/p/pasdoc/code/trunk/source/tools/file_to_pascal_data.dpr . And see http://pasdoc.sipsolutions.net/ for whole PasDoc website and links to whole SVN and GIT sources. I'm using these utilities throughout my projects -- PasDoc, Castle Game Engine, to include text and binary data inside compiled file. (Although at some point I may migrate to using FPC cross-platform resource files for similar purpose.) Regards, Michalis -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Loading OpenGL error
Aradeonas wrote: > Hi, > > I have a new Laptop and with new Windows 10 and tried my old working > demos and I tried it with Last Lazarus Trunk 1.7 and FPC 3.1.1 and just > tried to run it and its happen : > > A dynamic link library (DLL) initialization routine failed > > It is because OpenGL loading error and I dont have clue how to solve it. > I already update all drivers and windows but nothing. > Any one know how can I solve this or faced it before? > > And I tried it with Lazarus 1 and FPC 2.6.2 and it works good and it > seems OpenGL units changed but I dont know what changes break it. > Are you sure it's in the OpenGL units initialization? Can you test the Lazarus examples/openglcontrol/ demo, and see does it crash too? Base FPC units are part of FPC (trunk/packages/opengl/src/), they are outside the Lazarus "OpenGL component" package. In Castle Game Engine we're using FPC OpenGL units on many platforms, including Windows 10, and we often test with latest FPC from trunk. And everything seems to work cool. Also, the FPC OpenGL units did not have any "critical" change since a long time, so I doubt something broke there. And since you already tested that reverting old Lazarus version doesn't help, it does indicate the problem is somewhere else... Regards, Michalis -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Tool to convert a multiline text to a pascal string constant
Marco van de Voort wrote: > On Wed, Feb 03, 2016 at 07:07:46AM +0100, Michalis Kamburelis wrote: >> >> As part of PasDoc project we have developed simple file_to_pascal_string >> utility for this purpose. Just get >> http://svn.code.sf.net/p/pasdoc/code/trunk/source/tools/file_to_pascal_string.dpr >> and compile it. > > Kind of redundant if two such tools come with FPC (data2inc and bin2obj) > Hm, I admit I simply didn't know about them long time ago, when creating file_to_pascal_xxx utilities in PasDoc:) Looking at them now: 1. They both have quite longer code than our simple file_to_pascal_string.dpr / file_to_pascal_data.dpr... In particular data2inc wants to do much more (being able to process a special file format like data2inc.exm). Although it can do the simple thing when invoked with -b option. But bin2obj is cool, almost exactly what we need, and could replace file_to_pascal_string and file_to_pascal_data indeed. 2. However, neither of them produces a string with line endings expressed as LineEnding constant (so it's OS-specific when output). And we actually like that:) Both bin2obj and data2inc encode the text to a series of characters, and newlines are expressed by explicit chars (like #10 when input has Unix line endings). But that's a minor thing indeed. If we would know about bin2obj back then, we would probably use it:) Thanks! Michalis -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
