ENIGMA Development Environment
Website is in read-only mode due to a recent attack.

Pages: 1 2 »
  Print  
Author Topic: Unity Web Player  (Read 2283 times)
Offline (Male) time-killer-games
Posted on: May 25, 2014, 11:48:08 AM

Contributor
Location: Virginia Beach
Joined: Jan 2013
Posts: 1170

View Profile Email
Something really great about unity web player that beats GM's Html5 hands down is that it can do all the same things 2D and 3D that GM can on it's non-Html5 platforms, it is also in the browser, and works on windows and Mac just like html5 but without the shitty performance lag that makes tons of potential html5 games unplayable.

I've tried porting my games to html5 and they ran so slow it was a serious joke, unity web player is much better and I seriously doubt anyone actually plays shitty html5 games on their mobile device. They are really slow paced, primitive, and boring as hell.

I personally think ENIGMA should have a new sister project that mimics Unity web player but works with non-unity games. Since unity web player doesn't work on linux that could be our chance to shine. Unity requires an installation for it to work, we could just use java similar to eRun, but cross-compatible with PC and non-PC desktops. Similar to how LGM links to the compiler on the three platforms, it could be done for the games to run and embed in any website.

I doubt this will actually happen but it's fun to fantisize about. *runs away again*.
« Last Edit: May 25, 2014, 11:50:19 AM by time-killer-games » Logged
Offline (Unknown gender) Darkstar2
Reply #1 Posted on: May 25, 2014, 12:05:22 PM
Member
Joined: Jan 2014
Posts: 1238

View Profile Email
Yeah there are lots of good ideas, but as said many times, lack of developers and time :D

If I'm not mistaken GM did have something similar.I forgot what it was called but remember that thing they had where you could run your games through a website, by installing a plugin / addon? They probably removed it / discontinued it because of their multi platform one-size-fits-all-we-dont-wanna-work scenario.  They clearly showed their intention on making their product compatible to all platforms and that they won't work to accommodate any specific platform on its own.

But you have a point TKG.

and you're right it probably won't happen anytime soon, there are probably higher priorities.

And you're right, nobody wants to play shitty slow html5 games on their mobile........
Yet GMS allows for PS3, PS4, and soon other consoles - so I'm quite sure people will enjoy playing pixel land and the nice GM ports on their PS4 on their 60' TV !  ;D

Logged
Offline (Unknown gender) The 11th plague of Egypt
Reply #2 Posted on: May 25, 2014, 12:23:49 PM
Member
Joined: Dec 2009
Posts: 274

View Profile
It was this plugin
http://sandbox.yoyogames.com/help/firefox

It wasn't bad at all, but I can see why they went for HTML5.

Nowadays we have an extremization that could be summed up as "go HTML5 or go native".

It's not just GM, Unity will be moving towards HTML5+WebGL as well with v5.

As for me, I guess I'm going to move away from both Unity and GMS.
I'm tired with all the stupid problems arising from closed environments.

If you can code Java, check this out.
http://jmonkeyengine.org/
Logged
Offline (Unknown gender) TheExDeus
Reply #3 Posted on: May 25, 2014, 01:09:16 PM

Developer
Joined: Apr 2008
Posts: 1860

View Profile
I do like HTML5 and JS. It's not really slow just because it's HTML5. It's usually slow because it's coded badly. There are many badass HTML5 examples out there. Even Unreal Engine3 worked in pure HTML5/JS/CSS without any plugins. I think plugins are the thing of the past. Flash sucks, so does Silverlight. HTML5 that works everywhere with WebGL is a lot cooler. Like check this out: http://madebyevan.com/webgl-water/
Works without slowdowns for me. Of course wouldn't be that good for a phone.
Logged
Offline (Male) Rusky
Reply #4 Posted on: May 25, 2014, 02:09:30 PM

Resident Troll
Joined: Feb 2008
Posts: 954
MSN Messenger - rpjohnst@gmail.com
View Profile WWW Email
Too bad Unity is switching to HTML5.
Logged
Offline (Male) time-killer-games
Reply #5 Posted on: May 25, 2014, 04:10:03 PM

Contributor
Location: Virginia Beach
Joined: Jan 2013
Posts: 1170

View Profile Email
Native code runs much faster and better than JavaScript. There's no escaping that. It's not how the game is coded. That's bullshit. The same exact code equivalents produce by C++ runs much faster and smoother thank Html5 or HTML:next in any case. More browsers are supported by java than WebGL, WebGL, especially it's 3D won't run on most browsers. Unless you assume everyone has Chrome/Safari or thou might as well forget it.

Native runs much better and faster because its native. JS/Html5-next is not native. Java is much better and can run native binaries.
Logged
Offline (Unknown gender) TheExDeus
Reply #6 Posted on: May 25, 2014, 05:47:11 PM

Developer
Joined: Apr 2008
Posts: 1860

View Profile
Quote
Native runs much better and faster because its native. JS/Html5-next is not native. Java is much better and can run native binaries.
JS/HTML5 IS native. Because I don't know what you mean by "native", but for me it means "compiled to bytecode". And JS is compiled to bytecode for years now (starting with Google V8 if I remember correctly). Java is also compiled on runtime, but it actually is slower most of the time. Mostly because Java usually works as a plugin, so there is another layer between hardware and the program.

Quote
More browsers are supported by java than WebGL, WebGL, especially it's 3D won't run on most browsers.
Java is plugin. Whether or not Java is runnable purely depends on whether the user has Java enabled. I, for example, cannot run any Java applets in my browser. It's not that I don't want to, but because of security reasons Firefox has disabled it for me. And I really don't miss it. On the other hand HTML5 and WebGL run just fine. Also, the only browser struggling with WebGL is IE (and it struggles with everything). WebGL is 100% functional in Firefox, Chrome and Safari for years.
Logged
Offline (Male) Goombert
Reply #7 Posted on: May 25, 2014, 06:19:15 PM

Developer
Location: Cappuccino, CA
Joined: Jan 2013
Posts: 2993

View Profile
I agree with both of you, the part where TKG says native is faster. And the part where Harri says Flash sucks, I have my default web player for Youtube set to HTML5, even Adobe has realized the death of Flash. And I also agree with Harri when he says about it being poorly coded, that does make a huge difference, a properly coded HTML5 port should function better than GM's old interpreter/runner.
Logged
I think it was Leonardo da Vinci who once said something along the lines of "If you build the robots, they will make games." or something to that effect.

Offline (Unknown gender) Darkstar2
Reply #8 Posted on: May 25, 2014, 07:17:54 PM
Member
Joined: Jan 2014
Posts: 1238

View Profile Email
difference, a properly coded HTML5 port should function better than GM's old interpreter/runner.

That's a big statement there, and not too encouraging, and would mean their interpreter / runner is really bad..  :)
Logged
Offline (Male) time-killer-games
Reply #9 Posted on: May 25, 2014, 07:23:30 PM

Contributor
Location: Virginia Beach
Joined: Jan 2013
Posts: 1170

View Profile Email
Harri, there is a reason too obvious to bother mentioning why the newest Call of Duty will run fast and smoothly on the Xbox as a compiled standalone binary but be completely unplayable, incompatible and suck rooster balls if ported to html5/shit5. I'll let you connect the dots yourself on that one. I hope now you know the difference between JS and native, it won't kill you to figure out. GMS has two exports for Tizen and Windows 8. One labeled "Native" and the other "JS". Hmmm... Der I wonder why. :P to say Html5 can do everything an executable can is bogus. HTML5 / JS is not native, it's sandbox'd and interpreted.

For such an applet as described in the OP, the java part would just download, run, and embed the window of an external app. The native part is what matters most - the actual game after it's downloaded and ran. The game won't suffer from lag like it would with shit5 or even java itself, because the game isn't written in java, in most cases it would be native, compiled, standalone C++ depending on what game engine one would use to make the game for use from the applet.

Also, all browsers that disable java by default prompt you whether to enable it automatically, which takes one click, oh fucking my, one extra click, guess using java isn't an option and isn't as good because it requires one fucking click. :P that's not important at all. There are too many benefits to using java and native apps there's no reason to go for html5 unless you seriously enjoy wasting your time with games on your phone that are slow as shit, and boring as hell.

Why yes I've played many html5 games on my PC and tablet, many not made with GMS, and yet, no der, the games were extremely simple, slow paced, and a complete waste of time. I've never met anyone who complained about installing or updating java, it take 2 minutes, and I've definitely never met someone who's too damn lazy to install or update it. Big whoop.
« Last Edit: May 25, 2014, 08:04:22 PM by time-killer-games » Logged
Offline (Male) Goombert
Reply #10 Posted on: May 25, 2014, 07:30:08 PM

Developer
Location: Cappuccino, CA
Joined: Jan 2013
Posts: 2993

View Profile
I think on these basic points we all pretty much mutually agree. Also to add I prefer to download audio because of the higher quality playback.
Logged
I think it was Leonardo da Vinci who once said something along the lines of "If you build the robots, they will make games." or something to that effect.

Offline (Male) Rusky
Reply #11 Posted on: May 25, 2014, 10:51:22 PM

Resident Troll
Joined: Feb 2008
Posts: 954
MSN Messenger - rpjohnst@gmail.com
View Profile WWW Email
"Native" is nowhere near the same as "compiled to bytecode." "Native" is "compiled to machine code", usually NOT with a JIT. Thus, even though JavaScript is JITted, it's not native; even though Java has a bytecode and is JITted, it's not native. Java can call native code through JNI, but not in unsigned applets.

The big difference between JavaScript, Java, and native is the amount of runtime support crap they use. JavaScript is dynamically typed and uses hash tables for most variable lookups. asm.js is a specific subset of JavaScript that is closer to native in this way, and it gets within half native speed on FireFox (nothing else optimizes for it specifically). In fact, Mozilla has demoed running Unreal Engine in the browser by compiling it to asm.js using emscripten.

Java is statically typed but forces crappy memory layout, requires the one object paradigm to rule them all, and is poorly integrated into the browser. It is much faster than JavaScript, even asm.js, at most things. Yes, even though it's in a plugin. That doesn't really affect it as it's no more layered than JavaScript in the actual things that get done.

Real native code, either running as a downloaded executable, or using PNaCl, or using JNI (extremely rare and insecure), will beat the pants off JavaScript with or without asm.js, and Java, every time. But that's often irrelevant, because many games are just fine at the performance levels JS/WebGL give them. For example, one of the most demanding parts of games is graphics, and with WebGL that's done exactly the same way as with native.
« Last Edit: May 25, 2014, 10:53:46 PM by Rusky » Logged
Offline (Male) Goombert
Reply #12 Posted on: May 25, 2014, 11:50:37 PM

Developer
Location: Cappuccino, CA
Joined: Jan 2013
Posts: 2993

View Profile
Java doesn't have a single unified root? That's C#
Logged
I think it was Leonardo da Vinci who once said something along the lines of "If you build the robots, they will make games." or something to that effect.

Offline (Unknown gender) TheExDeus
Reply #13 Posted on: May 26, 2014, 05:55:30 AM

Developer
Joined: Apr 2008
Posts: 1860

View Profile
Quote
Harri, there is a reason too obvious to bother mentioning why the newest Call of Duty will run fast and smoothly on the Xbox as a compiled standalone binary but be completely unplayable, incompatible and suck rooster balls if ported to html5/shit5.
It wouldn't work not because of speed differences, but standard differences. WebGL is based on GLES, which means it is a subset of OpenGL and so has slightly less features. But still allows a great deal of games to be made (everything running on a phone, is based on GLES, even the "native" ones).

Quote
Also, all browsers that disable java by default prompt you whether to enable it automatically, which takes one click, oh fucking my, one extra click, guess using java isn't an option and isn't as good because it requires one fucking click.
It's not only that. Even if I do enable it, most of applets on the web don't work for some reason. And for me they really do work slower than pure HTML5 implementations. I often find applets for physics experiments when studying, and those that work are often VERY slow (taking into account that they usually solve 1 equation in real-time).

Quote
I've never met anyone who complained about installing or updating java, it take 2 minutes, and I've definitely never met someone who's too damn lazy to install or update it. Big whoop.
Well, you are going to meet a lot of people like that in the near future. Just like people don't want to use flash for anything anymore.

Quote
HTML5 / JS is not native, it's sandbox'd and interpreted.
Sandboxing doesn't mean it's not native and they are actually not interpreted. JS, for example, is usually compiled when you open the page, so when you run a game or something similar, then you are actually running bytecode native to your PC.

Quote
The big difference between JavaScript, Java, and native is the amount of runtime support crap they use. JavaScript is dynamically typed and uses hash tables for most variable lookups. asm.js is a specific subset of JavaScript that is closer to native in this way, and it gets within half native speed on FireFox (nothing else optimizes for it specifically). In fact, Mozilla has demoed running Unreal Engine in the browser by compiling it to asm.js using emscripten.
I was actually referring to asm.js previously. That is why I said that the fact you can run UnrealEngine in browser without any plugins, just shows how powerful and fast the thing can be. Unreal4 also runs in a browser now.

Quote
"Native" is "compiled to machine code", usually NOT with a JIT.
When I searched for "native", then wikipedia has the definition as "Something running on a computer natively means that it is running without any external support as contrasted to running in emulation" and while it does need extenral support (the JIT compiler), after it is compiled it still runs native machine code. So I guess it's mostly a definition issue.

Quote
Java is statically typed but forces crappy memory layout, requires the one object paradigm to rule them all, and is poorly integrated into the browser. It is much faster than JavaScript, even asm.js, at most things. Yes, even though it's in a plugin. That doesn't really affect it as it's no more layered than JavaScript in the actual things that get done.
Actually back in 2013 it was determined that asm.js runs faster that Java in most things. Sometimes asm.js worked faster than native C++ (even though the ams.js was generated from the same code). http://www.i-programmer.info/news/167-javascript/6238-java-asmjs-or-native-which-is-faster.html

I think now the difference is even more noticeable. And it's not only Mozzila. You can find cool stuff for chrome here: http://www.chromeexperiments.com/

And all of them run with 40+FPS on my AMD laptop which isn't that great (i3 CPU, ATI mobility radeon etc.).
http://alteredqualia.com/three/examples/webgl_terrain_dynamic.html
http://www.chromeexperiments.com/detail/webgl-water-simulation/

So I don't see how a 3rd party plugin would really run better than a HTML5 game, because they would probably both use WebGL which is as native, as OpenGL.
Logged
Offline (Male) Rusky
Reply #14 Posted on: May 26, 2014, 12:11:18 PM

Resident Troll
Joined: Feb 2008
Posts: 954
MSN Messenger - rpjohnst@gmail.com
View Profile WWW Email
In both Java and C# everything non-primitive derives from Object.

JIT compilers have lots of overhead over native, because it doesn't just one-time compile everything (even if it did, it would still have tons of runtime support crap the compiler would have to insert in). Instead, it compiles functions or loops as it gets to them (depending on the JS engine), often with some assumptions about types that make it bail out and interpret or recompile when you use it a different way. Yes, technically it's running native machine code but it's not really what people mean when they say "native"- for example, Mozilla always compares asm.js to "native" even though asm.js is even closer to a traditional ahead-of-time compiler than the normal JIT.

Your benchmark compares asm.js to the Dalvik VM, which sucks. It makes sense for them because they're talking about mobile, but desktop Java is much faster than Dalvik. The article also uses a JavaScript benchmark that JavaScript engines have been optimized for (which is pointless because nobody actually runs benchmarks, they run apps, and the results are often very different), and that native has not been optimized for (because, again, that would be pointless).
Logged
Pages: 1 2 »
  Print