Comments (16)
I honestly don't know nearly enough about C++ to attempt to solve this problem. :/ I really would love be able to deploy to JS via Emscripten, since that would be many times faster than Haxe's standard HTML5 target, but so far, I've had little luck. Perhaps we could hit up the guy that wrote Emscripten, and request his help? I think that he would certainly be able to tell us what's going on, but I'd imagine that he's quite busy as well. Maybe we could put our heads together and try to figure this one out on our own? I'm at a loss alone.
from lime.
Hey guys,
Emscripten was defined for statically linking the libraries. "lime", "std", "regexp" and "zlib" are ordinarily external dependencies, but for Emscripten, they're linked together.
The first step is to ensure that a "lime" library exists in the "lime/ndll/Emscripten" directory (by calling "lime rebuild emscripten") and "std", "regexp" and "zlib" libraries exist under "hxlibc/ndll/Emscripten" (by calling "lime rebuild hxlibc emscripten").
When statically linking, the application has "_register_prims" method calls in order to ensure that the symbols to the target library are brought in, and early. If you have these separate libraries built, then there could be a problem in the linking
from lime.
Ran these commands, all the libraries are there, still the same errors.
This warning might be relevant:
WARNING root: -I or -L of an absolute path "-I/usr/lib/haxe/lib/hxlibc/1,1,2/include" encountered. If this is to a local system header/library, it may cause problems (local system files make sense for compiling natively on your system, but not necessarily to JavaScript). Pass '-Wno-warn-absolute-paths' to emcc to hide this warning.
Thanks for looking into this!
On Dec 26, 2013, at 2:50 PM, Joshua Granick [email protected] wrote:
Hey guys,
Emscripten was defined for statically linking the libraries. "lime", "std", "regexp" and "zlib" are ordinarily external dependencies, but for Emscripten, they're linked together.
The first step is to ensure that a "lime" library exists in the "lime/ndll/Emscripten" directory (by calling "lime rebuild emscripten") and "std", "regexp" and "zlib" libraries exist under "hxlibc/ndll/Emscripten" (by calling "lime rebuild hxlibc emscripten").
When statically linking, the application has "registerprims" method calls in order to ensure that the symbols to the target library are brought in, and early. If you have these separate libraries built, then there could be a problem in the linking
—
Reply to this email directly or view it on GitHub.
from lime.
Thanks for the help, Joshua. I'll try what you suggested, and see what I get. Hopefully it helps :)
from lime.
I tried installing the latest version of Emscripten today, and giving everything a try. With some work, I've got it all compiling, linking together and running. For some reason, though, the rendering is wrong.
Drawing a square using an OpenGLView, the GL.clear call appears properly, but the square will only appear every 30 or so seconds for a flicker. Trying a sample such as PiratePig, may appear white on one browser, or like it intermittently works on another. I'm not really sure what's going on -- it seems to be entirely rendering related, since under the hood trace messages and logic appears to be rolling again just properly.
I'm not sure if this is due to the latest version of Emscripten, and a bug, or perhaps some minor regression on our part, which doesn't affect GL, GLES or WebGL targets, only Emscripten :/
from lime.
On the other hand, it seems to advanced quite a bit (problems I had before are gone) and seems to build much faster, or maybe its just this computer? It would be exciting if this were viable
from lime.
If you want to test the latest, you will need development versions of hxlibc, lime, lime-tools and openfl-native. Sorry it touches so many places, we dropped official Emscripten support before OpenFL 1.1, so there's been some catching up to get it running properly
from lime.
All very cool, looking forward to trying this with the dev versions. I can't even imagine the complexity behind openfl -> c++ -> js :)
On Dec 26, 2013, at 11:07 PM, Joshua Granick [email protected] wrote:
If you want to test the latest, you will need development versions of hxlibc, lime, lime-tools and openfl-native. Sorry it touches so many places, we dropped official Emscripten support before OpenFL 1.1, so there's been some catching up to get it running properly
—
Reply to this email directly or view it on GitHub.
from lime.
Actually, it may be more of a Firefox issue ATM. Chrome appears to be displaying simple samples, though (for some reason) it does not animate properly yet
from lime.
After some research, something about Emscripten appears to not like the behavior of Actuate. If I take a simple object and tween along one property, it works fine. If I try tweening along two, it doesn't work right, or crashes out. This works on every other target, it must be something with an Emscripten optimization? Something with dynamic access, I guess
from lime.
There's a workaround for that, actually, and in my opinion, the design pattern that it enforces is more efficient anyway. What you do is create a main class that all your game objects inherit from, and in your main class, create an array, which stores all of your game objects. When you add an object to your stage, also add it to that array. Instead of using Actuate to animate, create an update
method for your main class, and in that method, loop through all elements in the array, and call their update
methods. That way, the logic for animating your objects is encapsulated within their classes, and Actuate isn't doing it. I'm actually working on what I call the Gryffin Engine, which allows you to create a Stage object, and all game objects are stored there. Every game object has a render
method, and a update
method, so all the logic for rendering/updating them in stored in their classes. The Stage object also has a get
method, which takes a selector string as it's argument, the engine runs that string through it's built-in selector-string parser, generating a selector function of type GryfObject -> Bool
, and returns an array of all game objects for which that function returned true
. All update
and render
methods take two arguments: the first is a flash.display.Graphics object, and the other is the Stage object itself. So, using selector strings, you can access any other game object on the stage, from within any other object's class. Both the Stage and GryfObject fully support Event binding, so you're not limited there. As an added bonus, the engine also has it's own built-in scripting language, which can be used to script game objects, or modify the behavior of pre-existing objects. The language is almost identical to JS, with the exception of it's module system, and support for classes. All this is completely implemented in Haxe, so it's completely cross-platform. I created this to allow a better MVC system than was present in pure-vanilla OpenFL. Using this engine, or a similar system of your own, you can work around the problems Joshua mentioned. I may be releasing early versions of the engine to Github for open-source use, but the engine is largely closed-source, that's why I explained the way it works, rather than releasing it. Sorry for posting a novel :)
from lime.
Hey guys,
Great news! I tracked back 1503 commits back to find where Emscripten broke. They made a different frontend for LLVM the default, which triggered some of these data type issues. I have gotten things running again using the latest version of Emscripten, the updates are propagated across each library, and the next release should have official Emscripten support again. It does not mean that we will be able to track down every bug that may occur with Emscripten, but it should enable "lime test emscripten" out-of-the-box.
from lime.
Awesome, thanks for all the hard work! Can't wait to try this out!
On Dec 27, 2013, at 8:35 PM, Joshua Granick [email protected] wrote:
Hey guys,
Great news! I tracked back 1503 commits back to find where Emscripten broke. They made a different frontend for LLVM the default, which triggered some of these data type issues. I have gotten things running again using the latest version of Emscripten, the updates are propagated across each library, and the next release should have official Emscripten support again. It does not mean that we will be able to track down every bug that may occur with Emscripten, but it should enable "lime test emscripten" out-of-the-box.
—
Reply to this email directly or view it on GitHub.
from lime.
You may have caught this already, but the next release of OpenFL and Lime went out, with Emscripten support again :)
from lime.
And this support works properly? :D I would be so happy to see this working, because deploying to JS is the best way to debug a program for me, since I started my programming career as a JavaScript developer, and am most accustomed to that language. The problem with this is that my game's engine won't work properly on the HTML5 target. GryffinScript evaluates properly, but the rendering is extremely off. This is seemingly caused by something with the engine's tile system, because if I make an app that doesn't use the tile system, it works fine.
from lime.
Hey guys, tried building with Emscripten using updated versions of lime, lime-tools, lime-build, hxlibc, and OpenFL. Everything worked for a trivial test (single class running trace() and nothing else), but with a larger app, I run into new unresolved symbols:
I'm guessing FT is the prefix for libfreetype, and it looks like the issue might lie there. Tried every rebuild command I could think of to no avail. Any ideas?
from lime.
Related Issues (20)
- TextField IME candidate list pane invisible on Windows HOT 8
- lime rebuild extension-webm windows error HOT 3
- CURL is freezing the application
- window.fullscreen toggling error on MacOS HOT 5
- Doc on ThreadPool.new doesn't match the function HOT 1
- Lack of option to disable automatic `full-screen` mode. HOT 1
- Weird title bar on unfocused borderless window HOT 3
- Android emulator crashes with antialiasing >= 2
- Compilation error HOT 1
- Using HXP complains about a missing NDLL HOT 9
- Do think lime's native audio source time, length, dataLength, and samples should be an int64 instead of an int? HOT 1
- [ENHANCEMENT] Audio recording support HOT 1
- [8.2.0-dev] Target Cairo version doesn't exist HOT 5
- Sys.exit hangs the process on the latest 8.2.0-Dev branch HOT 2
- [html5] gamepad disconnect event is never dispatched
- is there a way to do this? HOT 5
- Add support for `maxSdkVersion` attribute in `permission` element. HOT 1
- Been trying to compile game, keep getting errors telling me "ApplicationMain.getEntryPoint(); Called from macro here HOT 6
- Context3D.totalGPUMemory returns inaccurate values on some non-NVIDIA graphics cards HOT 5
- Make x86 target flags more specific HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from lime.