|
Viewing 41 to (2135 Total) |
|
Hi again 
The first concept is a "class" ... unfortunately Lua does not have this concept, but it exists in a lot of languages.
A class is a collection of properties and functions. When you create a "new" instance of the class, you have a brand new object, with its own copy of each of these values. For example, if you create a class called "Weather", and give it a public variable called "type", then you could check its type using "var weather = new Weather ()" and checking "weather.type"
That's the first thing you might try playing with. You can also "extend" a class with new functionality. For example, you could create a "Rainy" class, that extends "Weather", and in its "new" function (which is called when a new instance is created) you could set the type to "very wet". When you check the "type" of a "new Rainy()" you will know that it is wet.
Classes are also compatible, so if you create something that expects a "Weather" type, you could also pass a "Rainy", since it extends Weather. There are also interfaces, so you can get this functionality without requiring inheritance, but standard class-based inheritance is the most common.
In order to make things clean and prevent collision, you can put classes into new folders. Instead of being in the top-level of your source directory, you could have "com/meteorologist/weather/Weather.hx". In order to work, you would want "package com.meteorologist.weather;" at the top of the class file. This is a lot to write, so instead of having to do "var weather = new com.meteorologist.weather.Weather ();" you can add "import com.meteorologist.weather.Weather;" so that every time you reference "Weather" it knows which one you are talking about.
Take a look at some of the samples listed on the download page, such as "nme create DisplayingABitmap", "nme create AddingAnimation", "nme create HandlingMouseEvents", etc, which are good simple examples to help see what code looks like
Posted on May 10, 2013 at 5:02 PM
|
|
You might try "nme create project MyExampleProject" somewhere, to compare how our project template varies from the one bundled with FlashDevelop. A lot of the above is unnecessary
import flash.display.Sprite;
class Main extends Sprite {
public function new () {
super ();
}
}
There's a concept called the "display list" that works in NME, similar to Flash. A lot of people tell you that the display list is bad, but it's a great paradigm and has a lot of flexibility built-in. It's just when you want "fastest" performance that you want to be balanced in how much you use it.
An "nme.display.DisplayObject" is something that can be seen on the display list, and an "nme.display.DisplayObjectContainer" extends the DisplayObject class with support for having children, or holding other display objects inside of it, which is important for creating a logical structure.
"nme.display.Sprite" is the simplest object that extends "nme.display.DisplayObjectContainer", and is the bread-and-butter for most development. It can have children, it has a "graphics" property (and instance of "nme.display.Graphics") which allows drawing graphic primitives, such as lines and fills, and most importantly, it can handle mouse interaction, unlike other display objects like the "nme.display.Bitmap" class. As a result, it is fairly common to create something like a Bitmap and put it inside a Sprite so you can click and interact with it.
As a result, a normal project usually extends the Sprite class. This means that it has all the qualities of a Sprite, but you are going to extend it with your own functionality.
"public static function main" is an entry point into your application, but NME does not require this by default. If it is not present in your code, it will create a new instance of your class and add it to the display list, similar to the FlashDevelop template above.
For mobile, you can enable multi-touch mode and listen for TouchEvents, if you want multi-touch, but by default an ordinary MouseEvent will work fine, and should work on all platforms. I believe you can also receive MouseEvents in multi-touch, but it won't tell you the touch ID, which you may need for two-finger gestures or other more advanced behaviors.
I hope this helps, please feel free to ask any question, no matter how small
Posted on May 10, 2013 at 4:33 PM
|
|
When you call BitmapData.draw(), it uses software to create a new BitmapData of the object. This isn't bad if you do it sometimes, but since its software-only it isn't the fastest method. Actually, when you look at the internals of a native Bitmap, it currently uses drawRect() to do it, so using a Bitmap on the display list is similar to drawing a rectangular fill and also comparable to a drawTiles() call with only one object. It's when you batch multiple objects off the same atlas that drawTiles() pulls far ahead, since copying textures to the GPU is the slow part.
Posted on May 10, 2013 at 4:22 PM
|
|
Shouldn't the database be a binary file? What happens if you treat it as bytes?
Posted on May 10, 2013 at 2:46 PM
|
|
It took longer than I expected, but 3.5.6 should be up in haxelib for Haxe 3. Please let me know if it works for you!
Posted on May 10, 2013 at 2:19 PM
|
|
I am going to publish NME to haxelib for Haxe 3 in a minute... when I do, you should be able to have a clean Haxe 3 and Neko 2 install, and "haxelib install nme"
The only thing that will be missing is the "nme" alias for "haxelib run nme", but "haxelib run nme setup" should create it for you if you run it after the install
Stay tuned
Posted on May 10, 2013 at 12:04 PM
|
|
Okay, bear with me.
Soon there are going to be updates that make it much simpler to go from a release to a dev build, but here's what you need now:
haxelib githttp://github.com/haxenme/nmedev...
haxelib install svg
nme rebuild tools,windows
(still using Haxe 3, Neko 2 and your above haxelib setup)
EDIT: Sorry, the forums are removing the space after "git" in the first command and added ellipses
Posted on May 10, 2013 at 9:15 AM
|
|
Roughly speaking, these are the fastest methods on Flash, from fastest to slowest (without using Stage3D):
copyPixels() > display list > drawRect() > drawTriangles()
When targeting native, it looks more like this:
drawTiles() > drawTriangles() > drawRect() > display list > copyPixels()
The order is basically reversed, Flash Player uses a software renderer, which is happiest dealing with blitting pixels (again, unless you use Stage3D for hardware, but that may be slower depending on the machine and library you use). When we target native, all of these operations are using OpenGL acceleration, which is happiest dealing with geometry and not individual pixels, which allows calls such as the display list or drawTriangles() to run faster than manipulating pixels, but the "very fastest" is doing this in a batch operation, such as drawTriangles() or our own drawTiles()
There is a library called "TileLayer" which abstracts copyPixels() for Flash and drawTiles() for native under one drawing API, which may be helpful. Otherwise, feel free to use your own code -- it isn't necessarily too hard to customize the rendering layer.
Posted on May 10, 2013 at 9:06 AM
|
|
A couple other thoughts, you can use "haxe.Serializer" and "haxe.Unserializer" if you need to take a lot of data and collapse it down to a String. That's one other format of aggregating game data into a single simple value. There are also "uncompress" methods on ByteArray, which should handle deflate, gzip and lzma compression formats, so that's also another possible way to handle compression.
Posted on May 10, 2013 at 9:00 AM
|
|
Haxe 3 added a "Map" class, so you may need to use Haxe 3 to use this version of the format library... though you may be to do your own version, such as "typedef Map<String, T> = Hash<T>;" or "typedef Map<Int, T> = IntHash<T>;"
Haxe 3 also added "haxe.zip.*" as a standard package, which should support Neko and C++ (the older Haxe release had only Neko support built-in)
Posted on May 10, 2013 at 8:58 AM
|
|
Hi!
It could be possible to run NME on any of these consoles, since we can go to C++ directly, with the time investment to support the platform, we could have it running on a console. The problem is that these businesses are strict about development kits and will only provide them to certain authorized companies, particularly ones they have decided have an interesting enough title for their platform.
There are some exceptions... the barrier for entering XBLA is lower, which uses C# and XNA (or did, before Microsoft cancelled XNA?), and PlayStation Vita has an open SDK based on C# as well, which one NME developer has actually used to get his game ported there (check for rymdkapsel, which was just released). It uses the Haxe beta C# target, plus some custom implementation of backend classes, such as DisplayObject and Sprite
Wii U announced a new "Web SDK" which will allow HTML, CSS and JavaScript to create Wii U content, but I wonder if this is mostly for apps, and not games, because canvas suffers from performance problems at high resolution. I don't imagine they have WebGL support, but if they did that could be viable. So far, Sony seems to be the furthest in reaching out to independent developers, though all companies say they are moving in this direction.
Posted on May 10, 2013 at 8:50 AM
|
|
Okay, sounds like you're almost there.
Can you check which version of NME you are using? Run "haxelib list" to see.
In the dev builds, we should have addressed this problem, so this may indicate you are setup to use something older, like 3.5.5.
Posted on May 10, 2013 at 8:45 AM
|
|
You can also use array.slice(), or set the invalid tile IDs to -1
Posted on May 09, 2013 at 11:52 PM
|
|
Are you "zooming out" as a part of your gameplay, or is this something that happens only once, like at the beginning of a level?
If it is the former, then I think you probably do want to get your game working properly at the "zoomed out" size, then see if you can zoom in. Again, in this scenario, you are technically never zooming out -- you just start at a broader scale.
If this is only an effect, like at the beginning of the level, you could consider creating an intro animation by hand that plays, or using an effect such as black coverage with a circle around the location of your player, so as you zoom in you see less and less black and the circle expands until it goes off screen. This would still give the feeling of zooming in without requiring that you show any more of the game world than normal
Posted on May 09, 2013 at 11:50 PM
|
|
I'm not sure how to translate it to what API Stencyl may expose, but the basic concept is to alter both the scale and position of your full game container, is probably the easiest approach. Imagine you take the entire screen, and begin making it larger... that zooms in. While that occurs, you may also need to change the upper left point, in order to remain focused on the center of the content, or to follow the focus you intend to illustrate. However, if you intend to begin by being zoomed out, it will be trickier because your content area will have to begin larger than normal.
If you take the full screen and zoom out, you'll see the edges, so if you can force the display area to be larger than the device screen, you can begin zoomed out until you reach the point you want.
I hope this helps? I'm glad to help how I can, though its difficult to translate to the specifics of what Stencyl may be exposing or the paradigms they use in constructing their app
Posted on May 09, 2013 at 10:02 PM
|
|
Okay, it sounds as if there may be some weirdness going on with Haxe 2 and Haxe 3 both on your system... Haxe 2 under "C:\Motion-Twin" and Haxe 3 in Program Files, I'm guessing?
It is possible that from the command-line you have Haxe 3, then from FlashDevelop you have Haxe 2, or something like that. I would try and get to having one Haxe install and align on that. NME 3.5.5 is going to install Haxe 2 and Neko 1, but unless you must, I would recommend moving to Haxe 3 and Neko 2 now, they enable some cool stuff that's going to be released
Posted on May 09, 2013 at 9:46 PM
|
|
Oh sorry, mistype. Is there a "RunScript.hxml" file in the folder? "haxe RunScript.hxml"?
Running "haxe" or "neko" (with no arguments) will tell you what version you are running
Posted on May 09, 2013 at 7:17 PM
|
|
Oh sorry, mistype. Is there a "RunScript.hxml" file in the folder? "haxe RunScript.hxml"?
Running "haxe" or "neko" (with no arguments) will tell you what version you are running
Posted on May 09, 2013 at 7:17 PM
|
|
Have you seen these performance scores?
http://esdot.ca/site/2012/runnermark-scores-july-18-2012...
Posted on May 09, 2013 at 6:21 PM
|
|
Are you using Haxe 3 and Neko 2?
If you are not, try running "haxe CommandLinemhxml" from the "tools/run-script" directory, as the "run.n" may be compiled for Neko 2 right now (NME has two scripts, the "run.n" boot script and the actual command-line tools)
Please let me know how it goes
Posted on May 09, 2013 at 5:59 PM
|
