Flash Display - Githubissues

ghost commented 5 years ago

The rs ecosystem is just growing. We can search crates.io for finding what we need from what we had in Flash, except the display tree (flash.display). With gfx-rs, winit and swf-rs we can implement a good one.

Porting old projects to Rust might be hard since it's gradually different from ActionScript, though. But that's for good since AS isn't a scalable language.

ROBERT-MCDOWELL commented 5 years ago

I changed the git repo name to be better found on git search, but didn't know it just deleted all discussion issues crates.io looks good, as long as it will be better than flash.display....

ROBERT-MCDOWELL commented 5 years ago

I also recalled FutureFlashFramework by Foo Flash Framework. I want to keep the work Flash to link Flash developers and user interest. btw Flash is not copyrighted anymore since 2015

ROBERT-MCDOWELL commented 5 years ago

Porting old projects to Rust might be hard since it's gradually different from ActionScript, though. but feasible?

ghost commented 5 years ago

I changed the git repo name to be better found on git search, but didn't know it just deleted all discussion issues

In fact It can still be found w/ is:issue is:closed. It can be re-opened, but I think some messages should be deleted. It's a bit large IMO...

crates.io looks good, as long as it will be better than flash.display....

crates.io isn't truly everything. I'm afraid you're thinking crates.io is a package (it's actually a registry). You don't use crates.io manually when building projects, but you usually have dependencies in it. I'm not sure if you're familiar with package managers (like Cargo or NPM), though.

btw Flash is not copyrighted anymore since 2015

Only ActionScript was copyrighted back in 2018 from what I heard...

Porting old projects to Rust might be hard since it's gradually different from ActionScript, though.

but feasible?

Yeah. Not much hard, but the developer is encouraged to change the code design. Existing code, if multi-threaded, can benefit in Rust avoiding mutability where desired.

ROBERT-MCDOWELL commented 5 years ago

first issue is always good to keep, yes I just saw it, it's ok to leave it as this. sorry, I wanted to say gfx-rs, not crates.io

Yeah. Not much hard, but the developer is encouraged to change the code design. ok, but for the SWF without sources it should work right?

ghost commented 5 years ago

Yes. We don't have much to do, just need to learn math and get used to low-level graphics, swapbuffers... Or use high-level graphics from Amethyst, SDL2, Idk.

There's no multi-purpose display tree implemented by anyone in Rust, still. A UDP server has been implemented by the looks: https://github.com/christian-smith/rust-udp-server.

Well, if we want port SWFs easily then it's a means of having a flash crate. It won't cost in anything in Rust.

ghost commented 5 years ago

Amethyst is for ECS (Entity Component System) patterns, so it's mostly for games. Flash is for ECS, Functional Reactive and all other graphical programming patterns.

Ohhhh, a pitty. >_<

ROBERT-MCDOWELL commented 5 years ago

udp server looks good, so an RTMFP protocol can for sure be created modifying this project code. Amtthyst looks promising, but why a pitty? :\

ghost commented 5 years ago

Amtthyst looks promising, but why a pitty? :\

Since it's ECS-based, that means it's for game-purposes only. But not much to worry, I'm writting the lib. It'll allow you to cast between the sealed classes (DisplayObject, Sprite, Shape, MovieClip, TextField etc.) just like you could in AS, but you won't be able to extend them (since that mostly leads to bad code).

The cool thing is that will be usable for ECS too. It'll be usable for everything, UI, these.

objects/mod.rs

mod unit;
mod inherit;
mod disp_obj;
mod sprite;

pub use unit::*;
pub use inherit::InstanceOf;
pub use disp_obj::DisplayObject;
pub use sprite::*;

objects/disp.rs

use fladisp::*;
use std::convert::*; // AsRef, From, Into

pub struct DisplayObject {
    kind: DispObjKind,
    x: Unit,
    y: Unit,
}

// Impl InstanceOf's

ghost commented 5 years ago

udp server looks good, so an RTMFP protocol can for sure be created modifying this project code.

Hmm, we could implement a Flash equivalent into Rust, then. E.g., a flash::net module that supports it. For #[cfg(target_arch = "wasm32")] it could fail silently, panic or be unimplemented (so the developer gets a static error).

ghost commented 5 years ago

To get used to Rust you can check Rust by Example. https://doc.rust-lang.org/stable/rust-by-example/

Well, as a ActionScript developer I've used Flash Professional/Animate or MXML directly to build projects. In fact it wasn't always direct to me (at least for MXML in the command-line). Flash Professional or AS&MXML is a bit better to use since it setups for you, but both of them are still incomplete for handling dependencies, caching etc.. The thing is, the AS environment is quite incomplete. Rust has a package manager in command-line. It's easier and more mature.

After installing Rust you can check:

https://doc.rust-lang.org/book/ch01-03-hello-cargo.html

It'll introduce it to you, even though it's, yeah, different from ActionScript. It's really light.

ghost commented 5 years ago

Ah, you do install rustup with the night channel. For now it's the one that stdweb supports. I also recommend using MinGW (GNU) as the default linker since MSVC+ is heavy to firstly download.

ROBERT-MCDOWELL commented 5 years ago

ok will do. We need also to think about a flexible and smart architecture. Let's say if Rust becomes a dead project, what are the chance to switch to another environment to avoid to not loose all the work? From the past lessons we always need to adapt the future to avoid to repeat the same mistakes

ghost commented 5 years ago

@ROBERT-MCDOWELL The framework doesn't depend in many particularities of Rust. But if it's not done in Rust, then it means we'll re-duplicate a low-level system to target WebAssembly, nope?

As to the display library (which I'm now having to work in phone...), as planned, it could be adapted to ActionScript/C#/Swift sealed class inheritance. Inheritance is important since it allows cheap field access through display elements. With that you can perform collision checks with various objects more efficiently (by first capturing rectangular collisions and then exact collisions).

Rust becoming a dead project is unlikely. Very different technologies may come (quantum computing), but binary ones will continue to still be exponentially faster for gaming, animating and such. SIMD operations, for instance, are already in std. They aim to be growing.

Rust is super unlikely to die due to its transparency. When something is transparent, you've full control and confidency of what you're doing.

Swift is also kinda there, but it looks like it has reflection by what's said out. I've never rant it since I've no opportunity to that so fine. (Swift is OSX-ish, cross-arch support is still being worked.)

Rust is a snake, orochi.

ROBERT-MCDOWELL commented 5 years ago

The framework doesn't depend in many particularities of Rust. But if it's not done in Rust, then it means we'll re-duplicate a low-level system to target WebAssembly, nope? I don't know, my question was from my ignorance. I even don't know if it's possible. What's the most long term language existing if it's not C and C++? so if Rust discontinues, does any conversion tools allow us to convert Rust language to C/C++? it's questions we need to seriously ask.
Rust is super unlikely to die due to its transparency mhhm, well, I won't say the story is repeating every decade, but it's unfortunately what I see through the internet development. Everything is nice and promising when a new stuff is created and many developers use it, then boom, one day the core staff decides to stop it for various reasons. I saw that for many languages/projects/softwares, Flash included. What you said about Rust above was exactly the same words 10 years ago with Flash. So it's always better to prevent rather than loose years of work.

ghost commented 5 years ago

@ROBERT-MCDOWELL But Flash isn't transparent, that's when we include its runtime. It requires many assumptions (e.g., store all API strings in ABC constant pool and bring objects with lots of properties representing the API classes at run-time, which can then also be seen by external SWFs and thus not optimised ahead-of-time).

C, C++ and Rust are the kind of transparent languages. Ah, and Rust wasn't implemented in C++, nor there's a Rust-2-C[++] transpiler. Rust is a product of lessions taught earlier from C++ by Mozilla.

What you said about projects stopping didn't exactly occur with, say, C++.

ROBERT-MCDOWELL commented 5 years ago

What you said about projects stopping didn't exactly occur with, say, C++. Ok so we need to know if, for the worst case scenario there is a bridge between Rust-2-C++ and C++ right?

ROBERT-MCDOWELL commented 5 years ago

To start such kind of big project we always need to think of all the worst scenario and negative aspects of it.

ROBERT-MCDOWELL commented 5 years ago

what do you think of this article? https://hackernoon.com/why-im-dropping-rust-fd1c32986c88

ROBERT-MCDOWELL commented 5 years ago

and this one? https://www.viva64.com/en/b/0324/

ghost commented 5 years ago

@ROBERT-MCDOWELL They're outdated. I've read the Hackernoon one and its main issue is inheritance. Inheritance is possible (it was my first issue, too, since I were to implement display/DOM-like objects). After having used Rust more, all needed is implementing conversion traits (From, TryFrom and AsRef), fallback traits (Deref), a custom InstanceOf trait and unsafe casts internally (Rc::from_raw(Rc::into_raw(r.clone()) as *const() as *const Out)).

I'm writting a macro class_decl! to facilitate that. Inheritance is efficient, but still the Rust folks don't get it right. They think I want delegation with traits or composition; err, I can't really communicate with them well.

Ah, they do many RFCs, but the language got better in 2018. It's really different from C++, e.g., there's no formal spec. exactly, but in the other hand the progress is fast in it.

Now, Viva64's article looks to also criticise the package manager. What? It's saying packages that depend in other packages hosted in GitHub will cause crates.io to be crazyland. In first place, a package cannot be published to crates.io when it has external dependencies; it can depend in crates.io itself, but cannot in GitHub or a local file-system. And to add, the Rust ecosystem is well aware of semvers (semantic versions), so it's quite the opposite of what this article thinks.

Overall they leak experience with Node.JS, Cargo and inheritance.

ROBERT-MCDOWELL commented 5 years ago

ok, indeed it in 2 years a lot of changes can happen... good luck fo class_decl!

ghost commented 5 years ago

It didn't go well. Well, still inheritance is hard in need of zero-cost Deref to the base class DisplayObject. Hmm, I'm starting to think Rust isn't a good idea, then.

ghost commented 5 years ago

Entity-Component-System isn't something I want directly; I'd rather use it in top of flash.display, thus escaping from inheritance to composition or trait delegation isn't appropriate.

ghost commented 5 years ago

N't sure, but I'm thinking a ActionScript alternative has to come later. E.g. a namespaced-language inspired by AS3. I was working in such, but since I gave up misc. times I won't be working in it any time soon. I guess we'll have to use AS3 as is, but breaking compatibility with the spec (and thus non-static indexing and run-time reflection would be broken).

ROBERT-MCDOWELL commented 5 years ago

I found this https://internals.rust-lang.org/t/why-not-inheritance/5738/21 maybe it will help, if not, le'ts continue to dig in the rabbit hole

ghost commented 5 years ago

@ROBERT-MCDOWELL They've still not added a feature like fields in traits. I've done the class_decl! macro, but I couldn't implement Deref efficiently and am thus not satisfied w/ Rust. What a pitty...

ghost commented 5 years ago

Everything in Rust is good, except Rc. Lalaolohuahu

ghost commented 5 years ago

I could do something different for the standard's Rc, but why, really? Hm...

ROBERT-MCDOWELL commented 5 years ago

@hydroper it it helps to get inheritance.... What's the motivation of the authors of Rust to lack of it?

ghost commented 5 years ago

They look to say it's not a priority, but is really affecting the flexibility of future libs, I think so.

ROBERT-MCDOWELL commented 5 years ago

weird. anyhow, it stays C++ right?

ghost commented 5 years ago

Yes. C++ isn't very unsafe (compared to Rust it's unsafer), but the usual build systems (Make, CMake, Bazel and others) are very boilerplate. Wauh. No module system... :(

ghost commented 5 years ago

Rust doesn't let me display anything in particular. It misses flexibility in that piece of need. I think I should still try to Deref. I'll have to duplicate Rc in that case...

ghost commented 5 years ago

Okay, I better don't spam about inheritance here. I'll still give a try to replacing Rc somehow.

ROBERT-MCDOWELL commented 5 years ago

There is always a way to do it, it only needs the righ idea ;)

ROBERT-MCDOWELL commented 5 years ago

https://github.com/WebAssembly/design/issues/1255#issuecomment-455003301

ghost commented 5 years ago

Crystal has inheritance, but its host/target systems are still very undone. Well, meanwhile only C++ has inheritance and targets systems well (like Rust).

Inheritance is something efficient/flexible for display objects, but what I need isn't inheritance at all; I just need efficient field traits within reference-counted structures. The unique way will be to diverge from Rust standard library's Rc pointer, but I think I'll just use Adobe AIR for now. I'm writting a package manager for ActionScript and maybe something good might happen.

ghost commented 5 years ago

What I see is that Adobe AIR has few-few showcases. I know apps/games done w/ Adobe AIR (Atelier 801 games (principally the newest, Dead Maze, released in 2017), Hero Fighter X, Brawhalhia, Gasha Universe and I'm not reminding right now other samples). 3D games there're too, but all of which I know aren't MMO (I even remind a nearly 3D RPG).

Probably with a package manager people'd stop being lazy.

ROBERT-MCDOWELL commented 5 years ago

In digital world the beauty is everything is possible, from bad to good. It just needs imagination, out of all squared guides, manual and else...

ghost commented 5 years ago

I solved to continue building a refinement language of ActionScript. (Now that I've deleted my unicode-gc repo and lost its source, I'm so sick about it...)

ghost commented 5 years ago

Vega isn't exactly a subset of AS. It's not AS, but by the syntax and namespaces it looks like. It's mostly zero-cost (near Rust and C++), has no RTT (runtime-type) info and no property names in run-time, very unlike JS/AS/Lua/C#/Haxe.

ROBERT-MCDOWELL commented 5 years ago

ok good idea, but is the purpose of this new language to be used with Rust or?

ghost commented 5 years ago

@ROBERT-MCDOWELL Mostly with C++. If it were Rust, then I'd have to waste neurons with the borrow checker and general crates obligging me to borrow several times.

ROBERT-MCDOWELL commented 5 years ago

ok gotcha. So what the advantages to create a new language on top of C++ knowing that for ex Haxe is an Actionscript like language and can be compiled in native?

ghost commented 5 years ago

@ROBERT-MCDOWELL Haxe has RTT-info (reflection and property names in run-time), what means it already has certain overhead for large projects. But whether that RTT-info would cause slowness, well, it depends in AOT optimizations. If dead code isn't eliminated, much may happen.

Haxe is at least better than ActionScript, but it's not entirely near a systems programming language. Its implementation uses a mark-sweep GC. If you take into account mark-sweep GC and RTT-info, it has a quite considerable overhead for the Web.

RTT-info? Well:

class A {
    constructor() {
        this.f = 'Hi'
    }
}

const a = new A
a[String.fromCodePoint('b'.charCodeAt(0) + 4)]

Unfortunately languages with reflection may already have libs using reflection and C#-like dynamic values.

ghost commented 5 years ago

These languages are for more than general purposes. Meta-hooking is everywhere and thus clustering your run-time...

But did it influence performance at all? Hm, I remember playing Super Mario Bros. Crossover (SWF) in a browser and it were slow. Playing it in a Flash Projector used to be more efficient. Embedding a big GC into another big GC isn't cool.

WebAssembly will allow re-use of the JS GC, I think, but I still don't like using them... Though it's acceptably usable.

ROBERT-MCDOWELL commented 5 years ago

I see... So just enumerate the pros and cons of this new language

ghost commented 5 years ago

@ROBERT-MCDOWELL Pros:

Flexibler names (with namespaces) and aliasing versus Haxe/AS
Really better imports (and the compiler aims to allow better directory-structure)
Data-classes (Vector3F as a copy-value everywhere)
Many syntax goodies (function keyword only used in non-method definitions; lambdas use arrow-likes)
Implementation will use A.R.C. (auto ref-count) rather than tracing GC since the language provides WeakRef.<>
Faster-to-write loops (numeric ones may use (inclusive) ranges, e.g., for (var i in 1..=j) task;, though there's no step like in Lua)
Safer switch, safer in general.
Less run-time clustering guaranteed.

Cons:

No reflection (definitions can't be hooked at run-time; properties aren't exposed too).

ghost commented 5 years ago

Error-handling is also different. It's Rust-based, but discrete. throw will return and such and such.

ROBERT-MCDOWELL / Flash

Flash Display #2