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