Archive for the ‘ARCHITECT’ Category
(use arrow keys and spacebar to control the red ball)
A new 3d physics library is under development and in early stages called jiglibflash. Like the Box2D ports it is based on a C++ library of the same name called jiglib, only this is 3D instead of 2D. It is similar in purpose to WOW Engine which is the other current open source 3d flash physics engine. For more on this toolkit see the links below.
UPDATE: katopz has also ported this to use Away3D as the renderer.
UPDATE: Also updated for the sandy3d engine as the renderer.
SWFAddress 2.2 has been released. SWFAddress is pretty much THE solution for deep linking in flash and works greatly in combo with THE embedding solution into (X)HTML/Javascript for flash SWFObject.
The new SWFAddress has just arrived after seven months of active development, various contributions and lots of positive feedback from the community. The list of changes includes the following:
- Refactored JavaScript implementation
- New SWFAddress.swc AS3 component
- New CS4 based Splash screen sample
- New Digg API sample
- New up() method for easier deep linking path navigation
- New XSS protection that doesn’t affect special characters
- Support for Internet Explorer 8
- Support for custom HTTP status messages in the SEO sample
- Improved title handling
- Improved unload event handling for IE
- Updated Rails sample
- Fixed getBaseURL() for AS3
- Fixed Safari 2.0-2.0.3 support
- Build-in fix for the Firefox 3/Mac OSX blinking effect
- Additional onLoad fix for application/xml content type
- Fixed optional options parameter for the popup method
- Cross platform build script
- Various optimizations
I believe that this new version is pretty stable and won’t require an update soon. There are two known Safari bugs (19202 and 20355) that currently affect the project and we can only hope that they will make it’s way into the next major release of the browser.
SWFAddress has grown significantly in the last two years and it’s very likely that we’re going to provide a lite version for users who need just the basic functionality. Very soon the same API will become available for Silverlight and we’re also scheduling the development of a jQuery plugin.
I have mentioned before that flash to unity3d communication is a key part of game development for the web now where you are using Unity3D as a higher end renderer and some of your other page elements might be flash. Now there is a new open source kit for this called u3dobject.
To get Flash and Unity3D to talk to one another in an HTML/XHTML page is pretty simple with javascript and with the internal Unity3D Application object and the ExternalInterface in Flash. But there are lots of elements of that communication that can be consolidated and reused so you don’t have to recreate that over and over. Various studios and programmers come up with their own kits but when it becomes a shared activity to get the best integration and make it more of a platform that is where things like swfobject, swfaddress and u3dobject come in.
So far swfobject is the standard for flash html embedding and unityObject is a similar take (but a bit dated) on that but now we have u3dObject that is open as well and a more official open source project for unity3D <–> flash integration and test harnesses for development when those two technologies are used together.
Unity3D <-> Flash Embedding Info:
This is pretty impressive. This is Moonlight for mono (a silverlight clone in mono.net for multiplatform) running inside of Ogre3D (a 3d renderer) as a material.
Argiris Kirtzidi (one of the developers behind Managed OGRE) modified Moonlight to run inside the Ogre3D engine. You can render Moonlight applications or XAML files inside Ogre3D.
Some details in no particular order:
-Moonlight uses cairo for the graphics. I developed a new backend for cairo that fully utilizes the GPU (through Ogre’s RenderSystem) for rendering. This is completely independent from Moonbeam and can be used standalone.
-Moonlight’s core is a native C++ engine and is not dependent in Mono. It is flexible enough to be scripted by anything, javascript, managed code, native code, etc. I’ve got it working on both Mono and the .NET framework and I plan on embedding and trying out Lua for more lightweight stuff.
-If you opt for using managed code, it should be possible, in theory, to utilize the silverlight controls, develop a silverlight widget using visual studio and have it run through moonbeam with full debugging support.
-Getting it to work on Windows was no small task as the moonlight team is completely focused on linux, and there doesn’t seem to be much consideration about cross-platform-ness. I think this is reasonable, though, since moonlight is a young project and their specific goal is to implement silverlight for *nix systems. The downside is that it reduces its flexibility, e.g. in order to inject keyboard/mouse events I will have to create and pass to it GDK events or make heavy patches to it.
Hopefully, there will be more push in the future to get the *nix dependencies abstracted away from the core moonlight engine.
- The Moonlight Calculator Example.
- Miguel’s post about this
- Original post about the technique from the author
Adobe stratus sounds pretty interesting for flash client to client communication much like peer to peer networks for small numbers of people.
Want to build a video chat application, multi-player games or voice-over-ip applications for the Flash Player or AIR without worrying about setting up a server infrastructure? Stratus (which we showcased at MAX) is your new best friend.
Stratus is a beta hosted rendezvous service that helps establish communication between Flash Player or AIR clients. Once two clients are connected to Stratus, they can send data directly client to client. The APIs in Flash Player 10 and Adobe AIR 1.5 allow for point-to-point communication between a small number of subscribers. Publishers have to send data to all subscribing clients, so the number of subscribers is limited to the available bandwidth on the publisher end.
This must be one of the first Real-Time Media Flow Protocol (RTMFP) protocol usage programs from Adobe? Basically this protocol is adding better UDP or broadcast support which allows for larger sets of users and is common in large scale real-time games. Here it seems to be more of a peer to peer usage rather than authoratative approach (maybe flash media server will have large user set support with this) which limits to about 15 users or the lowest latency in the group with anything close to real-time syncing. Stratus seems like more of a matchmaking middle man to help with nat punchthrough and then it relies on peer to peer. But more fun in store checking it out.
P2P like this can’t really be used for games due to cheating unless one client is the independent server but this works great for small file sharing apps, whiteboards, chats, watching videos at the same time, etc.
When you do lots of any language you build up libraries over time that are time savers that are repetitive and tedious if you do not consoildate into a library. Taking a look at the CASALib, an as3 library of common functions for flash that was released I have many of the same things in my libraries but CASALib just has lots of extras that go a bit deeper than some libraries, is very clean and is organized pretty well.
One cool thing about it is the IDestroyable interface and the CasaMovieClip, CasaSprite, CasaTextField , etcthat all have a destroy() method that cleans up all events, removed instances and even removes it from the parent display object. Gets me thinking why this isn’t just part of DisplayObject in the first place.
From the release:
Here are a few of our favorite things in CASA Lib AS3:
- Standardized external load API
- Easily remove listeners with IRemovableEventDispatcher
destroymethods make garbage collection easy- Large group of utility classes for common manipulations
We will be elaborating further the power of CASA Lib in future blog posts.
As with any new release there will be bugs that emerge, but with your help we promise to release updates often to keep CASA Lib as stable as possible.
1.0.0 Downloads & Documentation
ZIP: http://as3.casalib.org/releases/1.0.0/1.0.0.zip
SVN: http://svn.as3.casalib.org/releases/1.0.0/
Documentation: http://as3.casalib.org/releases/1.0.0/docs/[source]
Nicolas Cannasse is at it again. This time with a PBJ (Pixel Bender File) binary file reader and writer in haXe and Pixel Bender Assembler tools. What this can do is create and decompile PBJ files with haXe, the possibilities are limitless to how this is used including dynamic pbj file creation.
The latest haXe file format library contains complete support to read and write PBJ file, enabling you to write Pixel Bender assembler directly in haXe, then compile it on-the-fly into PBJ bytes, which can then be saved on disk or loaded directly in Flash.
I plan to have much more on Pixel Bender (shaders in flash) and Adobe Alchemy (compile other languages to which is a very cool technology that involves LLVM that Nicolas also has lots of great input on.
Augmented reality is a very cool technology. It is the star wars holograms that we always want, it is playing a game that maps out the physical world mixed with virtual assets, it is straight up cool.
The FLARToolKit is doing some of this cool in Flash. This little toolkit is pretty sweet mapping points and sets of points to patterns, colors or other visual queues that technology can latch onto. Combine this with a webcam and you have some pretty cool AR.
The YouTube Chromeless Player works with AS3/ActionScript 3.
The demo shows great examples of the player with just the window canvas (chromeless) from both javascript and inside of flash.
The project is hosted on Google Code [youtubechromelesswrapper-as3]
Looks like they maybe had a contribution for this, so do it where you can.
This is something we’ve been wanting to provide for a while, and the YouTube API team greatly appreciates the work of developer Matthew Richmond of The Chopping Block for making it happen. Thanks Matthew!
Links
- Demo
- Google Code [youtubechromelesswrapper-as3]
- Article about the library
- Download the source (get from google code recommended)
- Javascript Player Reference
Capabilities/API
Public Methods
player.loadVideoById(id:String, startSeconds:Number = 0):void- Loads and plays video based on specified id.
player.cueNewVideo(id:String, startSeconds:Number = 0):void- Loads but does not automatically play video based on specified id.
player.clearVideo():void- Clears currently cued/loaded video.
player.setSize(w:Number, h:Number):void- Sets the size of YouTubePlayer instance.
player.play():void- Plays the currently cued/loaded video.
player.pause():void- Pauses the currently cued/loaded video.
player.stop():void- Stops the currently cued/loaded video.
player.seekTo(seconds:Number):void- Seeks to specified time within the currently cued/loaded video.
player.getPlayerState():String- Returns the current state of the currently cued/loaded video.
player.getBytesLoaded():Number- Returns the value of current bytes loaded of the currently cued/loaded video.
player.getBytesTotal():Number- Returns the value of total bytes loaded of the currently cued/loaded video.
player.getCurrentTime():Number- Returns the current position in time of the currently cued/loaded video.
player.getDuration():Number- Returns the current duration of the currently cued/loaded video.
player.getStartBytes():Number- Returns the start bytes of the currently cued/loaded video.
player.setVolume(newVolume:Number):void- Sets the volume of the currently cued/loaded video.
player.getVolume():Number- Returns the current volume of the currently cued/loaded video.
player.mute():void- Stores the current volume and changes the volume of the currently cued/loaded video to 0.
player.unmute():void- Returns the volume of the currently cued/loaded video to the last stored value when muted.
player.getEmbedCode():String- Returns the current YouTube embed code of the currently cued/loaded video.
player.getVideoUrl():String- Returns the current YouTube video url of the currently cued/loaded video.
Events
YouTubeLoaderEvent.LOADED- Fired once the Chromeless Player has successfully completed loading and is ready to accept operations calls.
YouTubeLoaderEvent.STATE_CHANGE- Fired whenever the player’s state changes. The YouTubeLoader class translates the JavaScript API numbers to their related string values, the YouTubeLoaderEvent class stores the current event in a variable called
state. Possible values are unstarted, ended, playing, paused, buffering, video cued. When the SWF is first loaded, it will broadcast an unstarted event. When the video is cued and ready to play, it will broadcast a video cued event. YouTubeLoaderEvent.IO_ERROR- Fired when an error in the player occurs. There are two error codes possible: 100 is broadcasted when the video requested is not found. This occurs when a video has been removed (for any reason), or it has been marked as private. 101 is broadcasted when the video requested does not allow playback in the embedded players.
