I understand the overall concept of the Haxe programming language and OpenFL, but I'm having a lot of trouble understanding the purpose of these various libraries and how they relate to each other and which ones are deprecated.
I've read that lime-tools is deprecated and became aether. I've read that aether is deprecated and became lime-tools. And I've read that both are deprecated and became lime. Upon writing this I've now also read that aether has been reintroduced.
I also don't understand the difference between lime and openfl itself as the commands seem to be identical; do they have different processes in accomplishing the same thing?
This has been an issue I've returned to a number of times in my attempt to get up to speed on the current state of Haxe development.
lime-tools and aether are both deprecated as of the 2.0.5 version of lime.
Originally lime-tools was called haxe-tools because the project format could be used for any development in Haxe. The Haxe Foundation suggested that it be changed because it wasn't an "officially" supported tool and thus lime-tools was created. It was kept separate from lime in hopes that it could still be used by someone not using lime or openfl.
During the development of lime 2.0 there was still discussion on whether to keep the tools separate or integrate them directly into lime. The decision was made to keep the tools generic enough for any Haxe development so lime-tools was renamed aether in the idea that the new name would be considered separate from lime. For a few releases aether was required to test/build lime and openfl projects until Joshua Granick (the primary maintainer of openfl and lime) decided to merge the tools with lime to simplify the installation process.
So as it currently stands lime contains all of the code from lime-tools and aether. You should use lime <command> <target> from a terminal to build/test/etc a project. lime also contains code to create an OpenGL context, handle input, and play audio. openfl is simply the layer on top of lime that acts as a replacement API for Flash and is now completely written in Haxe.
http://www.robertshady.com/content/getting-started-cross-platform-game-programming-using-haxe-lime-and-openfl-part-1-installati
https://medium.com/kodemint-technologies/haxe-lime-openfl-ec9c2784aaa8
Lime or Light Media Engine is the glue which helps make our Haxe code
to run in various native platforms. Lime exposes native functionality
like OpenGL, Audio, Input, Windowing etc (From the lime project readme
https://github.com/openfl/lime). Lime is the layer closest to our
targeted native platforms.
OpenFl is an open source implementation of the familiar Flash API.
(The DisplayList based API that flash exposes. If you have experience
with targeting Adobe AIR all this will be very familiar). OpenFL
resides on top of Lime thus providing a true native experience.
Related
I am not a completely inexperienced developer, but I often find myself struggling with tools and workflow related questions due to not understanding the related compilation process well at all. I have worked with FlashDevelop before, and with Haxe, but one simple thing that I’ve never understood is what occurs when choosing a specific "project type" for a new project.
The primary reason I want to work with Haxe is to be able to more easily target multiple platforms, but I am very new to this. I’d like to make a play-project, a game, with the purpose of learning. One thing I would definitely like to get more experience with is the process and pitfalls of simultaneously targeting web-host-able platforms like Flash and HTML5, tablets, and potentially one day, consoles, etc. In addition, I’m told that targeting Neko can make early-game debugging easier. Finally, should I have the bulk of my 3rd party libraries chosen before deciding on this, or will all of these project types allow me roughly the same flexibility on this as well?
With that in mind, even though I have a rudimentary understanding of the differences between Flash, OpenFL, and Lime, I don’t know which project type to choose to get the best balance of flexibility and ease of setup. I found one answer that seemed to indicate that adding a second target isn’t that difficult. My instinct is to use the OpenFL Project because I have AS3 experience, but I’m not entirely in love with the Flash-centric structure of building games using the display list. Might I be better off just starting with the Haxe “Empty Project” and learning to set it all up myself?
Basically I’d just like to understand what FlashDevlop projects are, and how do I chose the appropriate one to start with Haxe, without losing flexibility to add more targets and various libraries later on.
I hope I phrased that well and that it is an appropriate question. Thank you!
Start with OpenFl project. Haxe is a language that allows you to compile your code to other language(c++,as3,js...). But it's Lime or other frameworks that make it work in all those platforms(c). OpenFl is build over Lime. OpenFl implements all the flash API, so if you know As3 that's a great place to start. You can start there implementing things and getting to know the language. You can start programming immediately, but it's cool to learn all the other cool features that as3 doesn't have.
You have other frameworks, but not all let you export to all platforms.
some popular frameworks are
http://snowkit.org/2014/09/20/about-snowkit/
http://getflambe.com/
I use openFL because I think its the easiest to use, and I think it has the biggest community.
My personal experience, I never had an experience as great as OpenFl. Flash is awesome and OpenFl is like flash on steroids. As any framework you need to know how to use it to get the most out of it.
Best of lucks!
I've been looking through the sites of Haxe / OpenFL / Flixel but am struggling to understand what each one is for.
As I understand it:
Haxe is a language that can be deployed to multiple platforms.
OpenFL is something to do with Flash.
Flixel is a library to help you make games.
Could anyone correct me/make it clearer.
Haxe
To quote from haxe.org:
Haxe is an open source toolkit based on a modern, high level, strictly typed programming language, a cross-compiler, a complete cross-platform standard library and ways to access each platform's native capabilities.
Language:
Haxe is a programming language. It's similar to AS3, C# etc. It is strictly typed, but has great type inference. It has a lot of powerful features such as Pattern Matching, Enums (ADTs), Macros etc. These work no matter which target you compile to.
Standard Library:
Haxe can compile to JavaScript, C++, Flash, Java, C#, PHP, Neko, HashLink, Python and Lua. It has low level standard classes that work consistently across platforms, such as: String, Int, Float, Date, Map etc. It also has some useful cross platform code for things like Serialization, Xml, Json, Date formatting etc.
As a general rule, anything on api.haxe.org that is in the top level, or in the haxe package, is going to work whichever target you compile to.
Each target has its own package. These let you access native capabilities of that target via externs. Eg. js.html has DOM externs, flash has externs for the Flash API, etc.
There is the sys package, which is available on "backend" targets: C++, Java, Neko, HashLink, PHP, Python and Lua. It's also available on JavaScript/Node with the hxnodejs library.
Other stuff:
The Haxe compiler is super fast compared to a bunch of other compilers. That's a selling point in itself. There's also macros, which let you do a bunch of pre-processing in a really powerful way. Then there's tools like Haxelib which let you link in with 3rd party libraries.
OpenFL
When Haxe first started, Flash was still a big target, it was installed everywhere, and it was great for making games. A lot of Flash developers liked Haxe because it was fast, type safe, open source, and gave them more features. But the flash API (sprites, graphics, movie clips, events) only worked on Flash, not on mobile, or on HTML5 etc. Which was a problem once flash started becoming less popular.
What OpenFL does is make that Flash API work on other Haxe targets. So you wrote a Haxe game targeting the flash API using sprites and graphics and flash-style code. Then, you want to compile to C++ (for targeting mobile etc). OpenFL lets your Haxe code use the Flash API, even if targeting C++ or JavaScript. For example, OpenFL creates the flash.graphics.DisplayObject class not only for flash, but for C++ and JavaScript. So if you know how to write Flash games, you are close to writing OpenFL games already.
OpenFL also has some great tools for making it easier to deploy your games to specific platforms. Where Haxe targets are things like "JS", "SWF", "C++", OpenFL platforms are things like "iOS", "Android", "Switch", "HTML5", "Windows EXE" etc. When you hear about Haxe targeting mobile, a lot of the time it is OpenFL, because it works with Haxe to compile your code (into C++, JS, SWF or whatever) and then packages those binaries for mobile.
Flixel
Haxe is a language, compiler and standard library.
OpenFL builds on this and adds the Flash API working across targets.
HaxeFlixel builds on this even further and provides game specific APIs that work on OpenFL.
An example of how it all works together:
You create a game. All of it is written in Haxe. Things like player name, scores, and completion info all use data structures from the standard library. They'll work in your game, but you could also make them work on your PHP website.
Your game uses OpenFL to compile to Flash, HTML5, iOS and Android. As part of OpenFL, you also have access to standard Flash API classes, like the Stage and Buttons and MouseEvents, which you might use for your menu screen. Because OpenFL provides the flash.* classes for other targets, your app compiles to all different things.
For your actual game, performance is important, and the flash DisplayList approach is a bit slow and not optimised for gaming. HaxeFlixel is optimised for gaming, and is very fast. So you design your game with HaxeFlixel using their APIs.
Summary
Haxe is a language, compiler, toolkit and standard library. It provides the most basic tools for cross-platform code.
OpenFL is built on Haxe, and provides the Flash API to multiple targets (Flash, C++, JavaScript) and makes it easy to compile to a bunch of platforms: web, native, iOS, Android, Nintendo Switch etc.
HaxeFlixel is built on OpenFL - it uses the APIs provided by OpenFL to create a game specific framework that is high performance and easy to make 2D games.
I just recently discovered HaxeFlixel, and I LOVE it! I came from making games in AS3 using Flixel, and now I'll probably never go back!
So, to attempt to answer your question (and the way I understand it):
Haxe is sort of the bottom layer. It's the programing language that can be compiled into Flash, Windows, Android, iOS, etc, etc, etc.
OpenFL is a software development kit which uses Haxe to make it easier and smoother to get games to work via Haxe and allow you to easily harness the power of Haxe's compatibility while not having to deal with a lot of the hassle and problems that you can get into. It takes care of a lot of the basic stuff for you and makes it easier to code.
HaxeFlixel is a 2D Game framework based on a combination of Adam Atomic's Flixel for AS3 and Flixel Power Tools by Photon Storm. It makes it easier to make 2D games in almost the same type of code as in AS3/Flixel.
When just starting out, you should only need to worry about the highest level, which in your case is HaxeFlixel.
So, to summarize a bit: Haxe is a powerful programing language. You can try to figure out how to code with it 'as-is', which is complicated, or you can use one of a number of libraries to make it easier - OpenFL is one of these libraries.
You can use OpenFL on its own, and code a game with it, or you can use one of a number of different frameworks to make it easier - HaxeFlixel is one of these frameworks. There's also the Starling and HaxePunk frameworks which have their own pros and cons.
Opinion Time!
I highly recommend sticking with HaxeFlixel - since it was so similar to Flixel, I managed to pick it up and learn how to use it, and made this complete game in exactly 1 month and released a Flash, Windows, and Android version all on the same day - which is outstanding considering I had not touched Haxe before, and had never had time to even start looking at Android Development before. That game's source code, by the way, is completely open source, so feel free to dig in and see how I did stuff.
The community for HaxeFlixel is also pretty amazing and people will help you out and answer questions.
It's really not too hard to jump in and start working with HaxeFlixel:
http://haxeflixel.com/documentation/getting-started/
Follow those steps and you'll at least have a Hello, World! up and running in minutes (excluding the time it takes to download and install all the stuff). Like I mentioned earlier, until you're more comfortable with it, just follow the directions for Haxe and OpenFL but don't even think about it for now!
Good luck! And let me know if you make it anywhere or not!
I'm currently writing an embedded application for J2ME environment (CLDC 1.1 configuration and IMP-NG profile). Being spoiled by all those new features in JVM-based languages (Groovy, Scala, Clojure, you name it), I was considering using one of them for my code.
However, most of the mentioned languages require pretty decent JVM environment. Most so-called "dynamic" languages require the VM to have reflection. Many ask for annotations support. None of the above features are available under J2ME.
From what I found, Xtend looks like a viable options, as its compiler spits out plain Java, not bytecode, and doesn't require any library for runtime needs. Of course, the generated Java code also must meet some requirements, but Xtend webpage looks promising in this regard:
Xtend just does classes and nothing else
Interface definitions in Java are already nice and concise. They have a decent default visibility and also in other areas there is very little to improve. Given all the knowledge and the great tools being able to handle these files there is no reason to define them in a different way. The same applies for enums and annotation types.
That's why Xtend can do classes only and relies on interfaces, annotations and enums being defined in Java. Xtend is really not meant to replace Java but to modernize it.
Am I right and it is possible to compile Xtend-generated code for J2ME platform, or there are some constructs that will not work there?
Alternatively, can you recommend any other "rich" Java modification language that can be run on J2ME?
Update: Knowing that the "compiler" producing results as another source code is called transcompiler, one can also find Mirah, a tool which requires no runtime library and specific Java features.
Xtend's generated code uses google guava heavily. If that is compatible to the J2ME, Xtend could be the language of your choice. I'm not aware of anything that prevents from using it on other platforms that provide a dedicated development kit (e.g. Android).
In addition to being able to generate Java source, Mirah recently added support for javac's --bootclasspath option, which allows you to generate your bytecode against a non-standard version of the java core classes, e.g. LeJOS.
It's still a little fresh, but it'd be nice to have more people using it on different javas.
My friend and I are looking to play around with building a browser game (e.g. Farmville) from a linux environment. Flash seems to be the way most browser games are built, but from what I google flash programming can't be easily (at all?) done from linux. Java seems like the leading candidate, but I am rather bamboozled by all the options out there. What platforms should I consider?
As an aside, I have a strong-ish C++ background and some professional experience with Python.
For browser based games, there are 2 main options if I remember correctly:
Flash, as you've already noted is the most common options. Usually this is done using adobe's software (around $200) or just an actionscript compiler (which is more programming like then normal flash). For Linux, your best bet may be: Burrito 4 Linux with the flashpunk libraries for your game engine.
Second most common option is Java, in which case you'd have to use the .applet package for.
Since you have C++ experience, I would recommend trying a flash actionscript compiler. I've personally used FlashBuilder, but I could not run it in Linux, so your next best option is Burrito 4 Linux noted above.
Hope this helps!
Use the FREE adobe flex SDK on linux.
Gives you flash/flex libraries, and command line tools to compile SWFs, flex, and air applications.
I've been playing around with Direct3D 11 a little bit lately and have been frustrated by the lack of documentation on the basics of the API (such as simple geometry rendering). One of the points of confusion brought on by the sparse documentation is the (apparent) move away from the use of effects for shaders.
In D3D11 all of the effect (.fx) support has been removed from the D3DX libraries and buried away in a hard to find (sparsely documented, of course) shared source library. None of the included examples use it, preferring instead to compile HLSL files directly. All of this says to me that Microsoft is trying to get people to stop using the effect file format. Is that true? Is there any documentation of any kind that states that? I'm fine doing it either way, but for years now they've been promoting the .fx format so it seems odd that they would suddenly decide to drop it.
Many professional game and graphics developers don't use the effects interfaces in Direct3D, and many of the leading game engines do not use them either. Instead, custom material/effects subsystems are built on top of the lower-level shader and graphics state state management facilities. This allows developers to do things like target both Direct3D and OpenGL through a common asset management pipeline.
The main issue is that the fx_5_0 profile which is needed to compile Effects 11 shaders with the required metadata is deprecated by the HLSL compiler team. The runtime is shared-source, but the compiler is not. In the latest D3DCompiler (#47) it emits a warning about this. fx_5_0 was never updated for some newer language aspects in DirectX 11.1 and 11.2, but works "as is" for Direct3D 11.
The second issue is that you need D3DCompile APIs at runtime to make use of Effects 11. Since D3DCompile was 'development only' for Windows Store apps for Windows 8.0 and Windows phone 8.0, it wasn't an option there. It is technically possible to use Effects 11 today with Windows Store apps for Windows 8.1 and Windows phone 8.1 since D3DCompile #47 is part of the OS and includes the 'deprecated/as-is' compiler support for fx_5_0, but this use is not encouraged.
The bulk of the DirectX SDK samples and all the Windows Store samples avoid use of Effects 11. I did post a few Win32 desktop samples that use it to GitHub.
UPDATE: With the release of the legacy Microsoft.DXSDK.D3DX NuGet repacking of the original D3DX #43, I was able to update the rest of the legacy DirectX SDK samples so they can build with the modern Windows SDK and not require the legacy DirectX SDK to be installed. Most of the Direct3D 9 and Direct3D 10 samples, and a few Direct3D 11 samples, all use legacy Effects. See GitHub.
So in short, yes you are discouraged from using it but you still can at the moment if you can live with the disclaimers.
I'm in the exact same position, and after Googling like crazy for even the simplest sample that uses D3DX11CreateEffectFromMemory, I've too come to the conclusion that .fx file support isn't their highest prio. Although it is strange that they've added the EffectGroup concept, which is new to 11, if they don't want us to use it.
I've played a little with the new reflection API, so it looks like it will be pretty easy to hack together your own functions for setting variables etc, in essence creating your own Effect-class, and the next step is going to be to see what support their is for creating render state blocks via the API. Being able to edit those directly in the .fx file was very nice, so hopefully something like that still exists (or, at worst, I can rip that part from the Effect11 code).
There is an effect runtime provided as a sample in the DirectX SDK that should be able to help you to use .fx files.
Check out the directory: %DXSDK_DIR%\Samples\C++\Effects11
http://msdn.microsoft.com/en-us/library/ff476261(v=VS.85).aspx
This suggests that it can take a shader or an effect.
http://msdn.microsoft.com/en-us/library/ff476190(v=VS.85).aspx
Also, what is the difference between a shader and an effect?