>Most of your graphics primitives should already be targeting OpenGL ES 2.
My engine had a chance to rot for a while; I'll be upgrading to GLES2 as soon as I'm developing on it again. (Pesky clients paying me to do other work has been slowing down development on my game and engine.)
That is one of my hesitations about Proton; they're still on GLES1.
>This would enable your engine to target HTML5 robustly with Emscripten via lua and sdl.
Not a bad thought. Hmm. Not a bad thought at all. In fact, part of the game I've been trying to work on involves an HTML component, and I've been planning to do it in JavaScript, but if I could do it in my own engine...wow. Thanks for rebooting my brain there. :)
>Is your engine open source?
Not yet. There are a (very few) parts that I don't want to publish, for reasons from "they're broken and I want to fix them first" to "this class prevents pirates from copying games in a novel way, and publishing it would just make it easier for them to pirate my games."
My current code is pretty trivial; dropping in a pair of standard shaders and tweaking the code would probably be sufficient.
WebGL is interesting, but it only just got support in IE11 [1]. My only current project with a web requirement would need to support older browsers, including older mobile browsers, and Safari and Android browsers also lack support.
I'd be very surprised if you had a seriously novel method of avoiding piracy. I get the desire to do so, but realistically, not so much. (If only because they just have to find its code and nop it out.)
You can be surprised if you like. But it was novel enough to prevent my game from ever being pirated. [1]
>If only because they just have to find its code and nop it out.
If they changed a single byte in the executable, then none of the encrypted data files (i.e., the actual game) would load. I used a cryptographic key generated from the signature of the binary.
More than one byte would need to be changed. :)
I know I just raised the bar, but due to that feature and the additional obfuscation and misdirection I added, no one ever cracked it. I'm sure that the bar has been raised higher on commercial PC apps (self modifying anti-debugger code comes to mind), but what I did was at least novel on Android.
My technique was dead in the water on iOS, unfortunately; Apple mucks with the binary (encrypts it?) in the production version. But no one pirates on iOS anyway, right? ;)
[1] Successfully, I should say. Pirates thought they'd hacked the game and uploaded it all over the various pirate web sites multiple times. Thing is that the game always detected that it had been pirated, and as a result it downgraded to the "free demo" behavior, so people downloaded the same app they could have gotten for free from the store.
Why don't you make that a product? Esp the downgrade to demo, it is a great feature.
I am sure you could take the signature of the executable in memory and create a key from that for iOS? You just can't _write_ to executable memory but you can read it.
My engine had a chance to rot for a while; I'll be upgrading to GLES2 as soon as I'm developing on it again. (Pesky clients paying me to do other work has been slowing down development on my game and engine.)
That is one of my hesitations about Proton; they're still on GLES1.
>This would enable your engine to target HTML5 robustly with Emscripten via lua and sdl.
Not a bad thought. Hmm. Not a bad thought at all. In fact, part of the game I've been trying to work on involves an HTML component, and I've been planning to do it in JavaScript, but if I could do it in my own engine...wow. Thanks for rebooting my brain there. :)
>Is your engine open source?
Not yet. There are a (very few) parts that I don't want to publish, for reasons from "they're broken and I want to fix them first" to "this class prevents pirates from copying games in a novel way, and publishing it would just make it easier for them to pirate my games."