Boris van Schooten

Members
  • Content Count

    18
  • Joined

  • Last visited

  1. Finally got round to publishing gles.js. It's now available on github! https://github.com/borisvanschooten/glesjs
  2. @BdR, It's not compiled no, though that is my approach in the original JGame project. It uses my homebrew HTML5 renderer gles.js, which I developed with the goal of being smaller, faster, and smoother than the usual renderers. So far, it's done a pretty good job. This renderer is not yet available to the public but I hope to release it next week, as I will have more time to add stuff like docs appropriate to the target audience.
  3. @cheesepencil: I fixed the music toggle bug. Thanks again for reporting it! I could not reproduce the sound toggle bug though. @MesmerismJS: Thanks for the feedback! I am using conventional controls. What controls do you refer to: mouse, multitouch, or gamepad? Do you have a suggestion for improvement? About gles.js: It's not been released yet. I want to fix some small things, so that it's actually useful to others. In particular support for phaser style bitmap fonts. What toolkit are you using?
  4. Hi @cheesepencil, Thanks for the feedback! Could you tell me what browser + version you are using?
  5. Super Pyro Runner is an open source endless runner with emphasis on shooting (yeah!). It started as a tile engine test for my new 2D game engine/framework jgame.js, but it got a little out of hand. This is also my first source release of jgame.js, which is a revised port of JGame. Note that most of the game's graphics are procedurally generated. Play the game here. Get the Android version on Google Play (based on gles.js). Get the source here. UPDATE: it's now on the Ouya appstore as well.
  6. I now got a partial implementation for Ouya, enough to purchase entitlements. I put the API under window.navigator.paymentSystem. Yes, my WebGL implementation checks for Ouya hardware to determine system type (currently either ouya or none). If it's not available, a piece of JS code can detect other payment systems (such as clay.io). The code in my game now looks something like this: // init if (window.navigator.paymentSystem && window.navigator.paymentSystem.getType()=="ouya") { window.navigator.paymentSystem.init(ouya_developer_id); } // call this at your paywall or for showing your "play full game" button in the main menu if (window.navigator.paymentSystem && window.navigator.paymentSystem.getType()=="ouya") { if (window.navigator.paymentSystem.checkReceipt("full_game_purchased")) { //give access to full game } } // call this when users clicks buy if (window.navigator.paymentSystem && window.navigator.paymentSystem.getType()=="ouya") { window.navigator.paymentSystem.requestPayment("full_game_purchased"); }
  7. I am working on WebGL for Android/Ouya, and I wonder if it would be nice to have a universal html5 payment API. Since there's no such thing as a W3C or a de facto standard for it (unless I'm mistaken!), I figure I'm just going to create something myself. I want to keep it as simple as possible. I want to start by creating a wrapper around the Ouya API. I also looked at Clay.io and Google Play. I think I can distill a simple API from these three systems that covers the basic functionality. Here's my first try (note, return values are Java style). PaymentSystemID detectPaymentSystem() initPaymentSystem(Secrets) requestPayment(ProductID) boolean checkReceipt(ProductID) ProductID [ ] getAllReceipts() consumeReceipt(ProductID) ProductInfo getProductInfo(ProductID) The main idea is that you get receipt statuses through checkReceipt and getAllReceipts, which will cache the result locally so you can call it 60 times a second in your game loop, and it will return something even if the user is not connected. requestPayment just sends out a request to start the payment dialogue, which will eventually lead to checkReceipt becoming true. My hope is that any user login processes and payment dialogues can be handled entirely behind-the-scenes. The Secrets, ProductIDs, and ProductInfo are payment system dependent. You can use detectPaymentSystem to get the system currently in use. Clay.io also has a shopping cart feature, which is not exposed through this API. Not sure that's essential. Does anyone here have any thoughts on this? Any particular payment system that you use or is often used? Or maybe this has already been done by someone else?
  8. Update! I got most of pixi.js examples and the first phaser example game running in gles.js. The pixi and phaser engines run without any hacks in the code. Check them out on the website.
  9. @ashley, Sure, I hope we won't be forced to write our own homebrew wrappers for html5 for long. You can wait for 1 or 2 years for someone else to fix this problem, but I certainly won't wait. I've already made a release of my first Android html5 game, so for me the wait is over. But since it's mostly C2 users that take a keen interest in my little project, I was suggesting that maybe you can cater to your users better by implementing a layout-by-layout loading option for canvas2d. That is, set Image.src only at the beginning of a layout, and drop the reference at the end.
  10. Memory management can mean a lot of things, but I think you are referring to image loading in C2? I looked it up. It appears C2 creates textures at the start of a level (layout) and deletes them when a new level starts (layout-by-layout loading). At least, when WebGL is used. See the link here. For Canvas2D, dynamic loading of textures is left to the browser/display engine. In all cases though, C2 pre-loads all images at startup by defining and using all Image objects in the entire game once. This is done to hasten the slow process of loading from the internet to local (disk) cache (something not really needed for apps running from a local filesystem, I think). Again, they rely on the browser not to load all the images uncompressed into memory, and either store them on disk or store them in compressed form. Apparently, regular browsers have memory management that handle this well, so they stick to this approach. See the link here. I think the image pre-loading causes CocoonJS to load all assets into memory at startup of a C2 app. This will also happen if WebGL is used. But CocoonJS can do dynamic asset loading, and there is even a CocoonJS-specific Image.dispose() function that prioritises unloading an image. See the link here. This suggests C2 can do better in terms of Canvas2D dynamic loading for apps that run on the local filesystem (do layout-by-layout loading by defining images only per layout), but they choose not to implement it, because they believe this is the browser's problem. A similar problems seems to occur with other engines like Ejecta, which apparently load images into memory as soon as they are defined. Gles.js has no such problem, because it does not load anything into memory unless on demand. In gles.js, an Image is just a dummy object that stores only the filename. Image data is loaded into memory only when a texture is explicitly loaded with texImage2D, and the original data is immediately discarded again, so that only the texture remains in memory. This ensures minimal memory usage, at the possible expense of extra load time (it currently loads from local filesystem only, for actual URLs a caching scheme would be desirable). About Crosswalk, afaik it's just yet another Chromium wrapper, so I don't expect it to be much different from Chrome. Except that you can disable the gratuitous blacklisting behaviour in your wrapper. But I will try it when I find the time. Maybe there's someone here who already uses it who can try to compile my game?
  11. @joannesalfa, Great to hear it also works well on other tablets. I can tell you that not only old cheap tablets have blacklisted GPUs in Chrome, but also new expensive ones. It seems to miss a "gpu reset notification" feature on many tablets. This is some security or robustness feature that it insists on, which needs override through the ignore blacklist option. I can explain a bit about how APKing works. The APK contains an Android app that is basically a wrapper around the V8 Javascript engine. V8 can execute JS, but misses the browser functions. No graphics, no DOM, not even a console.log function. The wrapper interfaces with the V8 internals through (fairly convoluted) C++ calls. Thus it creates new JS functions inside V8 that lead back into C++ functions that do the graphical stuff / browser emulation. Then it feeds JS source code into V8 for execution. The APK is just a glorified ZIP file (you can probably unzip it with you favourite zip tool). It contains the app binaries (the "browser") and a data directory (assets/) that holds the "website" . When started, the app looks for a file assets/index.html, and will use assets/ as the base directory for loading scripts and resources. Creating an APK from a html5 game is done by simply putting your own game files in the assets/ directory and APKing it. Unfortunately that can't be done with a regular ZIP tool, because it needs to be signed with a personal key (and aligned), so you need the Android SDK for that. I think CocoonJS uses the exact same scheme, only they provide a convenience cloud compiler for APKing.
  12. @Tumira, I'll take a look at Construct 2 examples if I can find them. Audio is currently based on the audio element, but Web audio API is in the pipeline if OpenAL cooperates. Do you have a particular game/app that makes good use of the Web audio API that actually has added value over the Audio element? As with WebRTC, I need use cases to see if it's meaningful on mobile and how it should be efficiently implemented. The input bug is actually a feature, unless you see something else than I think you see. That is, it's a relative control scheme to make the game more playable. Movements of the finger (on any part of the screen) are translated to amplified movements of the mouse/cat. @joannesalfa, You mean, if my Nyan Cat APK somehow depends on another package like Phonegap or CocoonJS? No, it's just the V8 engine and a small piece of C++. Phonegap seems to depend on WebView (I haven't tried it yet), which means you won't even get WebGL on KitKat, and CocoonJS wrappers are huge, so I don't think that's even possible. I remember getting a 10Mb APK out of their cloud compiler, but last time I tried it was 22Mb (both with the "WebGL/accelerated canvas" option). I guess a release is due so you can play around with it yourself.
  13. @Tumira, I am planning to add support for the most popular monetisation services. About WebRTC, I'm a bit skeptical about its maturity. Can you point to a couple of killer example apps/games that use it?
  14. Finished coding basic support for DOM, input, and sound, and a few more GL bindings. I just got my first game running on it! Check out the APK on the website.
  15. OK guys, I guess I just have anecdotical evidence, but I have a growing impression that WebGL on Android is still in a sorry state. When using Chrome on Android, I often had to click past the part that says "here be dragons" "careful, these experiments may bite" before I even got WebGL at all. That's not just on my crummy tablet, but also on top tablets like the Samsung Galaxy Pro Tab 10.1. After I do, performance ranges from bad to reasonable. My experience comes mainly from games at html5games.com and playzap.net, and my own games. Most run at unusably slow frame rates (like 5fps) on my tablet. It seems that, as soon as you have a screen-filling background, performance drops through the floor. On my tablet it runs the 10,000 sprite demo at like 10 fps (relatively good actually, though with hiccups). For what I've seen, gles.js runs consistently faster than Chrome. It appears that the only WebGL alternative is CocoonJS. That is, PhoneGap and Ejecta-X don't seem to support it. Please correct me if I'm wrong. I previously tried CocoonJS on a couple of my own apps, and I was disappointed with the performance, though it was faster than Chrome. But why is performance so much worse than the Java OpenGL apps I made? You seem to find this puzzling, so did I. I also tried the 10,000 sprite demo on CocoonJS. I waited the 4 or so minutes that it takes to compile and download, and I got a 22 megabyte APK. All it does however is crash right after the splash screen. I searched for the error for a bit and found this: http://support.ludei.com/hc/communities/public/questions/200762527-Not-Able-To-Get-Past-Ludei-Splash-Screen-On-The-Cocoonjs-Complier-For-Android Not very encouraging. Neither is the 22 Mb file. I remember I used to try and keep APKs below 1Mb, because device space used to be so limited. And the google play apk size limit is still only 50Mb. Anyway it seems I am not the only one with issues. http://www.html5gamedevs.com/topic/7478-cocoonjs-game-performing-worse-in-webgl-than-in-canvas-mode/ http://www.html5gamedevs.com/topic/3980-common-phaser-cocoonjs-issues/ OK, enough talk for now, back to coding!