|
Forum Index : Microcontroller and PC projects : Micromite eXtreme V5.04.12: Sprites etc.
| Author | Message | ||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10568 |
Please find attached MMX V5.04.12 for 100/144 pin chips 2018-01-29_234539_MMX5.04.12.zip and for 64-pin chips 2018-01-29_234628_MMX645.04.12.zip Manual 2018-01-30_014224_Micromite_eXtreme_Manual.pdf This contains a first complete implementation for sprites including layers, scrolling background, and full collision detection. It also contains the full USB keyboard implementation (US and UK layouts supported). The sprite functionality works on VGA, all SSD1963 displays (RD pin must be connected and specified in the OPTION LCDPANEL command), and the ILI9341 display (SPI2-IN pin must be connected to the display). Sprite and scroll functionality on the SSD1963 TFT displays is memory intensive if large sprites and scroll moves are used and users will need to code to avoid the dreaded "Error: Not enough memory" The functionality is particularly targeted at use on VGA screens where a double buffering approach has been implemented to completely overcome screen flicker during sprite moves and screen scrolling. Performance on the VGA screen is also much better than on TFT with background scroll commands taking an average of 11mSec (177mSec for a 800x480 SSD1963 in 16-bit parallel mode) The manual contains details of the new SPRITE command and function The following is a simple test program that has been checked on VGA and SSD1963 (100/144-pin) and ILI9341 (64-pin) 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. 2. Sprites are loaded to a specific number (1-50) 3. Sprites are displayed using the SPRITE SHOW command 4. For each SHOW command the user can select a "layer". This defaults to 1 if not specified 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 collison 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" If anyone would like to code up a simple game to test this properly (pong?) I'm very willing to provide as much support as needed. Option explicit option default NONE memory dim integer testrun=1 load image "tiger640" sprite INTERRUPT collision ' specify the interrupt routine to handle collisions sprite load #4, "apple" sprite load #2, "apple" sprite load #17, "apple" ' ' test 1 - sprites on different layers don't collide except with layer 0 sprite show 4,10,10,1 sprite show 2,50,50,2 pause 200 sprite show 17,35,30,0 pause 1000 ' ' test 2 - single sprite overlaps the corner sprite hide 17 sprite hide 2 sprite show 4,-10,-10 pause 1000 ' ' test 3 - one sprite moves and hits another sprite show 4,10,10,7 sprite show 2,100,100,7 pause 200 sprite show 2,50,50,7 pause 1000 ' ' test 4 - collision in contact with edge sprite hide 2 sprite hide 4 sprite show 2,-10,10,7 pause 1000 ' ' test 5 - all layers collide with layer 0 sprite hide 2 sprite show 17, 55,25, 0 sprite show 2, 100, 10 pause 1000 ' ' test 6 - scroll causes collision with edge of screen for layer-0 sprite sprite hide 2 BLIT scrollv 30 pause 1000 ' ' test 7 - scroll causes collision between sprites BLIT scrollv -60 BLIT scrollv -60 sprite show 4,10,10,7 sprite show 2,110,10,7 blit scrollv 30 pause 1000 ' ' Close everything and check for memory leakage sprite close 0 sprite close 4 sprite close 2 sprite close 17 clear memory end ' ' This routine demonstrates a complete interrogation of collisions ' sub collision local integer i print "Test : ",testrun testrun = testrun +1 if sprite(S) <> 0 then 'collision of individual sprite print "Collision on sprite ",sprite(S) 'sprite(S) returns the sprite that moved to cause the collision process_collision(sprite(S)) print "" else 'collision of one or more sprites caused by background move print "Scroll caused a total of ",sprite(C,0)," sprites to have collisions" for i=1 to sprite(C,0) print "Sprite ",sprite(C,0,i) process_collision(sprite(C,0,i)) next i print "" endif end sub sub process_collision(S as integer) local integer i ,j print "Total of ",sprite(C,S)," collisions" 'sprite(C, #n) returns the number of current collisions for i=1 to sprite(C,S) j=sprite(C,S,i) if j=100 then print "collision with left of screen" else if j=101 then print "collision with top of screen" else if j=102 then print "collision with right of screen" else if j=103 then print "collision with bottom of screen" else print "Collision with sprite ",sprite(C,S,i) 'sprite(C, #n, #m) returns details of the mth collision endif next i end sub |
||||
| WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2959 |
Hi Peter, I have loaded up this version (by-passed last two Betas) and this seems to be working really well. No issues with what I am seeing on my 'usual' monitor Will have a play this evening with moving some Sprites around and report back with any issues. NICE WORK yet again! WW |
||||
| WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2959 |
Found a small bug I think. Concerns a scrolling background (layer 0) and two sprites colliding on layers 1 and 2. Upon collision between the two sprites, something is drawn to layer 0 (where the sprites collide), resulting in a scrolling 'collision' graphic on layer 0 (these sprites should not draw anything on layer 0?). Discovered this whilst trying a quick 'Defender' speed test (scrolling landscape with moving sprite spaceships). Use the following code to see what I mean (press the 'A' key to collide bottom Apple into top Apple!) Do NOT comment on code quality - I am simply doing some basic testing cls sprite load 2,"apple" sprite load 3,"apple" sprite show 3,10,100,2 y%=400 slx%=30 sly%=200 sprite show 2,slx%,sly%,1 do d%=int(rnd(0)*3)-1 y%=y%+d%*8 if y%>460 then y%=460 if y%<350 then y%=350 box 600,y%,8,8,1,rgb(red),rgb(red) box 0,350,8,130,1,0,0 sprite scrollh -8 i$=inkey$ if i$="," then slx%=slx%-8 if i$="." then slx%=slx%+8 if i$="a" then sly%=sly%-8 if i$="z" then sly%=sly%+8 if slx%>600 then slx%=600 if slx%<0 then slx%=0 if sly%>460 then sly%=460 if sly%<0 then sly%=0 sprite show 2,slx%,sly%,1 loop WW |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10568 |
Wasn't respecting the LIFO properly during scroll. Try this 2018-01-30_215045_MMX5.04.12.zip 2018-01-30_235005_MMX645.04.12.zip NB there are actually two LIFOs, one for layer 1 to 50 and one for layer 0. In general layer zero sprites should always be drawn first but this isn't required as long as they do not "collide" with a non-layer-0 sprite when initially drawn or moved otherwise screen corruption will occur when the background is scrolled. The algorithm for a scroll (this all takes place automatically) is: remove sprites not in layer 0 in the reverse order to which they were drawn remove layer-0 sprites in the reverse order to which they were drawn scroll the background redraw layer-0 sprites in the order in which they were drawn redraw sprites not in layer 0 in the order in which they were drawn Moving any sprite puts it back to the top of the respective LIFO. i.e. it becomes the last drawn - first removed. The layer a sprite is on does not influence drawing order, other than layer 0 |
||||
| WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2959 |
@Peter So far so good . . . . |
||||
| The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |