Jump to content

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 sh
  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() in
  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 (somethi
  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 con
  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
  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
×
×
  • Create New...