Hacker News Reader

Comment by memracom | Hacker News Reader

This sounds like the same old rule that has existed for the last 30 years or more. If you want to build an app that uses graphically intensive animations, build as close to the metal as possible and do not rely on layers provided by the OS.

I learned nothing from this because if I was going to build a game like he described, I would suck it in and get down to the platform's assembly language layer which for IOS is ObjectiveC and for Android is Java.

It would be far more interesting to read a review that explores the boundary of what works well in PhoneGap and what doesn't. Clearly lots of successful apps are built in PhonegGap/Cordova. We could have the same conversations about desktop apps or server apps. Too many layers make things easier to build but impose a performance penalty. It is wise to think before you build and do some architecture and engineering before coding. Writing code is NOT engineering.

View on HN

Your comment sounds very confused. Obj-C and Java are not "assembly language", and nobody writes games for iOS that don't use any sort of OS-level functionality. That's completely ridiculous. Especially because iOS provides multiple different APIs for high-performance graphics, such as Metal/OpenGL for 3D rendering and SpriteKit for 2D rendering.

Really the advice should just be don't use JavaScript and web technologies for mobile gaming.

I took "assembly language layer" in the parent comment to mean the "lowest-level high-level language" commonly available on the platform.

In android c++ binding is used to create high performance games and not Java entirely.

The fact that you may have understood what the grand parent meant does not mean he formulated it correctly.

I personally would recommend developing games in C++ for both platforms. You're not going to be heavily using any of the APIs that necessitate using Obj-C or Java. It's just OpenGL ES and other low level APIs. Additionally, it's easy to port between iOS and Android and you can use a much wider variety of libraries.

Yup, you can do things that'll start getting close to the metal with Java(arrays to keep caches warm, avoid allocations). However at the end of the day it's a huge pain and you lose the portability you get with C++.

>> you lose the portability you get with C++

Wouldn't Java be more portable than C++?

Not on mobile. You can embed compiled C++ code in both iOS and Android apps, but there's no easy way to run Java on iOS.

Is that the reason unity 3d is popular. Never thought c++ would be more portable than Java. But it makes sense now.

Maybe not "easy" but certainly quite possible (x2):

https://github.com/google/j2objc https://software.intel.com/en-us/multi-os-engine

Not if you don't have a JVM on your target platform.

I always recommend Unity3D because the devs that would be comfortable starting in C++ with "raw" OpenGL already know their options and generally aren't looking for recommendations.

Usually when someone asks me "What should I use to make a cross-platform game", what they're really asking is "What tool can I use that won't get in the way of me making my game, that additionally allows me to target multiple platforms"

> Cross platform mobile games when you have C++ skills: Use C++ with OpenGL and share most of the code.

I would recommend MOAI - gives you the best bang for the buck, as long as you're willing to learn Lua to do all the app-layer stuff, and leave the MOAI engine to manage the performance-critical resources...

http://getmoai.com/

But isn't this project dead? MoSync also comes to mind. It had a nice cross-platform C++ API.

Dead? No, far from it. Its still quite a powerful engine.

Of course the little detail here is that 50 tiny sprites apparently counts as graphically intensive.

Why do web developers constantly make the argument that Javascript is not slower than C (or Swift, or C++, or any native programming language) ? The difference is night and day, 5000% and up for simple things like drawing.

It's a cargo cult.

Who makes that argument? No one suggests that.

> The difference is night and day, 5000% and up for simple things like drawing.

I find that seriously doubtful, you're going to have to provide a citation if you want me to swallow that.

The relevant comparison is a single JavaScript function in Firefox looping through a static array and making WebGL calls vs. a C++ function looping through the same array and making OpenGL calls.

If the difference is 5000% or more I will donate $20 to the charity of your choice.

> The relevant comparison is a single JavaScript function in Firefox looping through a static array and making WebGL calls vs. a C++ function looping through the same array and making OpenGL calls.

...that's not how graphics benchmarking works. That would be like benchmarking a language by seeing how fast it can add up integers.

Actually their example of iterating over an array and making WebGL calls is very close to exactly what you need to benchmark.

It would seem more to the point for me to compare something like a game downloaded from steam with a webpage, as that is directly comparing the user experience.

If you artificially limit the scope to something trivial, anything can work. I mean, that might be interesting for web browser developers, sure, and by all means, use it for that. But what matters is what experiences can be created by it.

The web experience for games sucks.

> That would be like benchmarking a language by seeing how fast it can add up integers.

So you mean like most language benchmarks. :)

WebGL has really high draw call overhead compared to native OpenGL. The rough rule of thumb is that you can do 2000% [0] the draw calls in a native app per frame than you can do in WebGL. It's not about execution performance it's about overhead of leaving JS and converting data to the format the GPU needs.

0 - http://floooh.github.io/2016/08/13/webgl-next.html

C is always going to be faster than almost anything you compare it to, of course. But the V8 interpreter is also not 5000% slower; for computationally intensive tasks it's not actually significantly slower. The problem in OP's case is that JS lacks an interface to interact with the display and render that is as "close to the metal" as their "native" counter parts. You are drawing sprites on a html canvas which is then rendered by a web view, which just not that great no matter what language you use to get there.

What I'm getting at is that it's easy to blame Javascript, but really that's not the whole picture, and if Google and Apple chose to support Javascript natively it wouldn't have these dramatic performance issues.

> Google and Apple chose to support Javascript natively it wouldn't have these dramatic performance issues

What would "supporting Javascript natively" mean? If you mean AOT, classic AOT (without some pretty fancy research-level PGO or something) is not a viable compilation strategy for JS.

I do agree heavily with your overall point that the JS blame is misplaced. People often forget that JS is faster than Objective-C at important things like method calls for systematic reasons.

By supporting natively I mean provide a layer of APIs that let developers interact with the phone and in particular with the display at a low level, while still writing JS; I imagine that if you could draw on the screen bypassing canvases and html views entirely it would solve most issues.

You mean like NativeScript?

https://www.nativescript.org/

How would that differ from WebGL?

I assume the grandparent means access to UI APIs, not just drawing. I think there would still be significant performance drawbacks to "native JS".

> Why do web developers constantly make the argument that Javascript is not slower than C (or Swift, or C++, or any native programming language) ? The difference is night and day, 5000% and up for simple things like drawing.

Probably because that's completely untrue, and would be irrelevant even if it were true.

If you're doing "drawing" (which in this case means blitting) on the CPU to begin with, you've already lost.

But this is beside the point. Firstly, I've been doing demos for years, so

1) it is possible, even at high resolutions

2) anything worth doing in opengl can't work in javascript for other reasons (mostly data size). And yes, you could download hundreds of megabytes worth of data files just to show an intro screen and then a few gigabytes for a game over an internet connection. I hope you have patient customers and a huge webhosting budget.

So let's be honest here : for small games, the effort of doing it with OpenGL/WebGL is not worth it. For large games it cannot be done, but for other reasons (that actually also apply to small games: 50 megabytes is incredibly oversized for a webpage, but still rather small for a game, so these problems actually overlap)

I myself feel guilty for stating this, but it actually works better to render the entire game server-side and videostream it to the client. Yes, javascript (and the web ecosystem) is that bad.

Is there no use for it ? Well, I appreciate the speed at which I can try out shaders locally. None of the niceties of javascript such as debugging or any sort of development process work, but it's still nice that you can get up & running in an hour or so.

But any reasonable game on javascript or the web platform ? Doesn't work and at this point it's so far from working it's a bad joke.

> I would suck it in and get down to the platform's assembly language layer which for IOS is ObjectiveC and for Android is Java.

That only makes sense if the graphnics performance is actually the bottleneck of your game.

99% of the games I've seen have game design as the weakest link though, and sometimes art (it's not amount of polygons on the screen — it's how beautiful those polygons are). And if you actually want to improve on your game design, the metric you have to optimize is iteration speed — and the "assembly language layer" is rarely the best for this purpose.

Being a person who programs actual ARM/Neon assembly for both iOS and Android, your post is hilarious. ObjectiveC and Java are anything but assembly.

> get down to the platform's assembly language layer which for IOS is ObjectiveC

The assembly language layer for iOS is assembly language.

C combines the power and performance of assembly language with the flexibility and ease-of-use of assembly language.

Most high end games are developed in C++ for both iOS and Android with Java and Objective-C wrappers for things such as IAP's and Game Kit/Play Games integration.

Reply on news.ycombinator.com