Using the new compiler Inline methods

(Abel Toy) #1

So apparently there’s a new compiler for flash now. It’s called ASC2.0.

It’s a bit better on everything, faster to compile and stuff. Constants are handled a bit better.

But one of the things I like most about it is the introduction of Inline methods. You can tag a method as inline now. This would be useful in utils classes, such as the ones FP has, such as approach, clamp, and a large etc.

I think FlashPunk should add support for this new compiler?

Also I discovered flash now supports multithreading as well, which is nice :), but I don’t think much of FlashPunk’s internals can gain from that?

(Martí Angelats i Ribera) #2

With multi threads you can do absolutly independent things. For example have the graphic render in a thread and all the phisics to another making the input more precise and rendering when necesary. This could also be good for non frame realted calculations (for example voice chats in the game or the timer for speedruns [more acurated]). Also external things like send archivements in Kongregate or load online staff.

(Jacob Albano) #3

I don’t think he was saying he didn’t know what multithreading could be used for in general, just that it doesn’t benefit Flashpunk. I can’t myself think of any aspect of the engine that could be improved with threads; there’s no physics simulation, and Flash performs its rendering step at the same time as the entry point for the update loop.

(Abel Toy) #4

Exactly. I can’t see anywhere in the flashpunk engine itself where multithreading would help.

Inline methods, on the other hand…

(Jacob Albano) #5

Inlines would definitely come in handy. Improved constants are interesting too…I read recently that using const on a member still results in a lookup every time it’s referenced, rather than simply patching the values in at compile time.

Edit: Announcement here.

  • Non-linear control flow added to AS3 through a new ‘goto’ keyword.

(Abel Toy) #6

Bahahahaha yeah. Fuck goto.

We need to see @Draknek’s view on this. I think the new flash players that support this are not on linux?

(Jonathan Stoler) #7

That would be my concern as well. We can definitely have a development branch (prep for 2.0 in the process? ;P) that supports these features, but I’d be worried about compatibility issues if this becomes the main branch.

As nice as these features are, I would hate for people to be unable to play FlashPunk games because their Flash Player is slightly out of date.

Here’s a page outlining potential compatibility-breaking changes in ASC2.0. I didn’t get a chance to take a really close look, but none of it looks like it would cause problems in terms of simply switching compilers with the current codebase.

Also, I feel like I must be missing something, but I don’t see where it says anything about threading, besides this:

While this is certainly good news, it only seems to affect compilation, not actual running code…

(Jacob Albano) #8

My guess is that we’ll continue to support the lowest common denominator, which in this case means MXMLC. ASC2.0 has been out since September and I haven’t noticed it gaining widespread adoption.

However, if all that’s necessary to attempt inlining a method is the [Inline] metatag, we could potentially add support for it in Flashpunk without breaking compatibility with the Flex compiler.

(Abel Toy) #9

@JonathanStoler There’s a 3-part tutorial on AS3 multithreading here: http://esdot.ca/site/2012/intro-to-as3-workers-hello-world - it’s basically the Worker api, found here: http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/system/Worker.html

I’ve tested flashpunk with ASC2.0. It works. I just had to fix some things a bit. There are some ugly if(e = collideTypes(something)) bits in the code which the compiler just doesn’t like.

So, fixing that (which would be compatible with ASC1.0), and having some way of marking methods as Inline that don’t break ASC1.0 (simply ignoring them, and only inlining them when using ASC2.0), would be great, as @jacobalbano said .

Also keep in mind you have to pass an -inline parameter to the compiler when using inline methods. Or just setting this option to true in FlashDevelop: http://puu.sh/9S5Pe/f1b70abc65.png

(Zachary Lewis) #10

If rendering ran on a separate thread, it would increase performance. Rendering is pretty much the slowest thing going on. If rendering did its own thing, it would allow for update ticks while the screen was drawing, reducing latency.

(Jacob Albano) #11

Well, not necessarily. In many cases, adding threading to a program can actually cause it to perform worse. You need to synchronize so you don’t render a frame while the world is halfway through updating, and you lose the ability to skip frames if the update loop is too intensive – unless you run the two simulations in lock-step with each other, and that completely negates the benefit of running two threads anyway.

(Martí Angelats i Ribera) #12

I think it may be posible to save the state every “update” tick, then render the last full updated “update” tick (making a “render” frame). Meanwhile the next “update” could have been calculated. So if there is more than one “update” ticks, the last one will be rendered. (basically making the “update” ticks adn “render” frames independent).

Would it be possible? Or it could cause problems? Or maybe even losing performance?

Another thing that can be tried is to start to update an object’s frame right after his render and while the nextone is rendering.

(Abel Toy) #13

Let rendering be the main thread. I’m not sure how flash handles it, but I know OpenGL and some engines don’t allow rendering on a separate thread.

If people want things to go faster and not be limited to rendering speed, thread those instead. Rendering needs to run continuously and at the game’s fps to look good. But if people want physics to run twice as fast, they can thread physics, instead of making the physics thread the main one and threading graphics.

I think it makes most sense to keep rendering as the main thread.

(Jacob Albano) #14

That’s the way it’s usually done, but it’s not really feasible on a platform like Flash.

For one, multithreaded engines are heavily data-oriented. Instead of having many classes that each have their own properties (like Flashpunk entities), they’ll use large banks of entries that each game object refers to. Since all that memory is in one place, it can be copied very easily, and oftentimes there will be two copies of each object at all times; one that belongs to the game state, and one that exists as a snapshot of the last tick for the renderer to use.

Further reading: https://github.com/EngineArchitectureClub/TalkSlides/blob/master/2012/11-DataOrientedDesign-SeanMiddleditch/DataOrientedDesign.pdf

Just by virtue of its design, Flashpunk can’t take advantage of this approach. Don’t get me wrong, the Entity/World model is really great, but it’s inherently incompatible with memory packing techniques that make it viable to constantly be copying state. On top of that, Flash doesn’t allow direct memory access anyway, so the point is moot.

Off the top of my head, the minimum processing each entity would require each frame in order to take a snapshot would be as follows:

  • Whether the entity is visible
  • The entity’s position
  • The entity’s graphic (recursively; remember graphiclists)
  • The graphic’s position, scale, opacity, etc
  • The graphic’s source image (with tinting, this would require a hard copy each frame)

It’s very likely that each graphic would have to be copied wholesale, since each one has a very different render() function; just look at Backdrop and Emitter for two examples of the specialized work involved. Copying the reference wouldn’t suffice, since that would open up the possibility of desyncs.

Short version: Due to Flashpunk’s structure, the limitations of the Flash platform, and considerations that must be taken when attempting multithreading in general, it’s just not feasible.

In any case, we’re pretty far off-topic now.