SDL and Adobe's Alchemy (compile C to Flash ActionScript)

SDL Development
1

Has anyone looked at making an ActionScript Virtual Machine target for SDL?

I’ve had numerous people ask whether Tux Paint can be used "on the web."
What this always meant to me was: embedded in a web browser, via Java or Flash.

I am not interested in creating and maintaing a Java or Flash port of
Tux Paint, but it seems that Alchemy could be used to port SDL and SDL-based
games to Flash. So there’s my solution! :wink:

“Alchemy is a research project that allows users to compile C and C++
code that is targeted to run on the open source ActionScript Virtual
Machine (AVM2). The purpose of this preview is to assess the level of
community interest in reusing existing C and C++ libraries in Web
applications that run on Adobe Flash Player and Adobe AIR.”

See: http://labs.adobe.com/technologies/alchemy/

Their dev toolkit is out for Mac OS X, Cygwin on Windows, and Linux.
(And it weighs in at ~40MB. Yikes!)

I’ve looked at neither the license / terms of use, nor the toolkit itself.
I personally don’t have time (or SDL expertise!) to do this. But in case
someone out here missed it, I wanted to post the link. :slight_smile: Have at it!

Thx,–
-bill!
“Tux Paint” - free children’s drawing software for Windows / Mac OS X / Linux!
Download it today! http://www.tuxpaint.org/

2

I haven’t looked at it, but the first thing that comes to mind is that it wouldn’t be nearly that simple, especially if you wanted to port SDL itself. ActionScript is an interpreted language that has to run in a VM. It’s completely unsuitable for the sort of low-level, direct-hardware-access tasks that SDL deals with. You can’t do that sort of stuff in anything but native code.

An alternative would be to have the VM have the ability to access external C libraries, which is pretty common these days. That might work, if the VM doesn’t automatically set up its own canvas. If it did, it would certainly be incompatible with the SDL_Surface that SDL uses as a screen buffer. Anyone here know enough about the VM to provide more information on this issue?>----- Original Message ----

From: Bill Kendrick
Subject: [SDL] SDL and Adobe’s Alchemy (compile C to Flash ActionScript)

I am not interested in creating and maintaing a Java or Flash port of
Tux Paint, but it seems that Alchemy could be used to port SDL and SDL-based
games to Flash. So there’s my solution! :wink:

3

I haven’t looked at it, but the first thing that comes to mind is that it wouldn’t be nearly that simple, especially if you wanted to port SDL itself. ActionScript is an interpreted language that has to run in a VM. It’s completely unsuitable for the sort of low-level, direct-hardware-access tasks that SDL deals with. You can’t do that sort of stuff in anything but native code.

I think it could be made to work, if it came along with a backend that
would use whatever the VM to a Flash app. For example, you ask for the
resolutions, and you get a single “resolution” available, that of the
Flash widget in the web page, which would be used as a dumb
framebuffer. It wouldn’t be very fast, though, but the VM might offer
some unexpected features peculiar to that platform (I wouldn’t be
surprised to see some scaling primitives, for example, which might not
be done in hardware, but the VM would at least do them in native
code).On Fri, Nov 21, 2008 at 7:20 PM, Mason Wheeler wrote:

–
http://pphaneuf.livejournal.com/

4

The demos they showed running using Alchemy were a Nintendo NES emulator and
Quake running. Whatever kind of speed they’re getting is probably
suitable for Tux Paint, at least. :wink:

-bill!On Fri, Nov 21, 2008 at 04:20:27PM -0800, Mason Wheeler wrote:

I haven’t looked at it, but the first thing that comes to mind is that it wouldn’t be nearly that simple, especially if you wanted to port SDL itself. ActionScript is an interpreted language that has to run in a VM.

5

I am fed up with people complaining about VM languagages without really
having any compiler development
background.

It is possible to have VM implementations, with JIT support, that run as
fast as pure native code.

There are several algorithms that can only be applied with knowledge of how
a specific program runs.

The JVM does that for example, and a specific method can be recompiled
several times depending
on the information that the VM keeps getting.

With a native language, you can do at most, a profile guided optimization at
compilation time, thus
making processor specific.

You will probably never get the same speed as ASM, but it will be good
enough for many cases.

So I think that the work Adobe is doing is pretty cool, but I don’t know if
you can really
implement SDL on Flash VM. Are they providing access to the graphics APIs?

Cheers,
PauloOn Sat, Nov 29, 2008 at 10:30 AM, Bill Kendrick wrote:

On Fri, Nov 21, 2008 at 04:20:27PM -0800, Mason Wheeler wrote:

I haven’t looked at it, but the first thing that comes to mind is that it
wouldn’t be nearly that simple, especially if you wanted to port SDL itself.
ActionScript is an interpreted language that has to run in a VM.

The demos they showed running using Alchemy were a Nintendo NES emulator
and
Quake running. Whatever kind of speed they’re getting is probably
suitable for Tux Paint, at least. :wink:

-bill!

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

6

I haven’t looked at it, but the first thing that comes to mind is that it wouldn’t be nearly that simple, especially if you wanted to port SDL itself. ActionScript is an interpreted language that has to run in a VM.

You need to reacquaint yourself with the concept of a VM. Now days
most VMs are actually on demand compilers. The current javascript
engines run code nearly as fast as compiled C++. The main slow down is
because Javascript is a dynamically bound language with runtime type
checking which adds a bit of runtime overhead. Depending on how they
translate they could be eliminating almost all run time type checking.

Compiling from one high level language to another is not at all
trivial. To capture the semantics of the source language you often
have to use the target language as an assembly language and stay clear
of most, if not all, of the high level features of the target
language. The resulting form is often such that a type deduction
system can remove many run time type check from a dynamic language
like javascript.

BTW, there is no such thing as an interpreted programming language.
Interpretation is an implementation technique just like compilation is
an implementation technique. Implementation techniques are not
language features.

And, yes, I know all this from personal experience. I spent a great
week once reading a lisp compiler that generated numeric code that
outperformed several commercial Fortran compilers, and that was back
in about 1981. The state of the art has improved a bit since then. The
only way to judge the performance of an implementation is to test it.
Just as a door is not locked until you test it no implementation is
slow until you test it.

Bob PendletonOn Sat, Nov 29, 2008 at 3:30 AM, Bill Kendrick wrote:

On Fri, Nov 21, 2008 at 04:20:27PM -0800, Mason Wheeler wrote:

The demos they showed running using Alchemy were a Nintendo NES emulator and
Quake running. Whatever kind of speed they’re getting is probably
suitable for Tux Paint, at least. :wink:

-bill!

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–

±-------------------------------------+