Page 2 of 4 FirstFirst 1234 LastLast
Results 11 to 20 of 33

Thread: Asphyre Sphinx 3.0.0 has been released.

  1. #11
    Quote Originally Posted by Andru View Post
    First of all - path like /Develop/Asphyre... are you serious? GNU/Linux is not a MacOS X Better to use relative paths, or ask programmers to move Asphyre source code into home directory and use paths like $Env(HOME)/Asphyre, where is $Env(HOME) is a standard macros supported by Lazarus.
    Regarding that specific path: it's just a path, which you can always change. There is also no pleasing everyone as one way or another people will have to change paths to accommodate for their environment. If you use relative paths, and then move example application to a different folder, the parental structure will change and path won't work. If you set for home folder, and move application to somewhere else, the path won't work.

    Therefore, "/Develop/Asphyre" was chosen as a supposedly intuitive illustration referring to Asphyre installation path, which most likely will be changed. Besides, if you use "Basic" as a startup sheet, you'll most likely put it anywhere you like, so you may end up using absolute paths after all.

    Quote Originally Posted by Andru View Post
    Also I didn't notice dependency to LazOpenGLContext package(adding it manually solves the problem), which is needed for compilation.
    Your code worked and native Linux provider is now complete! Therefore, I'm going to ditch LGLProvider and dependency on Lazarus TOpenGLContext. It looks like an update to Asphyre Sphinx 3 will follow soon.

  2. #12
    There is also no pleasing everyone as one way or another people will have to change paths to accommodate for their environment. If you use relative paths, and then move example application to a different folder, the parental structure will change and path won't work. If you set for home folder, and move application to somewhere else, the path won't work.
    When I download some SDK/etc., I'm waiting that it will work and compile out of the box, and Asphyre is not. That is why I wrote about relative paths, because it will work at least for standard demos after unpacking the archive(but maybe this is your plan - make a bit higher barrier to entry for developers, and "cut off" too lazy people ). What about using the home directory - it will also work until Asphyre source code will be "installed" into it(I know two types of SDK - just an archive, and something installable ), but this is not an option for standard demos without description somewhere.

  3. #13
    Quote Originally Posted by Lifepower View Post
    Yes. Examples on Windows have been precompiled in 32-bit, but on Linux they have been precompiled in 64-bit.

    Linux support relies on TOpenGLControl from Lazarus components for creating GLX context. This means that multisampling settings don't work there yet and there could be some key weirdness when using GUI interfaces. The problem was that I couldn't find a way to extract X-window ID from Lazarus window handle to use proper GLX device. If someone knows how to do that, I can implement direct OpenGL context creation in native fashion.
    Lifepower the windows isn't compiling with 32 bit ... the builds is 64 bit...

  4. #14
    Quote Originally Posted by azrael11 View Post
    Lifepower the windows isn't compiling with 32 bit ... the builds is 64 bit...
    You are right, sorry. There are 5 different example sets, 3 for Lazarus on all three platforms and 2 for Delphi. Delphi executables are 32-bit, Lazarus executables are 64-bit except those on Mac OS X. I've updated examples to use relative paths in the trunk, along with some other features. An update will be released soon.

  5. #15
    Is it intended that Asphyre is under MPL license?

    http://www.mozilla.org/MPL/2.0/
    If You distribute Covered Software in Executable Form then:

    such Covered Software must also be made available in Source Code Form, as described in Section 3.1, and You must inform recipients of the Executable Form how they can obtain a copy of such Source Code Form by reasonable means in a timely manner, at a charge no more than the cost of distribution to the recipient; and...
    I mean, i went with MIT license for nxPascal to give permission for game programmers to make also commercial projects.

    It's parts like this in source code that i dislike:
    Code:
    // If you modify/use this code or one of its parts either in original or
    // modified form, you must comply with Mozilla Public License v1.1,
    // specifically section 3, "Distribution Obligations". Failure to do so will
    // result in the license breach, which will be resolved in the court.
    It doesn't sound like fully open source, even though you do must retain rights for your source.

    Can i copy parts of it to nxPascal or not i wonder. Wouldn't want to reinvent the wheel.
    Last edited by User137; 30-08-2012 at 04:18 PM.

  6. #16
    Quote Originally Posted by User137 View Post
    Is it intended that Asphyre is under MPL license?
    Yes, under MPL 1.1 license. I don't see why can't you distribute commercial projects, as long as you provide full credits and mention location to original Asphyre framework. You need to provide source code only for any derivative works. It seems that MPL 2.0 is more enforced in this terms, but you can choose whether to stick with MPL 1.1 or with MPL 2.0.

    Quote Originally Posted by User137 View Post
    It doesn't sound like fully open source, even though you do must retain rights for your source.
    MPL is an open-source license. Asphyre framework, its tools and all related content are copyright protected. It is not, however, available for public domain, as it does have intellectual property rights, which must be not be violated.

    In any case, it is not unreasonable, assuming that you get a free and polished product, which you can use to create commercial projects, and the only thing you need to give in return is to provide credits for the framework and its author(s).

    In my understanding, MIT license only protects itself but not the actual author: MIT license and its statement propagates easily, while author rights are eventually dissolved. I think it is most applicable to software that is intended to be illegal or violate some laws, so it is easily distributed yet remain more or less anonymous. One such example would be a P2P content sharing tool. I wouldn't recommend it for nxPascal project.

    Quote Originally Posted by User137 View Post
    Can i copy parts of it to nxPascal or not i wonder. Wouldn't want to reinvent the wheel.
    You can, provided that MPL license is complied with.

    By the way, I have checked your project and it seems promising. Sorry for not checking it earlier, but I've been in a hurry and thought that "nxPascal" was like a new compiler or something. Indeed, there are many parts where you could reuse a lot of Asphyre: vector math, types, functions, GUI, not to mention the fact that you use same DGL OpenGL headers. Any reason why can't you build nxPascal on top of Asphyre, or as an extension of thereof, such as a combined project or something? (Especially now when it is on SVN.) Asphyre solves a lot of low-level tedious problems, while you could focus on actual high-level 3D stuff.

  7. #17
    Quote Originally Posted by Lifepower View Post
    In my understanding, MIT license only protects itself but not the actual author: MIT license and its statement propagates easily, while author rights are eventually dissolved. I think it is most applicable to software that is intended to be illegal or violate some laws, so it is easily distributed yet remain more or less anonymous. One such example would be a P2P content sharing tool. I wouldn't recommend it for nxPascal project.
    That does make me reconsider... If it would give more protection to nxPascal, while keeping it open source and available to different purposes, then i'd see the change beneficial.

    Quote Originally Posted by Lifepower View Post
    Any reason why can't you build nxPascal on top of Asphyre, or as an extension of thereof, such as a combined project or something? (Especially now when it is on SVN.) Asphyre solves a lot of low-level tedious problems, while you could focus on actual high-level 3D stuff.
    It is interesting offer, however i feel like current nxPascal might be more lightweight and faster in many areas It should be modular enough to be able to be used with Asphyre though. I could try make demo sometime where these 2 engines are merged together in 1 project. My first game engine was trying to expand on DelphiX, creating a visual component on form for game window. Later decided it was bad approach and went with something more generic, that doesn't need any components installed. That is why it can blend with any engine. Clashes can come with math and types though, but propably not much.

    I was interested in quaternions today, but found also source from Irrlicht engine. That and implementing operator overloading for fpc for vector, matrix and quaternion math. nxPascal should work on most Lazarus versions (with all operating systems), and possibly Delphi 3 or 5 onwards.
    Last edited by User137; 30-08-2012 at 07:01 PM.

  8. #18
    It is interesting offer, however i feel like current nxPascal might be more lightweight and faster in many areas
    Err, I wouldn't make such claims before doing any performance benchmarks first.

    Lightweight characteristic is also debatable as Asphyre uses nothing but its own features with the only exception being its GUI framework. Typical Asphyre-based applications compiled in Delphi 2007 occupy less than 700 Kb. (Check its compiled examples in "\Examples\Delphi2007\").

    Delphi 2009+ and FPC/Lazarus applications are bigger due to Unicode in first case and LCL in the second one. Neither of those are related to Asphyre itself.

    If you are referring to Asphyre's reliance on VCL/LCL application types, they are both great frameworks and people use them. In your case, as long as you rely on GLUT, your code is not so "lightweight" either.

    nxPascal should work on most Lazarus versions (with all operating systems), and possibly Delphi 3 or 5 onwards.
    I can understand the point regarding Delphi, as purchasing different Delphi versions can be expensive, but I don't see any reason why you wouldn't use latest official FPC/Lazarus version as long as it is not broken or something (and even in this case, you can update from trunk rather than keep using some outdated version).

  9. #19
    finally Asphyre for lazarus , how about the performance i mean between lazarus and delphi which one produce fast code ! , in my machine delphi is faster but just 4 or 5% iam sure with FPC 2.7.1 the result would be much faster , due to the new optimization O4.
    in lazarus it would be better if you define the paths like so :
    ..\..\..\..\Source;..\..\..\..\Source\Providers;.. \..\..\..\Source\Headers;..\..\..\..\Source\GUI


    thanks for the update and keep it up
    Last edited by AirPas; 31-08-2012 at 10:02 AM.

  10. #20
    Quote Originally Posted by AirPas View Post
    how about the performance i mean between lazarus and delphi which one produce fast code !
    Does it matter, lol. Make game with both, and player won't notice any difference.

Page 2 of 4 FirstFirst 1234 LastLast

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •