OpenFL running slow on the Apple TV

Thanks so much for that, unfortunately it does not seem to be working just yet.

First,

haxe compile.hxml
cd …/project <<<< Should be two levels up, I think

neko build.n
cd …/…

But more importantly, when I try to build the tools, this is what I get:

lime rebuild tools -v -clean

Error in building thread
g++ -Ilib/sdl/include/ -Ilib/sdl/include/configs/mac/ -DHAVE_LIBC -DUSING_GENERATED_CONFIG_H -DTARGET_API_MAC_CARBON -DTARGET_API_MAC_OSX -D_THREAD_SAFE -mmmx -msse -msse2 -c -fvisibility=hidden -stdlib=libstdc++ -O2 “-I/Users/hak88/Documents/workspace/test/hxcpp/include” -DHX_MACOS -m64 -Wno-parentheses -Wno-unused-value -Wno-format-extra-args -DHXCPP_M64 -DHXCPP_VISIT_ALLOCS -DHXCPP_API_LEVEL=0 -x c ./lib/sdl/src/SDL_error.c "-o/Users/hak88/Documents/workspace/test/hxcpp/project/lime/project/obj/darwin64/d1952bb7_SDL_error.o"
Error: In file included from ./lib/sdl/src/SDL_error.c:21:
In file included from ./lib/sdl/src/./SDL_internal.h:34:
lib/sdl/include/SDL_config.h:52:2: error: Wrong SDL_config.h, check your include path?
#error Wrong SDL_config.h, check your include path?
^
1 error generated.

So this is the exact same error I had before. Any idea how to fix this?

Well, I don’t know much about the in’s and out’s of rendering, but here’s normal (with inlining):

And here’s what’s revealed without, aka --no-inline:

So the time is mostly being spent in fillVertices, with significant time from there also in ArrayBufferIO.set calls - not sure if that’s helpful, obvious. or otherwise. :smile:

I know why it’s failing. I made you replace the whole project/lib/sdl/include.
You should actually first move the project/lib/sdl/include/configs somewhere safe.
Then you can remove the old include folder and replace it with the one from my SDL repo.
Next copy the configs back there.
And finally remove the include/SDL_config.h

This should solve your issue.

Let me know if it works. Cheers!

1 Like

Getting real close.

I think what needs to be added to your script is this in the end:

lime rebuild hxcpp tvos

else, you do not have the libs in hxcpp you need.

After that, compile seems possible, however I can’t really tell yet, as I’m searching for the right cable right now to connect to my appleTV.

It seems, compiling to the simulator is not possible so far, build fails, while compiling to a binary with openfl fails on the certificate step. Xcode does not want to compile for me without the TV connected, So I’ll get a cable now and will report back

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.

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?

That’s good to hear! :smile:

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.

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

This is how I use it:

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

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

Has support been merged into the main SDL tree now?

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.

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

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.

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.

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?

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

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…

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? :confused:

Or are you doing XMLSocket?