Polymer Picker v1.10 released

[sa_scott]

V1.10 released - click here to read the post.

Hi all,

I've been picking about with Polymer Picker these past weeks, mostly to try and remember how all of the code works, and to try and add some new features into the mix.

I've therefore attached an alpha of v1.10, which attempts the following:

- for speed, I've reduced the number of fish from 8 to 4. This is primarily to increase the speed of levels with both the fish and shark.
- the difficulty is increased a little earlier on now, the previous game was a little too gentle in it's difficulty curve.
- addition of a static obstacle, a jellyfish

The graphic of the jellyfish(Octopus?) was cribbed from Rob Walmsley's Crystal Sea game, and the intention is to add a few of these around the level, in a manner which doesn't impede on the diver's ability to collect the items of rubbish.

The jellyfish are only going to be static, no movement is intended. However, I'm at a loss as to how to detect colliding into them. I already have a box collision for the diver and the fish, and for the collectibles, and was hoping to do the same for the octopus.

For reference, here is the assembly language used for point checking:

Code: Select all

.check
STX &AB0:STY &AB1:LDY #7
.checkloop
LDA &AE0,Y\BX:CMP &AB0:BCS notinbox\BX>CX
CLC:ADC #8\BW%:CMP &AB0:BCC notinbox\BX<CX
LDA &AE8,Y:CMP &AB1:BCC notinbox\BY<CY
SEC:SBC #8\BH%:CMP &AB1:BCC checkfinish\BY>CY - inverted check
.notinbox
DEY:BPL checkloop
.checkfinish
STY &AB2:RTS

I believe it was 'jms2' who provided this, I'm at a loss as to how to achieve this. If we have the octopus and shark onscreen at the same time, I'm worried the box collision is going to heave massively.

Any thoughts on the above? I'm somewhat put off from starting a new Polymer Picker game at the moment (thanks to those who provided their input on it, in my other thread), but would appreciate some learned opinion from people far better at this than I am! (let me know if a Pull Request on the Github would be preferred for easier code browsing)

I'm going to keep trying to find an acceptable solution without adding too much more code.

Other items on the agenda:

- getting rid of the welcome message on each level (the 'jingle' is terrible, another one is required) - it might be quicker to switch to the next level and then play a jingle just before play resumes.
- Perhaps moving some assembly code around, so I can access extra envelopes (I'm stuck with 4, due to code assembling at &900)
- The 'level' data for the mountains, and sealife colours could use further optimisation, to reduce memory.

I look forward to your thoughts on the above. I do enjoy tinkering with this, even if I don't know what I'm doing half the time!

Steve S

[jms2]

For reference, here is the assembly language used for point checking:

I believe it was 'jms2' who provided this, I'm at a loss as to how to achieve this.

Not me I'm afraid. I adapted the sprite plotting code from "Creative Assembler" into your original listing, and I think I added a crude machine code version of "POINT", but not the bounding box thing.

I could never figure out a good way to do collision detection myself, and one of the disappointments of Creative Assembler for me was that it didn't include it. So I'm still in the dark really!

[sa_scott]

For reference, here is the assembly language used for point checking:

I believe it was 'jms2' who provided this, I'm at a loss as to how to achieve this.

Not me I'm afraid. I adapted the sprite plotting code from "Creative Assembler" into your original listing, and I think I added a crude machine code version of "POINT", but not the bounding box thing.

I could never figure out a good way to do collision detection myself, and one of the disappointments of Creative Assembler for me was that it didn't include it. So I'm still in the dark really!

Not to worry mate! I'm gonna have a rummage online, and through some other resources, see what I might find on this front

[ChrisB]

Not my code - but it's checking if a point sent to the routine in X,Y is within a list of eight 8x8 boxes. The corners are contained in an array at &AE0-&AAE7 (x co-ordinates) and &AE8-&AEF (y co-ordinates). If you need to extend it you will need to

This is probably used to check if the diver has caught a piece of plastic - with X,Y being his hand. If you're going to do bounding box checks you'll need to check both "sides" of each sprite. However the actual number of calculations will be very small compared to the other stuff you're doing so I'd not expect performance to suffer.

[sa_scott]

Not my code - but it's checking if a point sent to the routine in X,Y is within a list of eight 8x8 boxes. The corners are contained in an array at &AE0-&AAE7 (x co-ordinates) and &AE8-&AEF (y co-ordinates). If you need to extend it you will need to

This is probably used to check if the diver has caught a piece of plastic - with X,Y being his hand. If you're going to do bounding box checks you'll need to check both "sides" of each sprite. However the actual number of calculations will be very small compared to the other stuff you're doing so I'd not expect performance to suffer.

Thanks Chris, your input makes more sense now.

I've attempted to annotate the code, as follows:

Code: Select all

.check
STX &AB0:STY &AB1:LDY #7            - feed X,Y values into &AB0 and &AB1 respectively, load accumulator Y with 8 pixels?
.checkloop
LDA &AE0,Y:CMP &AB0:BCS notinbox    - item x coord, compare with X value, go to notinbox subroutine if no collision
CLC:ADC #8:CMP &AB0:BCC notinbox    - item x coord+8 (item width), compare with X value, go to notinbox subroutine if no collision
LDA &AE8,Y:CMP &AB1:BCC notinbox    - item y coord, compare with Y value, go to notinbox subroutine if no collision
SEC:SBC #8:CMP &AB1:BCC checkfinish - inverted check item y coord+8 (item height), compare with Y value, got to checkfinish subroutine if collision?
.notinbox
DEY:BPL checkloop                   - not in box yet, so we decrease the Y value (must be scanning one row at a time?)
.checkfinish                        - we must be here because we've had a collision, so we store the Y value into &AB2 and return
STY &AB2:RTS

I'll need to properly consult what BCC, BPL are for (BCC means Branch Carry Clear, and BPL means Branch on Positive Result - having checked an advanced user guide), but it looks like we are scanning one line at a time, assuming the item to check is 8x8 (which a collectible item is)?

[fizgog]

Isn’t LDY #7 for the number of bottles / rubbish 8 in total per level ?


PS I thought you were working on a new game?

[ChrisB]

Yes - Y is the number of items.

LDA &AE0,Y - Loads A with the contents of address &AE0+Y - Same structure as A%=Y%?&AE0 in BASIC

BCC is being used here as Branch if less than.
BPL is branch if positive - i.e. the top bit of the byte isn't set. So Y will start at 7, decrease to zero and then wrap back to 255 - or to -1 in two's compliment binary - at which point the top bit is set so the branch doesn't happen and the code falls through to the exit routine. You'll see that Y is saved into location &AB2 to say which piece was hit - or 255 if nothing hit.

[sa_scott]

Isn’t LDY #7 for the number of bottles / rubbish 8 in total per level ?


PS I thought you were working on a new game?

You are probably correct (I see ChrisB has replied as well).

Yeah, I did have a notion to work on something, but this itch needs scratching, would like to get v1.10 finished, so I can confidently say it's the best game it could be. Androidz sat untouched for decades, before I spat and polished it, I don't want PolyPicker to suffer the same fate

[sa_scott]

Yes - Y is the number of items.

LDA &AE0,Y - Loads A with the contents of address &AE0+Y - Same structure as A%=Y%?&AE0 in BASIC

BCC is being used here as Branch if less than.
BPL is branch if positive - i.e. the top bit of the byte isn't set. So Y will start at 7, decrease to zero and then wrap back to 255 - or to -1 in two's compliment binary - at which point the top bit is set so the branch doesn't happen and the code falls through to the exit routine. You'll see that Y is saved into location &AB2 to say which piece was hit - or 255 if nothing hit.

Ah, thanks for highlighting this - I was trying to output the result onto the screen at one point, and saw it was only ever outputting 255, this explains why!

Since the jellyfish is a 16x16 VDU character, rather than a sprite (like the front facing shark), I could in theory duplicate this function, except I have to cater to a character the same height as the diver sprite, but not as wide.

It does lead to a wider point - I'm currently using Basic to detect collision between the shark and the diver, only when the shark is rendering in its forward position. If the jellyfish was made as a sprite, with the same dimensions, could the above procedure be adapted to cater to colliding with either baddie?

[ChrisB]

Being a sprite doesn't really matter - The collision detection is simply a calculation - so yes that routine - or a similar one could do the job. Remember that you're looking for overlapping bounding boxes rather than whether a point is within a box so the calculation is slightly more complex.

[sa_scott]

Being a sprite doesn't really matter - The collision detection is simply a calculation - so yes that routine - or a similar one could do the job. Remember that you're looking for overlapping bounding boxes rather than whether a point is within a box so the calculation is slightly more complex.

Thanks ChrisB

I scoured through some old copies of The Micro User online, and came across Roland Waddilove's machine code games articles, published in 1987. These complemented Kevin Edwards' series from a few years prior.

The article from the March 1987 issue covers collision detection, and I have pasted the listing into bbcmic.ro to see if that works, and matches what I'm looking for.

Update: it does work, but bbcmic.ro doesn't output sound, the code outputs a beep upon successful collision detection.

The routine makes use of box collision, in the same manner as the BASIC code in Polymer Picker performs box detection. However, is the collision code considered best practice for 21st Century programming?

btw, while browsing online, came across this Github page - Easy 6502 - it's a good read, has anyone had a look at it? How does it fare for Beeb assembly learning?

Thanks in advance!

[ChrisB]

I'm not a 21st century programmer so I don't know what current best practice is. However - bounding boxes was "good enough" for night ninja.

The easy 6502 does look like a decent resource - the syntax is slightly different than BBC Basic ($ instead of & for hex) but the info is there. It seems a little bit of a jump from the principals to the snake game.

[sa_scott]

I'm not a 21st century programmer so I don't know what current best practice is. However - bounding boxes was "good enough" for night ninja.

The easy 6502 does look like a decent resource - the syntax is slightly different than BBC Basic ($ instead of & for hex) but the info is there. It seems a little bit of a jump from the principals to the snake game.

Sorry, I meant the technique in terms of 6502, not the principle. There's more than one way to skin a cat!

Ah, you noticed it too. Quite a good learning curve, then came the game, and now the whole page, is very much 'How to draw a horse':

I've lost count of how many tutorials end up doing this. Infuriating really.

[sa_scott]

I've attached a second alpha of v1.10.

I've added a 16x16 size jellyfish sprite to the disc image, which is loaded into the game. However, I've hit a brick wall again, with fitting the sprite data, in tandem with the memory relocation routine. But the sprites are not only corrupted, but I run out of room.

After spending hours on this, I've had to call it a day, so I'm hoping that the attached zip will provide a challenge to others, as to how best I can squeeze in an additional adversary

I'm certain I've done something stupid, but I'm tired now

[sa_scott]

While I still work things out, I've cribbed ChrisB's box collision demo to mock up interactions between the diver and jellyfish.

Due to the different dimensions, box collision is more complex.

I've placed the demo here on bbcmic.ro

I would have to put the same kind of detection within the game. I can't really use the collision detection used by the shark, as it ignores the fact that you are wider than the width of the shark. So I have to take into account the different dimensions.

Would anyone mind taking a look, and performing a sanity check? I'm somewhat perturbed by examples found so far online, all relying on the sprites being the same size, which I wish I could get away with. I may intend to create a level where the jellyfish move up and down, so the collision would need to be fairly solid, but not too unforgiving.

Thanks again in advance!

[ChrisB]

Points to boxes - the next level

I assuming that you are looking for any contact between the two areas.

For two rectangles they will not be touching if:

Code: Select all

The right edge of box A is to the left of the left edge of box B
OR
The left edge of box A is to the right of the right edge of box B 
OR
The bottom edge of box A is above the top edge of box B
OR
The top edge of box A is below the bottom edge of box B

The reason for that logic is that if any of those are true then the boxes are not touching. Which means you can abort the check and move on. If you check the other way round you have to do all 4 checks each time.

As far as I can see your example isn't quite right (I think you're checking the bottom against the bottom) so they only become touching if one box is totally inside another.

[sa_scott]

Thanks for de-dunking my brain, ChrisB

I've updated the code, and it appears to be working now.

Hopefully, these snippets will serve useful to others trying to attempt similar things!

[sa_scott]

I've attached v1.10alpha2 below:

• Jellyfish have been added
• Instructions amended
• Collision detection for jellyfish added
• Some other code refinements, to increase memory

Screenshot of v1.10-alpha2

The memory remaining debugger information is still retained prior to the display of the high score table.

Thanks to fizgog and ChrisB for their kind assistance these last few weeks.

Some outstanding things, or open thoughts:

• Rather than have static jellyfish, can they also move? There could be an extra level, where the jellyfish move up and down, so you have to swim around them (I've just remembered the sequence in Finding Nemo, and Michael Crichton's Sphere, where a lot of jellyfish come and quickly overwhelm the characters).
• The jellyfish placement is very random, and some of the collectibles will inevitably clash with them, so loss of air is guaranteed. This may result in some levels being more unfair.
• Having recently seen 47 Meters Down - Uncaged, I was particularly struck by the sequence where the remaining characters only have an intermittent light, which serves as an excuse to make the audience jump when the sharks suddenly lunge out of the darkness. Having a level 'set in the dark', where you can't see the shark, until some temporary light source flickers on and off, would be interesting.
• Can you get 'heavier' as you collect more items?

I have to admit that point 1 is the most likely scenario I'll be tempted to add in, but with only 900 bytes left to play with, my concern is that any extra variables, or code to deal with this extra menace, may result in the inevitable 'No room' error.

During testing of this attached version, I've not run out of room... yet. That said, if anyone can test this, and see if anything is amiss, would be appreciated!

Thanks in advance.

[sa_scott]

I've made some further amends to the code, and now have the jellyfish moving up and down, after level 4.

The game is an awful lot harder with the moving jellyfish. Once you have the poisonous fish, shark and moving jellyfish onscreen from level 6, it's a bit of a nightmare to be honest

I've adjusted the spare tank mechanic so that the tank no longer shows up only once per level. This means every time your air reaches 50%, a new tank will appear. This will become vital on later levels.

The game obviously struggles for speed when everything is thrown at you from level 6 onwards. Basic is having to perform an awful lot of plate spinning. I was additionally having to work around 'No room' errors, which I've (hopefully) addressed. I honestly don't think there's anything new I can add now, it's more about tinkering a bit further with what is already there.

I've attached v1.10alpha3 below. The PR is also available to view on Github.

Do give it a go - I feel it's closer to what I consider to be a polished (and proper final) game

[sa_scott]

Sorry for the delay, I've now attached v1.10 release candidate 1 below.

Link removed

I've shaved a bit more bytes from the BASIC file, and removed the commented out memory output section, and re-inserted the disabling of the Escape key.

In terms of gameplay:

• the jellyfish move from level 1, but the speed of movement increases every 4 levels or so. That said, one of the jellyfish is picked at random to move at a fast speed.
• I've changed the colours of the fish on later levels, for a bit of added variety.

Unfortunately, I came across a No Room error, so I still need to perform some code shaving. I think the culprit is the workspace needed to calculate the speed of the jellyfish on each level.

I've left the zipfile attached, but have pulled the link for now.



There is of course, the Github PR to browse.

Enjoy!

[sa_scott]

V1.10rc2 attached below.

Play online in your browser.

So far, I've not been able to repeat the No Room error, but I have performed some further code crunching, merging single use procedures into one, and moving some other bits of code around.

You can view the latest commits in the Github PR.

I'm not certain, but I feel the game is a little bit (and I do mean a little bit) zippier with these amends. But I'm biased, naturally.

I've played it a fair number of times today, and it's definitely more challenging now. I've even reduced the highest score

Fingers crossed very tightly that this is the final release candidate. Do shout if you get the dreaded No Room error - the code is a bit smaller now, so I would be very surprised if it did occur (he says).

[sa_scott]

In the absence of feedback, and my own extra play tests, I think we're done

I've now merged the PR.

• Website updated - https://www.sassquad.net/polymerpicker
• Download link - https://bbc.godbolt.org/?disc=https://w ... d&autoboot
• Github repo - https://github.com/sassquad/polymer-picker-6502
• Playthrough video - https://youtu.be/hrgzWWyr84Y

I've not yet updated my Itch.io site, but will in due course.
If anyone can add the new version to the archive, would be much appreciated!