After reviewing the rules I decided to challenge myself, I will be using a custom engine written from scratch (starting after this post), this is allowed in both the compo and the jam (source code will be provided regardless).
If that fails (which, realistically, it could) I’ll use SDL and box2D, even then my source code will be provided.
I’m not entirely certain what featureset it’ll support but it will be basic, I want to challenge myself by not having fancy features available.
Probably will have shader support though.
Anyway, I can’t be wasting time here! I have an engine to write.
And it looks like I’ll still be using a custom engine, aside from a 2 day struggle with emscripten just refusing to work and some… err, minor setbacks I’m still somehow on schedule
The rendering code I need has been written, I need to write some more complex shaders and some AABB bounding box intersection code for physics but other than that I’ve written almost the entire engine (well, I still have sound support but that’s optional I can always just rush in mp3 support for looping bgm and not use sound effects, that works I hope).
Now if emscripten would just accept my std::vectors that’d be lovely, of all the things that break one of the critical data structures has to be one of them. bloody hell.
And I wrote such nice shader compilation code too (ha! told you I’d use shaders)
Ah well, I filed a bug report, if it’s not an emscripten bug it sure as hell is a documentation bug, I read it cover to cover and nowhere did it say that vectors are defunct.
I suppose I should convert my logging function to use C style arrays instead of vectors, I can’t really test my code without the debug logging (and it would never be invoked during normal gameplay so that’s fine, the only way it would be invoked is if shader compilation or linking failed; something that won’t happen past release because I test my shaders :3)
Ah well so far so good, I really enjoy crunch time; so much gets done.
I’m not entirely certain how I can pull data from the vertex shader into the fragment shader, after writing a quick test shader and butchering it until it worked I didn’t manage to pull vertex colors.
But that’s fine, that’s actually fine. This works too; I just have to be a bit more peculiar about it (I WAS going to pull vertex colors as a lazy way to color sprites because that would save a huge time), if I can’t get my engine to support that I’ll just work around it.
(webgl shaders are essentially GL ES 1.0 shaders and they don’t support in/out or inout)
Regardless, still in.
On the bright side, there’s no API I could possibly know better than that of my engine, I wrote it after all (in two days nonetheless!); it’s deceptively simple with only
fivefour graphical functions.
Textures (global resources set up for use by sprites, tiles and shaders).
add simple bounding box intersection physics and a very crude SDL2 audio wrapper and you have yourself a deceptively simple engine with a potentially huge power:simplicity ration (because shaders, all the magic happens in the shader code… and it’s not that interesting, it’s really rather close to the reference implementation because the OpenGL documentation is very robust).
Also licensing. I have to figure out if the ludum dare supports the CC-BY-NC-SA license, because when I invariably release my source code I will release it as such, it’s for people to learn from, not earn from.
Anywho, back to coding, if someone has a clue as to how one would solve my shader predicament that’d be lovely but in worst case I’ll just not use vertex colors, that’s fine too.
I need to finalize my interfaces, do a bit more unit testing and polish up my audio implementation.
And that about sums up what I’ve been up to recently, that and a ton of procrastinating prior to four days ago 🙂