Finally, threads

So, it's been about 3 days since my last blog...but in my defense, I have been very busy. After checking my previous blogs and looking at my todo lists, only 5 of them remain still active (big plus).

I made a file on my desktop to keep track of all of the features I've added, and here is what I've came up with:

- Reels can be size adjusted without wasting resources
- Clicking on the "GO!" in the menu now moves to the gameplay (no transition yet)
- User can now move to both ends of the spool without glitches
- Spool rotation doesn't have the dis-alignment glitch anymore
- Each menu sub-item has it's own block assigned to it in code (I don't have pictures for the blocks yet)
- More functions have comments (easier for my coding)
- Made each screen into "Screen objects" for easier function accessing
- Each Screen also has it's own world and camera, which makes moving between different screens smoother and less complicated. The process was fairly easy, just copy/paste what I already had.
- Gameplay movement uses the block actions to determine if movement into the block is allowed
- Movement faction is re-enabled. This allows the user to move around the reel with more "restriction" (to prevent flimsy/wobbly-like movement)
- The block placement was backwards on the spool. Originally the numbers increased above and around the block. Now numbers increase down and around the spool to correspond to the menu items placement/ movement.
- Moving left/right fades in/out menu items
- Each main section of the menu remembers which sub-item it was on
- The menu can now easily be populate with new menu blocks and sub-menu items
- Panels are now made in threads to speed up the generating process


The loading still takes awhile, about 4 seconds to load all of the resources and 3 seconds till the first render. But, it's giving more bang per second that it was a few weeks ago. What made me feel the best is that to create the gameplay spool, it's less than 1/4 of a second. Which is perfect timing and around the mark I was looking for.


Some of the problem I've found is that the transition between the menu to game is.....troubling. I tried to make a bitmap of the image which was on both screen (easily done via the engine), then fade from one to another each render cycle. This causes errors, did nothing (displayed a blank screen for 3 seconds), or crashed without errors. So I'm researching more ways to transition between screens.
 
Another problem is the menu needs 12 items for the sync between spool and sub-menu items to work. I've made a patch to make sure the menu always has 12 items, but eventually I want the menu to handle 5 to 30 items per category. That's going to be moved to the beta version due to it's limited requirement right now.

= Todo =

- Test more of the gameplay movements, they seem to have glithes
-+ Some panels are falsely saying the user can't enter, although they should be
-+ When the player shouldn't be allowed the enter the block, the user is able to move, then settles back to the block they were at. It should be a straight "NO" like how the end blocks are
- Figure out why the selected block is moving around in the gameplay
-+ This easily happens when the user moves left, up, then right. the selected block is 2 above or 2 below where it should be.
- Better lighting/ display for which is the currently selected block
- Make a GUI for the gameplay window
-+ Not a requirement, but I want the previous items done before this is started
- Find code of how to save panels to the device so the game won't need to generate them each time
- Write up a function to permutate through the colors to make more panels...although the correct wording would be combination, because the order of the colors doesn't matter.
-+ note: I need to get the code to save panels to the device before I can do this part. Having a 4 second loading time each time the game starts will get annoying.
- Add music/sound effects (this has been on the list as long as the camera thing was). Now that I'm getting closer to the end, this is becoming more important....too bad I only have 1 song and no sound effects.


The level generator, I'm just going to take that off for now. A random level is doing pretty well for the alpha stage.

= PICTURES!! =

The action of moving between the menu items. Ignore the pink blocks, they are automatically used when the correct panel images can't be found (in this case, I don't have them still).

The dashes in the menu is the patch I was talking about earlier. Not a huge problem, just a minor annoyance.

Now, the gameplay screen in all of it's glory...

 

 ....yea, I know, it looks lame and dull (besides the colorful blocks). I still need to add the block displayer on the bottom left (that black circle is apart of the displayer), a gameplay map (which will be on the top), and the item window (on the left). As per my drawing example below.

World of worlds

After talking with the developer of jPCT-AE, he gave me some ideas of how to fix my frame rate issue. The model now has less objects needing to send to the gpu for processing (25 instead of 37), and I'm using a beta version of the engine which has brought the game up to 16 fps. MEGA UPS!!

Although I should be working on game play issues, I'm stuck on a menu issue. 2 days ago (I didn't work on it today), I thought about the idea of action a faction to the menu system. So if the user moved too much in one direction, it would stop accepting inputs from the other direction till the user lifts their finger. A sort of x/y faction system.
I don't know why, but it's causing weird glitches. If the user moved their finger down left at a 45*-ish angle, the game would choose a faction (as expected), allow movement of that chosen faction...but it wouldn't reset the other faction's movements.


= Movement faction code

dta[0] = dx / 14;
dta[1] = dy / 8;

if(faction < 0)
{
    float div = 1/4f;
    facTest[0] = Math.abs(menuMovement[0]) / (hcycle * div);
    facTest[1] = Math.abs(menuMovement[1]) / (vcycle * div);
   
    Log.d(TAG + " -Fac", "FacX: " + Round(facTest[0], 4) + ", FacY: " + Round(facTest[1], 4));
   
    if(facTest[0] >= 1 && facTest[0] > facTest[1])
    {// dx wins
        reel.iSpin(menuMovement[1]);// un-rotate the previous spool
        menuMovement[1] = 0;
        dta[1] = 0;
        faction = 0;
    }
   
    if(facTest[1] >= 1 && facTest[1] > facTest[0])
    {// dy wins
        cam.moveX(menuMovement[0]);
        menuMovement[0] = 0;
        dta[0] = 0;
        faction = 1;
    }
} else
{
    Log.d(TAG + " -Fac", "Faction: " + faction);
   
    if(faction == 0)
        dta[1] = 0;
   
    if(faction == 1)
        dta[0] = 0;
}

I'm doing the action to reset the movement of the other faction....and nothing. So, I'm just gonna disable it. It'll make the menu look weird and unconstrained, but I have more important problems now, like MAKING A GAME.

After I disable this code, I'm gonna work on making a game play class (like the menu has it's own class, so it doesn't clutter the renderer class). I have a few ideas of how to make the game class and how to transition from the classes. Currently, the game has one 'world". Each frame, the world is given data to where to render data to, and then eventually the framebuffer renders that data.
So, my idea, each class will have it's own world to enable the option to disable all rendering on another part of the game. But, like all things, it needs testing and possible many failures till I get it right.

= Todo =

- Same as the last blog

Flying time and flashy words

Wow, it's already been 2 days since my last blog? Time sure does lose track when programming so much.
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.

Shiny White Walls

After sitting at the computer, coding something which should have already been built into the engine, I finally got the objects in each spool working. AND, I even have screen shots this time ;-)

My first test time....a little disappointing. The only visible blocks were the pink null blocks (created in code for testing) and the stone block (loaded straight from image, no processing was done).

Then after looking through the code, I found the problem. Each panel which was getting new coloring was using the wrong transparency. It was using the blue channel (which is at 0) instead of the green one (which was at 200).

But, something was still missing. Last time I ran the program, The first non-end spool was lit up. I have no clue how this happened, so I just lit up the whole spool. (so I could at least see the images better).

Closer to what I was looking for, and shows that each test is indeed generating random spools in random colors.....but the panels still don't have have transparency :-(. So, I looked through the code, did some research to make sure the generated colors were using transparency, and scratched my head a lot. Then it clicked, I need to set each object's setTransparency(x) to something. Yea, I know its weird, since the image has transparency and it's loaded into the engine with transparency.

What is happening is that although the image is transparent, the object it is on isn't. So, I have to make the object transparent. Anyway, IT WORKED.

Because the spool is now (hub sides, block backs, block sides, and block front), I have more range of control of the block images. For example, you can now see the inner sides of each block AND the block's back :-D.

Using a previous picture to show my point. Looking at the top of the lit up "B", you can see the block side, but what your actually seeing is the block above it's side. Look at the right of the lit up "B" block, and it has no white side, just goes straight through and picks up color from the next spool's side (depressing and primitive).

Now that I FINALLY have a generatable blocks.....I get to tackle that massive and massively overdue todo list. But at least I get to look at some pretty blocks while doing it :-).

= Todo (in no particular order) =

- Look for code of how to save each panel's generated bitmap on the device so the panels won't need to be generated each time (and hope that it won't hog too much space).
 - Update the xml parser to recognize when it needs to loop over the same object multiple times to include each color combination.
 - Add action data to the block (and incorporate it into the user's left/right swipe to allow/disallow movement)
 - Code up a level generator (which will also tell each block which panel it will be using)
-+ using a scheme like in Minecraft, using numbers and letters
 - Scrolling left/right will fade in new menu items and out-fade the old
-+ and add more menus 
- Fix the lighting problem on the blocks (so only the current block and it's neighbors light up, like in the previous release).
- Implement my camera idea
- Fix the spool rotation and sliding
- Make the menu item text more diverse to distinguish which item is the current item
- Add sounds effects/ music. This will be added last though, because it's the lowest priority.

Lessons learned

I was finally able to test the panel generator code, and there was some glitches, nothing outside of my bounds though.
First most, using "==" to compare strings doesn't work. It apparently compares where the strings are located instead of their values. So, by using StringA.equals(StringB), it properly compares the names.
Second, using getPixel() and setPixel() are VERY slow. I should have known this from my C# days. So now each unique image is converted to an int[] and saved. Then that array is used each time a new panel is needed.
And lastly, creating a new array of panels for each spool was stupid and slow. Now, each spool has panels already applied to it. After all, it's not like a spool will have less panels than it's max number of panel slots.


Now, the problem I'm having is accessing each object in the loaded model. Previously when each model was just one object, I didn't care about the object's name...now it's one of those important things. When loading the objects, the engine seems to like naming each object something besides it's actual name. I've already sent a message to the developer of how to fix this problem, hopefully the reply will be quick :-/.

Till then, I'll work up some hacky and use assumed places (modeled after the obj's file object placements). After I get this workaround finished, the panel generator should be complete and I'll be able to get my first screenshot of generated panels :-).


Here is some finally good news though, I know how to fix the camera problem :-D. The reel will be on an angle and the camera will be facing it directly and move left/right. The difference is that there will be an invisible object (named cPoint) which will move across the reel (not attached to it, just along it). it's pivot point will be 0,0,0 (the same as the reel's pivot point). Each time the camera wants to move, it will un-rotate cPoint, move it left/right, rotate it back, move the camera left/right, then adjust the camera's z by using cPoint's z value + some number. Damn, I can't wait till the panel upgrade code is finished so I can test this. It's been bugging me for the last 2 weeks (and these weeks have been very long).

In with the new and still with the old

After a good 6 hours today, I finished: the xml data file (which holds info about each panel), the xml parser (makes panels from the data), and the panel class which holds all the data. Which looks mighty impressive.

My only stumble now is determining which/ how to assign colors to each panel. Sure, I got the color codes in each picture to assign the colors to the picture and the panel class holds data about which colors it has, but thats not enough. Currently each panel is assigned its own name in the xml "One Way - Left - 2", which would mean the panel is a one way panel, the user can only enter it from the left (as opposed to the "Right" version), and it has 2 colors.

But that is causing a logical problem (in my head, not the code), that this prevents truly unique panels (by color). So, tomorrow I'm gonna replace the naming convention from a number to a "#". While going through the loading process, the code will see it has colors assigned to it and look through that panel X number of times till all of the colors are accounted for.

Since I have not done any testing yet (there was no place where I could), I don't know how long it would take to make all of the panels

= New Todo =

- Make a new type of spool which will have panels attached to it. This should enable faster object loading and less faces (24 to be exact).
- Change the naming in the xml to allow a more unique name for each panel (easy)
- Update the xml parser to recognize when it needs to loop over the same object multiple times to include each color combination.
- Look for code of how to save each panel's generated bitmap on the device (and hope that it won't hog too much space)

= Still on the Todo =

~ 5/21 ~
- Add action data to the block (and incorporate it into the user's left/right swipe to allow/disallow movement)
- Code up a level generator (which will also tell each block which panel it will be using)
-+ using a scheme like Minecraft, using numbers and letters
- Scrolling left/right will fade in new menu items and out-fade the old
- Add lighting to the blocks for a more elegant look
- Add sounds effects/ music
- Get the camera working

~ 5/23 ~
- Menu
-+ The spools don't rotate properly
-+ The sliding of the spools is off, they are constantly too much or too little
-+ Lighting up of the blocks is off, and often the light block wouldn't be in the center
-+ Make the menu item text more diverse to distinguish which item is the current item

- General
-+ Add music and sound effects

= Pictures =

This is what the panel used to be. Colorful and distinct to one panel (the "Cycle Colors - CCW - 3").

But it takes up too much data and can only be used once. THIS (shown below) is the new version of the above block. It not only shows the same (after being processed) thing as the above panel, but can be used multiple times.

Now I won't have to worry about the game becoming too large with all the panels in it.

oh, and the rest of the block (sides and back), they will each have their own pictures. White sides with black linking for the sides and I-don't-care for the back. Well, actually the back may just be a white panel. I haven't been able to see the back yet, but after the new spool upgrade and some testing....I'll post another update.

Unpictured panel problems

After some thinking about the panel pictures....I'm gonna scrap using png files. In fact, the panels won't be using any panel specific image. The number of combinations for each panel (colors), animations (eventually), and levels for each panel...the game will be huge.
For the 6 basic tiles in 6 different colors, the file size will reach ~3MB and be over 90 pictures.
For 6 basic tiles modeled as 3d objects and dynamically colored, the file size will be ~1 MB and only need 6 objects.

What I'm thinking about doing is one of two things. Have a panel made, then moved into position with the rest of the block. Or make a block with the panel already in place. I'm hoping for the former (due to a smaller file size)....but the latter sounds more plausible.