Tuesday, May 21, 2013

Slowly chipping away

I haven't posted anything for a while, too much uni, looking for work and other stuff...
But I've been coding here and there... Lots of little touch ups to the Kuba engine...
Many times I've felt like just rewriting the whole thing would be quicker then
just dealing with my horribly written old code (As I've said, Kuba started out
as myself trying to learn Java and how to code a game for the Android OS).

But anywho, I didn't rewrite the whole thing and I've just tried to rewrite
sections of code... I really do think it has made things slower, but I also
think it has taught me some interesting things about coding for Android
that I mightn't of learnt if I just scrapped and rewrote.

One of the biggest hassles I've faced (And I think I've finally sorted),
is trying to keep it looking okay but playable on low spec devices....
I've been testing it on my LG-p500, my Amicroe Touchtab II and my
partners LG optimus L5... Kuba definitely runs fine on my tabler and
my partners phone, but keeping it running at a playable rate on my
LG-p500 has been a bit of a hassle... Currently it is "playable", but
not smooth... It runs fine if you disable dynamic lighting, though a
little jittery at times with the lighting.

Here's a tip for anyone using openGL 1.x for android...
openg GL lighting is sssslllllloooooo-ow!
As soon as I finish this game, I'm gonna go learn ES 2.0.

But anywho, before I made my recent updates, I was feeling that maybe
getting my engine running on anything like a LG-p500 was unrealistic...

The problem with how I wrote Kuba is that it's overly simple...
it builds a map from a 2d array, it stores a mesh, it has a view
range, collision detection, touch input, sounds and state machines...
Not much else... Not very good culling, so a lot of unneeded things
were drawn.... A lot of GL state changes can happen...

For quite a while I had the 50x50 map divided into smaller 10x10
chunks because I though it might speed up rendering and make
the lighting faster... I was wrong... I recently switched to using
one mesh for the map and there are less state changes for the
lighting now... So there is still a slow down for the lighting,
but less of a slow down.

I've also fixed the FOV and LOS code... before every frame
is drawn, a 2d array the size of the map containing booleans has a
quick visibility check drawn onto it.... It switches all tiles that are
visible from the cameras location to true. I've ended up using the
same algorithm that I used to calculate the vertex lightmaps and
it seems to run fast enough to function each frame and really sped
up the engine on my LG-p500... So that's pretty cool.

So the overall check for each 3d model is that it checks if it
fits within some simple dot product checks, then if it does,
it quickly checks if the tile it is on is visible.

The problem with this is unfortunately sometimes an object
is clipped when it is meant to be poking around a corner...
But when I think about the speed increase, I think it's a worthwhile
sacrifice... But who knows... maybe people will be turned off
by this.

Hopefully things will settle down soon and I'll have enough time
to finish the assets needed for the first version of the actual game...

I might post my lighting/visibility code some time soon...
it's pretty simple... not brilliant, but it is faster and more accurate
then some of the other algorithms I've seen for it.
It might be useful if anyone is wanting to create a roguelike...
Which is something I want to do with the Kuba engine after this
upcoming game and before I write a new engine... Wrote myself
a quick dungeon generator which works fine... fits right into the
Kuba engine too... So that could be fun.

Well, I'm off to do some more homework... *sigh*