View Full Version : Experimenting with WebGL...
Runs anywhere under Chrome 18+ (will fallback to software if hardware acceleration is not available)
Runs under FireFox if you have good enough drivers (DirectX or OpenGL)
On Android, it runs under FireFox Mobile & Opera 12 on my HTC Desire.
http://delphitools.info/wp-content/uploads/2012/05/webgl-poc.html
http://delphitools.info/wp-content/uploads/2012/05/GraphWebGL-poc.html
Height field & its normals are computed at runtime from JS, haven't benchmarked the thing in detail, but I'm under the impression Chrome & FireFox both JIT the maths code fairly well.
WebGL isn't ready for high framerate games just yet (other things in the browser can make it stutter for one), and things are missing from the immersion POV (mouse capture, full-screen...) but for games with less ambitions and more static graphics, it is coming close to good enough :)
http://delphitools.info/wp-content/uploads/2012/05/poc1.png
http://delphitools.info/wp-content/uploads/2012/05/poc2.png
http://delphitools.info/wp-content/uploads/2012/05/poc3.png
I have done some experiments with webgl some time ago. it was very buggy and worked only in chrome at the time, but it's obviously getting better now that firefox and opera support it.
http://gen2gdk.com/WebGL/SkinnedMesh/
http://gen2gdk.com/WebGL/Particles/
Both your snippets works on Android too under FireFox & Opera, with Opera having the edge.
The skinned mesh is obviously too much for my paltry phone gpu :/ but particles runs at a good frame rate.
They run on Web TV too.
I've been following the W3C & Khronos groups: Mozilla, Google and Apple are all pushing new standards, so it's just a matter of time I guess until the missing bits for game-oriented usage become widely available (full-screen, mouse-capture, audio API etc.).
Once/if Apple enables WebGL in iOS 6 for widespread usage, that could be a game changer, so to speak.
it will never be as fast as the native compiled executables though, which is why I decided to use fpc for cross platform game development. but you are right, for the small in-browser games this technology is starting to look very attractive.
it will never be as fast as the native compiled executables though.
It depends on the problem and what is used to compile the native executables, f.i. on pure maths like the Mandelbrot set, FireFox and especially Chrome were giving Delphi XE2 a good sweating a few months ago:
http://delphitools.info/2011/09/02/first-look-at-xe2-floating-point-performance/
FreePascal was in the same ballpark as Delphi, but I haven't tried since, it would be interesting to see if it has since caught up with the JS engines.
WebGL and HTML5 aren't designed to compete against native compiled code. However, Webgl and HTML5 offer something that neither delphi or fpc can and that is that the code is running in a browser. At work we are biting the bullet and moving away from Delphi apps and we will be doing HTML5 apps from now on for our in-house business requirements and our education/games software.
one major problem with these apps: they are hard to sell since all the source code is open.
You can't stop people from reading your JavaScript, so consider that part of the game open-source. You can use obfuscation to make it difficult. Design your game in such a way that seeing that code won't matter. Mostly this is done by only implementing the user interface, visuals, and sounds on the client-side; everything else in the game is done on your server and communicated between the client and server using AJAX techniques.
Also have a look at phonegap, I haven't used it but it takes html5 code and makes native apps for various phones etc
Here is a small demo of obfuscation
http://wiseloop.com/demo/php-javascript-obfuscator
I would hate to have to reverse engineer a significant program :D
WebGL and HTML5 aren't designed to compete against native compiled code.
Well that's changing, Google ChromeOS, MS Metro, node.js, that FireFox mobile OS and the direction of new Html5 specs, they are step by step being pitted against native code.
And Dan, there are tens of thousandths html5 apps getting sold, wrapped with phonegap or other similar homemade browser apps. For some the HTML shows through, for the well done ones, you can't tell them apart from the user point of view.
Obfuscation as Czar pointed means that even though you get the code, you can't do much with it, you certainly can't reuse it without an effort that is as high or higher than writing it yourself anyway, especially when before obfuscation, the js went through an optimizer or smart-linker.
I have started porting my game engine to smart mobile studio and it is looking very promising: http://gen2gdk.com/g2mp/demo0/
only around 30 minutes to port the code. which could be reduced to 10 if sms supported operator overloading and some sort of non class typecasting (but apparently that's not possible).
phibermon
20-01-2013, 11:40 PM
Well that's changing, Google ChromeOS, MS Metro, node.js, that FireFox mobile OS and the direction of new Html5 specs, they are step by step being pitted against native code.
It's all a matter of processing power and economics. HTML5 browsers are just slow, buggy virtual machines for a computing platform that never existed.
Drivers tend to be written in C/ASM because every cycle counts when your hitting the limits of a bus. Nobody wants JavaScript Nvidia drivers.
Game engines, same reason again, it takes more work in a lower level language but what you gain is performance.
Which of course, is totally obvious however, this isn't my point.
A web-browser running some javascript code providing access to a HTML5 DOM, is no less capable in terms of coding efficiency than any object-orientated language and a suitable framework/engine to work in.
And the only reason we are seeing the proliferation of HTML5 as a gaming platform now is because of one un-important reason, and two important ones.
The unimportant reason : That the code is portable across multiple platforms.
Why it's unimportant : Good engine code is portable on those same platforms, for native compilation in C etc.
Now the two important reasons we're seeing the proliferation :
A) Certain vendors don't let you release or even write native code, you're forced (will be forced) to use HTML5/Javascript (because it protects their investment, not because it's better for the consumer)
B) Every man and his dog gets into web-development, fancies themselves as a game developer and sticks with the language they know.
--
Now if a game is fun, then people arn't going to care if you coded it in machine code or javascript. (They'd care even less if it wasn't fun)
But if you're on some mobile device, then it does matter because for now, the devices are still fairly restrictive when compared to desktop computers. So coding in a native language for the device or coding in HTML5 is the difference between some laggy version of solitare or some fast and detailed 3D world. (I know that's an exaggeration but the margin is still signifigant, especially when it comes to latency bound operations such as realtime sound processing)
One day it won't matter, the gap between native and interpreted performance will be nothing compared to the upper capabilities of the device.
But for now, anybody looking to get into web-development who also would like to write games, HTML5/Javascript is an excellent choice.
However if you want to be a professional game developer or indeed, are a hobbiest that wants to really understand game development? don't waste your time with a markup language that's more suited to a newspaper layout and a scripting language that was designed for flexibility, not speed.
And yes, I know the goolge JS engine (V8 or whatever) is fast, optimized with JIT style capabilities etc
But do you care? honestly? I mean what kind of claim is that? "Our new javascript engine is only 3% slower than native code!"
So it's still slower than native code? and I've gained absolutley nothing but some exotic language features that are useful in the abstract but of no use when it comes to mathematical algorithms. My language is already turing complete thanks and I'm a game developer, I need to be next to the hardware, not waving at it from across a river.
pstudio
21-01-2013, 06:18 PM
So how do you guys use WebGL in SMS? Last time I looked I couldn't find any support for it. Are you basically just using a lot of javascript or have they added support for WebGL?
as far as I can tell sms has everything you need to work with webgl, a header file (an import unit is what they call it) that connects all the webgl calls, typed arrays, though a bit buggy right now but usable. they even have a demo which should cover most of the basics. and where sms just doesn't work for you, you can always make a patch with inline javascript.
pstudio
22-01-2013, 11:51 PM
Thanks Dan.
I downloaded the latest beta and found Eric's demo. It was missing two custom units, so I had to download the demo from Eric's site to get it working.
Maybe I'm just not looking at the right places, but I sure miss some documentation when looking at SMS. Where can I for instance see all the units that follow with SMS? I would never have found the w3c.webgl unit if it wasn't used in the demo.
you can find all the units included with sms in the installation folder in rtl. but yes the documentation is one of the weakest points of sms. you can find a small documentation on their website and they also sell a book that may cover a few more aspects of the ide. btw, a new beta is out, hopefully it fixes that operator overloading bug.
I have partially ported one of my older games to sms. there is still no sound and the profile saving/loading doesn’t work so the game progress will reset when you close the game. but otherwise it’s quite playable, even on opera which is generally slower than chrome and firefox.
http://gen2gdk.com/g2mp/gemmaster/
the game was made for the mobile devices so some of the buttons may seem huge in the browser.
alright, now the sound and saving/loading the profile works.
Dan, the game you posted is quite nice, but I didn't work on my iPhone, nor on Samsung Galaxy. I thought mobile Chrome browser would support WebGL?
And what you guys mean by SMS?
the sms is short for smart mobile studio, it's a tool that basically compiles object pascal into javascript, you can find more info here: http://op4js.optimalesystemer.no/
I do not use sms to make apps for mobile devices, I use fpc for that: https://play.google.com/store/apps/details?id=com.pascode.gemmasterdemo
on android only opera and firefox support webgl (with opera having the edge), but the performance is still very poor. as far as I know iphone does not support webgl.
SilverWarior
28-01-2013, 02:17 AM
When you see SMS here on PGD it is meant as Smart Mobile Sutido (http://smartmobilestudio.com/) and not Short Message System as wee know it from mobile phones.
BTW I think it would be best for PGD users to not refer to Smart Mobile Studio as SMS as it is just creating confusion amongs oters especially becouse SMS is often used in todays lives but as I sad before stands for Short Message System.
BTW I think it would be best for PGD users to not refer to Smart Mobile Studio as SMS as it is just creating confusion amongs oters especially becouse SMS is often used in todays lives but as I sad before stands for Short Message System.
Yeah, I've actually looked it up first on Wikipedia, which had many definitions (http://en.wikipedia.org/wiki/Sms), the closest one being Systems Management Server. :-[ Google search with "WebGL SMS" didn't return any useful links neither.
But you could have taken a look at the forum section name instead ;)
SilverWarior
28-01-2013, 06:50 AM
Google search with "WebGL SMS" didn't return any useful links neither.
That's becouse pepole first started refering to Smapr Mobile Studio as SMS in PGD forums. Even Smart Mobile Studio developers don't refer to it as SMS.
So since Google sorts their results based on keyword popularity there is no way it would return any usefull results.
But you could have taken a look at the forum section name instead ;)
You could in this thread but the fact is that SMS has been used in several other threads on the forum already. So looking up to forum section in those threads wouldn't be of any help.
When I first saw Smart Mobile Studio refered as SMS I needed to read whole thread to figure out what it stands for. And this was only posible becouse I'm monitoring every thread in every section of this forum. So basically I know everything that it is going on on the forums.
But if I had a problem to understand what SMS stands for in the first place and I do know everything what is going on on the forums imagine how difficult it might be for someone who is new to the forums or isn't monitoring the forums so closely as I do?
That is why I suggested that PGD users avoid using SMS when refering to Smart Mobile Studio.
You could in this thread but the fact is that SMS has been used in several other threads on the forum already. So looking up to forum section in those threads wouldn't be of any help.
sure, I would never use that abbreviation in a thread not related to smart mobile studio. however, in this particular context I think it makes perfect sense.
also if you use that abbreviation on the official SMS forum everyone would understand what you are talking about.
every compiler or an IDE that has a long name is often referred to by a short abbreviation: fpc (free pascal compiler), gcc (GNU compiler collection), vs (visual studio) etc.
so why can't we do it here? it's not our fault that the abbreviation turns out a bit confusing for the unenlightened.
SilverWarior
28-01-2013, 09:36 PM
so why can't we do it here? it's not our fault that the abbreviation turns out a bit confusing for the unenlightened.
The goal of our forum is to atract as many pepole as posible. This also include what you cal "unenlightened" pepole.
So tell me how many pf theese pepole would stay here if they won't have idea what we are talking about?
It is the same as if you would try to read some scientific paper which heavily uses scientific terms. For such paper you usually need a dictionary to understand it or be a scintist in that area yourself.
So wouldn't it be easier to read such paper if it is writen in layman terms?
SilverWarior, please note that I did not disagree with you. out of the context the abbreviation would make no sense. however, if these people that you are talking about are unable to decipher the abbreviation in the context of a topic where it has been mentioned several times or are plain lazy to read the entire thread, then it is their own fault. but ok, consider me convinced since smart mobile studio is still a fairly new tool. let's not go off topic any further.
phibermon
29-01-2013, 10:17 PM
I've examined the output of this converter and while it does an admirable job of optimizing the conversion of Pascal to Javascript, when concidering the limited performance of mobile devices and the relative slow performance of javascript/html5 compared to native executable binaries, you're sacrificing a significant part of your potential performance by using this.
That's not to say that I don't believe this is capable of creating games for such compatible platforms, but it'd be a hell of a shame to design an engine, code most of the game and then find out that you haven't got the cycles left to do what you need.
Plus there's the fact that there are optimized internal operations and language features that can't always, and sometimes just can't; be exploited by a pascal conversion because there's nothing comparable in the language.
I'd recommend anybody writing games using this software make the effort to make as much as the code compilable in Delphi/FPC as possible, that way if you do hit a wall, the option of switching to native code won't be so hard.
I'd recommend anybody writing games using this software make the effort to make as much as the code compilable in Delphi/FPC as possible
as I have mentioned before this is exactly what I did. I only use smart mobile studio to port my games to html5.
I do not use sms to make apps for mobile devices, I use fpc for that: https://play.google.com/store/apps/details?id=com.pascode.gemmasterdemo
phibermon
30-01-2013, 06:06 PM
Oh my apologies Dan, I already know you're an experienced developer, I only mean to try and present more views for any budding developer learning about game development, I should imagine there's more than a few OOP coders looking to create games for mobile devices and SMS offers such a reliable and easy way to target the platform, with the added benefit that SMS can help them deliver a wide range of web apps.
I simply wished to express the opposing view so that those making long term decisions are armed with all the pros and cons, It's important to consider the future of a project in relation to the limitations of your target platform, it's somthing we all learn and I wished to decrease the size of folders titled 'abandoned projects'
--
I will re-itterate in the interest of balance that SMS can be used to make a wide range of game styles that'll run brilliantly on many mobile devices. It's very well made and has an intuitive interface that many IDE's could learn from. Hopefully it'll continue to get better and better as web standards evolve, I am of course utterly thrilled to have any representation of Object Pascal in this world.
Oh and your demos are pretty sweet btw, skinning running well on my system. I've not had time to examine your shaders (I'm gearing up for a release of Jink, previously JenJin, previously VFA, in the next few months) are you using per-vertex/mesh animation, or bone/armature animation? if bones are you using matrices, quaternions or double quaternions for the translation/rotation? particle system runs well too, Are you rendering your billboards from a list of vertices in system memory or are you ping-ponging a VBO between frames?
the first two demos I posted are actually made with pure javascript, and it was quite a while ago. I mainly wanted to see how advanced webgl was (and it was pretty buggy at the time).
the skinned meshes are done using bone animations with matrix transformations. the billboards are done using a shader pseudo instancing so there are no changes to the vbo at all.
I also agree that for any serious projects for mobile devices, javascript is just not fast enough. so it's best to be able to do both the javascript and the native binary.
It is all about the right tool for the job. We initially looked at Smart Mobile Studio to create an online education product that would also work with iPad and Android. We thought of SMS so we could leverage our pascal coding skills. We then decided to go with HTML5 instead (HTML/javascript/css3). This too would have been ok, however, we are now using contruct 2 which still compiles to HTML5 (WebGL etc) but doesn't require much in the way of coding. I estimate project that would take us 4-5 weeks to complete using standard coding only take a week to do with Construct 2. Our current project looks like it will be completed under budget and under time by a fair amount which means we can afford to invest more money in extra art assets.
To get back to the point Javascript and WebGL works well for some projects. Personally HTML 5 has so many big plusses it makes it very attractive to use. Wether it is business apps or casual gaming/ educational software the idea that you can write once and then more or less distribute to pc/mac/ipad/android etc is very nice.
I have ported the 3d capabilities of the engine: http://gen2gdk.com/g2mp/demo1
I bet that's something that construct 2 cannot do ;)
That last WebGL is cool in many ways!
I also agree that for any serious projects for mobile devices, javascript is just not fast enough. so it's best to be able to do both the javascript and the native binary.
It's a mixed bag TBH.
On the desktop, Chrome V8 can run right up there with .Net, Java and Delphi in most scenarios, and I've occasionally seen it pull some stunts that required use of ASM to beat with Delphi or FreePascal, especially on floating point tasks. FireFox SpiderMonkey has nice tricks, but is often lagging behind V8.
On mobile platforms, the king is iOS Safari, for some reason Chrome for Android's V8 doesn't seem to be in the same league as its desktop brother, and Chrome for Android generally isn't quite up to iOS standards in the web graphics department.
When graphics are involved, Safari can really push the pixels, pity Apple still hasn't enabled WebGL... Given what I've seen with CSS 3D demos, guess having WebGL in Safari would get the browser competitive with most apps, with only special cases out of reach.
Also node-webkit really shines on the desktop, it starts instantaneously and performance is as good as, if not better, than regular Chrome (they don't have the overhead a proper browser has). They have plans for mobile versions, I'd really like to see if their Android one could run better than the classic PhoneGap approach or Chrome for Android.
I currently have a non-game related project underway, a plant floor scheduling Gantt chart, being developed in SmartPascal. The graphics are 2D, but involve a lot of under-the-hood trees, hashes, lists and other high-level structures, light on maths but heavy on graph logic, and so far HTML+JS holds its own at least as well as Delphi would IME, and better in the graphics department. Tendering is all anti-aliased Canvas, with paths, brushes, gradients... and everything is properly hardware accelerated AFAICT on the usual suspects. And it runs everywhere "out of the box", which is mighty comfortable.
In my case the main point of interest is high performance game development, so I have to use direct3d, opengl, gles, webgl for the graphics. unfortunately, webgl is basically nonexistent on ios platforms so there's nothing to even talk about here. on the android you can compare the performance of the latest demo I posted and its binary equivalent http://gen2gdk.com/files/g2mp_demo0.apk. so I am convinced that for the mobile game development the native code has an edge over html5. however, html5 is still an awesome platform since it works in the browser, and on the desktops the difference in performance is negligible. personally, by using my game engine, I get the advantage of being able to compile both the native executables (fpc + lazarus) and the html5 javascript (smart mobile studio).
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions Inc. All rights reserved.