OpenFL running slow on the Apple TV

tanis · October 14, 2015, 5:36am

Actually the line neko build.n should build all of the hxcpp targets, including the tvos one. It’s wrong that you have to rebuild it again after messing around with Lime.

It looks like I forgot something somewhere along the toolchain to get the simulator working. I tried as well and it seems that it’s not passing the correct architecture and SDK path down the pipe. I’ll look into it.

And yeah, you need a developer certificate to deploy on the device, just like you do for iOS.

hak88 · October 14, 2015, 11:19am

Strange, I did not have the TVOS libs in hxcpp (only in lime).

But, more importantly I got it running on my appleTV.

Yeah! Thanks so much.

No I need to figure out how get a Mouse pointer. Will Mouse events work in general or do I need to the Joystick class?

tanis · October 14, 2015, 12:33pm

That’s good to hear!

AFAIK mouse clicks are being passed down the pipe when the user clicks on the remote (only the click on the touch area and the play button are mapped right now).
I don’t know about the mouse position as I’ve not checked it out. So far I’ve been using the GamePad class to deal with the remote.

hak88 · October 14, 2015, 6:47pm

Do you have an example for the GamePad class? The API has changed so much that none of the examples I find seem to work

tanis · October 15, 2015, 8:11am

This is how I use it:

github.com

tanis2000/openfl-test-tvos/blob/master/DisplayingABitmap/Source/Main.hx

package;


import openfl.display.Bitmap;
import openfl.display.BitmapData;
import openfl.display.Sprite;
import openfl.display.Graphics;
import openfl.display.CapsStyle;
import openfl.display.JointStyle;
import openfl.display.LineScaleMode;
import openfl.events.Event;
import openfl.events.GameInputEvent;
import openfl.ui.GameInput;
import openfl.Lib;
import openfl.Assets;
import lime.ui.Joystick;
import lime.ui.Gamepad;


class Main extends Sprite {

This file has been truncated. show original

hak88 · October 25, 2015, 9:12pm

Thanks for the link - does not work for me at all, no idea why. Gamepad never registers anything. Similar to what this guy reports:
Gamepad-Api not working

tanis · October 26, 2015, 6:23am

That’s because Lime is still using an old version of SDL: https://github.com/native-toolkit/sdl/commits/master

You’ve got to wait until they upgrade to the latest SDL version or you’ve got to upgrade SDL yourself. You can find info about how I usually do it right on this same thread: OpenFL running slow on the Apple TV

singmajesty · October 26, 2015, 8:26pm

Has support been merged into the main SDL tree now?

hak88 · October 26, 2015, 10:25pm

Hold on- but I build SDL according to your instructions from your repo - else my app would not be running on twos at all, no?

Further info - I’m running your hxcpp + lime gits and openfl 3.3.8. Using 3.3.9 introduces strange display problems.

tanis · October 28, 2015, 9:31am

Not yet.
My suggestion is to wait as it will be merged soon. The Apple TV launch is just around the corner.

hak88 · November 3, 2015, 2:09am

Here is a question - could the tvos libraries be built for legacy? I tried and it failed (see below).

Why would I want to do that? I have an art project for which it would be perfect to run some code for a Phidget board on an appleTV. The code runs great on desktop, but only in legacy (nextGen just stops midway).

Error: In file included from ./…/legacy/project/src/opengl/OGLShaders.cpp:1:
./…/legacy/project/src/opengl/./OGLShaders.h:19:4: error: unknown type name 'GLuint’
GLuint createShader(GLuint inType, const char *inShader);
^
./…/legacy/project/src/opengl/./OGLShaders.h:19:24: error: unknown type name 'GLuint’
GLuint createShader(GLuint inType, const char *inShader);
^
./…/legacy/project/src/opengl/./OGLShaders.h:30:4: error: unknown type name 'GLuint’
GLuint mProgramId;
^
./…/legacy/project/src/opengl/./OGLShaders.h:31:4: error: unknown type name 'GLuint’
GLuint mVertId;
^
./…/legacy/project/src/opengl/./OGLShaders.h:32:4: error: unknown type name 'GLuint’
GLuint mFragId;
^
./…/legacy/project/src/opengl/./OGLShaders.h:42:4: error: unknown type name 'GLint’
GLint mImageSlot;
^
./…/legacy/project/src/opengl/./OGLShaders.h:43:4: error: unknown type name 'GLint’
GLint mColourArraySlot;
^
./…/legacy/project/src/opengl/./OGLShaders.h:44:4: error: unknown type name 'GLint’
GLint mColourScaleSlot;
^
./…/legacy/project/src/opengl/./OGLShaders.h:45:4: error: unknown type name 'GLint’
GLint mColourOffsetSlot;
^
./…/legacy/project/src/opengl/./OGLShaders.h:46:4: error: unknown type name 'GLint’
GLint mTransformSlot;
^
./…/legacy/project/src/opengl/./OGLShaders.h:47:4: error: unknown type name 'GLint’
GLint mASlot;
^
./…/legacy/project/src/opengl/./OGLShaders.h:48:4: error: unknown type name 'GLint’
GLint mFXSlot;
^
./…/legacy/project/src/opengl/./OGLShaders.h:49:4: error: unknown type name 'GLint’
GLint mOn2ASlot;
^
./…/legacy/project/src/opengl/OGLShaders.cpp:37:1: error: unknown type name 'GLuint’
GLuint OGLProg::createShader(GLuint inType, const char *inShader)
^
./…/legacy/project/src/opengl/OGLShaders.cpp:37:30: error: unknown type name 'GLuint’
GLuint OGLProg::createShader(GLuint inType, const char *inShader)
^
./…/legacy/project/src/opengl/OGLShaders.cpp:40:4: error: unknown type name 'GLuint’
GLuint shader = glCreateShader(inType);
^
./…/legacy/project/src/opengl/OGLShaders.cpp:45:4: error: unknown type name 'GLint’
GLint compiled = 0;
^
./…/legacy/project/src/opengl/OGLShaders.cpp:50:4: error: unknown type name 'GLint’
GLint blen = 0;
^
./…/legacy/project/src/opengl/OGLShaders.cpp:51:4: error: unknown type name 'GLsizei’
GLsizei slen = 0;
^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
20 errors generated.

tanis · November 3, 2015, 9:47am

Well, the current version hasn’t been ported to the legacy code. And I guess that legacy should stay legacy and new targets should only end up in the new version of OpenFL. But that’s just my opinion.
This is something that should be decided by @singmajesty tbh.

hak88 · November 3, 2015, 3:00pm

On principle, I would agree. However, there are things that just do not seem to work on nextGen, for example Sockets seems to be broken - see here: Openfl.net.Socket targeting cpp/neko

Right now, my particular project would work fine with legacy available…

@singmajesty what do you think?

singmajesty · November 9, 2015, 7:05pm

Is this anything we can fix? Why does your project stop half-way? Can we fix sockets?

hak88 · November 9, 2015, 7:34pm

Fixing sockets on nextGen would be great. I tried using sys.net.Socket instead, but that seems broken for any returned server message that exceeds a single line: Openfl.net.Socket targeting cpp/neko unless I’m doing something wrong…

The AppleTV could be a great platform for home automation and physical computing projects that can output directly to a big screen and comes with a remote, but working networking is essential in this kind of setup…

As sockets work quite fine in _legacy, the question is what is easier? supporting _legacy on tvos or fixing sockets? Another way would be to figure out what the problem is with sys.net.Socket, which seems almost there…

singmajesty · November 9, 2015, 8:02pm

I think it would be best to compare https://github.com/openfl/openfl/blob/master/openfl/net/Socket.hx and … wait, there is no legacy socket. This file appears to be used on both?

Or are you doing XMLSocket?