Also try Disc Image Manager:
viewtopic.php?p=299825#p299825
Sorry for the delayed response on this. Time hasn't been on my side, and even this is a quick message.jms2 wrote: ↑Wed Jan 12, 2022 5:30 pm Having looked at it only very briefly, yes that should work.
The sprite data is just bytes, so the DATA statements don't care what the bytes actually mean. Provided you have captured all the bytes in the DATA statement and the sprite routine can "find" them in the expected place it doesn't matter.
Code: Select all
1450 DIM shapes 300
1460 FOR I%=0TO3
1470 READfilename$
1480 OSCLI("LOAD "+filename$+" "+STR$~shapes) 1490 I%?shapeloaddr=shapes AND&FF
1500 I%?shapehiaddr=shapes DIV256
1510 READ I%?shapesize
1520 READ I%?shapedepth
1530 shapes=shapes+I%?shapedepth*I%?shapesize
1540 NEXT
1550 DATA alien, 5, 14
1560 DATA base, 4, 20
1570 DATA bomb, 2, 8
1580 DATA bullet, 2, 8
Code: Select all
10REM Data Maker
20MODE7
30INPUT'"Sprite file name:"sprite$
40OSCLI"LOAD "+sprite$+" B00"
50PRINT'"Sprite loaded..."
60INPUT'"Data file name:"name$
70OSCLI"SPOOL "+name$
80X%=?&B00:Y%=?&B01:L%=9020:B%=&B02:a$="9020DATA "
90PRINT"9000REM "sprite$
100PRINT"9010REM X=";X%;"/Y=";Y%
110FOR I%=0 TO X%-1
120FOR J%=0 TO Y%-1
130a$=a$+STR$(?B%)+",":B%=B%+1
140IF LEN(a$)>200 OR (I%=X%-1 AND J%=Y%-1) a$=LEFT$(a$,LEN(a$)-1):PRINT a$:L%=L%+10:a$=STR$(L%)+"DATA "
150NEXT
160NEXT
170*SPOOL
Code: Select all
10REM Data Maker
20MODE7
30INPUT'"Sprite file name:"sprite$
40OSCLI"LOAD "+sprite$+" B00"
50PRINT'"Sprite loaded..."
55INPUT"Width:"X%
56INPUT"Height:"Y%
60INPUT'"Data file name:"name$
70OSCLI"SPOOL "+name$
80L%=9010:B%=&B02:a$="9010DATA "
90PRINT"9000REM "sprite$
110FOR I%=0 TO X%-1
120FOR J%=0 TO Y%-1
130a$=a$+STR$(?B%)+",":B%=B%+1
140IF LEN(a$)>200 OR (I%=X%-1 AND J%=Y%-1) a$=LEFT$(a$,LEN(a$)-1):PRINT a$:L%=L%+10:a$=STR$(L%)+"DATA "
150NEXT
160NEXT
170*SPOOL
Apologies for the long delay in responding. I would prefer to have some kind of listing for the sprites, even if it's only purpose is to create the data files themselves.jms2 wrote: ↑Thu Jan 20, 2022 8:14 pm I'm struggling slightly to understand what you're trying to do, and where you're getting stuck. I do understand your previous observation that it's nice to see sprite data within a program listing, but you need to bear in mind that the necessary DATA statements will take up memory - so they really have to be put in a loader program, perhaps along with the source code to the sprite routine.
Unless I'm very much mistaken, BeebAsm will only assemble machine code programs. If necessary it can contain sprite data in the form of EQUB statements or similar, but it can't deal with BASIC.
Code: Select all
; Acorn charset data...
; 9 images, 32 bytes per image, total size is 288 bytes.
.char_sprite_0
EQUB $00, $00, $00, $00 ; ........
EQUB $00, $00, $00, $00 ; ........
EQUB $00, $00, $00, $00 ; ........
EQUB $00, $00, $00, $00 ; ........
EQUB $00, $00, $00, $00 ; ........
EQUB $00, $00, $00, $00 ; ........
EQUB $00, $00, $00, $00 ; ........
EQUB $00, $00, $00, $00 ; ........
.char_sprite_1
EQUB $00, $00, $00, $00 ; ........
EQUB $00, $00, $00, $00 ; ........
EQUB $00, $00, $00, $00 ; ........
EQUB $00, $00, $00, $00 ; ........
EQUB $00, $00, $00, $00 ; ........
EQUB $28, $00, $00, $00 ; #.......
EQUB $14, $00, $00, $00 ; .#......
EQUB $14, $28, $00, $00 ; .##.....
.char_sprite_2
EQUB $00, $00, $00, $3C ; ......##
EQUB $00, $00, $00, $3C ; ......##
EQUB $00, $00, $00, $14 ; .......#
EQUB $00, $00, $00, $14 ; .......#
EQUB $00, $00, $00, $00 ; ........
EQUB $00, $00, $00, $00 ; ........
EQUB $00, $00, $00, $00 ; ........
EQUB $00, $00, $14, $3C ; .....###
.char_sprite_3
EQUB $00, $00, $00, $00 ; ........
EQUB $00, $00, $00, $00 ; ........
EQUB $28, $00, $00, $00 ; #.......
EQUB $3C, $00, $00, $00 ; ##......
EQUB $3C, $28, $00, $00 ; ###.....
EQUB $3C, $3C, $28, $00 ; #####...
EQUB $3C, $3C, $3C, $3C ; ########
EQUB $3C, $3C, $3C, $3C ; ########
.char_sprite_4
EQUB $00, $00, $00, $00 ; ........
EQUB $00, $00, $00, $00 ; ........
EQUB $00, $00, $00, $00 ; ........
EQUB $00, $00, $00, $00 ; ........
EQUB $00, $00, $14, $3C ; .....###
EQUB $00, $3C, $3C, $3C ; ..######
EQUB $3C, $3C, $3C, $28 ; #######.
EQUB $3C, $28, $00, $28 ; ###...#.
.char_sprite_5
EQUB $14, $3C, $00, $3C ; .###..##
EQUB $00, $3C, $00, $14 ; ..##...#
EQUB $00, $3C, $3C, $3C ; ..######
EQUB $00, $3F, $3F, $3F ; ..######
EQUB $00, $3F, $00, $3F ; ..##..##
EQUB $15, $2A, $00, $2A ; .##...#.
EQUB $15, $00, $00, $00 ; .#......
EQUB $2A, $00, $00, $00 ; #.......
.char_sprite_6
EQUB $00, $14, $3C, $3C ; ...#####
EQUB $3C, $3C, $3C, $3C ; ########
EQUB $3C, $3C, $3C, $3F ; ########
EQUB $3F, $3F, $3F, $3F ; ########
EQUB $15, $3F, $3F, $3F ; .#######
EQUB $00, $2A, $00, $00 ; ..#.....
EQUB $00, $00, $00, $3F ; ......##
EQUB $00, $00, $00, $2A ; ......#.
.char_sprite_7
EQUB $3C, $3C, $3C, $3C ; ########
EQUB $3C, $3C, $3C, $14 ; ######.#
EQUB $3F, $15, $3F, $15 ; ##.###.#
EQUB $2A, $2A, $3F, $15 ; #.#.##.#
EQUB $15, $3F, $15, $3F ; .###.###
EQUB $3F, $2A, $00, $00 ; ###.....
EQUB $2A, $00, $00, $3F ; #.....##
EQUB $00, $00, $00, $2A ; ......#.
.char_sprite_8
EQUB $3C, $28, $14, $28 ; ###..##.
EQUB $14, $3C, $3D, $2A ; .######.
EQUB $15, $3F, $2A, $00 ; .####...
EQUB $15, $2A, $00, $00 ; .##.....
EQUB $3F, $3F, $2A, $00 ; #####...
EQUB $00, $15, $2A, $00 ; ...##...
EQUB $00, $00, $00, $00 ; ........
EQUB $00, $00, $00, $00 ; ........
Code: Select all
shapes=&2C00
PRINT"Loading sprites at &";~shapes
FOR I%=0TO5:READfilename$:PRINT"Sprite ";filename$
OSCLI("LOAD "+filename$+" "+STR$~shapes)
I%?shapeloaddr=shapes AND&FF
I%?shapehiaddr=shapes DIV256
READ I%?shapesize,I%?shapedepth
shapes=shapes+I%?shapedepth*I%?shapesize
NEXT
DATA LDIVER,12,16,RDIVER,12,16,LFISH,4,8,RFISH,4,8,LSHK,16,16,RSHK,16,16
PRINT"Sprites loaded, next free byte=&";~shapes
Code: Select all
51.shapeloaddr
52EQUD 0\&7C-7F
53.shapehiaddr
54EQUD 0\&80-83
55.shapesize
56EQUD 0\&84-87
57.shapedepth
58EQUD 0\&88-8B
Thank you so much for looking into this. Really appreciate that. I've not had a chance to try this out yet (family and work!), but will get stuck in as soon as I am able!0xC0DE wrote: ↑Sun Feb 13, 2022 2:36 pm You have 6 shapes (sprites) so you need to add 2 extra bytes to each of 4 following labels in zero page:
Code: Select all
51.shapeloaddr 52EQUD 0\&7C-7F 53.shapehiaddr 54EQUD 0\&80-83 55.shapesize 56EQUD 0\&84-87 57.shapedepth 58EQUD 0\&88-8B
Yeah, I may have bitten off more than I can chew, in terms of the size of sprites I've used! I may have to dive into 8bs.com's magazine archive, as there were some machine code sprite series printed in there (the latest I'm aware of was in The Micro User during 1989, but there were series during the earlier years from Kevin Edwards and Roland Waddilove as well).jms2 wrote: ↑Sun Feb 20, 2022 9:47 pm No offence taken - it was only a quick lash-up anyway!
It's nice to see how the game has progressed. Both the Basic and Assembler versions are now looking very good, and actually the Basic version is close behind in terms of appearance and gameplay.
As you have noticed, the sprites use up a lot of memory (960 bytes, nearly 1k). This is because they are big, and in Mode 2. The screen itself uses up a huge chunk of memory (20k), and each sprite swallows up more of the small amount you have left. Ideally the sprite routine would be able to plot flipped sprites, thus reducing the requirement to 480 bytes. Unfortunately the Creative Assembler routine doesn't do this, although I'm sure it would be possible to modify it.
The collision detection routine is crude because it isn't really machine code at all, it's mostly Basic. I just use a machine code routine to convert co-ordinates to an address. Basic then checks the byte at that address for a specific combination of two pixels (eg, both red). Ideally it would return a positive result if either or both pixels are red. This would be much easier than adding sprite flipping, and I'm sure I could do it.
Yes - it's possible - but before you go venturing into the dark arts of interrupts and timers there is probably some more space that you can use. You have page at &1100 (to allow the use of the DFS) but you could quite easily use from &E00 by disabling the DFS giving another K of space (The data to be loaded into this would need to be loaded somewhere else first then copied down to &E00 after all your loading had taken place). Personally I tend to raise PAGE to the highest possible value that my code will work in and use the space below this for code/data.Wonder if it's possible to switch palette twice (the sky, the sea, and the sand?)
OK - I'll bite . First thing to do is stop using arrays to store the fish data. The check routine is going to need access to the co-ordinates and it is possible to get these out of the BASIC variable space it's easier (in my opinion) to simply store these in memory. You are in MODE 2 so the actual pixel resolution is only 160x256 - both of which fit in a single byte.Think I'm asking for the bounding box routine in assembly, that would have appeared in Creative Assembler. The 'missing' chapter?
Oh my, that is a vast improvement in speed and reliability. Thank you so much. At this rate, you'll have to be the author of this work!
But of course. I was looking at the wrong Owlet link from way backChrisB wrote: ↑Thu Feb 24, 2022 5:30 pm The shark collision detection is using the "read point on the screen" technique. It might be better to just do a box comparison. Given there are only two objects involved picking a point to be the sharks mouth and checking if this is within the diver's area is might be more efficient/effective.
Thank you for that. Fingers crossed, I may actually have some time later this week to do some more work on this. Here's hoping!