Polymer Picker (formal release)

[lurkio]

… so I can extract files this way.

Also try Disc Image Manager:

viewtopic.php?p=299825#p299825

[jms2]

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.

[sa_scott]

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.

Sorry for the delayed response on this. Time hasn't been on my side, and even this is a quick message.

Having tried that little program, it's clear that the data from the sprite editor is saved in a different manner, to that of the data maker.

Looking at Griffiths' example game, it uses this code to load in the sprite data:

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

whereas the data maker is as follows:

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

Clearly, the fun stuff is between lines 110-160. How the data strings are put together relies on the data being in a particular format, which is how Griffiths' code is interpreting it. I can't figure out how to implant his code into the data maker, to get the desired data strings.

I'm getting rather stuck between data extraction of sprites, and the new world of having it at hand within VS Code. Can anyone point to a game that is assembled using BeebAsm that utilises Basic, machine code, and sprite data files, so I can bring all this together?

Thanks in advance!

[jms2]

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.

Turning to the detail of converting sprite data into DATA statements:

The Jonathan Griffiths "format" is just raw data, one byte after another, and contains no "metadata", ie the width and depth. This is hard-coded into the game as you see below, and is placed into two special tables called "shapesize" (for the width) and "shapedepth" for the depth. The machine code indexes into these tables when plotting any given sprite, using the sprite number as the index.

By contrast, the Data Maker program assumes that the width and height are stored in the first two bytes of the data file. I don't know how the sprite plotter works in this instance - but the most efficient way would be to replicate the Griffiths approach at some point downstream of loading the sprite data.

So as a starting point, with the aim of getting the existing sprite data into textual form, you could modify the data maker program to accept the width and height from the user, rather than from the data:

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

I haven't actually tested this, so it may need some experimentation, but in principle it should work.

[sa_scott]

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.

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.

I did check out the data maker, and it did work, so many thanks for that. I was surprised it didn't output in hexadecimal format, but the original listing does the same thing. I did have some kind of data maker for Headcase Hotel back in the day, but that was too long ago to recall where I got it from.

BeebAsm merely acknowledges their presence in the build scripts, through the PUTBASIC command, but other than that, it's heart is more into assembler.

Thanks again for your efforts on this. Other than creating a few more sprites, I am struggling with the bridging between old and new world on my setup, but I think this is more for personal reasons - I've hit a slump, and my day job has now picked up to a point where it's really difficult to find time, and when I do, I just feel 'overwhelmed' and back off again. I need a real kick up the backside to get back on the saddle!

[fizgog]

Don't give up it's going to be a good game.

Are you wanting something like these data statements 8x8 for your sprites from the Micro User?

Direct link to further reading https://archive.org/details/KevinEdward ... 5/mode/2up

In a couple of days to a week I should be able to release an alpha version of AcornPad which can in theory get you the above sort of data

Current reading thread is here
viewtopic.php?f=55&t=23918

[fizgog]

I had a spare 5 mins, so made the shark as an example with hex output

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 ; ........

[sa_scott]

Thank you so much fizgog - much appreciated!

[sa_scott]

It's been ... a while since an update. In the past week, I have started to pick up the 6502 version of the Polymer Picker game. I incorporated the shark sprite into the attached disc image. However, I cannot get the diver sprite to display properly.

The sprite appears all corrupted, after adding the shark graphic to the data loading routine.

Here's an extract from POLY1, showing the amended data strings for the shark graphic.

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

PROCwrsprite(0,X%,Y%) and PROCwrsprite(1,X%,Y%) should display the diver in either direction. But instead, I get corruption

The only things I can think have happened are either, or both of the following:

• The POLY2 program is too long, even with PAGE at &1100, and the end of the code is overwriting the diver sprites.
• The method used to load the sprite data is somehow corrupting the diver sprite, when the shark sprite is added. The shark is a different size to the diver and fish sprites, so perhaps this is at issue?

In any case, I'm utterly stumped as to what is causing this. The diver sprite files themselves are not corrupted, as you can load them onto the screen just fine.

Any assistance is most appreciated!

[0xC0DE]

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

[sa_scott]

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

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!

[sa_scott]

Thanks to all who contributed these past few weeks - I really appreciate your time on assisting me in getting this over the line.

I've attached two versions of the game here. v0.07 offers a few minor enhancements, but is still considered incomplete.
I've also attached v0.01 of the assembly language assisted version. Both are now aligned in terms of their UI now.

Here are screenshots from the assembly version:

As you can see, the shark doesn't always display correctly (more on this below)

Here are my thoughts on these:

• At the moment, collision detection is better in the Basic version. I get extremely varied results with the 6502 version. Sometimes I can pick up the items, other times, I can't. I've enhanced the detection by adding a 4 pixel 'scan' to attempt to pick up the item colour, but the results are still varied at times.
• The movement of the shark in the Basic version is so slow. It's clearly much better in the code version, but in both versions, the issue of how to deal with collision detection remains a concern. The 6502 version also has issues with switching direction, I'm getting artifacting - pretty sure the procedure to deal with it's rendering is not as well programmed as those for the fish and diver. In the case of the latter, I've managed to get artifacting when switching direction, but more rarely.
• The random coordinate function is still placing items in places it shouldn't, such as deep in the grass. Not a big problem in the Basic version, but the collision detection in the 6502 version doesn't work at all if items are hidden in the sea grass.
• In both versions, the breathing sound isn't clipped when pressing Enter/Return.
• The coral doesn't yet hurt you. I think in both versions, the graphic evades collision detection, as it's relying on a point colour in a certain place. Being hurt reduces your oxygen, and in the case of the shark, would normally make it move faster.
• The fish dont turn red like before, as the graphic was switched to a sprite. Would be great to be able to turn it red, without having to define another sprite to do it, is this possible?
• I'm unsure as to whether adding extra sprites is going to hit me hard, memory wise. There are others I'd like to add in, I may have to add a shark sprite for when it is facing you, instead of just left and right.
• Wondering how to animate the divers legs, I may have to open the graphics and redraw them using the flashing colours, so I can redefine them as frame colours?

I'd very much like to introduce extra adversaries, such as jellyfish and pufferfish (these can stay still, they don't need to move, or perhaps the pufferfish can move very slowly), but this puts pressure on the collision detection - am I relying on point colour detection, or position detection? Either way, a bounding box technique is required, and the more code required, the less memory I have left. And in the Basic version, this will make it even more slow.

I'm still very unsure of myself with 6502, but is the Creative Assembler book's general purpose sprite routine... too general for a game like this?

At the very least, these two versions can serve as a good comparison of the game in Basic and assembler, but any further feedback is always welcome

[sa_scott]

I'm naughty. The collision detection was by jms2, and there's me criticising it!

My bad! There is no way I would have done it, so who am I to say otherwise!

Humble apologies jms2!

[jms2]

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.

[sa_scott]

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.

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).

Collision detection is a key issue here - if I can find anything of value, that would be great.

If I have to face up to using Mode 5 instead, I'm gonna need some sort of interrupt driven palette switching - the sky section requires a different set of colours to the sea itself. Wonder if it's possible to switch palette twice (the sky, the sea, and the sand?)

[lovebug]

The game is coming along nicely, great work

If you are running low on memory maybe program the unofficial 10K mode 8 which is a 80 x 256 mode 2 type display

This would also cut the sprite storage size in half too

Maybe the horizontal resolution might be too low for your graphics ?

just a thought

[ChrisB]

Wonder if it's possible to switch palette twice (the sky, the sea, and the sand?)

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.

The assembly code currently ends at &9C9. Page &A00 is reasonably safe to be used for code/data as well.

As to your checking routine - the reason we introduced the POINT statement was to reduce the time taken to perform the search/check for the bags. However if you moved this to assembler - and moved the data structures for the fish/bags there as well - then you could use the original "brute force" checking logic which does more work than necessary - but because it's so much faster would almost certainly provide a speed up. This would probably even fit in page 9 - the bags are plotted at character boundaries - which means you're doing very simple one byte comparisons.

[sa_scott]

Many thanks for your replies.

I've done some digging regarding collision detection. I came across this article regarding the subject in the March 1987 Micro User. I've attached screenshots to the post.

This details a technique which ChrisB highlighted way earlier in the thread, the 'bounding box' technique. This article highlights the machine code equivalent.

The listing has two subroutines - bumped and collision - the collision routine does the work of detecting, while bumped feeds the coordinates required to perform the detecting.

Clearly something like this would be highly invaluable, not only for the sprites, but even for detecting the rubbish collection.

• The listing probably uses a different method of screen coordinates.
• Will I need to consider rendering the rubbish as 'sprites', or use the sprite plotting solution to render VDU characters?

Think I'm asking for the bounding box routine in assembly, that would have appeared in Creative Assembler. The 'missing' chapter?

[ChrisB]

Think I'm asking for the bounding box routine in assembly, that would have appeared in Creative Assembler. The 'missing' chapter?

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.

So the array FX%(A%) now becomes FX%?A% with FX% being defined in page &A (I've left 16 bytes of space for the arrays rather than the 8 you have used for now in case you want to change the number of fish/bags - this could be reduced.) I seem to have broken the collision detection at the moment - but that it to be replaced.

pp.ssd

Next step is to write a check routine.

[ChrisB]

Here's a version with the diver/bag collisions done in assembler. I've reduced the space allocated - so you'll need to stick to 8 of each of bags and fish.

pp.ssd

(21.5 KiB) Downloaded 50 times

Next to do the fish/bag collisions.

[sa_scott]

Here's a version with the diver/bag collisions done in assembler. I've reduced the space allocated - so you'll need to stick to 8 of each of bags and fish.
pp.ssd
Next to do the fish/bag collisions.

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!

I did fix the shark sprite artifacting, btw. I'm working at the moment, but can't wait to look at what code you've done to achieve this.

[ChrisB]

And this one has the fish detection in as well. Some of the changes are around the fish and diver movement values - this is because I'm assuming that the byte values are unsigned.

pp.ssd

(21.5 KiB) Downloaded 53 times

[sa_scott]

Thanks so much ChrisB!

I've attached an updated version, where I've brought it together. I've performed some rearranging of colours (well, used VDU19,0,4;0; instead of COLOUR132:CLS, so the fish and shark are now correctly coloured (I guess the EORing was responsible originally, this puts things back to how they should be)

The shark collision detection isn't great frankly. Since your diver character is smaller than the shark, I think that may be connected to the unreliable detection. The high pitched beep is when you are hurt by the shark, and your air reduces more. The shark also swims faster, because you're bleeding).

Clearly more to do, but it's so far ahead of where it was a week ago!

[ChrisB]

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.

[sa_scott]

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.

But of course. I was looking at the wrong Owlet link from way back

[sa_scott]

Not too big an update, to be honest. I'm at the point where I really should start using Github for version management, especially with two versions of the game on the go now.

This version features a bit of bleeding when the shark gets near you (just a sprinkling of PLOT69s around you a bit). It's a bit scrappy for now.
There's also a bit of extra sealife on the ocean floor. See if you can spot them in these images

The shark collision detection is not sorted as yet, I'm gonna need a decent block of time to work it out properly. Then I can start to calibrate the playability of the screens.

• I'm starting to think about how to add greater variety to the levels. Why stick to the tropics? How about the Arctic? Gonna have to be careful with my sprites (I'm guessing a seal, or polar bear as your predator, instead of the shark - mind you, I could change the shark's colours, so it's more like a Greensand shark, with literally green and yellow colours, as in earlier iterations)
• And how about completely dark caverns, where you only have a dodgy light that keeps switching off, so you then have to find the rubbish in the dark. When the light comes on, you can quickly see where they are floating.
• Why stop at just 8 items to collect? You can always collect more, until you've collected the desired number.
• Add in a scoring mechanism, losing points for each lost fish, against how much air you have left.
• I have a pufferfish sprite, if you get injured by it, then the shark tracks you more quickly.

I'll see how I get on in the coming days and weeks, but with most of the collision detection sorted out now (thanks again ChrisB!) it's starting to take proper shape now.

[sa_scott]

I've created two repos for the game, one for the BBC Basic version, and one for the BBC Basic/Assembly version:

https://github.com/sassquad/polymer-picker
https://github.com/sassquad/polymer-picker-6502

I only did this with a little bit of time to spare, but I hope the repos can be cloned and rebuilt accordingly. The disc images are included for both. It has been a while since I last touched the game, as my family and I all fell down with Covid, having managed to avoid it for 2 years. We're thankfully all better now, for the most part.

Lack of time remains my constant enemy now, thanks to work and family commitments. I'll make another update as soon as I am able.

[sa_scott]

I tweeted about this a week or so ago, but didn't update here accordingly.

I finally spent some time looking at the code, and made some further refinements. I grew tired of seeing my 'boat' being nothing but asterisks, so hit the drawing board, and came up with some VDU definitions for a boat. By rendering it twice, in different colours, and offsetting the dark version, I was able to cheat with adding outlines to the boat shape. I'm well pleased with the result.

I've added the ability to refill your air supply when you swim under the boat. This may prove useful for harder levels (more sharks, hazards), but am toying with whether this is a one-time only refill. Given the small number of items to collect, it may prove too easy if you could have unlimited refills.

I'm also considering whether there should be a score, and with it, a high score table. My current version features the Mode 7 score table lifted from one of Gordon Key's games, as the routine seemed easy enough to incorporate. It did reveal how little memory I have, as I got the 'No room' error upon playing the second game. This encouraged me to convert more MOVEs and DRAWs into VDU25 statements, to reduce space, along with bulking up various lines of code into single lines. This gave me back more memory, but I may have to reconsider having it, if I find room too lacking for building up the levels.

I have found that the shark sprite leaves artifacts when it is aligned with your horizontal position, as it can't figure out which directional sprite to print. Clearly it has to favour one direction over another, so it's yet another problem to figure out.

I still need a way to define decent envelopes, as well as introduce small tunes into the game, for added polish. I'm really struggling with a way to do the latter, but found another thread which featured an 'envelope' shaper, which was quite useful.

I'm always itching to do more coding of this game, but - after a good Sunday a couple of weeks back - I promptly fell ill with some cold virus for a number of days. I've since gotten better, but have been snowed under with work again. I'll no doubt return with an update, but with no idea as to when.

[fizgog]

I'm liking the boat graphics, it gives it a bit more polish to a wonderful game.

[sa_scott]

I'm liking the boat graphics, it gives it a bit more polish to a wonderful game.

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!