|
Viewing 1 to (51 Total) |
|
If anyone's interested, I experimented with this feature a few months ago (see this commit). The speed gain was really minimal (almost null even with massive arrays) compared to an array.slice(). The only difference was with the GC usage, especially in Flash.
Posted on May 10, 2013 at 3:39 AM
|
|
Hi there !
I used Haxe/NME for LD26 so I figure I should share it here as well 
It's called (Follow the) Line. Click the screenshot to view the entry !
Posted on April 29, 2013 at 6:38 AM
|
|
Please stop using weird forum systems, and use a mature one (Vanilla is not, it gets messy very quickly and it's quite restrictive as Jon said - Jon from Stencyl, right ?). My vote goes to SMF...
Posted on August 30, 2012 at 3:29 AM
|
|
Hi,
Unless I'm mistaken, there's no way to set a different scale value on X & Y using drawTiles(), which is very limiting.
Is there any way we could change the tile array from :
[ x, y, tID, scale, rotation, ... ]
... to :
[ x, y, tID, scaleX, scaleY, rotation, ... ]
... before it's too late and NME takes over the world ? Such a feature would help a lot, allowing to scale on both axis independantly, flipping sprites for free (scaleX = -1, thus saving memory), etc.
Posted on April 07, 2012 at 3:31 AM
|
|
I'm in the same boat. Still haven't found a solution to this problem yet. There a shouldRotateInterface() in the Stage class but it doesn't seem to work or I don't know how to use it correctly. I made a thread a while agohttp://www.haxenme.org/community/forums/programming-with-haxe/orien... and I've seen some posts about that so it *should* work...
Posted on February 10, 2012 at 1:07 AM
|
|
1) Yep, actually the NSUbiquitousKeyValueStore is stored on disk until "synchronize" is called, and if there's no internet connection, it'll wait patiently until it can be synchronized again. At least that's what I've read in several Stackoverflow topics and some tutorials, like this onehttp://www.techotopia.com/index.php/Synchronizing_iPhone_iOS_5_Key-...
2) Yes, it does add a few things to the project.pbxproj file and also adds a new small ProjectName.entitlements xml file next to the Info.plist. I've prepared two quick Xcode projects, one with iCloud enabled, the second one without. You can find a zipball here :http://dl.dropbox.com/u/11859630/vrac/iCloudDiff.zip...
I don't know about it being enabled by default. Some people may not want to enable iCloud, so IMO it should be disabled by default and there could be an option in the nmml file to enable it.
If you need anything else, don't hesitate to ask. I have all the tools here, but only a basic understanding of all this Objective-C mess
Also, is there an equivalent to iCloud on Android ?
Posted on February 07, 2012 at 11:07 AM
|
|
Hi,
Would an iCloud support be doable for the iOS target ?
Here's what I think could be done after browsing the native sources (I'm no C++ / Objective-C expert, so please correct me if I'm saying stupid things) :
Instead of a complete iCloud support (which would mean quite a lot of work), we could add its support at least for the SharedObject. From what I can see, the iOS target uses NSUserDefaults to store the ShareObject, which is perfect because it works exactly the same way as NSUbiquitousKeyValueStore (Apple's NSUserDefaults equivalent on iCloud, working with key-value).
So I think the only file that needs changes in NME is System.mm in "/project/iPhone" (functions GetUserPreference, SetUserPreference, ClearUserPreference).
I found this on the webhttp://github.com/sdarlington/SDCloudUserDefaults... It's an abstraction layer on top of NSUserDefaults and NSUbiquitousKeyValueStore. As you can see, it looks "simple" enough and the code is quite small.
Now, there are two problems I can think of. The first one is that iCloud is only supported on iOS5. So every iCloud related functions must have a way to check if iCloud is available or not and if it has been configured. For the later part, I found this piece of code that seems to do the trick :http://stackoverflow.com/questions/8957036/simple-icloud-implementa... And for the former, my Objective-C knowledge is very limited so I don't know how to check for an API presence.
The second problem is that to use iCloud, you need to add an Entitlement in Xcode. I don't know if it could be handled in the nmml file. And obviously there should be a NME flag to enable/disable iCloud support.
Any thoughts ? Does that make any sense ? Could it be done ? Or did I miss something ?
Posted on February 07, 2012 at 5:46 AM
|
+1 for OpenGL batch tile rendering. This would make NME seamless across all targets for display!
Unless I misunderstood you, NME already has that feature (for cpp desktop/mobile targets only though). See the nme.display.Tilesheet class and the NME sample "20-Tiles".
Posted on February 05, 2012 at 5:36 AM
|
|
I'd love this as well.
Posted on February 02, 2012 at 3:27 AM
|
|
In the mean time, TextField.htmlText seems to be working correctly (flash & cpp).
Posted on January 28, 2012 at 7:33 AM
|
|
Hi,
The TextField.setTextFormat() is broken on CPP target and can lead to serious crashes (segfault without stack trace).
Here's a code sample :
console.text = "This is a text example.\nLet's make it crash, shall we ?";
console.setTextFormat(new TextFormat(font.fontName, 8, 0xff0000), 15, 22);
What I'm doing here is setting the TextFormat from the index 15 to 22 to a red colored font. On flash target, the following text will turn red :
example
On CPP :
example. Let's make it
As you can see the endIndex parameter on CPP is actually startIndex + endIndex, and as you can imagine, it'll crash the whole application if it goes out of text range (no Error thrown). A workaround for CPP would be :
[quote]console.text = "This is a text example.\nLet's make it crash, shall we ?";
console.setTextFormat(new TextFormat(font.fontName, 8, 0xff0000), 15, 7);[quote]
Except it doesn't work either, because the TextFormat will only be applied if endIndex > startIndex.
I don't have a fix because I don't have everything I need nor the time to recompile NME, but I guess it should be a pretty easy job for anyone working on the SVN version (line 146-190 file TextField.cpp).
Posted on January 28, 2012 at 7:25 AM
|
|
So, did you find a working trick using an event listener ? Because I'm currently working on a game that uses the keyboard in a few different places and I'll really need to come up with a workaround if it's not fixed when the game gets released...
Posted on January 24, 2012 at 12:43 PM
|
|
In your "NME_test.nmml" file, make sure the package attribute in the app tag has 3 segments, like so :
<app [...] package="com.something.stuff" [...] />
More infos about the nmml file :http://www.haxenme.org/developers/documentation/nmml-project-files/...
Posted on January 24, 2012 at 10:44 AM
|
|
About the vsync : activating the vsync will synchronize your application framerate with your screen refresh rate which will avoid screen tearing (the "half frame" bug).
But... Are you sure it's tearing and not rounding error on tile placement ? I never had tearing with drawTiles...
Posted on January 23, 2012 at 3:38 AM
|
|
I believe a fix has been posted 5 or 6 days ago in the SVN repo.
Seehttp://code.google.com/p/nekonme/source/diff?spec=svn1242&r=124...
Posted on January 22, 2012 at 1:03 AM
|
|
The centerPoint is relative to the top-left corner of your tile rectangle (so no, it's not absolute to the whole bitmap). Which means that if you have a 32x32 tile and you need to put the centerPoint in the middle, it'll be on 16x16. At least, in the CPP target. Haven't tried the Flash target yet, but it should be the same.
Posted on January 07, 2012 at 8:27 AM
|
|
I've noticed this as well, but I've made myself a small "Key" singleton so I don't have to worry about it anymore.
See, for example, the Key class in Haxepunk : https://github.com/MattTuttle/HaxePunk/blob/master/src/com/haxepunk/utils/Key.hx
(Although it doesn't fix the numpad keys from being the same as the normal keys).
Posted on December 15, 2011 at 2:43 PM
|
I have also heard that copyPixels can work faster with small reads/writes, but that beginBitmapFill and drawRect have a faster fill rate for larger textures, and that clearing a Graphics object is faster than clearing BitmapData.
From my own tests, this is indeed true.
One (very nice) thing about this approach is that we can also remain consistent with the C++ target, using a Graphics object instead of needing a Bitmap.
Yeah I guess this is the main argument, it's best to keep things simple.
I guess we'll see soon enough if the drawRect method is fast or not. I'll test it as soon as the next NME beta build is available.
Posted on December 15, 2011 at 12:00 PM
|
How do you feel about calling tileSheet.drawTiles (mySprite.graphics, ...); instead of mySprite.graphics (tilesheet, ...); ?
This. Do it. It would be so much better and cleaner (also for the cpp target).
Also, I was curious if you guys had rendering code on-hand to make sure this runs as fast as possible.
I actually have a graphic engine which exclusively uses drawTiles for the rendering (and features like automatic sprite batching, low memory footprint, etc). It's very fast on cpp/windows and cpp/ios. I can't compile against nme-svn right now, but be sure I'll test it asap on flash target with this new drawTiles method.
I just took a look at the code on (http://code.google.com/p/nekonme/source/browse/trunk/nme/display/Ti... ). Is there a reason you're using a fillBitmap with a drawRect instead of a faster copypixels ? I know copypixels can't do transforms, but I believe something like this would be faster (needs to be benchmarked, but I'm almost sure) :
if (no scale and no rotation and no colortransform) dest.copypixels(...);
else dest.draw(...);
Obviously, this would mean keeping a BitmapData reference for each Graphic to draw tiles on. But it should be faster.
Posted on December 15, 2011 at 4:30 AM
|
|
I'm interested in this as well. Swipe is easy to emulate, but Pinch, Zoom and other multi-finger gestures can be a pain in the ass to get correctly.
Posted on December 12, 2011 at 4:26 AM
|
