|
Viewing 1 to (547 Total) |
|
Hi
The question really becomes how to actually get new objects and static variables into hxcpp after it has been compiled.
When you load a swf using flash, the classes inside are defined using adobes virtual machine bytecode. hxcpp does not understand how to interpret this bytecode as functions/objects so you can't create new object classes. This means that there is nothing really to put in the application domain.
Hugh
Posted on May 21, 2013 at 9:41 PM
|
|
Hi,
Currently not.
You might be able to hack it on the cpp target with:
var oldLen = array.length;
untyped array.length = 2;
gfx.drawTiles( ...array...)
untyped array.length = oldLen;
Hugh
Posted on May 09, 2013 at 10:59 PM
|
|
Hi
You can use:
nme.filesystem.File.documentsDirectory
To get a path, and then create data in there using the haxe native file io code.
Hugh
Posted on May 02, 2013 at 10:30 PM
|
|
Hi
Thanks for the DCE tip - the problem should be fixed in the dev version of NME.
The android debug problem should be fixed in HXCPP dev version. I will release a 3.0.1 in the next week with this fix.
Hugh
Posted on May 02, 2013 at 10:25 PM
|
|
This is true for flash, but not nme:
> All pixels in a BitmapData object are stored as premultiplied color values...
Although, both APIs deal with un-multiplied alphas as far as the haxe code goes, since you normally can't detect how the data are actually stored (unless you notice the graphics bugs)
Hugh
Posted on April 30, 2013 at 9:26 PM
|
|
Hi,
The problem is probably that we are *not* using premultiplied alpha. So what is happening, is that a black pixel with zero alpha is getting blended with green pixel with 100% alpha, to give a dark green pixel with 50% alpha, which is wrong.
This can be worked around by filling pixels with 0 alpha with the rgb values of neighbouring pixels (but still with zero alpha).
Hugh
Posted on April 28, 2013 at 10:28 PM
|
|
Hi,
My guess is that the resource.cpp file it too big. How big is it?
Some c++ compilers have a nasty habit of being quadratically slow when compiling big files.
My generally, I would not expect the resource files to be too big. How are you adding resources?
Hugh
Posted on April 28, 2013 at 10:25 PM
|
|
Hi,
Joshua forked the original gm2d into haxenme version for he own reasons, so I can't really comment on that version.
The gm2d version is the one I use for various projects that I have been thinking about and I will probably respond to change requests eventually.
The gm2d version will never be on github, if that influences your decision.
Hugh
Posted on April 28, 2013 at 10:16 PM
|
|
Hi,
I have been using text and svn head on windows recently and not seen a direct problem.
Some of the font embedding may have changed - are you using the system font, or something else?
If you compile a a debug version of nme, and a debug version of you app, you should be able to get a stack trace, which would pinpoint the problem.
Hugh
Posted on April 18, 2013 at 9:58 PM
|
|
Hi,
I think Joshua has fixed this on the git version.
Hugh
Posted on April 18, 2013 at 9:55 PM
|
|
Hi,
The opengl code consists of a couple of parts. The device dependent bit, which create the context (fixed pipeline or shader pipeline) one way or another (SDL, Java, ios).
Then the core code is pretty simple, it's mostly in "opengl/OpenGLContext.cpp", along with a few functions for resources in the same directory.
The wegGL API is more extensive, exposing quite a bit of functionality, but this is not used directly by NME.
Hugh
Posted on April 16, 2013 at 9:35 PM
|
|
Hi,
Most of the setup is done in:
project/ iPhone/UIStageView.mm
Which is compiled into nme, rather than exposed via templates (we should change this one day). So you will need to hack at the internals of NME to fix this problem.
I'm not too sure about how multiple applications interact on IOs, so I can't me much more help.
Hugh
Posted on April 16, 2013 at 9:30 PM
|
|
Hi,
This seems to be working for me. I guess the "x" and "scaleX" may refer to different objects depending on the event handler?
Just to avoid confusion with the special variables "x" etc, the code I tested is below (or do you think that may be the problem?)
Hugh
var t = 0.0;
public function onEnter(_)
{
var sx = 1.2;
var sy = 1.3;
t += 0.01;
var sin = Math.sin(t);
var cos = Math.cos(t);
var x = 100;
var y = 100;
var newMtx = new flash.geom.Matrix();
newMtx.a = cos * sx;
newMtx.b = sin * sx;
newMtx.c = -sin * sy;
newMtx.d = cos * sy;
newMtx.tx = x;
newMtx.ty = y;
sp.transform.matrix = newMtx;
}
Posted on April 15, 2013 at 10:19 PM
|
|
HI
Should be fixed now.
Hugh
Posted on April 15, 2013 at 10:02 PM
|
|
Hi,
You might be able to use:
native/gl/GL.hx "glReadPixels", but the trick here would be to do it as the very last thing in the render before the "swapBuffer" call.
So you would have to add an "OpenGLView" to the end of you main sprite, can call "glReadPixels" from its render function when the touch is down.
It's so crazy it just might work.
Hugh
Posted on April 14, 2013 at 10:12 PM
|
|
Ok, good to know - I will look at fixing the BuildTool
Hugh
Posted on April 11, 2013 at 10:43 PM
|
|
Hi,
The code seemed to handle ellipses, but not circles. I have put a tiny tweak in gm2d\svg\Svg.hx on svn to fix this.
Hugh
Posted on April 09, 2013 at 10:33 PM
|
|
Hi,
These files are built from the line in the build.xml:
<hlsl name="winrt\\SimplePixelShader.hlsl" profile="ps_4_0" variable="gPixelShader" target="winrt\\shaders\\SimplePixelShader.h"/>
by the hxcpp BuildTool, which runs the "fxc.exe" command to generate the .h and .cpp
I have not looked at this in a while, so I'm not 100% it is going to work.
Hugh
Posted on April 08, 2013 at 10:09 PM
|
|
You need to be careful when doing the rotation yourself - eg, the keyboard comes from the wrong direction.
Hugh
Posted on April 04, 2013 at 9:44 PM
|
|
Well, actually probably not. It does look like it was put in on Feb 13, and not tested before release. What could go wrong with a simple debug print?
Hugh
> This problem only show up with the debug flag on. So the 10 platforms were tested, just not twice.
Posted on April 04, 2013 at 9:42 PM
|
