iMiniB3D -> generic cpp port
BlitzMax Forums/MiniB3D Module/iMiniB3D -> generic cpp port
| ||
| Unfortunately, Openb3d's LGPL license doesn't sit with me very well, being somewhat overly-restrictive. Would it be worth porting iMiniB3D to a generic cpp library with less restrictive licensing? Also the whole idea of "Ints" for everything makes me think of the 90's. Which rules out "Munch's" wrapper, as it uses Ints for all the pointers. On 64-bit, pointers are not 4-bytes big. |
| ||
| > Would it be worth porting iMiniB3D to a generic cpp library with less restrictive licensing? Yes :-)  |
| ||
| Considering that your own take on iMiniB3D might interface it better with the other technologies that you're handling, yes, it would be worth it. This leaves room for some optimisations as well. |
| ||
| I suppose I could rewrite the wrapper to be 64-bit compliant. I guess the best way would be to use custom types like in minib3d. |
| ||
| Munch, that wouldn't help with the LGPL license. As far as I know the LGPL license must be used because of the Coldet library which is included in OpenB3D and LGPL and therefore all projects using this must be licensed accordingly. LGPL is like a virus, I had such a discussion 5 years ago with my BlitzTiles project and finally using a modified BSD license. The Integer issue is bad but the license issue is even worse. As OpenB3D ist a fork of iMiniB3D, Brucey's suggestion is the way to go IMHO. |
| ||
| So if i want to release a game using OpenB3D, i have to use the LGPL license? |
| ||
| So if i want to release a game using OpenB3D, i have to use the LGPL license? No. If you are linking to a DLL that is LGPL, you can license your game any way you wish. But, you cannot statically link (i.e. embed the library in your game binary), unless the library gives a static linking exception - one example of an LGPL-type library which has this exception is wxWidgets. |
| ||
| To be honest the idea to reuse blitz 3d for syntax (I mean obj=createcube().. Obj is int) is... Pure nightmare. I really wish the oop approach... |
| ||
| You can statically link the library in your game, and you don't need to release its source: you just need to provide the object file of your game to anyone who legally have a copy of your game, if asked to, so he will be able to link it with another version of OpenB3D (but I doubt that anyone will ever ask). And don't worry about reverse engineering... an object file is just as hard to decompile as an executable. |
| ||
| I have a new OOP version of the wrapper now. Hopefully it is now 64bit compatible. I do think it's better now, being like minib3d syntax. Krischan, thanks for the info. I didn't know about the coldet library. Yeah, it would be nice not to have the LGPL issue as I'm sure it puts a lot of people off. Oh well. |
| ||
| The part from coldet is only used for the MeshesIntersect command, so it could be removed, but I'd rather not to have to do that; anyway, I've just sent a mail to Amir Geva, the author of ColDet, and I'll wait for a response. |
| ||
| Ok, I got an answer: the part of Coldet I used (the file "collidetri.c") has not been written by Amir, he took it from public domain code. So, I'm allowed to change the license. To allow static linking, I was thinking about adding this: "As a special exception, the copyright holders of this library give you permission to link this library with independent modules to produce an executable, regardless of the license terms of these independent modules, and to copy and distribute the resulting executable under terms of your choice, provided that you also meet, for each linked independent module, the terms and conditions of the license of that module. An independent module is a module which is not derived from or based on this library. If you modify this library, you may extend this exception to your version of the library, but you are not obliged to do so. If you do not wish to do so, delete this exception statement from your version." |
| ||
| That seems acceptable. Thanks angros :-) |
| ||
| Brucey, Might I suggest doing what you were talking about regardless? I took Simon's iMiniB3d and smashed sdl into it without any problems. It was only about a days worth of work. Initially I too was concerned about OpenB3d's licensing and asked Angros47 about it. Even so using his version of the library for testing I ran into all sorts of problems. He uses immediate mode in GL which is a big no-no for core and gles. So I was stuck stripping out features to basically make it iminib3d again in order to get it to work cross platform as well as on mobile. Along the way i have sent bug fixes to Simon and Angros that I have came across and I really wish I could just share my code, but its a complete cluster now. I'm a few years in and have heavily modified most of the code base. Honestly I think it would be a great idea for the community to get together here and add proper shader support, no immediate drawing, no arb, and just make it Gl 3-4core/ES 2.0 compliant. Just my two cents. Either way, Im glad to see other people getting into this! -Vert |
| ||
| I removed the immediate mode in the upcoming version: I replaced all glBegin/glEnd with glDrawArrays. The only reason I haven't uploaded it yet is because I'm adding a new feature (metaball support) that still requires a bit of work. |
| ||
| Awesome. Looking forward to it! :-) |
| ||
| and just make it Gl 3-4core/ES 2.0 compliant. With an ES 2.0 compliant engine, we could then also use Angle on Windows and render to DX11/9 :-) |
| ||
| +1 to Brucey's genius- I'd love to use Angle. |
   |