Work

[robert-mcdowell]

Work

People will be able to embed SWFs in the page through either the HTML page or scripts (by invoking things like SWF.embed()). But it'll be limited, e.g., only 2 players can be alive at one time. It'd be like embedding a SWF 'app'.

Also, https://github.com/ChristianMurphy/compile-to-web. There are many languages over Rust, butn't all still target WebAssembly (properly). Maybe it's weird to say Rust everytime, but I've used it and it really works in different envs.

---

[ROBERT-MCDOWELL]

This repo is open for everyone who has an idea or want to share a project related to Flash plugin and AS1/2/3 environment to webassembly. So if it was inactive until that's because no one came to write here or they just don' know it.
The most important here is to find a way for Actionscript project running since year to find a conversion to webassembly with the minimum of code change. Sure it's a big ordeal, but doable. It just need the best ideas, tricks or concept creativity to be on the right rail. Today the WASM specifications are still evolving, but some teams are already working hard on it.

---

[ROBERT-MCDOWELL]

I think you didn't catch it. First of all stop to judge me and calm you excitation. Secondly I created this repo to help developers to meet and discuss about how all the work on compiled in SWF can continue to run in browsers after 2020, and despite of disinformation about Flash death, there still is a lot of companies, developers, schools and universities who have no way but to continue to use what's done with Flash. This said, now if you find a way to convert Flash runtime engine in webassembly and interpret any SWF so as webassembly is language agnostic it's up to the genius to choose whatever assembler to do the trick.

---

[ROBERT-MCDOWELL]

Well, with webassembly this can be done all in one. I mean let continue previous AS/SWF job done and improve the API. there is no limit in webassembly but the size of the total bytes (~ 25MB).
Games is on sector, but there are plenty of much more responsible sectors like nuclear plants, universities, factories, aeronautics etc who use Flash/AIR AS1/2/3 since more than 10 years now and don't want or cannot afford to take the risk to change their applications. We are talking here of billions $$$ in the game.
As you know since 3 years a massive racist campain against AS developers and Flash itself raise like mushrooms, of course there is nothing random here. But what I know is the protagonist don't give a f... of others who worked on it for years, and this is where we can start, save and win the game.
Yes, I'm not a low level coding expert, but certainly know what's in the brain of who are controling the web language.

---

Shit... I was updating my message and the internet cab was disconeccting. .-.

Idk what'd be the project's name, though!

For implementing the Flash API itself we'd use the WASM assembly lang, I guess. I'm lazy to re-invent langs other than DollScript/XevelScript.

[ROBERT-MCDOWELL]

not as bad a javascript.... btw, if you think that it's a bad API so here is the opportunity to improve it...

@ROBERT-MCDOWELL And to improve it I need compatibility breaking. You said compatibility was important for old projects... But, yes, it's not quite boring!

[ROBERT-MCDOWELL]

We could use AS3SWF + AS3ABC and perform a lot of AOT optimisations, like auto-inlining rather than [Inline] meta-data, AOT ns accesses etc..
yes, it's an option. The most complex being to wrap it yes.

[ROBERT-MCDOWELL]

it's a big challenge for sure, so nothing is boring since at the end of the bridge some profit can come and for a long term. it's like save a man in the sea.

@ROBERT-MCDOWELL FYI AS3SWF is a library for parsing SWFs. It decodes and parses SWF tags into a manipulable structure. AS3ABC is yet more simple, but it does its job (obviously parse ABC).

[ROBERT-MCDOWELL]

We have one year to have a first version, The very important point is to think about the architecture of the project, a good example is the linux kernel that brilliantly can run almost everything from middle age to today. Once the architecture is perfect, it will be faster and easier for other developers to join (and I know at least 6 who'd love to get involved).
Yes, I have a bunch of old flash games that I will never stop to play ;)

I'm not sure if it's interesting to run SWFs in the Web so much. I'm always using Flash Projector (direct download) for playing (with my brother) in Windows. There's also ADL etc.... Also no reason to even develop with AS3 and the AIR API.

Maybe writting a Web Flash Player runtime in Rust (so I can target wasm with stdweb) and a JS library for triggering SWF loading. It'd have to implement AIR 31. Nah, not worth. :/

[ROBERT-MCDOWELL]

"Maybe writting a Web Flash Player runtime in Rust (so I can target wasm with stdweb) and a JS library for triggering SWF loading. It'd have to implement AIR 31" -> why not!!! :)

[ROBERT-MCDOWELL]

the game being to save mllions websites of flash games and applications without to force the user to download everything. now WASM has same sandbox of Flash or JS, so anyhow you won't be able to use some AIR classes. to be also more performant than the JS wasm api. I'm almost sure that the solution will be the most creative and evolutive way to wrap what's already existing in Flash runtime. Do you know avmplus?

I've never seen a SWF that uses the AIR-API running with the pure Flash Player, then maybe it doesn't make sense to implement AIR 31, but the recent Flash 31. When you run a AIR-SWF in the Flash Projector and it requires any part of the AIR API, it throws an reference error AOT.

For instance, Bouboum, like any other Atelier 801 game, has a Flash-SWF and a AIR-SWF. There's a downloadable standalone there.

I've looked AVMPlus before, but it's just a AS-VM. It implements only few parts of the Flash API (ByteArray etc.). But I'll do something better in Rust, however... I'm having to use different devices; sometimes I'm in a cell and other times I'm in the laptop. This happens because there's a dumb person (truly my brother) taking the laptop to play games even concious he's already 18 old. I wanna smash him 'til his anger death, but anyway I'll have to use git as hell due to this dumb, @!!!!!!! etc. person! I wanna a SDCard for exchanging between the cell and laptop for working in my source codes. #@@#@@#/=

Uh, so I'm still typing in the cell. I can't yet advance in the source codes because they're in the laptop and I didn't push them to the GitHub because I'd have to use a fake account and that's what I've to do, even if it's boring.

It'd not be so if only me and my mother were living in this house andn't these @!#!$...

Aff, I wanna dmash it!

Sorry for typing my angry words. Truly I couldn't still express my wraith. :(

So I'm not sure... I need a SDCard for working in the cell and n't a pendrive.

Okay, so the goal will be to implement Flash 31 and it'll be directly implemented with the browser API. I'll attempt to work now.

[ROBERT-MCDOWELL]

Sorry for late answer, yes, now it's Flash 32 ;)
yes absolutely, the hard work is to create the flash api wrapper into the browser API.
some guys started to do it (maybe you know already) with apache royale as-js, but frankly
I'm not sure they use a very enjoying, simple and powerful way... I'm sure there are more better idea to wrap it.
keep it easy ;), concentrate your energy to your work and stay calm for other disturbance....
do you want any sdcard?

[ROBERT-MCDOWELL]

The situation today, from what I learned from companies, statistics, users etc...
the shock will be:

• The games, experienced game developers who hate javascript and simple users who love to play some anthology games since years which are not supported by its developers anymore.
• The small, middle size companies in medicine, education, science and government sectors. The world financial status is at the edge of total collapse, and most of them won't have a clue why Flash will stop and why it needs to redevelop everything, Craziness and rage will be.
• the communities websites, where tools were developed years ago and still working well, used everyday, but without any budget to recreate the wheel on the ugly way
  If we are enough organized, smart and strategically accurate, FFF can make all its contributors as rich hero ;)

[ROBERT-MCDOWELL]

I don't have a clue of Rust, nevermind the technology, the most important is how experienced developers and users can continue to enjoy SWF on the web with if possible much more performance and less CPU usage with a maximum of security.
since 20 years I lead many many internet projects, starting as a developers until project chief and executive producer,
and always told the developers:
"You cannot understand or accept the global trends of users and business strategies since you are too deep in the code, unless you get out from your developer perspective..."
and always told the commercial managers:
"You cannot understand or accept the deep technical aspects and choice of developers since you are too deep to sale or promote a product, unless you get out from your commercial perspective..."
This said, the game is always find a balance between them.
I like to take a very simple example to convince that "mature" technologies wrongly called "legacy" were new and powerful a short time ago, and what we call "new" technologies and languages today will be "legacy" in a short time ahead, putting in an infernal hellish wheel users and contributors, reinventing the wheel over and over, like stupid mice turning a wheel infinitely.
Go back to the example, I have a bunch of word .doc I created in 1997, today I'm still ok to open, modify and change the code on the last MS word version. PDF is another good example, I made a PHP script that creates dynamic PDF on the fly in 2001, and today I still can read it, modify and change the code on it. I don't have to reprogram or reinvent the whell every 5 or 10 years, the code is good and stable, so why waste the nerve and time to the developers rather than find a way to create bridge between the layers of runtime machines?
A project success to make a wide audience to enjoy and adopt your project is to develop it as wide as possible with a maximum of performance and clearness. Actionscript, despite of its weakness, is far beyond javascript, widely used although it's an older language. Now we are free to think about how to let the developers continue to enjoy this language and why not make it evolve, to fill the gaps or just stack it to another language with a common runtime machine that compile/transpile transparently to wasm?
The main goal to never forget is to keep in mind that a project like this one is not done to satisfy our own wishes, but to offer an alternative to millions users and developers that will satisfy them, and btw us.

[ROBERT-MCDOWELL]

I forgot to mention that if we let them to easily transit from Flash to XXX without to rewrite the entire wheel so it will be a full success. Flash is not rare as what google and co wants us to believe...

[ROBERT-MCDOWELL]

Another idea which can make a big investment return, create a flash CS6/ animate CC/ or else extension at a low price to convert the project into wasm.

I'd be nice to be a SWF-WASM conversion, but there's not much need to, seriously! Most games I know of load external SWFs, so it's worthless to perform ahead-of-time conversion for the entry SWF (because it'll grow the player's WASM).

[ROBERT-MCDOWELL]

Ha ok, it makes more sense to me. if SWF.embed() is possible so it can be a good way indeed

[ROBERT-MCDOWELL]

as always the most difficult is to start it with a very good concept and for sure more friends will come to join us....

Yeah, probably when part of it gets done. The cool thing is that are a lot of weird games. Sometime ago I've been trying to find a strange water game on which you jump the platforms to go through different scenes and fallback to different places. I don't remind the game's name, what's a pitty.

For my time it looked interesting, but Idk if it's really interesting. There're more out there.

I wonder if AVM2 is backwards compatible with AVM1. Will be hard to know, but probably it's.

[ROBERT-MCDOWELL]

the thing I know is AVM1 can be loaded into AVM2 then AVM2 is calling AVM1 automatically.
the opposite is not possible, so in Flash AVM1 and AVM2 are coexisting. Also I noticed that the PPAPI version uses the AVM1 UI debugger in some cases

[ROBERT-MCDOWELL]

about games, personally I loved to play old arcade meme games, mario's, pacman, space invaders, galaga, tetris, and are still popular today, mostly programmed in AS2.

It's interesting how the majority of Flash games involve using HTTP/internet. SM63 and SMBCrossover are being remade in different ways. Atelier 801 will keep all their existing games in Flash (a.k.a. AIR) btw, but they recently said they'll experiment HTML5 frameworks.

The advantage of web-swf will be for AIR devs and general old-school emulation (i.e. SWF Emu), but it's actually recommendable to not develop for Flash unless it's AIR (the Flash alternative maintained by Adobe still).

It's fine to use AIR for general purposes (HTTP, sound and multi-media w/ GPU vectorization). It's like an alternative for the Rust ecosystem (which is the fastest zero-cost language alternative to C++). In fact Rust can be used for writting ANEs (AIR native extensions).

That's what I think of a future Flash framework. It's really a way of emulation and AIR deployment.

[ROBERT-MCDOWELL]

That's what I think of a future Flash framework. It's really a way of emulation and AIR deployment.
that's sound good since AIR is sharing the same API than Flash with more functions and a more permissive sandbox. Then AVM1 will still able to coexist?

Yerr. AIR won't work at all at the Web (since there're OS-dependent parts), it may be silent or throw somethings... (Like restrictions, e.g. local filesystem.)

Ayeh! Now I'm back in the laptop.

[ROBERT-MCDOWELL]

• Yerr. AIR won't work at all at the Web (since there're OS-dependent parts),
  so If I understand well, we can use Rust to emulate Air and Flash?

Rust is a systems programming language. Its compiler was in fact implemented by the same people who did AVM2/ASC2.

Rust targets native code directly by supporting many toolchains (e.g., wasm32-unknown-unknown is a valid arch triple), however you'll mostly forget about rustup and rustc; the most useful tool is Cargo, the package manager which builds for you. The cargo-web tool and the stdweb crate are the main parts used for Web development.

Yes, we can, really. It's a language that aims to have C++ capabilities in a different and more restricted design. It's more documented in my opinion ;)

The module system is elegant. It doesn't support packages like AS3; it's file-based, like require-exports generally, but still different...

Truly I never wrote C++ deeply, but I'm quite sure Rust is getting more mature. The only thing I find weird is to share fields in a efficient way between a class tree...

Rust gives you many different ways to do tasks in comparison to AS. Both languages have different goals, though. Rust is naturally efficient (like Swift, C++ and so on) and provides conscience for writting programs, AS3 is like JS but a bit more restrictive (and thus less error-prone).

[ROBERT-MCDOWELL]

The thing is how to bridge Rust with SWF and Flash API to make it work in a browser?
If it's possible, so I'm pretty sure it can be a better solution than other project like apach as-js for now.

[ROBERT-MCDOWELL]

btw, once we decided what components to use I will close this thread and open a new one ;)

[ROBERT-MCDOWELL]

What do you think about Haxe and OpenFl?

Haxe + OpenFL aren't able to run SWFs in the web, but they target web apps, as I understand.

The thing is how to bridge Rust with SWF and Flash API to make it work in a browser?

One way: the AIR API (playerglobal.swc, which defines Vector, trace, DisplayObject etc.) is caught from the AIR SDK, shipped w/ the player's runtime (static ApiAbcs: Buffer = Buffer::new(include_bytes!("/res/playerglobal.swc")), something like that). Wait... I'm back. The player then implements all native functions from that API. There are things to think more, like dynamic wasm generation. As you know, Loaders are generally used by SWFs.

swf-rs will be used to parse SWFs. About graphics, I think either glutin and gl-rs will be used or winit-rs and gfx-rs.

[ROBERT-MCDOWELL]

a game il liked when I was a teen ;)
http://arcadegamesclassic.net/galaga/#.XDCdIqUgzPY

• swf-rs will be used to parse SWFs. About graphics, I think either glutin and gl-rs will be used or winit-rs and gfx-rs.
  ok for the graph, but what about network, stream protocols? does rtmp,rtmfp, multicast, peer to peer, sharedobject will find the equivalent?

Woah, 2004 is the year in which my brother bornt. Anyway, seriously we should just use Rust for a new Flash framework.

ok for the graph, but what about network, stream protocols? does rtmp,rtmfp, multicast, peer to peer, sharedobject will find the equivalent?

So, yes; HTTP and network, low-level graphics, (de-)serialization, co-routine, Web, math, audio, validation etc. libraries are all there in Rust, but you should read the book to understand the ecosystem. It's free, you can lookup it in the site.

We can build a vector graphics alternative for the Flash display tree and forget about AVM2. The goal is to use SWFs as graphics fragments, like people always were able to.

(AS3.)

import flash.display.MovieClip

[Embed(src = 'luigi.swf',
       type = 'application/octet-bytes')]
static const BuiltinLuigi: Class

root.addChild(new BuiltinLuigi as MovieClip)

(Rust.)

extern crate flash;
use flash::display::*;

mod Luigi {
    static Bytes: [u8] = include_bytes!("luigi.swf");
    static Mc: MovieClip = &Bytes;
    // impl<'a> From<&'a [u8]> for MovieClip
}

fn main() {
    let root = Sprite::root();
    root.add(Luigi::Mc);
}

Language isn't an issue. In Rust you don't have handy inheritance, but there're many ways to do tasks efficiently.

[ROBERT-MCDOWELL]

looks interesting indeed. The trick to embed the swf is a good thing, but will it be able to communicate between the swf and Rust code? If not, it's not a problem since legacy swf will just run as usual and if the developer needs to develop other project so he/she will have the choice to do it in pure Rust or Actionscript
about network classes, I still not understand how it will be possible to create UDP proto (RTMFP) since the browser is limited to TCP?

will it be able to communicate between the swf and Rust code?

That's not the idea. It'll ignore all ABC (ActionScript bytecode), no AVM will run. That's how Web transparency is possible; this way we don't need to track playerglobal.swc (super-heavy), air.swc etc..

I still not understand how it will be possible to create UDP proto (RTMFP) since the browser is limited to TCP?

Any browser limitation is acknowledged by the developer. In Rust the libraries will either be unimplemented or will panic if there's a limitation. Now, the Flash framework is just a matter of the display tree; the rest is depend in other libraries (serde, http, etc.). Ah, well, I never used protocols beyond HTTP too much so far. I've tried more by 2015 with web sockets and SmartFox in Flash Professional, but I were just 13 in that year to understand it properly.

Okay, let's close this since it got hard to browse by!

[ROBERT-MCDOWELL]

You still have plenty of time in front of you! but be aware, time never waits anyone ;)
That's the biggest problem, web sockets, webRTC and other JS classes are TCP limited, which is a real issue when multiple low latency live streaming are involved. With RTMFP (UDP based protocol) since 8 years now you can create a vast full multicast mesh with different arichitecture in pure IP or application level or both, which for now is (not?) implemented in JS engine, but it's on the W3C recommendations.
https://www.w3.org/TR/tcp-udp-sockets/
https://libraries.io/search?keywords=multicast&languages=JavaScript
for reference, multicast in Actionscript
https://www.adobe.com/devnet/adobe-media-server/articles/real-time-collaboration.html
https://helpx.adobe.com/adobe-media-server/dev/rtmfp-groups.html
You are aware of Display, I'm aware of communication protocol and live streaming (my last 11 years project is based on it) so we can really be complementary to find the best way to do it.

I suggest a deadline of Jan 30th to close the choice of all components and environment needed for the project, then start the hard work so I will be able to spread the word around.