TurboDieselSportInjection

I am definitly not good at choosing names for software projects. However TurboDieselSportInjection is a release of my experiments from yesterday. It is a spinoff from the whole framework and allows you to inline __bytecode and of course to use the new Memory API.

Hopefully you are kind enough to provide me with some feedback. I am especially interested in Exceptions that occur when reading or writing ABC files. Have fun!

Update: TDSI is now open source!

3 Comments

  1. Posted Sep 7, 2009 at 1:59 pm | Permalink

    zedia.net:
    1) Google for command line.
    2) No. In fact, you have to use the Memory API to make use of the Alchemy opcodes
    3) I am not sure at which exact version the Alchemy opcodes have been introduced.
    4) Sure. Someone would just have to write those libraries :)

    Best,

    Joa

  2. Posted Oct 8, 2009 at 2:53 pm | Permalink

    Hi Joa,

    Awesome work! We’re having some problems with writeShort / readUnsignedShort. Without tdsi the code runs fine (we are serializing a Vector. to a bytearray). After running tdsi we get stack underflow errors, any idea on these specific methods? (readFloat, writeFloat is fine..)

    I also see that current operations are little endian on my intel machine. Is there a way to force endiannes? (we need this for serializing) And is this code safe on an older PPC mac?

    Cheers!
    Alexander

  3. Posted Oct 29, 2009 at 3:49 pm | Permalink

    A tip for usage in a Flex environment: The Flex optimizer crashes on the Alchemy opcodes. So if you put a TDSI treated swf in a swc and compile that with mxmlc, there’s a good chance the whole thing won’t compile. I’ll file a bug report on the Adobe web site to that extent.

12 Trackbacks

  1. […] then Pixel Bender one. And it looks like it is more accurate in detecting edges. I’ve used Joa’s TDSI tool to speed up writing/reading processes to/from Alchemy memory. That’s why I’ve included […]

  2. […] it turns out that rendering particles is not really easy task and costs a lot. I’ve also used Joa’s TDSI again but it is not really needed as far as we don’t have to write/read Alchemy memory a lot […]

  3. By » Day Two Marc Hibbins on Sep 24, 2009 at 2:24 pm

    […] first was TDSI, TurboDieselSportInjection! an optimisation for Alchemy – you can see some examples […]

  4. […] P.S.: This project is using Joa’s TDSI Tool! […]

  5. By Median Filtering [updated] | astatic notes on Nov 2, 2009 at 10:51 am

    […] radius! I’ve also added new ByteArray based method that works amazingly fast with the help of Joa’s TDSI tool! Unfortunately this method may have unexpected results at very large radius (around 201×201 […]

  6. By FluidSolver 3D | first steps | astatic notes on Dec 29, 2009 at 12:48 pm

    […] in 3D experiment project. This project is based on my previous fluid solver classes and heavily use Joa’s TDSI tool. This is my first try to implement this simulation if flash and decided to start from Alchemy based […]

  7. […] был создан продукт под названием TurboDieselSportInjection (автор признавался что у него туго с названиями), […]

  8. […] человеком был создан продукт под названием TurboDieselSportInjection (автор признавался что у него туго с названиями), […]

  9. By FlashSURF – moving further | astatic notes on Feb 22, 2010 at 12:29 pm

    […] Now FlashSURF become really easy to use as far you don’t have to compile and process it with TDSI every time you testing your project. Provided SWC lib already processed, all you need is to include […]

  10. […] year later, Joa Ebert hacks fast memory in AS3, and release it as a feature of TDSI, an AS3 bytecode optimizer […]

  11. By Interruption « simonrichardson.info on May 6, 2010 at 6:00 pm

    […] other than haXe and Adobe Alchemy not much is taking advantage of it. You can of course try and use TDSI from Joa Ebert, but why should we have to optimise something after we’ve written it? This […]

  12. […] […]