|
Viewing 1 to (24 Total) |
|
Hey, I wrote a Keyboard tutorial for Haxe+NME last week, and posted it on my website...
Haxe Keyboard Tutorial
Of course, after I finished it, I realized that there's already an effective Keyboard library available on Haxelib. Still, someone might find it useful.
Posted on March 20, 2012 at 2:49 PM
|
|
The issue of game engines with Haxe is one that I've looked into several times. I know that HaxePunk (a port of FlashPunk) seems to be making solid progress, and may be compatible with multiple targets at this point. I believe there is also a Flixel port, but I'm not sure what level of progress they've made on it. I started working on a Flixel port last year, but ran into too many difficulties. Now that I'm a bit more familiar with Haxe, I could try again, but I think there might still be too many barriers.
The problem of porting flash-focused game engines to Haxe+NME is that most of them focus too heavily on Flash's way of doing things. The asset loading and handling in Flixel comes to mind. Asset loading in NME is much simpler, has automatic pre-loading, and a port would require stripping out all of Flixel's loading solutions.
Then there's also the issue of repetition. FlashPunk has it's own tweening classes. But the Haxe+NME libraries Actuate and Feffects already cover all the tweening you would ever need, and are already working for Haxe+NME. Ditto for collision detection.
I've been working on a simple framework as opposed to a full-fledged game engine. My objective is to provide some basic game management, and then pick and choose from other libraries for individual projects. Haxelib's install feature makes acquiring effective libraries as painless as possible.
Posted on March 20, 2012 at 2:44 PM
|
|
I've been testing some of my applications in development in HTML5 using Jeash. I've been running across a bit of an issue with the Mouse events. Performance for mouse events in jeash seems to be a bit spotty. The mouse over and mouse out events don't always hit, they have issues with the drawing api, and I found that they don't play nice with Sprites that aren't oriented to the upper left-hand corner. I'm writing a card game that relies heavily on mouse interactions, but the HTML5 target just isn't working.
Posted on March 19, 2012 at 11:12 PM
|
|
I know that a lot of the attention for 3D rendering is probably moving toward toward other areas. But I tried to get Sandy 3D working with a project recently. I found that it seemed to compile properly for Flash and HTML5, but I started running into compilation errors with CPP. Has anyone else gotten Sandy working with the CPP target?
At first it was throwing an error related to a function that exists in the TextField class for the flash target, but not for the CPP target. When I threw in a target conditional, it began throwing an unspecified error for the SoundTransform.cpp file.
Huh...after poking around the Sandy 3D files, I think I see what the issue is. No one ever went in and optimized Sandy 3D for the non-flash targets. I came across several fairly lazy programming errors in the Sandy 3D files. Unfortunately, I don't think that my technical expertise is up to the challenge of debugging Sandy 3D. The library is just too extensive and complex for me to wrap my brain around in anything approaching a realistic time frame. I believe that it could be re-worked to run properly on the CPP target, but I don't think I'm the one to do it.
It would be wonderful if one of the original Sandy 3D developers tackled the challenge. But for the time being I'm going to have to abandon any hope of using it.
Posted on March 14, 2012 at 12:55 AM
|
|
I'm not sure what the protocol is on Android. But I do know what the protocol is on iOS, and that is "Don't Do It." There is a way to "exit" apps in NME.
#import nme.system.System;
System.exit(0);
Pop those two lines of code into your application, and it will close. However, this approach DOES NOT WORK on iOS. If you attempt to use this code in your iOS project, it will freeze your simulator and cause your program to crash. Only the main iOS button is used to exit out of applications. (to my knowledge)
Posted on February 21, 2012 at 12:05 AM
|
|
Yes, URLLoader works fine with HTML5, and it's always worked well with the other targets I've tried it with.
Please note, if you are running the URLLoader class, you have to be running your HTML5 app off of a webserver. If you try to run it off of a regular machine, it will throw an error, due to security concerns.
If you don't currently have a webserver, I would recommend looking into WAMP or XAMP.
Posted on February 03, 2012 at 2:26 PM
|
|
Okay, I'm going to try to help you out here. I've run into this problem myself, and cooked up a solution that works pretty well for me.
if (_fullScreen)
{
_fullScreen = false;
Lib.current.stage.displayState = StageDisplayState.NORMAL;
_gameMain.scaleX = 1.0;
_gameMain.scaleY = 1.0;
_gameMain.x = 0.0;
_gameMain.y = 0.0;
} else {
_fullScreen = true;
Lib.current.stage.displayState = StageDisplayState.FULL_SCREEN_INTERACTIVE;
var xScaleFresh:Int = Math.floor(cast(Lib.current.stage.stageWidth, Float) / cast(PstG.GameWidth, Float));
var yScaleFresh:Int = Math.floor(cast(Lib.current.stage.stageHeight, Float) / cast(PstG.GameHeight, Float));
if (xScaleFresh < yScaleFresh)
{
_gameMain.scaleX = cast(xScaleFresh, Float);
_gameMain.scaleY = cast(xScaleFresh, Float);
}
else if (yScaleFresh < xScaleFresh)
{
_gameMain.scaleX = cast(yScaleFresh, Float);
_gameMain.scaleY = cast(yScaleFresh, Float);
} else {
_gameMain.scaleX = cast(xScaleFresh, Float);
_gameMain.scaleY = cast(yScaleFresh, Float);
}
_gameMain.x = (cast(Lib.current.stage.stageWidth, Float) / 2.0) - (_gameMain.width / 2.0);
_gameMain.y = (cast(Lib.current.stage.stageHeight, Float) / 2.0) - (_gameMain.width / 2.0);
}
_fullScreen is a boolean variable I use to determine whether or not the game is currently running in fullscreen
_gameMain is the root sprite for my HaXe application
PstG is a class with largely static variables that I use to keep track of information that doesn't change, in this case, the original pixel width and height of the game
This code was placed within a function that I use to toggle fullscreen on and off. It takes the original defined width and height of my application, and scales up the root sprite object to the nearest integer value without exceeding the size of the screen, and maintaining the aspect ration of the original application. It even works for applications that are oriented differently than the screen they are on. (games designed to have a vertical aspect ratio will remain that way, even when scaled up in fullscreen) The main thing is that I handle scaling for the game myself, as opposed to relying on the built-in scaling.
Posted on February 03, 2012 at 1:55 PM
|
|
I've been compiling NME projects on my Mac Mini, and have run across a bit of an odd bug. Whenever I try to change the StageDisplayState to fullscreen, it crashes the program. I am compiling for Mac OSX specifically, not iOS. (where fullscreen is the assumed state)
Fullscreen works fine everywhere else I've tried it. (Flash, Windows, and Linux) It just seems to crash the Mac OSX target. Has anyone else run across a similar issue?
Posted on February 01, 2012 at 7:21 PM
|
|
I was under the impression that smartphone applications exit when you hit the "exit" button on the phone. I know for a fact that if you attempt to use the normal "exit" function on the iOS simulator, it throws an error and the simulator locks up. For the iPhone and iPad, that particular functionality is not permitted.
It might work differently on the Android, but perhaps not.
Posted on October 31, 2011 at 2:04 PM
|
|
If I'm not mistaken, you have to re-assign the text for the text field when you are changing text transform options.
Posted on October 25, 2011 at 2:52 PM
|
|
Yeah, using Actuate looks like it will be the best solution for keeping everything cross-platform. My experience with using Actuate so far has been quite positive, it's a great little tweening library. The SDL mixer just doesn't include a property or method for retrieving a "position" value from playing sounds. From what I read, this is due to the wide variety of sounds that the SDL Mixer supports. Some of them simply don't work in a way that would allow for such a value to be extrapolated.
This isn't exactly the ideal solution. I'm planning on cooking up a lip-syncing solution, and having that position value would have been great. Once I do get the Actuate approach working I'll post a link so that people can test the performance.
Posted on October 13, 2011 at 4:15 PM
|
|
I'm working on a project that involves sound control. I've noticed that the position property of the SoundChannel class does not seem to be working for the C++ targets. It always returns the value 1.0 no matter what. In the flash target, it runs as expected, and returns the current position of the sound being played.
Is this something that just hasn't been addressed yet, or could it be resulting from the way in which I am encoding my audio? I've noticed that not all sound files will run on the iPhone target, and I suspect that the encoding process might be part of the problem.
Posted on October 12, 2011 at 10:12 AM
|
|
I've discovered that when using Actuate with the windows NME target, setting a tween to adjust the scaleX property of a sprite to 0.0 will cause the program to crash.
Now, I've found that you can change the scaleX value to be anything that is NOT 0.0. 0.0001 works just fine. But if you try to tween a Sprite's scaleX value to zero, it will crash the program.
It's not really a deal breaker for me, as getting close to zero is all I'm really interested in. But I did notice that this error only shows up for C++ compiling, and isn't present when compiling to flash.
Posted on October 11, 2011 at 10:02 PM
|
|
Unfortunately, I was not able to get a functioning Android test environment set up on my computer over the weekend. I tried, and installed all the suggested software and development kits. But at the end of the day I was not able to get Android apps building. Since I know nothing of Android development at this point it is hardly surprising.
On the plus side, I learned a lot about full screen settings, and am well on my way toward integrating full-screen toggling into the framework. I'm also working on scene transitions, and will probably incorporate some minor fade-in/fade-out transitions by default.
I've updated the trial above with my latest changes to the fullscreen and scene-switching features.
Posted on October 03, 2011 at 5:51 PM
|
|
I'm afraid I can't help much with up-scaling re-sized graphics. That is often something that you just have to accept. I would point out that avoiding the use of anti-aliased sprites would be a good way of avoiding issues like this. Sticking to pixel-style graphics seems to be the way to go for resizing and upscaling. The difference just isn't as noticeable when everything is hard-edged pixels from the word go.
On the multiple resolutions, I can give a bit more assistance.
import flash.Lib;
Lib.current.stage.stageWidth;
Lib.current.stage.stageHeight;
These lines of code are your shortcut to successfully resizing your applications. I've been using them over the past few days to add fullscreen toggling to my framework. When you aren't in full-screen mode, these properties will return the value of the window you are running in. If you ARE in full-screen mode, these properties will return the exact pixel dimensions of the monitor you are running them on.
From there the ball is in your court. At the moment I've been using Flash's built-in stage scaling, combined with a little re-positioning code of my own. (to center my application in full-screen mode) If you would prefer, you can set the flash scaling to not scale at all, and just scale your application's root sprite object yourself relative to the screen's resolutions. You could even throw in conditionals so that your application will only scale up to an exact multiple of its original size. (which will likely minimize scaling artifacts)
Posted on October 03, 2011 at 5:43 PM
|
|
The sprite sheet is my own custom creation. It is flexible enough to allow for sprites composed of rectangles of any potential width and height, not just strict squares. It also allows for full multi-row sheets, as opposed to just strips. I thought about adding the ability to have frames of different sizes, but ultimately decided that feature probably wasn't worth the trouble. Animations are handled in a fashion very similar to how they are in Flixel. (defined as an array of integers with a provided framerate)
At the moment, it is running correctly and identically on Flash, Mac OSX, iOS, Windows, and Linux. I haven't begun testing on Android yet, it just wasn't a priority for me. One of my friends is pushing me to help him develop a mahjong calculator for Droid, though, so I might install a dev environment over the weekend.
Posted on September 30, 2011 at 5:36 PM
|
|
A few months back, I started working on developing my own little game framework built around NME. This was actually before the upgrade to NME 3.0. I actually had to scrap a lot of my work that had become redundant once the install tool was incorporated into NME. After some time, I finally have a demo that displays some of what I've accomplished...
Piston Framework Trial
I'm designing this framework with very general functionality in mind. It is loosely based off of Flixel in its general approach to scene management. However, it is designed around the standard Flash display list, rather than the scene blitting that Flixel employs. In this initial trial you can see an animated spritesheet in action, hear the audio playback, and use the interactive buttons. Here are some screenshots of the different compilation targets that I've gotten it working on...
Ubuntu 64-bit
Windows XP
Mac OSX Lion
Posted on September 30, 2011 at 11:46 AM
|
|
Sweet, the NMML format is the first thing I would have asked for documentation on. (since it has become somewhat central to the preferred build process) Aside from that I would just focus on documenting the portions of NME that are unique to it. Points where the different build targets diverge would be a likely candidate for coverage.
Posted on September 14, 2011 at 4:43 PM
|
|
I've worked on an AS3-based custom GUI before. It used Flash drawing for creating buttons, scrollbars, and various GUI controls. I was planning on incorporating something similar into the Haxe game framework that I'm currently working on. It will probably be very bare-bones though, it isn't high on my priority list. I'll only need very basic GUI controls for some of the upcoming projects I'm working on.
Posted on September 09, 2011 at 1:05 PM
|
|
I tried the commands you gave me, and I was able to edit the configuration file. However, my project is still throwing errors. Here's the current error message that is plaguing me...
"ignoring file /Users/will/Documents/MyDevelopment/HaXe/NMETrial/bin/iphone/lib/libstd.iphoneos.a, file was built for archive which is not the architecture being linked (i386)"
I'm getting this same error message for all of the libraries that get generated for my Xcode project.
(Corrected) Oh snap! I downloaded the Display A Bitmap tutorial project, and it compiled and ran in the iPhone simulator without a hitch! The problem must lie with the application I was trying to compile, and not the build process itself.
(Further Revisions) Okay, after a little trial-and-error, I believe I hit on the root of my problem. In the NMML file, in the <app /> tag, there is an argument called "package" if you leave this argument blank, the program will compile but won't run in the simulator. I don't believe that argument actually refers to any part of your program, but is just some sort of identifier. I would appreciate a little more explanation on what that argument is and what it does. But at least I have discovered how to get my application running in the simulator. 
Posted on September 09, 2011 at 1:16 AM
|
