I had set myself a goal for today of loading a texture and throwing it up on the screen.
After uploading my video to YouTube yesterday, I noticed that the first two related items were in fact very related! I had watched the first of these previously, and found that I agreed with a lot of what the guy said and found the rest to sound like useful tips, so it's good to see an updated talk.
The 2009 Google I/O Android Games Talk:
The Updated 2010 Google I/O Android Games Talk:
So I watched through the second one of those and was feeling pretty good about myself. Then I got to work.
What seemed pretty simple turned out to be waaay more complicated than I thought it
needed to be. I eventually found the documentation and the buried newsgroup post that explained the hoops I needed to jump through to find things in Java and then open them up in C. I think I'm getting a handle on this JNI thing, but I sure wish there was a bit more documentation sometimes (ironic, considering how much I was praising it earlier). For example: that there is a function to convert Java strings to C strings, and how to actually invoke it: neither of those was very obvious.
So, anyway, I did eventually manage to get a bitmap loaded, but only just now, and not in time to render it to the screen.
So, after all that was said and done, I did actually accomplish a few things, despite not having any visual progress forward: I figured out how to get where my file lives in code, figured out how to read files embedded in it, figured out that I have to name all my files .png or .mp3 so they won't be compressed so I can open them some goofy way to pass them to my Native Code to fopen there.
Figured out how to set up GL to draw a texture and to (sort of) query the gl Extensions string. I'm still not sure how you do the equivalent of glGenTexture in GLES1.0. But... maybe that's not needed. I'll have to double-check; I recently saw somewhere that Android 1.6 supports 1.1, so hopefully by the time I'm done those 1.5 devices will all be gone... right?
Here I am being all technical again. In the downtime I had not directly researching Android stuff or spent coding/fighting, I did get to do some design work. I had a few great ideas, and I think I sort of like them. I dove into some UI diagrams to make sure I wasn't over-complicating things, and then I spent some time layout out a few game menu screens. I like what I came up with!
I also like that I'm trying to analyze the decisions I'm making from a few different perspectives. I want to give the player the option to change item x to alter their strategies some, but I'm afraid it might be a little too powerful/easy/boring to always be changing it. So I want to limit the frequency that it happens. The first thought was to give the player an incentive to keep it the same, but that's no good because it essentially becomes punishing the player for switching to a more tactically sound strategy, and in fact encourages players to not switch their x around, stagnating the creativity and movement I wanted to have. So, I think the user will just have some slowly replenishing resource they have to use to change the thing. I've been thinking of something similar for other decisions, so really it won't be a big deal and should fit in. Also - hmm, maybe I should in fact push the player to switch up their x by punishing not changing it rewarding changing it. I originally thought of this as "let's make strategy x' weaker the longer they use it," but of course psychologically that's a terrible idea, and nowhere near as good as saying "let's make strategy x'' stronger for a brief period after switching to it!" Same numbers behind the scene, different net psychological effect. So, ooo great, another idea!
Thanks, blog.
Leave a comment