Polymer Picker (formal release)

[sa_scott]

v1.10 released (28th Sep, 2023) - play online or read latest post in the dedicated thread

Here is the new game I am currently working on - currently titled Polymer Picker (the link takes you to The Owlet editor).

The idea of the game is to swim in the ocean, picking up bits of plastic, before the fish eat them. You move the diver around using the Z,X,F and C keys. Currently the fish just swim around.

Although I've got the fish and the diver moving reasonably well, blasted collision detection is getting the better of me in terms of the diver collecting the bags (the fish will need a similar technique). As I am using graphic coordinates, I'm relying on the use of POINT half way along the divers body then slightly below (sort of where the 'hand' is) to detect the red bags (currently blobs of colour).

Once the POINT collision is invoked, I call PROCcheck. This is where I attempt to use a bounding box to determine which of the bags I've picked up, from the BX%(),BY%() arrays. The loop I'm using is clearly not working, and I've spent too long looking at this to see what I'm doing wrong!

I'm wondering when I'm going to start hitting the limitations of MODE2. I would eventually like to have different levels, based on the time of day (denoted by the cyan section at the top, this can change colour according to whether it is daytime, evening or nighttime, plus different creatures to avoid, sharks or swordfish perhaps?). I can't have too much going on, otherwise it will slow down horribly.

I would be most grateful for any assistance on this game. It's my first original game on the Beeb this century, so it's nice to have a clean slate!

Thanks in advance!

Steve

[ChrisB]

I think you're getting your coordinates mixed up.

When you plot the bags you use MOVE then PRINT using graphics coordinates. This means that the top left of the bag is the point stored in the array.

When you come to check you calculate a bounding box starting at the diver's hand and then check if the box lies within this. I've modified the code to draw the box you calculate and it looks like this.

So you can see that when the top left of the bag is not going to be inside the bounding box when the diver's hand touches it. If you plot the bags with an offset (say -31,+15) then you're comparing with the centre of the bag.

Your comparison is also incorrect.
IF BX%(J)>TLX AND BY%(J)<TLY AND BX%(J)>BLX AND BY%(J)<BLY AND BX%(J)<TRX AND BY%(J)<TRY AND BX%(J)<BRX AND BY%(J)<BRY:HIT=J:J=10
should be
IF BX%(J)>TLX AND BY%(J)<TLY AND BX%(J)>BLX AND BY%(J)>BLY AND BX%(J)<TRX AND BY%(J)<TRY AND BX%(J)<BRX AND BY%(J)>BRY:HIT=J:J=10

Having said all that the comparison is overkill in the first place. Comparing against the top right X and bottom right X is duplicated effort. It would probably be better to think "outside of the box". I.e. if the diver's hand is to the left of the left hand side of the box then you haven't hit it so can move on. That would only be 4 comparisons per box.

[sa_scott]

I think you're getting your coordinates mixed up.

When you plot the bags you use MOVE then PRINT using graphics coordinates. This means that the top left of the bag is the point stored in the array.

When you come to check you calculate a bounding box starting at the diver's hand and then check if the box lies within this. I've modified the code to draw the box you calculate and it looks like this.

diver.png

Thank you so much for clarifying this.

Your comparison is also incorrect.
IF BX%(J)>TLX AND BY%(J)<TLY AND BX%(J)>BLX AND BY%(J)<BLY AND BX%(J)<TRX AND BY%(J)<TRY AND BX%(J)<BRX AND BY%(J)<BRY:HIT=J:J=10
should be
IF BX%(J)>TLX AND BY%(J)<TLY AND BX%(J)>BLX AND BY%(J)>BLY AND BX%(J)<TRX AND BY%(J)<TRY AND BX%(J)<BRX AND BY%(J)>BRY:HIT=J:J=10

This is what hours of late night coding can do. Less programming, more prog ramming!

Having said all that the comparison is overkill in the first place. Comparing against the top right X and bottom right X is duplicated effort. It would probably be better to think "outside of the box". I.e. if the diver's hand is to the left of the left hand side of the box then you haven't hit it so can move on. That would only be 4 comparisons per box.

Can you tease out this explanation a little more? I'm not quite joining the dots, so to speak.

Other than that, thank you for your input. I have something to look forward to now!

[ChrisB]

Basically if your divers hand is to the left of the box's left edge then it isn't in the box. Similarly with the other edges. So you can start by assuming that the point is inside the box check against the edges to prove that is isn't.

An example is probably easiest. Use ZXKM to move.
https://bbcmic.ro/#%7B%22v%22%3A1%2C%22 ... ALSE%22%7D

Edit - multiple box check example.
https://bbcmic.ro/#%7B%22v%22%3A1%2C%22 ... PROC%22%7D

[sa_scott]

Many thanks @ChrisB.

[sa_scott]

Many thanks @ChrisB. I've updated my implementation now.

One thing that is apparent, is how slow it all is, which I suspected would be the case. Also, the fish have no collision detection. I fear that if I add this as well, it's going to be even slower.

This is where I wish I knew more about 6502. The only other way would be to minimise the amount of animation occurring onscreen, or make the diver graphic a lot smaller - which I'm also not very keen on doing.

Any hints or tips on optimisation appreciated. And thanks again ChrisB!

[ChrisB]

If you add back in the POINT(x,y) to check the colour first then you can abort the check if it's not a red box - which makes it significantly faster. I've also removed the unnecessary I%=TRUE (leftover code from before) and corrected the box sizes.

Updated Code

In terms of checking the fish - you're only moving one fish at once so you only need to check that one. Again - using the POINT to check it's nose (or whever your active point will be) then once you've got a red pixel checking which bag is which would probably not be that much slower.

[sa_scott]

Oh my, thanks again @ChrisB, that is quite a big difference in speed. And you are right, adding back in the POINT check makes perfect sense, from doing all that needless checking.

My intent is to replace the red box with different plastic objects (cans, bottles, bags, etc). I'll have to be careful in ensuring that the graphics I employ have enough of the colour for the POINT check to work in the first place.

I'll work on the fish checking for now, ensure that this works before complicating myself further.

But again, many thanks - you definitely earn a credit in the finished product

[sa_scott]

I've taken the suggested revisions, and added some further amends to have the bare bones of a game here:

Updated link

If a fish touches a 'wet wipe' (that's the graphic for now) then it disappears ('dies') - the wipe also disappears, as it has been consumed by the unlucky fish. This adds the potential game mechanic of collecting more rubbish than there are dead fish. If there's too much of the latter, then it's game over.

The bits of rubbish hopefully cluster away from the edges of the screen, otherwise it would be impossible to collect them (the diver can't swim beyond the confines of the screen).

The game runs pretty well for now. Wondering whether I can increase the number of fish, or rather introduce different types of fish (faster moving predators, such as swordfish or maybe sharks); perhaps an oxygen meter, so you have to get to the surface (yeah, the diver has an oxygen tank at the moment, I suppose it could be removed, so you're snorkelling?)

As always, I'm open to suggestions on any further optimisations I can make.

[sa_scott]

After a flurry of development last week, I've attached a very early alpha version of the game.

There are 4 themed levels, based on the time of day. You have to collect a particular rubbish item (wet wipes, bottles, beer can 'yokes', plastic bags) before the fish eat them all by accident. The screen tells you how many fish are left, and how much rubbish is left to collect. Fish turn red, and drop to the sea floor if they eat any plastic.

I've added a rudimentary instruction screen, and attempted to iron out any bugs I've found. There are a few issues, and a few questions.

• Sometimes, the diver graphic leaves some artifacting when switching direction. Because it occurs randomly, I can't tell why it happens, unless it's because of the emulator I'm using (b2). I have seen it once or twice in the Owlet version from earlier in this thread, so my coding remain suspect.
• If VDU23 graphics are already rendered onscreen via VDU5, I should be able to redefine them without wiping out the previously rendered ones? I'm considering using further graphics for rendering more interesting stuff on the sea floor, such as coral, sea grass, rocks, and perhaps bonus items.
• The game at present - is very boring to play. Some more compelling mechanics are required, but without sacrificing speed.

Some feedback on this iteration would be great, as I've hit a fallow period personally, which is sapping me of inspiration to push on with this. The boredom level is something I'm finding it hard to enthuse about solving, and I'm struggling with creation of sound envelopes, without simply nicking them from other games (something I've been guilty of with my other work).

Thank you everyone.

[jms2]

Hello Stephen

I have had a quick play of your game using BeebEm this morning, and the good news is that I didn't see any graphical artefacting problems. The slightly less good news is that I found it impossible to collect two of the beer can yokes (I could collect all the others). I can't think why this would be happening!

My main suggestion I think would be that the game needs some kind of danger added to it, because currently you can't die - and the fish don't seem be too greatly imperilled by the plastic waste either. Running out of air would be a good idea, and maybe some static obstacles would be good.

Technically, it would really benefit from a simple machine code sprite plot routine for the diver (and the fish as well really).

[colinhoad]

Hi Stephen! Great little game, I enjoyed giving it a quick playthrough - and I really like the concept, very true to the origins of the Beeb, a game that has an educational purpose.

I, too, encountered the "unpickable" problem on level 3 - I've attached a save state from when this occurred, not sure if that's helpful to you? Also, I saw a small amount of 'artefacting' on the same level (moments after the save state) where a white 'ghost' of the diver got left behind as I moved from left to right. I realise these kinds of bugs are frustrating and may not be easy to recreate!

polymer_unpickable.uef

(129.26 KiB) Downloaded 47 times

[sa_scott]

Hello Stephen

I have had a quick play of your game using BeebEm this morning, and the good news is that I didn't see any graphical artefacting problems. The slightly less good news is that I found it impossible to collect two of the beer can yokes (I could collect all the others). I can't think why this would be happening!

My main suggestion I think would be that the game needs some kind of danger added to it, because currently you can't die - and the fish don't seem be too greatly imperilled by the plastic waste either. Running out of air would be a good idea, and maybe some static obstacles would be good.

Technically, it would really benefit from a simple machine code sprite plot routine for the diver (and the fish as well really).

Thanks for testing it out. Would definitely agree with those suggestions. I had thought that collecting dead fish should be encouraged, as the plastic they consume would threaten sea life again. By having them at the bottom, combined with the air supply, this could offer more of a challenge.

I lifted a very simple assembly language routine for my other game Androidz to improve display of characters:

https://github.com/sassquad/androidz-re ... 0.bas#L112

I'm not sure it's that much faster to be honest. Much as I would love to use MC sprites (because multicolour right?), finding good articles on this is very hard. Much of it is from books, whose listings havent translated to actual files, so it's harder than it should be to test good code. I am aware of old articles from magazines such as The Micro User which featured MC code routines.

I should note that my other game Headcase Hotel uses assembly language, but I can't figure out where I got it from or how it works, too long ago!

https://github.com/sassquad/headcasehot ... s#L75-L110

Thanks again for your comments.

[sa_scott]

Hi Stephen! Great little game, I enjoyed giving it a quick playthrough - and I really like the concept, very true to the origins of the Beeb, a game that has an educational purpose.

I, too, encountered the "unpickable" problem on level 3 - I've attached a save state from when this occurred, not sure if that's helpful to you? Also, I saw a small amount of 'artefacting' on the same level (moments after the save state) where a white 'ghost' of the diver got left behind as I moved from left to right. I realise these kinds of bugs are frustrating and may not be easy to recreate!

polymer_unpickable.uef

Thanks for trying this out Colin. Funnily enough I wasn't thinking of the educational purpose in that way, the link to the Beeb, but because of things I read recently about plastic pollution, initiatives such as The Great Garbage Cleanup, and - more recently - the greenwashing of COP26.

I have been able to reproduce the unpickable problem as well. The single point collision detection works for the other levels, as most of the graphic is filled in. Beer can yokes however... don't work that way.

There are 2 other things which come to mind now, concerning how the rubbish is displayed onscreen:

• The random placement of items (level 3 demonstrates this) sometimes means you can never align with the items to collect them.
• Again, the random placement of items occasionally results in two or more items being placed on top of each other in a way that makes collection impossible (the use of GCOL3,x means the EORing of the graphics cancels out the rendering). The random nature of placement will therefore need refining... somehow.

Glad you got to see the ghosting effect as well. It's not just me seeing ghosts!

[sa_scott]

I've placed this version of the game as a downloadable zip and playable link online now:

https://bbc.godbolt.org/?disc=https://w ... d&autoboot

https://www.sassquad.net/downloads/poly ... -v0-01.zip

I've shared this thread on LinkedIn and Twitter, so I wouldn't expect Stardot's server to be choking up!

[jms2]

That machine code routine you linked to for displaying characters probably doesn't save very much time. It is still using OSWRCH to plot the characters, the only difference is that it uses machine code to pass the data rather than having to interpret VDU or print statements.

I was thinking about how best to integrate a sprite routine into the program. The tricky bit is deciding where the machine code should stop and where BASIC takes over! I think that the best compromise would be to store co-ordinates for the man and all the fish in a block of memory and then CALL a routine that plots (or unplots) them all. The BASIC would just need to poke updated co-ordinates as necessary and then CALL the routine. Only one byte would be needed for each x and y value, because Mode 2 is only 160 x 256.

Doing this would indeed allow multicolour sprites as you say, but the main advantage would be greatly increased speed and reduced flicker. Being MODE 2, it should also be possible to achieve degree of overlapping without corruption, even using a simple and fast method like EOR to plot the sprites.

I do have the ability to write such a routine... but only in theory! I'd be interested to have a go if you like.

[sa_scott]

That machine code routine you linked to for displaying characters probably doesn't save very much time. It is still using OSWRCH to plot the characters, the only difference is that it uses machine code to pass the data rather than having to interpret VDU or print statements.

The code was based on what I found in Matt Eastmond's games - Danger Dog being the most well known (MU Nov 1990). I guess it was a way to eke out a bit more speed.

I was thinking about how best to integrate a sprite routine into the program. The tricky bit is deciding where the machine code should stop and where BASIC takes over! I think that the best compromise would be to store co-ordinates for the man and all the fish in a block of memory and then CALL a routine that plots (or unplots) them all. The BASIC would just need to poke updated co-ordinates as necessary and then CALL the routine. Only one byte would be needed for each x and y value, because Mode 2 is only 160 x 256.

Doing this would indeed allow multicolour sprites as you say, but the main advantage would be greatly increased speed and reduced flicker. Being MODE 2, it should also be possible to achieve degree of overlapping without corruption, even using a simple and fast method like EOR to plot the sprites.

I do have the ability to write such a routine... but only in theory! I'd be interested to have a go if you like.

I would be very pleased to see such a routine, if you have the time and inclination! But I agree, the tension between Basic and 6502 is always the bugbear for me. Basic plotting and machine code plotting are worlds apart - reconciling screen coordinates with screen memory is not for the faint hearted.

One game that intrigues me in terms of it's Basic/MC mish mash, is Andrew Cook's Moon Patrol - http://bbcmicro.co.uk//explore.php?id=1414 - check out MOON1 and MOON2. It's a Mode 2 game, and uses assembly language to render sprites, yet there are also VDU23 characters drawn to screen, so it offers an interesting combination of both approaches?

[jms2]

Yes, that has some nice features, for example:

- MOON1 contains all the source code. It assembles the code, and then copies all the entry points into suitable resident integer variables.
- The source code is then binned by loading MOON2, thus saving memory.
- It does look like blocks of data are used to pass co-ordinates etc to the sprite routines.

I get the impression that the machine code is doing a bit more than I envisaged though.

[tricky]

The sprites from basic that I posted is very similar to what you suggest. It remembers the last place that a sprite was plotted and the basic pokes the new coordinates.
It has a slight twist in that you set a flag (byte) to tell it to plot and then on the next vsync it XORs the sprites off and on again and copies the coordinates, finally clearing the flag so that basic can start updating again. I think it ships the ones that didn't move.
It allows the height of the sprite to be set as well as the vertical start into a table which allows sprites to also be scrolled on and off from the top and bottom.

Sprites that can be used from BASIC

[sa_scott]

The sprites from basic that I posted is very similar to what you suggest. It remembers the last place that a sprite was plotted and the basic pokes the new coordinates.
It has a slight twist in that you set a flag (byte) to tell it to plot and then on the next vsync it XORs the sprites off and on again and copies the coordinates, finally clearing the flag so that basic can start updating again. I think it ships the ones that didn't move.
It allows the height of the sprite to be set as well as the vertical start into a table which allows sprites to also be scrolled on and off from the top and bottom.

Sprites that can be used from BASIC

Thanks tricky, I'll take another look at this.

[sa_scott]

Yes, that has some nice features, for example:

- MOON1 contains all the source code. It assembles the code, and then copies all the entry points into suitable resident integer variables.
- The source code is then binned by loading MOON2, thus saving memory.
- It does look like blocks of data are used to pass co-ordinates etc to the sprite routines.

I get the impression that the machine code is doing a bit more than I envisaged though.

I've used Owlet to pull apart some of the game. You can see what I've done here:

Mangled Moon Patrol sprite display

I've grabbed some of MOON1, namely the sprite data, and some of the assembly language, concerning sprite display and checking screen memory. Then got some of the code from MOON2, to establish what goes on.

The .display loop (I think) just EORs sprite data to the screen. By reprinting it, the EORing cancels out the sprite draw. It's very simple.
The .check loop is more elaborate, and seems to be comparing values of sprites, in a similar way to the OSRDCH(sic?) routine used in Danger Dog and Androidz, except it's able to check not only sprites, but VDU characters as well, which I didn't expect.

You can CALL display, but feeding into !&70 the sprite address (&0A00 is for 'spaceman sid', while the last 4 - 3440 is the screen memory location:

!&70=&0A003440 (draws sprite &0A00 into screen position &3440)

This is what I've figured out so far. Unfortunately, the bulk of MOON2 is a loop full of GOTOs, so it makes deciphering harder than it should be!

[jms2]

You have delved into the code a bit more than I did, but I have some other observations to offer:

The routine "display" outputs precisely 32 bytes every time, which is a single character's worth in Mode 2. The way it does it means that the sprite has to be aligned on character lines in the vertical direction. Horizontally it can be positioned anywhere, with an accuracy of 2 pixels. This seems quite limiting for your game.

I have not had a look at what Tricky has suggested, but I'm sure it is worth considering and could well be a better option.

[sa_scott]

A quick update:

• I've 'lifted' the air supply routine from Moon Patrol, and employed it in the game.
• I've simplified the method by which items are placed randomly on screen. There is an implicit grid, to ensure items don't get placed in such a way as to make it impossible to collect items. This potentially eases the path to using Tricky's library, but am not sure whether to make that leap just yet.
• Some further graphical enhancements have been made. A tropical island is rendered on top of the sea, it's colour depends on the time of day. I'll play around with this a bit more, but I've lifted the mountain rendering procedure from The Wishing Wells game, and performed some amends to help it render accordingly.
• I was playing around with a BBC Micro Bot tweet that rendered ferns, to see if it could be used to render sea ferns across the bottom, where the sand is. The results were a bit disappointing - I may have to rein in my ambitions a little here, and adopt a different approach.

[sa_scott]

You have delved into the code a bit more than I did, but I have some other observations to offer:

The routine "display" outputs precisely 32 bytes every time, which is a single character's worth in Mode 2. The way it does it means that the sprite has to be aligned on character lines in the vertical direction. Horizontally it can be positioned anywhere, with an accuracy of 2 pixels. This seems quite limiting for your game.

I have not had a look at what Tricky has suggested, but I'm sure it is worth considering and could well be a better option.

Yes, as the sprites are single character, the 32 bytes makes sense. The sprite movement in the game on the vertical suggests it doesn't move by character lines, but by possibly half a character. I'll probably have to check this to be sure, but the way the other sprites move around suggest it is a bit smoother. There is a seperate chunk of assembly language which seems to figure out how the various characters move around - one called The Fuzz keep homing in on you, while another moves in random directions including diagonal, the last one moves slowly in straight lines horizonally or vertically.

I'm not certain I'll ever use this game's code, but because of the Basic/assembly hybrid nature, it's worth a look. Mike Goldberg's later magazine games such as Blue Meanie, Car Race and Pipe Loonacy employ assembly language for sprite rendering. I only wish he had it in place for Dickie Brickie, as that game would have benefitted hugely from such a routine, in terms of speed.

[sa_scott]

I've added v0.02alpha to this post, which contains the enhancements referred to in an earlier post

• oxygen supply - this goes down rather too quickly at the moment
• added scenery (mountains)
• better randomised positioning, to hopefully reduce incidents of poor collision detection, or overlapping items.

Incidentally, the BBC Micro bot tweeted out this lovely demo from 0xCODE6502 - I'd love to get these bubbles into the game... somehow.

https://twitter.com/bbcmicrobot/status/ ... 3780544513

[sa_scott]

0xCODE6502 kindly put the Bubbles source code onto Github.

https://github.com/0xC0DE6502/6502-asm- ... bbles.6502

I've tried to convert it into a BASIC assembly listing here:

Bubbles code in Owlet

Safe to say... it's not going well. Yet!

[jms2]

I started making a slightly amended version of your game where the coordinates for the fish and the man are each stored in a byte rather than a BASIC variable, with the vague plan that this would make it easier to interface to a sprite routine later. This almost works, however I also went looking for a Mode 2 sprite routine (Tricky's being for Mode 5) and what I found will require some changes to my approach.

There is a nice Mode 2 routine in "Creative Assembler" by Jonathan Griffiths - this also has a design program too, plus an example game which shows how to interface to the routine. The neat thing that he has done is copy the sprite number, X coordinate and Y coordinate to the A, X and Y registers just before CALLing the routine, which means you can continue to use BASIC variables in the bulk of the program (albeit with a different co-ordinate system).

Have a look at Chapter 14 (attached) - it is nicely commented. I think this routine looks like it would be a good fit with your game.

14EXAMPLEG.PDF

(73.16 KiB) Downloaded 37 times

Note that it can only plot with byte (not pixel) accuracy, so the X co-ordinate is 0 to 79. To get pixel accuracy it will be necessary to have two copies of each sprite, one offset by one pixel. However this also gives you the potential for animation.

[sa_scott]

I started making a slightly amended version of your game where the coordinates for the fish and the man are each stored in a byte rather than a BASIC variable, with the vague plan that this would make it easier to interface to a sprite routine later. This almost works, however I also went looking for a Mode 2 sprite routine (Tricky's being for Mode 5) and what I found will require some changes to my approach.

There is a nice Mode 2 routine in "Creative Assembler" by Jonathan Griffiths - this also has a design program too, plus an example game which shows how to interface to the routine. The neat thing that he has done is copy the sprite number, X coordinate and Y coordinate to the A, X and Y registers just before CALLing the routine, which means you can continue to use BASIC variables in the bulk of the program (albeit with a different co-ordinate system).

Have a look at Chapter 14 (attached) - it is nicely commented. I think this routine looks like it would be a good fit with your game.

14EXAMPLEG.PDF

Note that it can only plot with byte (not pixel) accuracy, so the X co-ordinate is 0 to 79. To get pixel accuracy it will be necessary to have two copies of each sprite, one offset by one pixel. However this also gives you the potential for animation.

I don't know what to say. Thank you for having a go at this.

I have to say, every time I look at the game, I find the lack of colour in the characters, rather dispiriting. I'm currently playing around with the air supply routine. I don't know if it's the b2 emulator playing about, but the air supply does not go down in a consistent way. It slows down when you move, as soon as you stop moving, it decreases at twice the rate. Not too sure what I am doing.

Funnily enough, I was looking through this book last night, as I had bought the Drag and Drop Book CD some time ago, so I should have the programs as well somewhere. I was admittedly skim reading, the subject matter is beyond my current mindset. I'll have another look at some point.

Thanks again for looking into this though - this idea has potential!

[richardtoohey]

It slows down when you move, as soon as you stop moving, it decreases at twice the rate. Not too sure what I am doing.

I'm definitely not an expert but it sounds like no CPU time left after your key detection/movement code for the decrement oxygen code to have some CPU cycles. Maybe?

[ChrisB]

What Richard said. Having played with the code when the diver moves there's much more time taken with unplot/plot etc. Than when the fish just move. This might be alleviated with some sprite code. Alternatively why not tie the oxygen to TIME which will decrement at a constant rate.