GLESGAE


Just made a rather viciously large commit, that adds much of what I mentioned above, and has graphics being displayed on screen.


It works on Pandora too... and I have proof!


120220-141610.png



Slightly mangled in places.. but it's getting there.. hopefully Craig doesn't mind me pinching it, and I'll hopefully have a playable build by the end of the week, if he's not averse to me doing so ;)


There's a few more weirder Canvas and Image binds to do, then onto the timer functions, rather than doing "while(1) { doEverything!!!! }" which is what it currently is *cough*


Afterwards, it's OpenAL support, then that should be enough for the time being, and I can start on my game.
 
Wow, great stuff! I see HTML5+JavaScript world domination occurring very shortly. ;)
 
i can see you getting a lot of fame when the right channels get aware of this :)
 
All graphical glitches are now fixed ( flipping texture flipping madness.. OpenGL expects it one way, and the HTML5 spec expects it another... ) so just the timing bit to sort out and the input, and it'll be runnable, but silent.


( Well, fixed on Linux.. haven't fully tested on the Pandora as yet... )


I will point out that GLESGAE's a bit of an oddity in that I'm trying to make sure it provides functionality to do things, rather than declaring "this is how it's done."


For example, the binding stuff can be compiled as an entirely separate module, and the whole rendering system is open enough to be able to support other platforms just by wiring a few bits together... so there'll need to be some application to wire it all up and provide a rendering context and things, much like how the two example applications run already.


The plus side is that it makes it really easy to extend things as needed, so customizing an application to do something special should not be too hard.. like network support, for example.
 
Last edited by a moderator:
Really nice work! Its going to be interesting to see where this goes once you get things stable and functioning acceptably ..
 
I have it running relatively well on Pandora now ( and fullscreen too ) ... it does slow down when there's lots of sprites on the screen, but I've not really optimized anything yet, and it's creating new vertex data every frame, per sprite, so the fact it runs as well as it does is pretty nice.


That said, it could be fun to try and optimise that, as each sprite doesn't necessarily get a transform - they more just get splatted directly on the canvas, so the transform is essentially an identity matrix, and the values are hard-coded into the vertex buffer. Not nice.


Some fonts are still a little mucked up, but I've a feeling this might be me not using ICU for the text encoding... so I might recompile that soon.. the fonts are correct, it's just displaying R instead of a space in some places.


I am also having issues with the getImageData function on the Canvas, which is meant to return a chunk of screen data, except I can't seem to get this behaving itself properly. There's also a putImageData function, so I'm thinking I'll bind that one up and get it to ping pong a bit; see what crap it's producing.


Unicycle Jetman uses getImageData for it's terrain collision detection, so it's going fixed for that at least.


Still no sound, but input works - which includes mouse, keyboard, nubs and buttons - along with timers, so it's getting there.
 
Hmm.. I now see why accelerated HTML5 can be such an absolute pest!


A canvas is a bit of a weird object in that it has a width and height, and a context.


A context is, of course, what you draw to.. and here within lies the fun problem!


If you have just the one context, it's straight-forward as it maps up (more or less) to your sole GL Context.


If you have multiple contexts, then it gets somewhat trickier... effectively they should really be FBOs that get switched about depending on what context is being drawn... however, FBOs are an extension to ES 1.1 and only guaranteed in ES 2.0 ( and on all iOS devices, funnily enough, ) so that can cock things up a bit if I do want to stick to ES 1.0 for the majority of it. I could use the EGL PBuffer support, which more guaranteed to be there on ES 1.0 devices, but complicates things a bit as it's still a bit device dependent, as each device can have different versions of the EGL spec.


It gets more fun when the Canvas specs also effectively expect immediate mode rendering...


Ironically, all this means that it would be easier to do all this in SDL rather than OpenGL...


Anyway, this is what I'm up to.. dealing with multiple canvases/contexts, as Craig uses a secondary one ( which I managed to not notice ) for collision detection with the world, so I need to figure this one out first.


There's also a fun bug that if the Window resolution is different from the Camera Orthographic resolution, when you redraw something you've just grabbed from the context, the sizing is very much completely off.. so I should probably fix that one too.


At least as it stands for simple things, it's workable. Just for any multiple context/canvas malarkey, it's a bit puggled and needs more work.


-edit-


Removed all weird HTML coding that crept in for some bizarre reason.
 
Last edited by a moderator:
Well, I'm way behind where I would like to be with this...


I've just made a large commit with a large amount of input, image, and canvas bindings.. though there's a problem with get/putImageData in that it seems to cause JavaScript to leak memory like sweeties ( from what I could piece together from Valgrind, it seemed to be in JavaScript, so probably a garbage collection issue. )


Either way, I still need to add Audio support, and add a few more basic things before I can start my own project.


I've not started on the framebuffer stuff yet, as I won't directly need it for my own project, and with time running short, I think I'll re-target to what I need just now!
 
Hi Stuckie I was wondering how far you got with this project since I was looking forward to using this to write a JS/Html5 game :)
 
Back
Top