|
Forum Index : Microcontroller and PC projects : New game for Color Maximite
| Author | Message | ||||
| dvanaria Newbie Joined: 04/03/2018 Location: United StatesPosts: 15 |
I just completed a game for the CMM (Color Maximite) - a clone of Breakout, but it uses a few parts of the Sprite system and brought up a few issues I see with the current implementation. (I posted this yesterday on a thread Geoff Graham posted called "Seeking Games Programmers" but I thought it would get more views if I just started a new thread here). Two improvements to MMBasic's implementation of Sprites I can think of (unless I'm using the sprite system incorrectly): 1. There's no way to reuse a sprite bitmap (defined in a .spr file) for multiple sprites in a program. For example, I didn't use sprites for the bricks in this game because I would have had to have the same brick image multiple times (63 times in this instance) in the file, which would have made the file unnecessarily big for this game. 2. The Collision function doesn't seem to be accurate when testing for two sprites overlapping. It works, but its not pixel-perfect (perhaps its not implemented to be that way). Here's some example code: r = Collision(3, SPRITE) If (r And &B10000) = &B10000 Then ' not exact, sprites overlapping by several pixels before this evaluates to True Here is the source code to the game if you're interested in testing it out. I'd love to know also if people notice flickering on the sprite images themselves (mainly the paddle in the game). No matter what I did I couldn't get rid of this problem. 2018-07-19_092134_BREAKOUT.zip |
||||
| rave Newbie Joined: 24/02/2018 Location: United StatesPosts: 28 |
Very nice! I'm pretty sure you can reuse sprites defined in a .spr file on the CMM. See the FruitOfTheShed example http://fruitoftheshed.com/MMBasic.Sprite-Demonstration-part-of-the-original-MMBasic-library.ashx That example actually has a bug, because the collision detection may cause a sprite to bounce indefinitely between two sprites or a wall without updating the other sprites, resulting in deadlock. I corrected this bug as follows: MODE 3 ' Set video mode LOADBMP"backdrop" ' Load backdrop image SPRITE LOAD "sprites" ' Load sprite definitions DIM p(8,4) ' Define array size FOR n=1 TO 8 ' Set all 8 sprites data p(n,1)=n*25+125 ' X co-ordinate p(n,2)=216 ' Y co-ordinate p(n,3)=FIX(RND*4)+1 ' Random 4 direction SPRITE on n,n*25+125,216 ' Turn on sprite NEXT n GAMELOOP: FOR n=1 TO 8 ' Start of main game loop MOVEGHOST: ON p(n,3) GOTO LEFT,RIGHT,UP,DOWN ' Branch to direction LEFT: ' Move sprite left SPRITE copy 11+b TO n ' Copy sprite buffer graphics p(n,1)=p(n,1)-1 ' Decrement X co-ordinate GOTO REDRAW ' Branch to sprite redraw RIGHT: ' Move sprite right SPRITE copy 9+b TO n ' Copy sprite buffer graphics p(n,1)=p(n,1)+1 ' Increment X co-ordinate GOTO REDRAW ' Branch to sprite redraw UP: ' Move sprite up SPRITE copy 13+b TO n ' Copy sprite buffer graphics p(n,2)=p(n,2)-1 ' Decrement Y co-ordinate GOTO REDRAW ' Branch to sprite redraw DOWN: ' Move sprite down SPRITE copy 15+b TO n ' Copy sprite buffer graphics p(n,2)=p(n,2)+1 ' Increment Y co-ordinate REDRAW: SPRITE move n,p(n,1),p(n,2) ' Move current sprite IF COLLISION(n,edge)>0 THEN ' Test for edge of screen GOSUB BOUNCE ELSEIF COLLISION(n,sprite)>0 THEN ' Test for another sprite GOSUB BOUNCE ELSEIF RND>.99 THEN ' Randomly decide to turn p(n,3)=FIX(RND*4)+1 ENDIF NEXT n ' Loop back for next sprite c=c+1 ' Counter for sprite animate IF c>8 THEN b=b XOR 1:c=0 ' Sets speed of animation GOTO GAMELOOP ' Do it all again BOUNCE: ' reverse sprite direction p(n,3)=p(n,3)+1 ' Reverse direction IF p(n,3)=3 THEN p(n,3)=1 IF p(n,3)=5 THEN p(n,3)=3 RETURN ' Go back to redraw sprite - Rob |
||||
| The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |