PDA

View Full Version : Asphyre Sphinx 3.0.0 has been released.



LP
29-08-2012, 02:06 AM
As the title says, we now have Asphyre Sphinx 3 (http://www.afterwarp.net/products/asphyresphinx3).

Some new features are:


Delphi versions from 2006 to XE 2 (and later) are fully supported.
FreePascal/Lazarus (latest version) is fully supported.
Platforms supported: 32-bit and 64-bit Windows, 32-bit and 64-bit Linux and Mac OS X.
On Windows you can use DirectX 7, DirectX 9 (with automatic switching between Direct3D 9 and Direct3D 9 Ex depending on OS support), DirectX 10 (with automatic switching between Direct3D 10.0, Direct3D 10.1 and Windows WARP (http://msdn.microsoft.com/en-us/library/windows/desktop/gg615082%28v=vs.85%29.aspx) software device depending on hardware, and OS support).
Brand new OpenGL provider for all platforms that uses OpenGL 2.1 features with programmable pipeline. Legacy support for OpenGL 1.2 is provided in additional renderer.
WYSIWYG GUI works across all platforms.
Many features from previous releases are, of course, still available too.


However, FireMonkey and DirectX 11 providers are not available for this release yet. They will be provided later as optional add-ons. OpenGL ES providers on iOS and Android platforms for the current release will also be available in the future. (Meanwhile, you can keep using Asphyre Sphinx 2 (http://www.afterwarp.net/products/asphyresphinx2), if you need to target iOS right now - you won't need to modify your code much to use Asphyre Sphinx 3).

Please note that Asphyre tools have not been ported to other platforms yet. Meanwhile, you can use Wine (http://www.winehq.org/) for Linux, Fusion (http://www.vmware.com/products/fusion/overview.html) or Parallels (http://www.parallels.com/) for Mac OS X to execute Asphyre tools until they are ported. Fonts and images created by Asphyre tools can be used along with ASVF compressed/encrypted archives on any platform without limitations.

You can visit Asphyre Sphinx 3 (http://www.afterwarp.net/products/asphyresphinx3) web page for more information and download links, or update everything from Asphyre SVN (http://code.google.com/p/asphyre/source/checkout).

SilverWarior
29-08-2012, 03:43 AM
When you talk about FireMonkey which version of Firemonkey are you refering? The old one introduced with DelphiXE2 which is compatible with FreePascal or Firemonkey 2 which will be introduced with Delphi XE3 and is no longer compatible with FreePascal?

LP
29-08-2012, 04:02 AM
When you talk about FireMonkey which version of Firemonkey are you refering? The old one introduced with DelphiXE2 which is compatible with FreePascal or Firemonkey 2 which will be introduced with Delphi XE3 and is no longer compatible with FreePascal?

The problem would be maintaining FireMonkey providers for both XE2 and XE3, which will roughly result in 6 different providers. Actually, providers from Asphyre Sphinx 2 can be used with Asphyre Sphinx 3 (you just have to remove rasterizer declaration from the provider), so technically XE 2 FireMonkey support including iOS can be used here. In any case, once Delphi XE 3 is released (hopefully pretty soon), we'll have a better picture of what to support and how.

The objective was to reduce number of providers to simplify maintenance: this is the reason why two DirectX 9 and two DirectX 10 providers were merged together, another reason was to support earlier versions of Delphi with DirectX 10+. Actually, the idea was to support DirectX 10 in FreePascal/Lazarus as well and it should technically work, except that DirectX 10 headers have some issues that I still haven't resolved.

Andru
29-08-2012, 07:06 AM
Cool! Finally one more great Pascal library got an real cross-platfom, I will definitely take a look how it works under GNU/Linux :)

azrael11
29-08-2012, 07:21 AM
Lifepower as you say Freepascal/Lazarus you mean 32/64 Windows 32/64 Linux and MacOsX.... ?

Cybermonkey
29-08-2012, 07:24 AM
Platforms supported: 32-bit and 64-bit Windows, 32-bit and 64-bit Linux and Mac OS X.


Finally Linux support. I'll have to try it this evening. Thanks in advance for that!

LP
29-08-2012, 01:19 PM
Lifepower as you say Freepascal/Lazarus you mean 32/64 Windows 32/64 Linux and MacOsX.... ?
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.

Andru
29-08-2012, 01:59 PM
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.
For ZenGL I use this solution(but works only with GTK version of LCL, I didn't try to use Qt version of Lazarus, so :)):


uses
{$IFDEF LINUX}
{$IFDEF LCLGTK}
GLib, GTK, GDK,
{$ENDIF}
{$IFDEF LCLGTK2}
GLib2, GTK2, GDK2, GDK2x,
{$ENDIF}
{$ENDIF}

// ..

{$IFDEF LINUX}
var
widget : PGtkWidget;
socket : PGtkWidget;
glist : PGlist;
{$ENDIF}
begin
{$IFDEF LINUX}
glist := gtk_container_children( GTK_CONTAINER( PGtkWidget( Panel1.Handle ) ) );
widget := PGtkWidget( glist.data );
socket := gtk_socket_new();
gtk_container_add( GTK_CONTAINER( widget ), socket );

gtk_widget_show( socket );
gtk_widget_show( widget );

gtk_widget_realize( socket );
{$IFDEF LCLGTK}
YourTWindow := PGdkWindowPrivate( widget.window ).xwindow;
{$ENDIF}
{$IFDEF LCLGTK2}
YourTWindow := GDK_WINDOW_XID( widget.window );
{$ENDIF}
{$ENDIF}

LP
29-08-2012, 02:51 PM
Andru, thanks a lot for this! I'm going to try using it.

Andru
29-08-2012, 04:15 PM
So far GNU/Linux version works fine :) But demos can't be compiled out of the box. 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. Also I didn't notice dependency to LazOpenGLContext package(adding it manually solves the problem), which is needed for compilation.

LP
29-08-2012, 08:48 PM
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.


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. :)

Andru
30-08-2012, 05:34 AM
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.

azrael11
30-08-2012, 06:17 AM
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... ;)

LP
30-08-2012, 01:08 PM
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.

User137
30-08-2012, 03:55 PM
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 (http://opensource.org/licenses/mit-license.php) for nxPascal to give permission for game programmers to make also commercial projects.

It's parts like this in source code that i dislike:

// 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.

LP
30-08-2012, 05:32 PM
Is it intended that Asphyre is under MPL license?
Yes, under MPL 1.1 (http://www.mozilla.org/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.


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.


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.

User137
30-08-2012, 06:57 PM
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.


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 8) 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.

LP
30-08-2012, 07:33 PM
It is interesting offer, however i feel like current nxPascal might be more lightweight and faster in many areas 8)
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).

AirPas
31-08-2012, 09:47 AM
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

User137
31-08-2012, 10:08 AM
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.

LP
31-08-2012, 02:12 PM
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.

Compiled examples with optimization enabled have very similar performance. From my perspective, both compilers optimize the code pretty well.



in lazarus it would be better if you define the paths like so :
..\..\..\..\Source;..\..\..\..\Source\Providers;.. \..\..\..\Source\Headers;..\..\..\..\Source\GUI

Yes, I've updated all paths to be like this, you can update from the trunk. Later today I'll publish another Asphyre version.

LP
01-09-2012, 05:55 PM
As the title says, Asphyre Sphinx (http://www.afterwarp.net/products/asphyresphinx3) has been updated to version 3.0.1.

In this update, DirectX 11 support has been added, which uses advanced fallback mechanisms for lower feature levels such as Direct3D 10.1, Direct3D 10.0 and even legacy Direct3D 9, in addition to Windows WARP (http://msdn.microsoft.com/en-us/library/windows/desktop/gg615082%28v=vs.85%29.aspx) highly optimized software device. This means that Asphyre powered applications using DirectX 11 will run on any system where DirectX 11 is installed no matter whether it has hardware support or not. This provider works with Embarcadero Delphi (either XE 2+ or any version from 2007 and upwards) and FreePascal/Lazarus. No external DLLs are required for this provider to work.

Also, 3D features that were available in earlier releases are now part of Asphyre Sphinx 3 too.

For more information and download links, you can visit official Asphyre Sphinx 3 web page (http://www.afterwarp.net/products/asphyresphinx3). Alternatively, you can update your repository from the trunk (http://code.google.com/p/asphyre/source/checkout).

Wizard
03-09-2012, 06:43 AM
Hi Lifepower, I get the following error when trying to compile the examples. Using Delphi 2010.

[DCC Error] MediaUtils.pas(319): E2254 Overloaded procedure 'ParseFloat' must be marked with the 'overload' directive
[DCC Error] MediaUtils.pas(121): E2065 Unsatisfied forward or external declaration: 'ParseFloat'
[DCC Fatal Error] AsphyreImages.pas(400): F2063 Could not compile used unit 'MediaUtils.pas'

Any ideas?

LP
03-09-2012, 02:03 PM
Wizard, unless you have conflict with some older Asphyre package, it seems more like a compiler bug, as you can see that the mentioned procedure does have "overload" flag. Could you try to comment one of these functions and remove "overload" parameter?

The package was tested in Delphi 2007 and XE 2, so there is no reason why it shouldn't work with Delphi 2010.

LP
03-09-2012, 02:20 PM
By the way, Asphyre Sphinx 3 works with Delphi XE 3 (http://embarcadero.com/products/delphi).

Also, I've ported some lousy software rasterizer (http://afterwarp.net/forum/topic/383-experimental-software-rasterizer-v101) for Asphyre Sphinx 3, for those who want some fun with it. ;)

LP
09-09-2012, 08:43 PM
It's time for another update. Asphyre Sphinx 3.0.2 (http://www.afterwarp.net/products/asphyresphinx3) has been released, which resolves minor aesthetic issues in DirectX 11 provider, fixes sleep recovery in DirectX 9 Ex (vista) provider and resolves minor timing problem. In addition, this release now features native Linux OpenGL provider that no longer depends on other packages thanks to code kindly provided by Andru, the developer of ZenGL.

Also, an alternative UI with its accompanying open-source WYSIWYG editor is now available called Tulip User Interface Library (http://afterwarp.net/forum/topic/397-tulip-user-interface-library/), kindly provided by Marcos Gomes. It uses latest language features of Delphi XE 2 and XE 3 and allows creating of a very good looking interfaces, while being also very easy to use.

Cybermonkey
11-09-2012, 07:19 PM
Okay, I just tried it with my Xubuntu 12.04 64bit. Version 3.0.1 worked fine. This is what I receive for all examples on the terminal (even after newly compiled):

The program 'Shapes' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadMatch (invalid parameter attributes)'.
(Details: serial 418 error_code 8 request_code 135 minor_code 5)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the --sync command line
option to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)

None of the examples works now for me. I thought you might need to know this.

Andru
11-09-2012, 07:37 PM
Seems this is a problem of NVIDIA blob(currently your videocard is GeForce 8600GT?) and initializing OpenGL context with custom options, when you use already created window with unknown visualinfo. Try to open XGLDevices.pas and replace line 168 with this one:


GLX_BLUE_SIZE, 8, GLX_ALPHA_SIZE, 0, GLX_DOUBLEBUFFER, GL_TRUE,
here main change is GLX_ALPHA_SIZE, 0

Cybermonkey
11-09-2012, 08:14 PM
Thanks Andru, that helped and now it works.

LP
11-09-2012, 08:41 PM
Thanks for reporting this, I'm going to change the source code to remove the alpha attribute.

LP
13-09-2012, 01:50 PM
This is another semi-major release Asphyre Sphinx 3.0.3 (http://www.afterwarp.net/products/asphyresphinx3), which now supports FireMonkey v2 in Delphi XE 3. It also includes a rewritten timer component that properly displays high FPS values (e.g. 5000 FPS and higher) in FreePascal/Lazarus, along with some other minor bug-fixes.

Please note that FireMonkey v1 in Delphi XE 2 is not going to be supported anymore to reduce maintenance costs. If you need to use FireMonkey v1 to target Mac OS X, you can either keep using Asphyre Sphinx 2.x branch (which is now deprecated), or use Asphyre Sphinx 3.x in FreePascal/Lazarus, which targets Mac OS X natively.

Also, on Windows platform if you use FireMonkey v2, only Direct3D 9 provider is used and enforced. If you want to use DirectX 10 or 11 on Windows, you will have to use Asphyre Sphinx 3.x natively in Delphi/VCL. You can also use DirectX 11 natively in FreePascal/Lazarus.

wagenheimer
13-09-2012, 07:03 PM
Very impressive the frequency of the updates ! =)

Are you planning to release some new game soon? I'm curious to see the full power of this new Asphyre in action! =)

LP
13-09-2012, 08:28 PM
The reason of frequent updates is that some features are developed in series of steps. It would be difficult and time consuming to develop all and everything simultaneously.

Regarding your question: yes, we have two pending game projects yet to be released, although the priority is to push these projects to mobile platforms. At the moment we're short on "manpower", so the projects have been put on hold temporally.

Specifically about myself - I'm developing some project for Embarcadero, but at the moment have a short break, so I'm trying to use this free time to be with my family and update Asphyre in the meantime.