LD Smith Games

One problem that continued to remain was the two different game states for the two display types in the game.  Those two display states are for the 2D sprite based view and the 3d model based view.  These two views shared the same data model, which is a reference to the game world.  However, having two game screen classes still led to some redundant code.  Both Screen states inherited from the ResistorKit.Screen class, which means that the control methods (stick movements and button presses) had to be handled in both Screen classes.  Therefore all of the controls were duplicated in both screens.  Additionally, other things not related to the display code also had to be duplicated, such as the sound effects.

Therefore, I modified the code so that there is only one GameScreen class.  This “new”class has two instance variables, one for the each display type, which are the GameScreen2D and GameScreen3D.  I should have probably renamed those to “Display” instead of “Screen”, since “Screen” implies a state in my game.  I could have also created a “Display” superclass for those two classes, but I thought that would have been overkill, especially since probably only one display method will ever be used in the final game.  I separated the actual drawing code for each display into its respective class.  The screen to be displayed is based on an instance variable in the GameScreen class which is set to an enum value that represents the currently active display type.  This prevents having to keep track of the display state in the main game class, which was the inefficient original approach that I took.

This also solves a long standing problem when exiting the menu screen.  Since the menu screen did not keep track of what screen was before it, the game always returned the player to the sprite based view even when the player was using the 3D model based view.  With the single display class, the player is always returned to the one screen state, which correctly displays the game screen based on the current display method.

I also have the GameScreen overlay displayed in the main GameScreen class, since the overlay should be identical for both the 2D and 3D views.

The only control difference between the 2D and 3D display is that the 3D display allows control of moving the camera when the Right Trigger is held.  That is the only display specific code that needs to be updated in the GameScreen class, and I will fix that in the near future.

I came across a new problem since adding my Jukebox class, which is an AccessViolationException when the program is ended.  This problem was reported in a thread on the AppHub forums, but a definite solution was never reported.  To see if it would help, I added a “Copy for Windows” of the ResistorKit library, and I added a reference in the BlastingBits for Windows project to the ResistorKit for Windows DLL.  However, I still occasionally see this error.