HTML5

TRS

Member
Why isn't it a good idea to make a version of TSO webbased with HTML5. It's multi-platform, simple to program and 100% opensource.

TR
 
It would only be open-sourced if the developer chose to have it open-source. There would be server costs, possibly some aspects of the game would have to be cut and the game would probably run better on the actual device itself because it would have easier access to system resources.
 
HTML5 is rubbish :S

Project Dollhouse is already Open Source.
Please lock this forum, Afr0!
 
In my experience, browser-based applications that makes heavy use of realtime graphics are slow. Tirnua is a good example of this. This, and the fact that you cannot go fullscreen, is enough of a reason for me to shun HTML5.
 
Afr0 said:
In my experience, browser-based applications that makes heavy use of realtime graphics are slow. Tirnua is a good example of this. This, and the fact that you cannot go fullscreen, is enough of a reason for me to shun HTML5.
Just saw this, Tirnua uses Flash, does not use any hardware acceleration and is just bad in general. :p There's been a fullscreen API for quite some time now, it has different implementations across browsers but it's pretty easy to flatten out.

WebGL is really capable and javascript is really high performance for anything that isn't per pixel rendering. For that, you can use WebGL shaders. ;) You can even set the cursor, generate 3d sound and simulate a persistent filesystem with IndexedDB, so it's possible to make apps that completely feel native in it.

I think chrome also allows you to create desktop shortcuts that remove the address bar for that extra genuine windowed native app feel ;)
 
Nice! :)
I really like your city rendering! :D
Still, the issue remains how you would distribute the installation files to users
 
Afr0 said:
Nice! :)
I really like your city rendering! :D
Still, the issue remains how you would distribute the installation files to users
Depending on if there are any laws against redistributing abandoned free trial software, I could always just host the install files on the same server as the game software. If not, I could set up an FTP proxy to allow the user to still download the game from ea but through a proxy, which should be legal. If not that, then I could: 1. Force the user to install the game scripts as an app in Chrome (to bypass Cross Origin, allowing direct download from ea ftp servers) 2. For any other browser/case the user hosts a localhost server with the game files they downloaded standalone with Cross Origin Requests allowed, and points the game to it.
 
I was thinking... isn't there any way you could use... maybe Java to locate the game's installation on the user's HD and then load the files from there?
 
RHY3756547 said:
Afr0 said:
Nice! :)
I really like your city rendering! :D
Still, the issue remains how you would distribute the installation files to users
Depending on if there are any laws against redistributing abandoned free trial software, I could always just host the install files on the same server as the game software. If not, I could set up an FTP proxy to allow the user to still download the game from ea but through a proxy, which should be legal. If not that, then I could: 1. Force the user to install the game scripts as an app in Chrome (to bypass Cross Origin, allowing direct download from ea ftp servers) 2. For any other browser/case the user hosts a localhost server with the game files they downloaded standalone with Cross Origin Requests allowed, and points the game to it.
There are laws that keep the copyrighting of Abandonware. Such software is usually left by it's original owner and not touched for ages. The only thing is, the copyrights usually expire late in the future, meaning we're going to have to wait a loooooooooong time. See this: http://www.ivanhoffman.com/expiration.html
 
Afr0 said:
I was thinking... isn't there any way you could use... maybe Java to locate the game's installation on the user's HD and then load the files from there?

JS is sandboxed. Although an applet may be able to find the path you still cant access it via JS.

HTML5 & JS are very capable. It seems like the current focus for browsers is game dev with projects like ASM.js, Web GL, all the new memory efficient types and some good sound Apis. For me, PD is C# because it is, if it was a start from scratch project I think there is a strong case to make it browser based.
 
ddfczm said:
Afr0 said:
I was thinking... isn't there any way you could use... maybe Java to locate the game's installation on the user's HD and then load the files from there?

JS is sandboxed. Although an applet may be able to find the path you still cant access it via JS.

HTML5 & JS are very capable. It seems like the current focus for browsers is game dev with projects like ASM.js, Web GL, all the new memory efficient types and some good sound Apis. For me, PD is C# because it is, if it was a start from scratch project I think there is a strong case to make it browser based.
Maybe once we get to a reasonable stage I could backport the gameplay to my HTML5 test version and get it to the stage where it could connect to PD through a WebSockets proxy. I found out the hard way that WebGL does NOT support hardware depth though, (due to roots in OpenGL ES 2.0) so there would have to be a workaround for z buffered lot rendering.
 
C# is an ISO/EMCA standard, meaning anyone can make a legal implantation, and Mono, one of those implantations, is open source. I honestly don't think an HTML-based TSO would be a good idea due to variying overheard of the broswers, the fact JavaScript was designed mostly a scripting language, never meant for games, and implantions of tend to vary between broswer to broswer, let alone platform.
 
aidancheddar said:
C# is an ISO/EMCA standard, meaning anyone can make a legal implantation, and Mono, one of those implantations, is open source. I honestly don't think an HTML-based TSO would be a good idea due to variying overheard of the broswers, the fact JavaScript was designed mostly a scripting language, never meant for games, and implantions of tend to vary between broswer to broswer, let alone platform.

You would be surprised. In many browsers Javascript runs faster and with less memory bloat than C# or CLR languages.
 
I'm more concered about the broswer. C# and Java requires only a thin layer, meanwhile Javascript needs a broswer that tends to be a memory hog in it's own right even if Javascript itself is light. I don't mind seeing someone make TSO in Javascript. I just don't think it's practical.
 
Yep, I'm specifically impressed with the latest developments in iOS Safari - they straight up managed to double the javascript performance on all phones (GBC emulation fullspeed on iPhone 5, before it went half speed on mono GB). In comparison, Chrome for Android is magnitudes slower on similar hardware... I don't think they've optimised V8 for ARM as much as they have for x86.

Modern implementations have been almost unified - they keep the things that function differently/partially or are still draft standards under alias names like "WebkitAudioContext", which is annoying in itself to work around but avoids the idea that these specific functions work 100% the same everywhere. It's up to the developer to make their own abstraction and keep up with the standards.

The TSO CAS demo I made runs at about 200MB RAM on a 6GB machine. If it were constrained more, it would probably do tougher garbage collection, but right now that's pretty good for loading all of the assets in the game (to map them to ids), unloading them, going through the SAS screen with the city view haphazardly plastered over it for testing... etc etc
 
Back
Top