Printable View
I've been fascinated with a few addons like 3d engines, particle systems, etc. I'm wondering...are they also using the built in render pipeline like we all use or is there a low level way to interface with Flash and create your own render routines in C,C++, etc? Papervision3d for instance, is that just a collection of source code you can add to your app or is it adding something to the flash kernal at runtime? Thanks for the tech info. ;)
most of them drawing API like:
no hidden secrets used in them - just AS3 made it possible to push around more data and loops - hence the boom of those engines.PHP Code:spr.graphics.beginBitmapFill(bitmap, matrix,..);
spr.graphics.moveTo(tri[0].x,tri[0].y);
spr.graphics.lineTo(tri[1].x,tri[1].y);
spr.graphics.lineTo(tri[2].x,tri[2].y);
spr.graphics.endFill();
Really? Thanks for the info renderhjs. wow..this flash/as3 stuff is truly amazing. It's like I've been in the matrix and now....well...you get the point. ;)
I wish that you can add C++ stuff...it would REALLY speed things up!
I heard that when mixing c++ and AS3 using Alchemy
http://www.as3apex.com/as3/alchemy-a...d-c-for-flash/
it gets really slow if you switch constantly between them- havent tried it though as it is not my turf
Hi,
I have done some work along these lines - but you need to write in haxe, rather than as3 (they are very similar). So you first write your program in haxe, using the flash API that you know and love (very easy to move between as3 and haxe). You can compile your SWF and run it as normal. Then with a few addional lines, you can compile to c++, which you then compile with a normal c++ compiler. Given that you then have c++ code, you can extend it however you like. Pragmatically, you would probably use the standard haxe c API to write additional routines that you can call from from your haxe code - possibly as replacements for your slower as3 code.
The rendering engine is build on top os SDL, and has opengl support.
Checkout the demos and code sample at:
http://gamehaxe.com/2008/12/23/hxcpp-03-released/
This is currenly not production quality, but is in active development.
There are mosly 1-to-1 replacements for the flash api, but significant (huge) gains could be made if you ported a whole library, say papervision, so when you ran in flash, it would use the standard stuff, but if you ran in c++, it would swap the whole library for an opengl one, while keeping the same interface.
Does that process still target a swf as the output? I was under the impression that the security sandboxes inside the flash player made opengl kinda off limits.
Yes, under flash it is pretty much the same. That is, same speed, inside a swf and no opengl. But you can make a separate program (a windows.exe) from the same code base, that runs faster because it can use opengl and c++. So the opengl is not really a browser solution, but gives you a way of offering improved speed to those that are willing to run a download from you,
without having to do very much at all.
eg. The web version may run at 800x600, but the downloadable may run fullscreen at 1920x1200. It gives you a way to up-sell from the web version.
That actually seems pretty interesting...So basically it's translating Flash into .exe, and at the same time they upgrade it to using OpenGL and stuff? That actually seems like a really good incentive for people to download a game!
Thanks Chookmaster, and by the way, have you made any examples of any sort?
P.
Hi, sorry about the late reply.
I haven't put together any complete game examples yet - although I am working on it. There is a physics tech demo in the download I pointed to earlier showing a swf version and a c++/opengl version generated from the same code base.
The haxe neash code base also has several examples, all of which can be compiled for flash and neko, and the neko ones can be run with the "-opengl" switch.
I'll let you know when I have some more complete demos.
So is neko sending the Flash file the openGL info / Flash sends basic info to Neko, neko figures out bitmapData's, screen coordinates, and then sends back to Flash?
P.
It's not really like that. The flash and neko are completely separate, the common part is the haxe source code.
So in your haxe code, you do something like this:
addChild(new Bitmap(myImageData) );
When this gets compiled to swf, you get something that is pretty much identical to what you would get if you had written that line in as3. eg something like "find class definition called "flash.display.Bitmap" and call its constructor with the provided object, then find my member function called "addChild" and call that with the result".
When your flash player reads this swf, it uses its virtual machine to process these commands. It must store the new Bitmap in its memory somewhere - but I'm not exactly sure of the details.
Now when you compile the haxe code for neko, a neko ".n" file is produced. This has a lot in common with the code part of a swf - eg it will have some bytes that essentially say the same thing: "find class definition called "flash.display.Bitmap" and call its constructor with the provided object, then find my member function called "addChild" and call that with the result".
The neko virtual machine (or NekoVM or neko player) processes these commands in a similay way to the way the flash runtime does (although the exact details differ greatly). However, in the neko case I am sure of the details of how the Bitmap is stored.
The basic NekoVM knows how to manipulate classes and do simple calcualtions etc, but to get it to do anything really interesting, you have to extend it with your own C code. So when the NekoVM calls the Bitmap's constructor, a function call to external C code is generated. In this call, the bitmap data is created using a SDL_Surface and/or an OpenGL Texture. When rendering time comes, standard SDL or OpenGL calls are made to draw the bitmap on the virtual "stage".
Another possibility is to compile the haxe code into c++. You then compile this c++ into an executable that does not rely on a virtual machine. There is no 'find class definition called "flash.display.Bitmap"', instead it becomes:
#include <flash/display/Bitmap.h>
...
this->addChild( new flash::display::Bitmap( myBitmapData ) );
When the c++ code constructs the bitmap, the same SDL/Opengl calls that neko uses are generated explicitly in the c++ code.
So, in short, the neko & c++ code does not use flash, it has an API that mirrors flash. Same API, completely different implementation.
Hope this helps explain a bit more about what is going on.
Is there a tool to 1:1 convert from as3 to haxe?
That explains perfectly! I'm just wondering about nekoVM though. Is it another plugin to download and install?
And I take it that the pure C/C++ code isn't deployable to the web?
@as3newb: Sorry, but I'm new to haxe as well (actually, I haven't even started to use it), and I actually don't feel too comfortable programming in haxe...but I might try to get into it sometime.
P.
There is a bit of code about to do this - but it does not work 100%. There are a few differences - on the down side, the "for" loop, properties and import "*" are a bit different. On the plus side you don't have to specify the type for your variables if the compiler can work it out. eg:Quote:
Originally Posted by as3newb
var x = "hello"; // x is a String
function ok() { return true; } // function returns "Bool"
which gives compile-time checking and run time speed. And the "typedefs" and "enums" are interesting concepts.
But the languages are very similar - you should have no trouble reading haxe, and it's pretty easy to write.
If you are happy with command-line or FlashDevelop then you should have hello world running in no time.
@Pazil The nekoVM is not currently a web-plugin. There would be some security issues with this because it is so powerful. However there are some options for restricting the functions available to the VM, so it may be possible, but I have not tried. My current feeling is that flash is best for browser based games, and neko/c++ for downloadable.
Same goes for c++, except that it would be harder to sandbox c++. (Although, google native API may help here, if it gets off the ground).
To distribute a neko app, you only need to include a bunch of DLLs - say in the same directory as your application.exe. ie, you do not have to "install a runtime" on the clients machine. The application.exe is very simple - used to bootstrap the vm. You can also change this (c) code do do extra stuff - eg some sort of license check on startup.
I think this is a key difference from AIR - the neko licensing is very permissive, when it comes to distribution and inserting you own code.