Just saw this, Tirnua uses Flash, does not use any hardware acceleration and is just bad in general.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.
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.Afr0 said:Nice!
I really like your city rendering!
Still, the issue remains how you would distribute the installation files to users
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.htmlRHY3756547 said: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.Afr0 said:Nice!
I really like your city rendering!
Still, the issue remains how you would distribute the installation files to users
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?
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.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.
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.