Polymer Picker (formal release)

[fizgog]

Very nice, feels a lot smoother to play with hexwab's sprite improvements.

1.5K free you say - does that mean you could bring back the air bubbles from the tank (I thought that was cool) or maybe animate the divers legs?

Also It was mentioned earlier about the money aspect, you could just remove the dollar sign then it would be just a points based system.

Also not sure if it's a cheat code or not, but I find it's best to leave one piece of trash at the top, collect everything else, then go back get extra air tank then get last trash - giving you more money / points.

Or maybe have the shark animate switching from left to right, right to left (should slow him down a bit)

Crude attempt at drawing and is not to scale for the game

Screenshot 2022-12-01 at 16.07.08.png (4.13 KiB) Viewed 3828 times

Regards
Shaun

[sa_scott]

Very nice, feels a lot smoother to play with hexwab's sprite improvements.

1.5K free you say - does that mean you could bring back the air bubbles from the tank (I thought that was cool) or maybe animate the divers legs?

Also It was mentioned earlier about the money aspect, you could just remove the dollar sign then it would be just a points based system.

Also not sure if it's a cheat code or not, but I find it's best to leave one piece of trash at the top, collect everything else, then go back get extra air tank then get last trash - giving you more money / points.

Or maybe have the shark animate switching from left to right, right to left (should slow him down a bit)

Crude attempt at drawing and is not to scale for the game


Screenshot 2022-12-01 at 16.07.08.png

Regards
Shaun

Thanks for the extra graphic. The shark at the moment does look a bit silly when he moves up and down, but facing left or right - would be worth trying to incorporate the graphic somehow

As to animating the divers legs, I think I would have to use 2 of the flashing colours, but aren't certain how many I have left now. It's going to be a headscratcher if I'm honest, clearly the simple approach of having 2 more diver sprites with moved legs is a waste of memory. Ergo the bubbles - I may need to employ some palette switching to get that to work.

AS to the 'cheat' - yeah, it sounds like a way to cheat. I may just have to make the items a bit 'heavier' i.e. closer to the bottom, without them being bunched together. I did consider whether each item should appear 1 or 2 at a time, but then again, not being able to plan ahead, may be considered unfair to the player (Gordon Key's McBrolly game had the mechanic, like Boffin, of showing the collectibles in a sequence, but one that was not random). Tom did mention that the rubbish being hidden in the greenery is a little 'off' which I may be keen to address, when I get a suitable block of time to unpick my compressed code.

I'll have a think about the dollar sign, but I may wait a bit for Tom to see if he has made any headway with other aspects of the game.

Stephen

[sa_scott]

Here's my proposed shark - he ain't half got some front

[sa_scott]

Ok, my attempts to add a front facing shark had hit a wall.

I've got a corrupted diver sprite, and crazy stuff happening when the shark animation tried to render the appropriate sprite

Broken diver left sprite

Raster mania!

The SPRITES file is now &480 length, due to the 16x16 shark front sprite (which is set to 8,16 in the sprite workspace data), so I've adjusted the load address and HIMEM from &2C00 to &2B80 to accommodate this.

I must assume some workspace is creeping into the left diver sprite, but I discovered the raster mania craziness, was because I didn't adjust the loop when reading the sprite width and height (there are now 9 sprites, not . I also added an extra byte to the 4 workspaces used for sprite addressing and size.

Here's the end result:

The shark now faces the front!

I've attached the work in progress below. I can't figure out at this point, why the left diver sprite has gotten corrupted. I am guessing that - as the left sprite is the first item in the sprites data file, and it's being loaded in at 2B80, it is getting corrupted by some other process. I've retained Tom's test output which shows the amount of bytes left to play with.

I'm therefore a bit stuck. Can anyone figure out what is going on? I've got to head off to work now, which is probably interfering with my thought process!

[sa_scott]

I spent some more time trying to sort out the corruption issue today but it's clear I don't know what I'm doing with the changes that Tom has made to manage memory.

I know that the sprites have to load in at &2B80 so as not to overwrite screen memory at &3000 with the additional shark sprite.

But that's all I know! Attempts to fix it either result in further display corruption or a complete crash, and I've had to accept defeat

[sa_scott]

I spent some more time trying to sort out the corruption issue today but it's clear I don't know what I'm doing with the changes that Tom has made to manage memory.

I know that the sprites have to load in at &2B80 so as not to overwrite screen memory at &3000 with the additional shark sprite.

But that's all I know! Attempts to fix it either result in further display corruption or a complete crash, and I've had to accept defeat

YAASSS!

Thanks to fizzgog for getting in touch. The assembler relocation required some tweaking:

Code: Select all

P%=&50:[OPT2:ldx#0:ldy#&1C:lda&4C00,X:sta&2A00,X:inx:bne&54:dec&56:dec&59:dey:bpl&54:rts:]

4D00 was changed to 4C00, while 2B00 was changed to 2A00. Another minor change was the ldy#&1D, changed to #&1C.

I have to rush to work, so I'll add some more detail later, but yes - quite a relief!

[sa_scott]

A further update, this is an alpha of version 0.993

• I've removed the dollar sign from the score
• I've re-introduced slightly more readable procedure and function names, purely for my sanity, while I decode this.
• The rubbish no longer displays behind the sea grass (one of hexwab's suggestions)
• The air supply reduces a bit more now, if the shark or sea life hurts you, this should decrease your air even more than before (another of hexwab's suggestions, getting bitten by a shark was nowhere near as perilous as it should be)
• the shark going up sprite has been introduced

It's this latter item that is stumping me, more specifically, how the sprite frames interact with you whether you are moving normally, or if you are injured when the shark moves more quickly.

The shark sprite still jumps between a directional sprite and the facing up sprite as you move when it is upon you.

The effect is lessened when the shark speed is throttled. I've therefore attached 2 versions, one with the slow shark, one with the fast shark.

I'm just using a counter that cycles between 0 and 1, the shark only moves when the counter is on 1. If I increase the counter, the shark moves more slowly. It's a cack handed approach, but I can't really use TIME based movement, as I'm worried it will confuse the air supply consumption.

I am still not getting anywhere with the shark/player collision detection. I need another pair of eyes looking at this.

• the diver sprite is 12 'sprite pixels' wide, while the shark is 16 'sprite pixels wide' - so, the bounding box is hard (for me) to still figure out. Hexwab suggested only the mouth area should detect if it is inside your diver's bounding box.
• if I don't throttle the speed, the shark moves at the same speed as you (when not swimming fast). So the shark continues to point ahead, when you move left or right and it's directly below you (as it should)
• if I throttle the speed, obviously this doesn't happen, unless you stop moving.
• During any shark attack however, any diver movement sends the shark sprites in different directions, depending on whether you are swimming slowly or quickly.

In other words, I think I'm overcomplicating this!

So, can another pair of eyes figure out what I'm doing wrong?

Here are the relevant bits of code:

Code: Select all

DEFPROCms:REMIFST%<>1ST%=(ST%+1)AND1:ENDPROC - this is the throttle code, remarked here
OS%=SX%:OY%=SY%:OA%=SD%:IFSX%<D%ANDSX%<62:SX%=SX%+V%:SD%=5:IFFNb(SX%+12,SY%)PROChurt // shark points to right, then check if colliding with diver
IFSX%>D%ANDSX%>1:SX%=SX%-V%:SD%=4:IFFNb(SX%,SY%)PROChurt // shark points to left, then check if colliding with diver
IFSX%=D%SD%=8:IFFNb(SX%,SY%)PROChurt // shark pointing 'up', then check if colliding with diver.
IFSY%<e%ANDSY%<194SY%=SY%+V% // check for screen boundary.
IFSY%>e%ANDSY%>64SY%=SY%-V%
PROCd(OA%,OS%,OY%):PROCd(SD%,SX%,SY%):ENDPROC // render old position, then render in new position, with relevant sprite number (SD%)
REMST%=(ST%+1)MOD2:ENDPROC this is the throttle code, remarked here.

...

DEFFNb(i%,j%):IFi%<D%ORi%>(D%+12)ORj%<(e%-12)ORj%>e%:=FALSE:ELSE=TRUE // check bounding box of diver with arguments from shark position.

I appreciate any assistance received. Time isn't on my side again, juggling work and family (aren't we all?).

[sa_scott]

I've pushed a branch to my Github account:

https://github.com/sassquad/polymer-pic ... ree/v0.993

Zipfile is below of the current changes.

This has a possible solution to the shark collision detection, and features the up and down shark sprite. It's not perfect - the shark and you move at the same speed when you are hurt, which causes problems (the 'slow' shark approach in my last message may need to be implemented to attempt some throttling) - the shark does it's merry dance left or right still, and does some horrid 'jank' in speed.

I've edited this post, as I was earlier in a rotten place, uncertain when I was going to get a chance to fix more of the game. The next few days will be very testing, but... we'll see.

Here is what you'll find in the latest revisions:

• Diver and shark animation are now flicker free
• Removal of dollar sign from score
• More refined shark collision. The mouth area is the bounding box now for left/right, while the whole sprite of the 'up' frame is the bounding box.
• I'll have to throttle the initial speed of the shark, as it moves the same speed as you, which is more annoying than it should be. Also, poor Basic trying to plot blood spots repeatedly when being attacked, causes hideous jank. Perhaps a colour change of the diver is required?
• If you browse the commits of the branch, you'll notice I did redefine the numerical characters. However, this broke the user defined characters, so I've not fully understood how *FX20, or ?&36D=B works exactly. You can see the changed numbers here

It's getting there...

[sa_scott]

I've attached what I hope to be release candidate 8.

The Github PR is here and I've attached a zipfile below.

Play the latest version online

• removal of flicker from diver and shark sprites animation
• refined high score table layout
• removal of dollar sign
• Added VDU graphic for bleeding
• Added shark speed throttle, unless you are injured.
• Added game over tune
• Adjusted bonus tones
• Further code shrinking
• removal of onscreen memory information.

The shark animation still isn't perfect, when you are injured, and the shark follows you, it still switches between the left shark frame and the 'up' frame. Clearly something amiss with the following code, which determines which shark sprite frame to display:

Code: Select all

DEFPROCE:IFV%=1IFST%<>1ST%=(ST%+1)AND1:ENDPROC // throttle shark speed if V% is 1 (when injured, value becomes 2)
OS%=SX%:OY%=SY%:OA%=SD%:IFSX%<D%ANDSX%<62SX%=SX%+V%:SD%=5:IFFNsbr(SX%+12)PROCu  // move shark right, display right sprite, check for diver collision
IFSX%>D%ANDSX%>1SX%=SX%-V%:SD%=4:IFFNsb(SX%+4)PROCu // move shark left, display left sprite, check for diver collision
IFSX%=D%SD%=8:IFFNsb(SX%+8)PROCu // display up sprite if x position is equal to diver's x position, check for diver collision
IFSY%<e%ANDSY%<194SY%=SY%+V% // move shark up
IFSY%>e%ANDSY%>64SY%=SY%-V% // move shark down
IFOS%<>SX%OROY%<>SY%OROA%<>SD%PROCd(OA%,OS%,OY%):PROCd(SD%,SX%,SY%) // delete old position of shark sprite, and reprint in new location.
IFV%=1ST%=(ST%+1)MOD2:ENDPROC // throttle shark speed, change counter

Other than that, I've improved some of the sounds, and added a game over tune (well, it did come from Ian Waugh's Making Music book, which helped me find the appropriate values for the bonus tones, as they were a bit 'off'

I'm very nearly happy with the end product, but the shark 'dance' is the only bug I'm aware of. I hope that the 'No room' error doesn't strike again on repeated plays.

Feedback welcome!

[sa_scott]

I've spent some more time trying to refine the shark movement. Here are the problems I've tried to solve.

• Left and right shark sprites are 32 x 16 pixels, while the shark 'up' sprite is 16 x 16.
• The diver sprite is 24 x 16 pixels.
• Therefore, collision bounding boxes, and which shark sprite to display based on positions, gets thrown into chaos. Considering that all sprites are rendered from the top left corner, this is playing havoc with my mind.
• When the shark 'right' sprite changes to the 'up' sprite, the x coordinate has to be increased by half the shark's width to position the up sprite correctly. The left sprite is ok, as we can just switch to the up sprite without having to subtract half the shark width.
• Bounding box collisions need to take into account these different sizes of sprite.

I've made some further changes, so v0.994's commit can be browsed here.

At the moment, none of the collision is working, because all the above points have combined/conspired/stabbed me in the back.

I was hoping to fix this, and be done with the game, as it's the last major item to resolve. I really want this out of my life before Christmas, as I'm going to be away from my computer for varying amounts of time, and I'll forget everything come New Year.

I'll try and plug away this afternoon and evening, but it's my last working day, so it's going to be very difficult to continue after today.

Otherwise... HELP?!

[fizgog]

If you haven't already taken it into account you should only have a bounding box around the sharks mouth as well - maybe an 8x8 box (not sure what the mouth size is)

As the shark should only be able to attack with it's mouth and not the whole of it's body

[sa_scott]

If you haven't already taken it into account you should only have a bounding box around the sharks mouth as well - maybe an 8x8 box (not sure what the mouth size is)

As the shark should only be able to attack with it's mouth and not the whole of it's body

Believe it or not, that's what I was trying to do. If you play the current version, the biting pretty much happens as intended. These amends are to try and resolve the disparities in how the shark transitions from left to 'up' to right, and back again, and taking care of the collision.

The FNs function sets the bounding box to be from the sharks left position, to 8 pixels in (or 4 pixels, according to the sprite routine), but is used for the shark's up sprite as well (both sprites would have the mouth within that bounding box)

However, the FNb function is used solely for the right facing shark, as the mouth is way over the right, so it tried to take this into account (shark left position + 12 sprite pixels, then the shark's far right edge (sprite position + 16 sprite pixels)

I suspect because the up sprite is pretty much used when you're near the shark, some of this code is redundant, or just not getting picked up?

Both functions check the 'bite' bounding box to see if it is within the diver's overall bounding box. The difference is in the initial calculation needed based on whether it is a right facing shark or not.

[fizgog]

Not looked at your code, but did some notes in my dinner hour, the way I would do it
NB this is not tested or optimised in anyway and may contain bugs
Also I've made some presumptions such as size of shark mouth

Also not BBC Basic but 6502

Code: Select all

    ; Save shark x and y
    LDA shark_x1 : PHA
    LDA shark_y1 : PHA
    
    ; Calculate shark_x1 and shark_y1 from shark direction
    LDA shark_direction                             ; I'm assuming  -1 left 0 up and 1 right and haven't checked your code
    BMI skip_offset                                 ; branch if minus
    BEQ going_up                                    ; branch if 0
    LDA player_x1 : CLC : ADC #20 : STA player_x1   ; Add 20 (requires 24 shark width is 36 so -8 is 24)
.going_up
    LDA player_x1 : CLC : ADC #4 : STA player_x1    ; Add 4 or 24 (shark width is 16 so mouth is 4 - 12)
.skip_offset
 
   
    ; Check bounding box
    LDA shark_y1
    CLC : ADC #4        ; only required if checking 8 pixels in y direction and not 16
    CMP player_y2
    BCS not_attacked    ; shark_y1 > player_y2
   
    CLC : ADC #8        ; use 16 if checking against full height of shark
    CMP player_y1
    BCC not_attacked    ; shark_y2 < player_y1
 
    LDA shark_x
    CMP player_x2
    BCS not_attacked    ; shark x > player_x2
   
    CLC : ADC #4        ; 2 pixels per xpos (so not #8)
    CMP player_x1
    BCC not_attacked    ; shark x2 < player_x1
 
    ; Attack code here
   
.not_attacked
    ; Restore shark x and y
    PLA : STA shark_y1
    PLA : STA shark_x1
    RTS
 

[sa_scott]

Not looked at your code, but did some notes in my dinner hour, the way I would do it
NB this is not tested or optimised in anyway and may contain bugs
Also I've made some presumptions such as size of shark mouth

Also not BBC Basic but 6502

Many thanks for sharing!

I was hammering away this afternoon, and I think I've cracked it. Check out the changes here.

I've attached this latest set of changes below.

The shark movement and collision procedure now consists of the following:

Code: Select all

DEFPROCE:N%=SX%:j%=SY%:OA%=SD%:IFSY%<e%ANDSY%<194SY%=SY%+V%
IFSY%>e%ANDSY%>64SY%=SY%-V%
_%=4:IFSD%=5_%=8:IFSD%=8:_%=0
IF(SX%+_%)>(D%+6)SX%=SX%-V%:ELSEIF(SX%+_%)<(D%+6)SX%=SX%+V%
IFSX%>(D%+8)SD%=4
IFSX%<(D%-8)SD%=5:IFOA%=8SX%=SX%-8
IFSX%>(D%-8)ANDSX%<(D%+8)SD%=8:IFOA%=5SX%=SX%+8
IFSD%=8ANDFNs(SX%)PROCu
IFN%<>SX%ORj%<>SY%OROA%<>SD%PROCd(OA%,N%,j%):PROCd(SD%,SX%,SY%)
ENDPROC
...
DEFFNs(a%):IF(D%-(a%+2))>0OR(D%-(a%+2))<13:IF(SY%+2)>=e%AND(SY%+2)<=(e%+16):=TRUE:ELSE:=FALSE

FNs is the bounding box of the 'up' shark being compared to within the bounding box of the diver, but more or less around the inner center, nearer the mouth.

Would be good if anyone can playtest this. The only thing I've noticed is that the fish no longer change colour, line 1 has the READo%,p% for reading of colours, but not sure where those values are coming from. Could be a leftover of hexwab's earlier changes.

Fingers crossed (and 'No room' errors banished) I've cracked it

[fizgog]

Sorry to disappoint but the hit test doesn't seem to be working correctly

Quick test shows that the shark is not attacking the player when the sprite is either facing left or right, but only when its facing towards the screen

Also notice the number 3 top right of the ocean and a comma under the boat (unless this is some sort of fishing line?)

Image showing player not attacked

[sa_scott]

Sorry to disappoint but the hit test doesn't seem to be working correctly

Quick test shows that the shark is not attacking the player when the sprite is either facing left or right, but only when its facing towards the screen

Also notice the number 3 top right of the ocean and a comma under the boat (unless this is some sort of fishing line?)

Image showing player not attacked

Screenshot 2022-12-21 at 21.42.08.png

I may have left in some code to print out the values of p% and o%, to determine where the colour data for the fish comes from. It's a leftover, I was in a hurry as I was being called downstairs

As to the method of shark collision, I've effectively restricted the shark collision detection to only when the front facing sprite is displayed. I've had to go for simplicity - I just couldn't cope with the switching of bounding box collisions, especially for the right facing sprite, and when to switch to the differently sized shark front sprite. It was just too much. I've imagined that the shark turns to face up a little bit to the left and right of the diver's position. This maeans I only have to worry about the diver / front shark bounding box collision.

It's a bit of a cheat, and I suppose I could amend it slightly to include the hit box for the mouth of either left/right sprite. My only concern is the increased risk of running out of room, having to do repeated checks like this. And would the game speed take a hit?

I'll put up a revised version without the test data - I still don't know where those numbers are coming from

[sa_scott]

Sorry to disappoint but the hit test doesn't seem to be working correctly

Quick test shows that the shark is not attacking the player when the sprite is either facing left or right, but only when its facing towards the screen

Also notice the number 3 top right of the ocean and a comma under the boat (unless this is some sort of fishing line?)

Image showing player not attacked

Screenshot 2022-12-21 at 21.42.08.png

I've attached a revised version - this now has had the numbers removed, and have also managed to get the shark collision to work with the left and right sprites

I've pushed the latest changes to Github

[sa_scott]

With the resolution of the shark sprite movement and collision routines, I've taken the decision to bump up Polymer Picker to a formal release of v1

My plan was to get something out before the end of the year. Extenuating circumstances allowed me a few days to focus on resolving the sprite collision routine, and fizgog gave some much needed insight into the issues I was having.

I'm at the limit of what else I can do in terms of time to tidy up other aspects of the game, and I think I've tinkered enough over the last 15 months or so. I'm a lot happier with the game now, and feel it is the right time to consider it a formal release.

If I do perform any further amends, it most likely won't be until the new year. Given how squashed the code is, I'm likely to forget a lot of what I've done here.

Who do I shout out to in order to get this released onto the BBC Micro Games Archive?

Other than that, Merry Christmas!

[leenew]

Who do I shout out to in order to get this released onto the BBC Micro Games Archive?

Other than that, Merry Christmas!

No need to shout
Merry Christmas to you too http://www.bbcmicro.co.uk/index.php?rt_ ... =on&sort=u

Lee.

[sa_scott]

Who do I shout out to in order to get this released onto the BBC Micro Games Archive?

Other than that, Merry Christmas!

No need to shout
Merry Christmas to you too http://www.bbcmicro.co.uk/index.php?rt_ ... =on&sort=u

Lee.

All I wanted for Christmas was THIS!

Many thanks Lee

[sa_scott]

Sorry to resurrect an old thread!

I (belatedly) wrote a blogpost about why I wrote the game, and why 8-bit programming matters to me

https://sascott.blogspot.com/2023/05/po ... 8-bit.html

Worth a read if anyone's interested?

[sa_scott]

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

Just waking up an old thread to thank you for your (at the time) comment. I must have missed it. I've been looking through your Lovebug source code on Github, just for inspiration. But thanks again (belatedly!)

[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

Just waking up an old thread to thank you for your (at the time) comment. I must have missed it. I've been looking through your Lovebug source code on Github, just for inspiration. But thanks again (belatedly!)

actually my lady bug code is pretty standard stuff and there's nothing really interesting to see, no fancy software/hardware tricks or anything like that

[lovebug]

BTW great game, very well done and I love the concept

[sa_scott]

Just a quick note - I've formally released v1.10 now, and have updated the repo and download links accordingly.