Polymer Picker (formal release)

[sa_scott]

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.

Thank you both. Funnily enough, I did tinker with TIME a bit later on, but I was still getting the same result. I looked at a couple of games from the archive for ideas on implementation - Professor McBrolly, and BlocBusta. They both utilise TIME, the former achives a consistent countdown, while BlocBusta has an air supply, which appears to decrement in a consistent fashion, but it does use a tick counter, rather than explicitly refer to TIME.

I've had to leave the code for a while, as I have a lot going on the rest of this month, which is annoying for me personally. I'll just have to grit my teeth!

[sa_scott]

Some further amends/enhancements for v0.03:

• The air supply now counts down in a more timely fashion. It flashes when it gets too low. I've not yet devised a mechanism to replenish the air supply.
• I've added some temporary characters to represent your boat. This may form the basis of replenishing your air supply.
• The bottom of the screen is used less for the sand now, and more for a simple clean status area. The air supply is drawn at the bottom now, leaving the top of the screen clear.

Glad I managed to crack the air supply issue though.

[jms2]

Just to let you know where I'm up to as well...

I have designed some sprites for it (identical to yours, but with colour) using the Creative Assembler tool, and have modified POLY1 to assemble the sprite plotting code and load the sprite data. My previous changes to POLY2 (moving all the variables into bytes) are now unnecessary, but what I need to do is change the co-ordinates for sprite plotting to 160 horizontally x 256 vertically.

Currently my plan is to plot the man and the fish using machine code, and also use the routine to do collision detection as well (rather than use POINT). Everything else will remain as-is.

I'll keep going with my v0.02 version in parallel to your changes because at the moment there remains the possibility that it won't work!

[sa_scott]

Just to let you know where I'm up to as well...

I have designed some sprites for it (identical to yours, but with colour) using the Creative Assembler tool, and have modified POLY1 to assemble the sprite plotting code and load the sprite data. My previous changes to POLY2 (moving all the variables into bytes) are now unnecessary, but what I need to do is change the co-ordinates for sprite plotting to 160 horizontally x 256 vertically.

Currently my plan is to plot the man and the fish using machine code, and also use the routine to do collision detection as well (rather than use POINT). Everything else will remain as-is.

I'll keep going with my v0.02 version in parallel to your changes because at the moment there remains the possibility that it won't work!

Many thanks for your efforts on this jms2. Really appreciate the fact you're using free time labouring on this.

I do have a plan to introduce predators of some kind into the mix (giant squid, sharks, barracudas) - since there is a risk of the screen getting too busy, perhaps the predator should roam the sea in a similar manner to the big goose from Chuckie Egg?

For now, one idea is that you have to reach your ship to get a refill of oxygen. I could introduce strong currents to restrict how quickly you can swim, either on a level only basis, or some kind of random factor. This could be changed by amending the values by which the diver moves accordingly, while being aware that this may affect the collision detection routine.

As usual, I have lots of ideas, and either not the time, or the programming clout to fulfil them!

[richardtoohey]

As usual, I have lots of ideas, and either not the time, or the programming clout to fulfil them!

You're doing a lot better than me

Trying to get back into the swing of things and writing a game is definitely on the bucket list. But I just get too ambitious and want to do something fantastic straight away but I need to crawl first!

[jms2]

Getting there... doesn't actually work yet though...

[sa_scott]

Getting there... doesn't actually work yet though...
Screenshot 2021-11-25 225542.jpg

'Tis a thing of beauty!

I'm running out of VDU characters as I've defined sea grasses, crabs and shrimps, gonna have to expand into pre-224 range, which I think is problematic on non Beebs. I might be wrong though.

[sa_scott]

As usual, I have lots of ideas, and either not the time, or the programming clout to fulfil them!

You're doing a lot better than me

Trying to get back into the swing of things and writing a game is definitely on the bucket list. But I just get too ambitious and want to do something fantastic straight away but I need to crawl first!

Believe me, I'm making this up as I go along. And when I can't do that, I scour scanned magazine listings, or the BBC games archive, and browse the listings there, and reuse and recycle!

[jms2]

OK, I have got a version with sprites working! As I said before, it's based on version 0.02.

POLY1 is the loader. This also assembles the code and loads the sprites.
SPRITE is the sprite designer, from Creative Assembler. DEMO is the game from the same book.
The sprites are saved with the names LDIVER, RDIVER, LFISH and RFISH.

The sprites get loaded into memory between &2C00 and the bottom of the screen at &3000 (there is some free space). HIMEM is moved down to suit.

The code is assembled at &900. The usable space extends up to &BFF I think, but it doesn't use anything like that much so far.

The diver and fish are plotted using a co-ordinate system with an origin in the bottom left corner (as per graphics as usual) but X goes from 0-79 and Y from 0-255. Accordingly, comparisons with the bag positions require an adjustment to be made (which is in the 'check' procedures).

Collision detection is done by a machine code routine rather than point. It looks at a pair of pixels rather than just one, and is looking for them both to be red. This is represented by a value of 3.

One thing I cannot figure out is why the bags always appear in the same pattern every time (on every level)... whereas if you run PROCbags from the command prompt, you get a random distribution.

I hope this is helpful and that you can integrate it with your latest developments!

PP with sprites.zip

(7.61 KiB) Downloaded 54 times

[sa_scott]

OK, I have got a version with sprites working! As I said before, it's based on version 0.02.

POLY1 is the loader. This also assembles the code and loads the sprites.
SPRITE is the sprite designer, from Creative Assembler. DEMO is the game from the same book.
The sprites are saved with the names LDIVER, RDIVER, LFISH and RFISH.

The sprites get loaded into memory between &2C00 and the bottom of the screen at &3000 (there is some free space). HIMEM is moved down to suit.

The code is assembled at &900. The usable space extends up to &BFF I think, but it doesn't use anything like that much so far.

The diver and fish are plotted using a co-ordinate system with an origin in the bottom left corner (as per graphics as usual) but X goes from 0-79 and Y from 0-255. Accordingly, comparisons with the bag positions require an adjustment to be made (which is in the 'check' procedures).

Collision detection is done by a machine code routine rather than point. It looks at a pair of pixels rather than just one, and is looking for them both to be red. This is represented by a value of 3.

Amazing!

One thing I cannot figure out is why the bags always appear in the same pattern every time (on every level)... whereas if you run PROCbags from the command prompt, you get a random distribution.

I hope this is helpful and that you can integrate it with your latest developments!

I've just noticed this in my version of the game. Even with the Q%=RND(-TIME) present, supposedly to kick the seed generator, it doesn't seem to be working. This happened in an earlier version of Androidz - I kept getting the same positioning every time, but adding the seeder changed it. Wondering why it's no longer random?

Other than that, I can't thank you enough for your efforts so far. I'll definitely have a rummage and see how I get on!

[jms2]

Glad you like it! For the avoidance of confusion, I'll stop messing about it with it now and let you digest the changes. But if you have any questions, please ask.

Here are some further observations:

- I wanted to be able to plot the sprites against a background colour of 0 (so the colours don't get messed up). Accordingly I redefined the sea to be colour 128 and used VDU19 to make it blue. The black edge to the mountains is now colour 8, redefined to black.
- I haven't made the bags into sprites. I don't think this is worth doing, as its better to have them as solid red anyway.
- The collision detection could be improved. At the moment, all it does is call the routine which converts X,Y coordinates into an address. Then it looks in that address to find the value for two red pixels (3). Ideally you'd probably develop a bit of machine code to be called via USR which returns TRUE if either of the pixels is red. I can probably knock this together quite easily.
- The diver and fish are not animated. I think animating the diver would be quite nice, and this could be done by defining new sprites shifted one pixel across and with the legs swapped round. Actually making the animation work would be tricky though - X movement would require swapping between (1) keeping the X coordinate the same and plotting the alternative sprite, and (2) Incrementing X and reverting to the original. Whereas Y movement would simply increment and decrement as usual, keeping with whatever sprite is currently displayed. The diver would only kick his legs when swimming in the X direction.
- Your idea of implementing 0xcode's bubbles effect would be very nice. But you'd have to find space for the code, and critically make sure you have some spare zero page addresses for it. I haven't looked at how possible this would be. Obviously it could be cut down a bit because you'd only need bubbles to rise from the diver, not all over the screen.

[lurkio]

I've just noticed this in my version of the game. Even with the Q%=RND(-TIME) present, supposedly to kick the seed generator, it doesn't seem to be working.

I think it's because the value of TIME will always be the same -- because bbcmic.ro will always allow the same amount of "Beeb time" to elapse before the game starts running because the bbcmic.ro emulator is deterministic. You need to introduce an "external" random time-delay.

Try this:

Code: Select all

IFGET Q%=RND(-TIME)

https://bbcmic.ro/#%7B%22v%22%3A1%2C%22 ... %5Cn%22%7D

[jms2]

I came to the same conclusion, so I moved the seeding statement to after the “press space to load game” stage in the loader. But it didn’t help - maybe I messed it up in some way.

[lurkio]

I came to the same conclusion, so I moved the seeding statement to after the “press space to load game” stage in the loader. But it didn’t help - maybe I messed it up in some way.

I suspect it's because the RNG is being reseeded with the value -3 on line 197:

Code: Select all

197MOVE0,0:L=LE%/PI:OX%=-32:OY%=0:A%=RND(-3)

[jms2]

Well spotted! That must be it. It never occurred to me to go looking for a further re-seeding. Stephen, was this intentional? I can see how it might have been (makes the levels predictable).

[sa_scott]

Well spotted! That must be it. It never occurred to me to go looking for a further re-seeding. Stephen, was this intentional? I can see how it might have been (makes the levels predictable).

Sorry for the delayed response, all. Yes, the A%=RND(-3), indeed the whole PROCmt procedure, was drawn from the game Wishing Wells (http://www.bbcmicro.co.uk/explore.php?id=828) - check out line 1640. This bit of code has no purpose.

In any case, removing it has resolved the issue. The items now display in a proper random manner. Even the mountains now render in a more random manner, so that wrinkle really was affecting the whole of the game!

Here's a work in progress screenshot.

I've been working slowly on the Basic version, and have incorporated the temporary boat graphic (which is where you can refuel your air - eventually), along with some sea grass. I was somewhat stumped by the non-random issue though. It did occur to me that the TIME amount would end up being the same each time I reset the emulator, and rebooted the game.

I had a chat with my 11yo daughter about the game. She suggested adding sharp coral - if you get injured, that can reduce your air supply, and perhaps introduce a shark to the proceedings! Add a bit of peril to the game while trying to refuel your tank!

I might not be able to work on this game for a little while, due to other commitments, but I'm not short of material to dive into now. The machine code is definitely better in terms of movement and speed!

I'm so grateful for all the time you've all spent looking into these problems. It's definitely spurring me on to get this over the line before Christmas

[sa_scott]

It's been a while since I gave an update. I've focussed more on the Basic version, which is the version I've attached here.

I've added a few more enhancements to the gameplay element:

• I've modified the control keys to Z,X,' and /, with the Return/Enter key allowing you to swim faster.
• Swimming faster consume more of your air supply, so use it wisely.
• I've added a 'shark' to the game, which homes in on your position, slowly to begin with.
• If you touch the pink coral, this will injure you. The shark will pick up your bleeding, and home in you faster.
• I'm hoping to add or change the fish to include more 'spiky' fish, such as pufferfish, so you can also get injured like with the coral.
• The 'boat' remains static, and without purpose. I'm hoping to add some kind of 'zone' underneath it, so you can get replenished air supply, and get first aid, so the shark stops tracking you quicker. Getting these mechanics to work cohesively, without consuming memory or speed, is going to be tricky.
• I've fleshed out the instructions a bit more.

The game mechanics are slowly coming into play. I'm contemplating whether it is feasible to have 'caves' where hard to reach junk must be collected. But this would play havoc with collision detection I fear, certainly with the Basic version.

One thing the game needs is sound! I'm wondering how to get the sound of 'bubbles' into the game. The only sound I can think of is the completion sound at the end of each level of BlocBusta (http://bbcmicro.co.uk//game.php?id=1297) - but I'm wretched at envelope creation - the theory is just too dense for me!

Hope you appreciate this update. Hoping to return to the assembly language version from next week, depending on how the day job goes this week.

[sa_scott]

Another long time since an update. It's been... difficult. I've kind of lost my way. I have added shark graphics now (I'm actually quite pleased with the graphic, but it took ages to mark down on graph paper and perform the calculations!), and the shark graphics switch around to follow you. I've not been able to take a look at the assembly language version. It is clear that adding the shark really slows things down.

This particular update is rather broken. The graphics get corrupted when the direction changes. As to what happens when the shark reaches you... well, all hell breaks loose! I've also noticed that pressing Enter reduces the energy supply even if you don't move.

It's likely I won't get a release before Christmas; I'm really hoping that I'll get some time in the next few weeks, as my workload is going to shoot up in the New Year. Wish me luck!

[sa_scott]

Version 0.06 attached addresses a few more issues/fixes:

• The shark now moves and changes direction properly now. However, no collision detection as yet. Not sure how I'm going to do that, to be honest. I'm sure it's going to slow the game down either way.
• The shark appears on its own every two levels. The game slows down far too much when used with the fish. The screen ends up being too busy anyway.
• Pressing Return/Enter would deplete your air, even if you were not moving! This has been addressed.
• Since I've blown out the user defined character sets (using ?&36D=&B, which I 'found' in Matthew Eastmond's games, such as Danger Dog), I've been able to move more of the character definitions into Poly1.bas, along with some sample envelopes. This reduces the size of the game code a little.

Since I can't have too much happening on screen (at least in the Basic version), I'll have to be a bit more creative in how the levels work. Some further mechanics are required. I do like the shark, and may end up switching to the assembly language version in order to retain it.

On the face of it, today has been a better day than the previous version; I think I was in a wretched place mentally. Too much going on in life!

As always, any comments, kudos or brickbats are welcome, if it helps to kick me up the backside. Safe to say, it's not a pre-Christmas release now. I'd rather take my time, and get it right, than rush things

[sa_scott]

Happy New Year everyone!

Just a minor update - I created a Github repo for the game before Christmas, but never had the time to push v0.06 to it, due to integration issues. Well... partly that, also my pre-Christmas brain was completely addled, and needed a long time away from the computer.

Anyway, I've pushed v0.06 to Github now, so I can start tracking changes to the game as I slowly get my head into retrospace.

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

Clearly, more updates to come.

[colinhoad]

Am liking the updates, especially the RETURN function to swim faster but at the sacrifice of your air. I played it through quite a few levels, I think about 5 (?) and eventually got to a shark level in which I collected all the red bottles but then the level didn't end and I just swam around until my air ran out... at which point the game said "NICE!" Is this an issue you've seen before?

[sa_scott]

Am liking the updates, especially the RETURN function to swim faster but at the sacrifice of your air. I played it through quite a few levels, I think about 5 (?) and eventually got to a shark level in which I collected all the red bottles but then the level didn't end and I just swam around until my air ran out... at which point the game said "NICE!" Is this an issue you've seen before?

Yeah, the game mechanics are still a work in progress! I'm somewhat put off by the lack of speed in the BASIC version, so I (very slowly) opened up the 6502 version that jms2 uploaded in an earlier post. I have redrawn the shark using the sprite editor that was supplied (from Jonathan Griffiths' Creative Assembler book):

Screenshot 2022-01-09 at 21.06.15.png (2.84 KiB) Viewed 4768 times

It's a definite improvement!

I'm interested in how level 5 didn't allow you to collect all the items? Wondering if two items got somehow printed too near or on top of each other? I've not seen that myself yet, but cannot disregard the possibility. As for how the game ends, I've not quite got that right yet. At the moment, if there are more rubbish left than fish, then you get a bad luck style message. If it's the opposite, then it says NICE, even if you've run out of air! So, it's not quite there.

I may have to resort to the assembler/Basic version, to eke out some more speed, as the shark sprite is too large to render in a satisfactory manner. I certainly can't render it on the same level as the fish, as it gets far too slow and flickery.

Stephen

[jms2]

I love the new shark sprite - you have a real talent for doing graphics!

[colinhoad]

I love the new shark sprite - you have a real talent for doing graphics!

Yes, seconded! It's a cracking sprite

[tricky]

I've somehow missed this thread for months and now, the game is looking great and wouldn't have been out of place in a 1980+ arcade. My favourite years as you may have guessed from the games that I have remade or ported are 1979 to 1983. Obviously there are games outside that range that I enjoyed, like R-Type, but not an awful lot.

[sa_scott]

I love the new shark sprite - you have a real talent for doing graphics!

Yes, seconded! It's a cracking sprite

Thank you! The hard part was drawing it. I originally used Aseprite, but resorted to printing out graph paper and doing it the old fashioned way, trying to add up the values mentally, and making a right hash of it in the process!

[sa_scott]

I've somehow missed this thread for months and now, the game is looking great and wouldn't have been out of place in a 1980+ arcade. My favourite years as you may have guessed from the games that I have remade or ported are 1979 to 1983. Obviously there are games outside that range that I enjoyed, like R-Type, but not an awful lot.

Thanks tricky. I really appreciate these comments. I've been in a real fallow period of late, having a crisis of confidence in coding the game, and have it play satisfactorily.

It's taken me days to figure out how to use Jonathan Griffiths' sprite editor. I had the shark drawn in the editor, but didn't know how to save it, so had it on screen for several days, not able to open the PDF I have of the Creative Assembler book, because I could never get around to it. This evening, I finally saved it, only to enter too long a name, and it errored, losing the whole thing! Luckily I hadn't thrown away my graph paper, so I could just redraw it again onscreen. Thank heavens there was a facility to flip the sprite. Both directions are now safely saved.

I now need to figure out how to extract these sprite files from jms2's UEF file, and into my repo folder on the Mac. Need to figure out how the DFS disk utilities work to extract it.

Also, out of interest, does anyone know how to convert these sprite files into DATA statements? I can either have the files listed on Github, but will be gibberish, or list it in data form. I still like looking at code listings, so am fond of 'seeing' sprite code, if you get what I mean?

[jms2]

Can you not use Beebem's Export files from disc function to extract the sprite files? Its a disc image (ssd) rather than a UEF, so this ought to work.

It should also be possible to turn them into DATA statements using a BASIC program based on BGET# to read each byte. Or on a PC load them with a hex editor and copy/paste.

[sa_scott]

Can you not use Beebem's Export files from disc function to extract the sprite files? Its a disc image (ssd) rather than a UEF, so this ought to work.

It should also be possible to turn them into DATA statements using a BASIC program based on BGET# to read each byte. Or on a PC load them with a hex editor and copy/paste.

I'm currently using b2 on the Mac, and I can't see anything similar within it's interface. However, Jon Welch's website has a DFS explorer for the Mac, which works on Big Sur, so I can extract files this way.

Thanks for the advice!

[sa_scott]

It should also be possible to turn them into DATA statements using a BASIC program based on BGET# to read each byte. Or on a PC load them with a hex editor and copy/paste.

I was scratching my head a bit at this point, but am wondering whether this small listing from Roland Waddilove's machine code games series in Electron User may be of use here? The listing relies on data created using his sprite maker utility - I don't know if there is a difference in how data is saved between his utility and Jonathan Griffiths' utility from his book.

This is from the March 1988 issue of Electron User, btw.