|
Forum Index : Microcontroller and PC projects : Also seeking games programmers
| Author | Message | ||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10572 |
For relative newcomers to the Micromite/Maximite world, if you are interested in games programming, please do look at the Armmite H7 as a platform. Not only does it include a comprehensive sprite implementation in full colour on a 800x480 screen but the chip is 5x faster than the PIC32 and getting up and running is cheap, just a Nucleo-H743ZI + a 800x480 SSD1963 screen is needed (an Armmite H7 backpack pcb PCB makes the connection easier). It can also play stereo .wav and .flac files in the background direct to the on-chip DACs if you want a musical background or sound effects. I've just added some new drivers for the SSD1963 displays that speed up sprites and still give 473K available for user programs and I will undertake to support and potentially extend the functionality for anyone who really gets stuck into programming a proper game. See the video Full details of the various sprite commands are in the manual but the concept of the sprite implementation is as follows: 1. Sprites are full colour and of any size. The collision boundary is the enclosing rectangle and they can be loaded from .PNG files or read off the screen. 2. Sprites are loaded to a specific number (1-50) 3. Sprites are displayed using the SPRITE SHOW command, they can be mirrored or inverted or both. 4. For each SHOW command the user must select a "layer". This can be between 0 and 10. 5. Sprites collide with sprites on the same layer, layer 0, or the screen edge 6. Layer 0 is a special case and sprites on all other layers will collide with it 7. The SCROLL commands leave sprites on all layers except layer 0 unmoved 8. Layer 0 sprites scroll with the background and this can cause collisions 9. There is no practical limit on the number of collisions caused by SHOW or SCROLL commands 10. The sprite function allows the user to fully interrogate the details of a collision 11. A SHOW command will overwrite the details of any previous collisions for that sprite 12. A SCROLL command will overwrite details of previous collisions for ALL sprites 13. To restore a screen to a previous state sprites should be removed in the opposite order to which they were written "LIFO" Because moving a sprite or, particularly, scrolling the background can cause multiple sprite collisions it is important to understand how they can be interrogated. The best way to deal with a sprite collision is using the interrupt facility. A collision interrupt routine is set up using the SPRITE INTERRUPT command. e.g. SPRITE INTERRUPT collision The code for the demo in the video is simple and should explain the concepts option explicit option default none const leftbar = 1, rightbar = 2, topbar=3, bottombar=4, rightapple=5, leftapple=6 dim integer moveright=1, movedown=1 box 250,100,10,280,,rgb(magenta),rgb(magenta) box 50,50,150,10,,rgb(cyan),rgb(cyan) SPRITE read leftbar,250,100,10,280 sprite copy leftbar, rightbar, 1 'make one copy SPRITE read topbar,50,50,150,10 sprite copy topbar, bottombar, 1 'make one copy load sprite rightapple,"apple" sprite copy rightapple,leftapple,1 'make one copy load image "tiger800" sprite interrupt collision SPRITE show rightapple,300,200,0 SPRITE show leftapple,100,200,0,2 SPRITE show leftbar,250,100,1 SPRITE show rightbar,580,100,1 SPRITE SHOW topbar,50,50,2 SPRITE SHOW bottombar,50,420,2 do option autorefresh off if moveright then sprite scrollr 259,100,322,280,4,0 else sprite scrollr 259,100,322,280,-4,0 endif if movedown then sprite scrollr 50,59,150,362,0,-4 else sprite scrollr 50,59,150,362,0,4 endif option autorefresh on loop ' ' sub collision local integer i, c(10), j if sprite(S) = 0 then 'collisions caused by scroll j=sprite(c,0) for i=1 to j 'store the collisions because a clearing scroll move will clear them from the list c(i)=sprite(C,0,i) next i for i=1 to j 'now process them process_collision(c(j)) next i endif end sub ' get details of the specific collisions for a given sprite sub process_collision(S as integer) option autorefresh off select case S case leftbar sprite scrollr 259,100,322,280,4,0 'make a move to clear the collision sprite show rightapple,sprite(x,rightapple),sprite(y,rightapple),0,0 'mirror the sprite moveright=1 case rightbar sprite scrollr 259,100,322,280,-4,0 'make a move to clear the collision sprite show rightapple,sprite(x,rightapple),sprite(y,rightapple),0,1 'mirror the sprite moveright=0 case topbar sprite scrollr 50,59,150,362,0,-4 'make a move to clear the collision sprite show leftapple,sprite(x,leftapple),sprite(y,leftapple),0,3 'invert the sprite movedown=1 case bottombar sprite scrollr 50,59,150,362,0,4 'make a move to clear the collision sprite show leftapple,sprite(x,leftapple),sprite(y,leftapple),0,0 'invert the sprite movedown=0 case else end select option autorefresh on end sub |
||||
Grogster![]() Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9755 |
[Quote]It can also play stereo .wav and .flac files in the background direct to the on-chip DACs if you want a musical background or sound effects.[/Quote] As these are dedicated hardware DAC's, can I assume that they don't therefore have the PWM audio pops and clicks that are present on the MM+ series of chips? Smoke makes things work. When the smoke gets out, it stops! |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10572 |
Yes |
||||
| The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |