Starling uses “open GL” rendering
Does’ open GL 'seem to have stopped updating?
This is getting properly under the hood now, and I’m not mechanic, but if I’m reading this correctly, ANGLE is used as a bridge when targeting Windows to prefer rendering via Direct3D (d3dcompiler_47.dll), not OpenGL (note line 94 below).
This is a feature provided by SDL, which is in the backend of Lime.
When targeting HTML5 WebGL, the browser automatically leverages ANGLE to bridge to other API’s.
Actually based on this, you should be able to try with:
openfl test windows -Dangle
Be mindful, that’s a C++ target, and will take a while to build. It’s also not really applicable to your HTML5 project.
How does the physics engine work on my ‘moveclip’?
Does the ‘Starling’ event support ‘delta’?
I have found that some developers, when defining variables, always do not write the type of the variable, but let the code infer it on its own?
var num = 10.22;
The tutorial of “as3” tells us to write the type of variable
But do some people seem to prefer letting code infer on its own?
What physics engine are you referring to?
The Starling EnterFrameEvent has a passedTime property, that can be used for delta time. It’s worth noting too, that the Juggler also manages delta time automatically for tweens.
In some instances, explicit type declaration is rather redundant. For example:
var mySprite:Sprite = new Sprite();
In this simple case, there’s no way mySprite can be anything but a Sprite. So it’s reasonably safe then, to infer the type:
var mySprite = new Sprite();
I would be more careful though, in situations where the value being assigned was less obvious or clear. Such as when a value is being assigned dynamically. In those cases, it’d be best to either be specific about the type you’re expecting, or to explicitly use a general type ilke Dynamic if you’re expecting various possibilities.
Importantly, the issue that’s specific to ActionScript 3.0, is if you didn’t specify the type, it would fallback to a default of Object, which was inefficient. It’s the same principle I mentioned earlier, of using the simplest option available. Well an Object was rarely the simplest (or most efficient) option available.
Haxe on the other hand is able to infer the type in most cases, but it too will fallback to Dynamic if that fails.
What physics engine will you use?
as3 Object
haxe Dynamic
ts any
Is it the same function?
I’ve yet to use one. Personally, I just code things like gravity, inertia and such, when needed.
How to integrate “OpenFL” with “Steam API”?
You may want to present that question in a new thread @785597448 . Hopefully someone who’s done it could provide some advice.
Currently, are all of your projects using ‘starling’?
Are you still using ‘as3’?
Is there still a company recruiting “as3” programmers now?
When using ‘as3’, many people use ‘TweenLite’?
What does everyone use ‘TweenLite’ for?
Is the performance of “vector graphics” poor in “as3”?
Is the performance of bitmap really efficient?
”Which is better in terms of performance between AS3 and OpenFL?
In my group chat, there are still some people who insist on using ‘as2’“
I understand your meaning, but this is just a terminology thing and I’d like to just clarify.
“as3” is a programming language, comparable to Haxe.
“OpenFL” is a framework, comparable to the Flash/AIR API.
When you say “as3”, I am assuming you mean the Flash/AIR API.
No, just the ones that need to. To further qualify that, I develop in multiple languages, Haxe, JavaScript (Node.js), PHP and Python, as the need arises. Starling would only be applicable to Haxe projects, and then, only to ones that need it.
I haven’t needed to for a while. It is however, the language I used for much of my professional career, and I would use it again, if the project required it.
It’s pretty good, I’ve used it in the past, mostly when colleagues prefer it in projects we’re both working on. Personally, I’m happy with Starling’s tween system, but if you weren’t using Starling, then TweenLite would be very helpful.
This isn’t so much a “poor in as3” issue, this is true for vector vs raster generally.
On a per-frame basis, a vector graphic is parsed, processed and rasterised (drawn as bitmap data), then drawn.
A bitmap on the other hand, is simply drawn, skipping 3 of those 4 steps.
I’m going to refer to AS3 as AIR, as being more applicable.
The TLDR version: OpenFL is the clear winner here.
-
On desktop, AIR runs inside a virtual machine (AVM2).
-
On desktop, OpenFL can run inside a virtual machine (Neko / HashLink) or be compiled into native code (C++), running at native performance.
The situation is different for mobile targets, these are compiled due to AppStore restrictions (iOS) and performance (Android), so in that respect the two options are probably more similar. -
AIR projects (at least in the Adobe era, I haven’t tested recently), have a strict GPU memory limit of 2GB, enforced by strict profiles. Because of the nature of my projects, I would frequently hit this limit.
-
OpenFL is limited only by the available memory of the GPU.
-
AIR targets only AIR, there’s no options here beyond building for desktop or building for mobile.
-
OpenFL targets multiple options, not the least of these native code, and HTML5. That expands what can be done with it.
Why?
What do they gain?
Some of them are teachers from the school
Using ‘as2’ to create courseware
Some are “as2” enthusiasts
For example, one of my friends still uses “as2” to develop games
He has already created 8 games using ‘as2’
And all posted on ‘Steam’
But he said he couldn’t sell it