Well, since the last post, I have made quite a few accomplishments (although they look short compared to how many hours have passed)
1. The spools and menu items now move correctly. For the longest time, I was using the direct movement of the user interaction to change both. The reason that is bad is because the spools need increments of 30 while the menu text needs increments of 44. What the code is using now is: the user's interaction is controlling the spools directly and the menu items are taking that number, diving it by 30, then multiplying it by 44. To the user, they move at a 1:1 ratio, which is how it should look.
2. On the note of movement requirements, the spools need movement increments of 30 (which is treated as degrees). To spin the spools, they need radians (damn those pesky things). So, I made a function which does the conversion within the spool class to deal with that. Now the spools spin smoothly with the user instead of spinning at the slightest touch.
3. (not visible in previous releases due to the lack of movement precision). When moving the blocks up/down, after a certain amount past the other blocks, the next block will active (light up). This was done by checking if the user has scrolled 2/3rds past the middle point. This was not only discovered today but also fixed today. :-)
4. The menu items are now more descriptive on what is selected (by flashing the selected menu item). I don't know how to make animated screen shots from the emulator, so here is 3 pictures. The flashy text fades brighter than normal, then fades below normal, then brightens back again above normal. This continues while the user is scrolling and automatically starts flashing the new menu item when it's selected.
4b. The "GO!" button fades out when moving. The button still doesn't do anything, but at least it looks less static.
5. When spinning the blocks, often the lit up block would not be in the middle. Now I am 90% guaranteeing the lit block will be the middle block. This is just done by a tighter watch of what numbers are being changed.
6. The game no longer uses *.obj files, instead its using *.3ds files. This makes my previous work of coding a loader to populate the game with the objects name as a waste of time (damn). Then there was some problems of "the object is on it's side" and "the spool is backwards, all the panels are backwards" and "the names have some extra junk added to them". All of those problems were fixed yesterday.
Now, today's problems :-). i REALLY want to add multi-threading to this game. It is disgusting of how long it takes the game to load. To load all of the resources, IT TAKES 2 SECONDS...well, 1.5 seconds, but thats still too long. If I had a splash screen, that might make the time look less troubling, but I don't and the waiting time disturbs me.
Here is a picture of the loading time for the basic elements (fonts, panel walls/ back, gui image, models) and 3 panel images. 2 are being colorized and 1 is just being used as-is.
0.5 seconds per panel....and this is all done in the UI thread. So, I need to figure out how to toss all of the panel creation into their own threads for some parallel panel processing.
Another thing I want to research into is of how the spools are drawn. Currently, the game makes new spools from the loaded spool data which helps reduce the time to load in the data. The idea I thought about is to just make 1 spool and the reel will contain "spool points".
Here is how it'll look. The reel will be created, which makes spool points (where each spool will be), then it generates panel data for each spool, then it's done.
When the reel needs to be rendered, it will move a spool into one of the spool points, rotate it, texture each panel to the spool point panel data, draw the spool to the buffer, then move the spool to the next spool point and repeat the process. If my calculations are correct, this should dramatically lower the memory requirement (less vertices = less memory), and enable each spool to be given a "light amount" to simulate it's acquired light from the selected spool.
What hurts the most about this game is that I have 2 weeks left to do these changes and make a playable level. For now, the threading and spool idea will be tacked onto the end of the todo list.
My current priority goals are to enable proper lateral movement of the spools, then make the first level (no goal, just movable spools which are not the menu spools).
= Todo (in this order) =
1. Make the camera move across the spools properly.
2. Create a second reel (of random length that is less than 20, for testing) for the game play.
3. Add block data to the movement ability to enable/disable movement
+ and to change the user's color, which will currently just be displayed as some text on the screen.
= Additional notes =
In the previous class meeting, my goals till the next meeting were:- Finalize block and menu code (80% done)
- textures finalized (done)
- at least one gameplay/ puzzle mechanic working (not done)
So, I'm getting there to being done with this weeks goals. It would be awesome if I could add some music/ sound effects...but I haven't had time to look at the engine Chris mentioned (JavaZoom)....well, back to coding.
No comments:
Post a Comment