Polymer Picker (formal release)

[jms2]

This is really good! I had been deliberately avoiding playing your various updates until now, because I wanted to get the full effect of all the changes in one go. It's very impressive and I can't quite believe you have managed to pack all these features into a BASIC program.

I reckon this is now superior to most of the type-in games from the magazines.

[sa_scott]

This is really good! I had been deliberately avoiding playing your various updates until now, because I wanted to get the full effect of all the changes in one go. It's very impressive and I can't quite believe you have managed to pack all these features into a BASIC program.

I reckon this is now superior to most of the type-in games from the magazines.

Oh, you're too kind - thank you!

I'm itching to get it finished, if I can get those 2 shortlisted bits squeezed in, then I'll be very happy with the end result.

Then there's the pure Basic version to sort out. That should be an interesting challenge to bring up to date!

[sa_scott]

Hi all,

Ok, here it is - most likely - the release candidate version of Polymer Picker

I've added the following to this version (attached below)

• There is an additional bonus for remaining air left - this makes the 'shark only' level a bit more interesting at the end, as there was previously no sound.
• The 'shark only' levels were still displaying the number of fish left. This has been removed.
• The 'hurt' sound has been replaced by a higher pitch version of the 'death' sound for the fish. As I only have 4 envelopes to play with, I had to make do with what I have.
• The high score table has some names in it, and a more challenging top score.
• Added a bit more text to the instructions, concerning the bonus award, and some info about how the levels progress, without giving too much away (too late?)
• Further shoehorning to reduce memory consumption, including removal of unused variables, and moving of a repetitive time delay into its own procedure to reduce space.

I'm still paranoid that the 'No room' error will crop up. I've played it many times today, to see if it still crops up, and for the last few hours, it hasn't. So, I think I'm safe.

Please do have a go on it, and reduce my paranoia - I'm hoping this is FINALLY IT!!!!!

• Link to Github repo
• Play online

[ChrisB]

Had a go with it last night - and wasn't able to break it. It has come together nicely and I'd definitely put it at good type in game quality. There are always more features to add or things to tweak and sometimes you just need to declare it done and walk away.

Having said that I think if you're going to add much more then you'll have to delve into assembler for the core game logic. This should give a significant speed increase and hopefully take less space...

[sa_scott]

Had a go with it last night - and wasn't able to break it. It has come together nicely and I'd definitely put it at good type in game quality. There are always more features to add or things to tweak and sometimes you just need to declare it done and walk away.

Having said that I think if you're going to add much more then you'll have to delve into assembler for the core game logic. This should give a significant speed increase and hopefully take less space...

Many thanks, ChrisB. It was your input early on that steered me in the right direction! I'm glad you weren't able to break it. So far, I've heard nothing from anybody negative, so I'm hopeful!

I was literally having to remove colons from the already compressed code, in order to fit in the air bonus routine, without the 'No room' error coming up. I now have a build process that involves already obfuscated code. Obviously, it makes the build process work, but at the expense of the code being horrendous to read.

I have been looking at various sources of assembly language on the games archive site. I got out games with assembler in viewable form, such as Moon Patrol, Monster Maze, and some of the early Gordon Key stuff. The idea is to use VS Code to do code compare with various blocks of assembler which all relate to each other, such as sprite drawing, key input, movement logic, collision logic, etc, and look for the similarities. This is how I tend to learn what's going on, I can then dig out my Birnbaum tome on Assembler to figure out what's going on.

I've got the following left to do on the project, once I've done the formal release:

• add an annotated version of the game code to the repo, or through a blog post.
• create a dedicated webpage on either my site, Github, or Itch.io
• one other thing... which I've always wanted to do, I won't say anything more, except it will be a faded (quite literally) 'homage' to the 80s. More will be revealed

[sa_scott]

v0.96 attached (release candidate 2)

Only 2 updates:

• The oxygen bottle collision detection was a little wayward, so I've corrected the code accordingly.
• A minor update to the high score table names

Other than updating the Github repo, I've now added what is effectively a permalink to the game on my website, so I don't need to keep making new links for each version.

I would say this is considered complete and can be added to the BBC Games Archive now.

I did encounter an issue, concerning the use of the Enter key when using JSBeeb on the Windows platform. Every browser I used on my work computer (Windows 10) didn't always accept the Enter key being held down with any other movement key, so as to move diagonally at speed across the screen. However, when I tried the same browsers on the Mac OS machine we have here, in addition to Safari, I had no such problem.

I'll need to try this out on my Windows 10 machine at home, to see if it occurs there. If it doesn't, I can attribute it to possible security software installed at work on the Windows machines (I am unable to install emulator software at work, due to MS Defender Smart Screen preventing these from running - they're unsigned, so they can't run).

[fizgog]

Managed to give a try, very good game but I did get the "No room at 108" on 4th attempt

[sa_scott]

Managed to give a try, very good game but I did get the "No room at 108" on 4th attempt


Screenshot 2022-11-11 at 18.41.27.png

Well, my only response to that - right now - is

matt-berry-yell.gif (1.26 MiB) Viewed 5617 times

Gonna have some more code mashing tonight!!!

Thank you for finding this, btw!

[sa_scott]

Here's release candidate 3 - v0.97

Some further code compression employed. I realised that the music tune data had a repetitive value, which I've pruned out, which has shaved some more bytes. I've exchanged 4 of the variables to the 4 remaining resident integer variables to reduce some further consumption.

I've played it several times, including at least 5 times, and I didn't get the No room error. That said, if anyone else can hammer through it, that would be appreciated.

• Play online
• Github repo

[sa_scott]

I did encounter an issue, concerning the use of the Enter key when using JSBeeb on the Windows platform. Every browser I used on my work computer (Windows 10) didn't always accept the Enter key being held down with any other movement key, so as to move diagonally at speed across the screen. However, when I tried the same browsers on the Mac OS machine we have here, in addition to Safari, I had no such problem.

I'll need to try this out on my Windows 10 machine at home, to see if it occurs there. If it doesn't, I can attribute it to possible security software installed at work on the Windows machines (I am unable to install emulator software at work, due to MS Defender Smart Screen preventing these from running - they're unsigned, so they can't run).

Having tried it on my Windows 10 PC at home, I was unable to reproduce the Enter key issue. I'm going to attribute it to the security setup at work. Not sure it's worth raising as an issue at jsbeeb's Github, but something to bear in mind if playing the game in a corporate network

[sa_scott]

Sorry to bump the thread a little - I'm still a little fretful that 'No room' is going to rear it's head at random opportunities.

I have tried running B2 in debug mode, which allowed me to view a memory debugger. I basically did an observation around the level of HIMEM, to see if the unused bytes hovering below it would get occupied with successive game plays. Despite various attempts, I was not able to observe any memory issues creeping up on me.

With that in mind, I'm somewhat tempted to bump this up to version 1.0, and consider the game 'finished.' I've not been able to uncover anything new, but then again, I've looked at this game so much in recent months, I may be blind to the obvious.

However, if anyone has found an issue, do let me know, and I'll do my best to address it.

Thanks again in advance!

[sa_scott]

v0.98 (rc4) attached. Github repo link

Play online

Thanks to some further playtesting by 'fizgog' the 'No room' error came up again, after about 5 or 6 games.

I've therefore performed some further code crunching:

• Moved memory location of sprites slightly higher up to reduce likelihood of memory issue
• Refined PAGE relocation routine, at expense of display of onscreen messaging (you could argue it's less refined, but it works)
• Further refinement of VDU statements, removing any unnecessary instances of VDU 4 or 5.
• Change of variables to looser type, removing percent symbol to reduce space.
• Adjusted top high score to 75000(!)
• Fixed bug in high score entry where excess characters typed would corrupt display. Fizgog sent me a screenshot of this, which I mistakenly believed was related to 'No room', but I was able to reproduce it by entering a name far longer than there was space. Yet, the 'extra' characters were not only retained, but corrupted the screen display.
• Further code refinements to reduce space further.

I'm not going to say I've gotten rid of the 'No room' error, but I've played it several times today, in addition to the above changes, and I don't seem to have tripped it... yet

[hexwab]

Since the Dithertron thread I somehow feel at least partly to blame for the loading screen, so I thought I'd fix it up a bit :)

The "by" screen is mostly empty. Loading over 14K of zeros from disc offends my sense of efficiency: trimmed. (You wouldn't do this for a tape version... I hope.)

Now that the by screen's smaller, it can fit into memory in addition to the main title screen, so no need to sit at a blank screen while that's busy loading.

While I'm here, fade the by screen in and out why not.

Avoid printing over the gorgeous dithered picture until loading has actually finished. Do everything we possibly can first: assemble code, load the sprites, load the instructions... This means we now run POLY2 before POLY1, and thus POLY1 must avoid overwriting the variables that POLY2 sets up.

Rewrite the move-to-&E00 routine in assembler for a big speed boost. (Could be faster still but hey.) We assume the game code ends at &2C00, which means copying a bit extra just in case. The relocator is no longer in the main game program, so there's some extra bytes freed up. Add a line number to avoid breaking RESTOREs.

Move the sprites into a single file for faster loading. Rearrange the catalogue so that files that get loaded first are nearer the beginning of the disc to minimise seek time.

Turn off shadow RAM if present to avoid more staring at black screens (and to ensure you can, y'know, actually see the diver). Load screens into the I/O processor just in case we're across the Tube.

Speaking of Tube, access the key translation table via OSWORD 5 as it lives in I/O space. This works on a Master with co-pro but not on B or B+ with co-pro (bug somewhere?).

The game itself fails over the Tube in the same manner it used to fail with shadow RAM: no sprites. (It's a testament to use of OS facilities that as much of the game works as it does. Not sure whether that's a good or bad thing.)

There are other things I'd change about the game too but that's a project for another day.

Code is on github.

Update: just as I'm about to push I find you've been making simultaneous changes. Oh well. Sorting that out is also a project for another day.

Tom.

[TobyLobster]

I see I have a credit in game and in the README, thanks! But I am TobyLobster, not TonyLobster.

[sa_scott]

I see I have a credit in game and in the README, thanks! But I am TobyLobster, not TonyLobster.

I'm so sorry Toby! I've corrected it now, as I found a stupid bug straight after uploading the previous version. Will amend shortly!

[sa_scott]

v0.982 (rc5) attached - Github repo link

Play online

Just as I uploaded that last version, and play tested, I immediately found that moving the sprite location, broke one of the dead fish sprites, turning it into a chunk of the sun (I guess I pushed it upwards into the beginning of screen memory - silly me)

• I've correctly credited TobyLobster - you're no longer called Tony!
• Reverted the sprite memory address and HIMEM value to resolve the corrupted dead fish sprite issue
• Moved credits to the initial loading screen.

I think I need a lie down

[sa_scott]

Since the Dithertron thread I somehow feel at least partly to blame for the loading screen, so I thought I'd fix it up a bit

The "by" screen is mostly empty. Loading over 14K of zeros from disc offends my sense of efficiency: trimmed. (You wouldn't do this for a tape version... I hope.)

Now that the by screen's smaller, it can fit into memory in addition to the main title screen, so no need to sit at a blank screen while that's busy loading.

While I'm here, fade the by screen in and out why not.

Avoid printing over the gorgeous dithered picture until loading has actually finished. Do everything we possibly can first: assemble code, load the sprites, load the instructions... This means we now run POLY2 before POLY1, and thus POLY1 must avoid overwriting the variables that POLY2 sets up.

Rewrite the move-to-&E00 routine in assembler for a big speed boost. (Could be faster still but hey.) We assume the game code ends at &2C00, which means copying a bit extra just in case. The relocator is no longer in the main game program, so there's some extra bytes freed up. Add a line number to avoid breaking RESTOREs.

Move the sprites into a single file for faster loading. Rearrange the catalogue so that files that get loaded first are nearer the beginning of the disc to minimise seek time.

Turn off shadow RAM if present to avoid more staring at black screens (and to ensure you can, y'know, actually see the diver). Load screens into the I/O processor just in case we're across the Tube.

Speaking of Tube, access the key translation table via OSWORD 5 as it lives in I/O space. This works on a Master with co-pro but not on B or B+ with co-pro (bug somewhere?).

The game itself fails over the Tube in the same manner it used to fail with shadow RAM: no sprites. (It's a testament to use of OS facilities that as much of the game works as it does. Not sure whether that's a good or bad thing.)

There are other things I'd change about the game too but that's a project for another day.

Code is on github.

Update: just as I'm about to push I find you've been making simultaneous changes. Oh well. Sorting that out is also a project for another day.

Tom.

Firstly, thanks so much Tom, I really appreciate what you've done here. I saw that you had messaged, but wanted to focus on getting the revised version up, before I crash out for the night.

I don't normally create so many versions in one evening - my time is usually extremely limited, but resolving the no room glitch that fizgog found was bugging me like crazy so I spent a large chunk of today pushing myself, not being certain when I would get another chance.

I've had a quick look at what you've done, and appreciate the work done on putting the sprites together., in addition to the memory relocation. I would love to be able to have the sprites viewable in Github, or at least have a sprite data generator (which is old school), but maybe another time.

I'll pore over the rest of the amends, and cherry pick most/all of it into the next RC. But thank you

[hexwab]

if you're going to add much more then you'll have to delve into assembler for the core game logic. This should give a significant speed increase and hopefully take less space...

Seconded.

I've looked at this game so much in recent months, I may be blind to the obvious.

My "obvious" takeaways are:

(a) it's slow and flickery. Slowness may be unavoidable in a mostly-BASIC game (although that's a far-from-optimized sprite routine you have there), but the diver flickers even when stationary because for some reason you're replotting it repeatedly even when nothing has changed. There's no attempt to synchronise plotting to the vertical blanking interval. Slowdown is noticeable in later levels.

For real pain play on an Electron. (Yes, you can play on an Electron, you just wouldn't *want* to. If nothing else, you get many fewer frames of gameplay before your air supply runs out.)

(b) Fish move very jerkily. Dead fish in particular seem to sink by 5 or 6 pixels at a time.
Live fish move by 2 pixels at a time even vertically. (Smarter people than I have concluded that *horizontal* pixel-accurate movement in MODE 2 is best done with two copies of each sprite, one offset by a pixel horizontally, but at least in the case of the live fish there's only two sprites and they're only 32 bytes each so such duplication seems feasible, allowing smooth movement in all directions.)

(c) Player seems to be immune to shark attacks. You can bumble about, bleeding out all the while, with seemingly no ill effects other than the shrill "I'm dying (allegedly) here!" sound. You'd think the adrenaline rush of being eaten alive would make you use more air or something...

Also the shark active point should be its head. More generally, the difficulty curve could use some balancing.

(d) The "white coloured" items aren't always, particularly if they're on the sea bed, making them hard to see (and the instructions inaccurate). This isn't unavoidable even with exclusive-or plotting once you realise that with twice as many logical as physical colours, you can simply redefine an entire half of the palette (say colours 8-15) as all white and plot items in colour 8. Bonus: plot bubbles emanating from the diver in the same guaranteed-white. Another option is to set colour 8 to white and colours 9-15 to match 1-7, thus making items appear *behind* other objects, and preserving the "items can hide out on the sea bed" notion but with fewer colour artifacts (but now you need to be sure that regardless of item positioning there's always at least a glint of white).

Speaking of colour artifacts: fish can flash when your air is low.

(e) The tunes run at different speeds depending on your BASIC version. Delay loops such as "FORz=1TO400:NEXT" take less time on a Master with its more efficient fp routines, and given the OS's sound queueing facilities you shouldn't even need them. The end-of-level ditty is out of tune.

On to more personal preferences:

(f) The dollar amounts for everything (particularly as it's not my native currency or I imagine that of most users of the British-made Beeb). Are we saving the environment for the good of humanity or are we profiteering foreign capitalists? Game seems undecided. Given that the message seems to be a big theme of the game, personally I'd drop the money angle.

(g) Everything's 8x8. The fish, the items, the default font. Particularly in MODE 2, such characteristic squatness screams to me "I don't know how to make things any other size, I just used what was provided". Admittedly this has a charm all of its own and it's not like you're making a state-of-the-art-pushing tech demo. Is this "classic" Beeb look deliberate?

(h) There's a lot to skip through before you get to the actual game. I count five presses of the spacebar before the game starts. That's a lot for impatient or repeat players (or playtesters!). Maybe start with the controls screen and have a separate "press I for instructions" button to render the three pages of text optional. Accepting other keys in addition to space would allow impatient redefiners to mash "R" rather that having to remember to press space four times (but not five! then you have to reload! made this mistake more than once). There's probably no need to display the high score table until after the first game ends.

I personally would not consider this game "done" until there are no more improvements to be made, which is not yet the case. But admittedly I am a perfectionist and my standards are off-the-charts high.

(Despite the snark I quite like this game :)

Tom.

[sa_scott]

My "obvious" takeaways are:

(a) it's slow and flickery. Slowness may be unavoidable in a mostly-BASIC game (although that's a far-from-optimized sprite routine you have there), but the diver flickers even when stationary because for some reason you're replotting it repeatedly even when nothing has changed. There's no attempt to synchronise plotting to the vertical blanking interval. Slowdown is noticeable in later levels.

For real pain play on an Electron. (Yes, you can play on an Electron, you just wouldn't *want* to. If nothing else, you get many fewer frames of gameplay before your air supply runs out.)

I had intended the code to not print the diver repeatedly, and I could have sworn it wasn't doing that in an earlier version. My code is so unreadable now, that I'm not certain I can resolve it. In terms of the blanking interval, I presume you mean the use of *FX19? I tried this a few times, but saw no noticeable improvement - I suspect I was using it in the wrong place - I was unable to find working examples of it's use in BASIC on the archive, so decided to drop it.

(b) Fish move very jerkily. Dead fish in particular seem to sink by 5 or 6 pixels at a time.
Live fish move by 2 pixels at a time even vertically. (Smarter people than I have concluded that *horizontal* pixel-accurate movement in MODE 2 is best done with two copies of each sprite, one offset by a pixel horizontally, but at least in the case of the live fish there's only two sprites and they're only 32 bytes each so such duplication seems feasible, allowing smooth movement in all directions.)

I was keen to ensure the dead fish drop out of view quickly, hence they are a bit 'heavier' - the jumps in movement were primarily to increase the illusion of speed.

(c) Player seems to be immune to shark attacks. You can bumble about, bleeding out all the while, with seemingly no ill effects other than the shrill "I'm dying (allegedly) here!" sound. You'd think the adrenaline rush of being eaten alive would make you use more air or something...

Also the shark active point should be its head. More generally, the difficulty curve could use some balancing.

The shark collision detection is the one thing I remain unhappy about, I've tinkered with it to the best of my ability, but it remains wanting. I have also gotten used to swimming quickly which reduces air anyway, so haven't noticed that being attacked by the shark doesn't reduce your air, which is something I'll need to address.

In terms of difficulty, the difficulty curve was determined by the shark being closer to the bottom of the sea on earlier levels, the depth reduces a little with each shark level, so he gets closer.

(d) The "white coloured" items aren't always, particularly if they're on the sea bed, making them hard to see (and the instructions inaccurate). This isn't unavoidable even with exclusive-or plotting once you realise that with twice as many logical as physical colours, you can simply redefine an entire half of the palette (say colours 8-15) as all white and plot items in colour 8. Bonus: plot bubbles emanating from the diver in the same guaranteed-white. Another option is to set colour 8 to white and colours 9-15 to match 1-7, thus making items appear *behind* other objects, and preserving the "items can hide out on the sea bed" notion but with fewer colour artifacts (but now you need to be sure that regardless of item positioning there's always at least a glint of white).

The use of colours 8-15 is somewhat patchy, as I've changed the fish colours to use 2 of those, so I could introduce differently coloured fish on later levels. I appreciate the comment about the rubbish being hidden at the bottom, I had been wondering whether it would make sense to raise the minimum position for the rubbish, so this doesn't happen.

Speaking of colour artifacts: fish can flash when your air is low.

I hadn't noticed that - good catch

(e) The tunes run at different speeds depending on your BASIC version. Delay loops such as "FORz=1TO400:NEXT" take less time on a Master with its more efficient fp routines, and given the OS's sound queueing facilities you shouldn't even need them. The end-of-level ditty is out of tune.

I have to admit, I lifted the tune routine from one of Mike Goldberg's games, which included these - I guess he didn't have access to a Master either - as to the end-of-level ditty, do you mean when the fish show hearts? The tone/delay is determined by the index number of the fish, so if any fish are dead, you get a 'pause' which isn't ideal.

(f) The dollar amounts for everything (particularly as it's not my native currency or I imagine that of most users of the British-made Beeb). Are we saving the environment for the good of humanity or are we profiteering foreign capitalists? Game seems undecided. Given that the message seems to be a big theme of the game, personally I'd drop the money angle.

Originally, it was more about ensuring that you collected more rubbish than killed fish. The game mechanics have kind of moved away from that, and I was keen to have some kind of 'score' - the use of currency points to an uncomfortable truth - the only way the oceans are going to get cleaned, or even to encourage recycling, is for it to mean good business. There has to be money to be made in rubbish. Until rubbish has value, we'll just keep making more of it. Or, at least until capitalism dies, so we can all stop racing to get one up on each other, at the expense of the planet.

(g) Everything's 8x8. The fish, the items, the default font. Particularly in MODE 2, such characteristic squatness screams to me "I don't know how to make things any other size, I just used what was provided". Admittedly this has a charm all of its own and it's not like you're making a state-of-the-art-pushing tech demo. Is this "classic" Beeb look deliberate?

I could always make some VDU statements for the numbers, but they would obviously still be 8x8. My knowledge of assembly is the same as Elon Musk's knowledge of how to run Twitter - miniscule.

(h) There's a lot to skip through before you get to the actual game. I count five presses of the spacebar before the game starts. That's a lot for impatient or repeat players (or playtesters!). Maybe start with the controls screen and have a separate "press I for instructions" button to render the three pages of text optional. Accepting other keys in addition to space would allow impatient redefiners to mash "R" rather that having to remember to press space four times (but not five! then you have to reload! made this mistake more than once). There's probably no need to display the high score table until after the first game ends.

This was something that I had in mind - after all, my previous games had the ability to skip instructions, so it's not something I should leave out in this case. Waiting to play the game is not a good thing! Actually, having the high score table gives an indication to the player as to what to achieve to get the high score (if this was like an arcade game, you'd have a demo mode, but I'm short of space as it is)

I personally would not consider this game "done" until there are no more improvements to be made, which is not yet the case. But admittedly I am a perfectionist and my standards are off-the-charts high.

Yeah, I can see you're a perfectionist. Some of the points you've raised are valid ones, and are things I have thought about. For me however, I've been at this over a year, sometimes with long periods between sessions, as my life outside of retrogaming (family, work, having a child with special needs) can be challenging, and mentally draining. I can certainly go through some of your suggestions, but there are some I'll have to just let go of, or - since the code is on Github - throw it open to others to 'fork and break' (f*****kin break?) in the hope of improving it.

I think someone's earlier comment about it being like a good magazine type-in game is closer to what I had in mind - flickering be damned

(Despite the snark I quite like this game

I'm glad you like the game enough to have left all these comments on how to improve it

Tom.
[/quote]

[TobyLobster]

[*]I've correctly credited TobyLobster - you're no longer called Tony!
[*]Moved credits to the initial loading screen.

Err, I still seem to be TonyLobster on the initial loading screen.

[sa_scott]

[*]I've correctly credited TobyLobster - you're no longer called Tony!
[*]Moved credits to the initial loading screen.

Err, I still seem to be TonyLobster on the initial loading screen.

Don't worry, I've corrected you in v0.99, which I'm still working on. Have been trying to include hexwab's suggestions from his code fork. I had some teething issues with the initial load screen, but then realised that the bootfile had been changed to include PAGE being set to &1100, which didn't seem to show up on Github for some reason (had to examine the bootfile from within the disc image to see the change).

I've managed to integrate the amends he had in his fork, which greatly improve the loading experience, adding that extra bit of polish. I've also now given more choice to the player, whether to view instructions, redefine keys, or just play the game. The improved loading of the game code and relocation, make getting to the game itself, a quicker experience.

V0.99 code changes so far, can be viewed here - https://github.com/sassquad/polymer-pic ... tree/v0.99

I need to take a look at hexwab's other suggestions concerning the gameplay itself. I'll have to work with already heavily compressed code, to try and decipher the issues he's raised, so I can correct / improve accordingly. Unfortunately, I'm out of time for today

[hexwab]

I had some teething issues with the initial load screen, but then realised that the bootfile had been changed to include PAGE being set to &1100, which didn't seem to show up on Github for some reason (had to examine the bootfile from within the disc image to see the change).

Oops. Looks like that slipped through the cracks due to a different fix: renaming the previously-all-lowercase BOOT.txt so that it would build on my case-sensitive filesystem.[1] During my attempts to persuade git that this was a rename and not a creation+deletion, the changes to the actual contents got lost and the result just happened to work on the (emulated) Master I was testing with. Sorry.

Anyway. I have rebased on v0.99, reinstated build.sh that I think you inadvertently emptied, reapplied the aforementioned rename (that I assume you missed because it didn't affect you), and sent a pull request. Hopefully we're now on the same page.

If you're willing to hold off for a week or two I'm happy to go down my own list and make what improvements I can.

Tom.

[1] I didn't mention such "administrative" fixes, the other being making the build script executable so it can be run with ./build.sh.

[sa_scott]

I had some teething issues with the initial load screen, but then realised that the bootfile had been changed to include PAGE being set to &1100, which didn't seem to show up on Github for some reason (had to examine the bootfile from within the disc image to see the change).

Oops. Looks like that slipped through the cracks due to a different fix: renaming the previously-all-lowercase BOOT.txt so that it would build on my case-sensitive filesystem.[1] During my attempts to persuade git that this was a rename and not a creation+deletion, the changes to the actual contents got lost and the result just happened to work on the (emulated) Master I was testing with. Sorry.

Anyway. I have rebased on v0.99, reinstated build.sh that I think you inadvertently emptied, reapplied the aforementioned rename (that I assume you missed because it didn't affect you), and sent a pull request. Hopefully we're now on the same page.

If you're willing to hold off for a week or two I'm happy to go down my own list and make what improvements I can.

Tom.

[1] I didn't mention such "administrative" fixes, the other being making the build script executable so it can be run with ./build.sh.

Many thanks hexwab, I've merged your changes into v0.99, I'm going to merge it to main, so others can enjoy the fruits of your labour so far, along with the refined user experience, on choosing to view instructions, redefine keys, or play the game.

[sa_scott]

v0.99 attached. Link to Github repo

Play online

This version introduces the changes to the loading sequence initiated by hexwab. I've also given the option to view instructions, redefine keys, or play the game, so it's quicker to get to the game itself.

Many thanks to hexwab for making these amends in his own time, and of his own volition. It really adds some extra polish to the game.

Some further changes have been promised, if I'm prepared to wait.

[hexwab]

https://github.com/sassquad/polymer-picker-6502/pull/19 sez "Authored by screen now renders in Mode 1". It's more complicated than that :)
We actually render in MODE 0 same as before[1] but lie to the OS about what mode it's in. Then we change back to MODE 1 (again behind the OS's back) before printing the "press SPACEBAR" message, for which the OS needs to know the truth to be able to print correctly. Why? Because when you ask the OS to change MODE it also clears the screen we've just loaded.

Anyway. Part one of the "more memory" trick is to have a separate program just for variable initialization. How this works is kinda intricate: running a program with "RUN" clears the variables but running it with "GOTO" doesn't. So we load POLY3 and the new program POLY4, relocate POLY3, set PAGE to &E00 (which does nothing other than set a pointer), and run "OLD", which checks the program length and sets LOMEM, the location of BASIC variables, to the end of the program. Setting LOMEM clears all variables. Then we change PAGE again to wherever POLY4 was loaded (we have plenty of space in MODE 7, it's not important precisely where), and run it with GOTO (importantly, this leaves LOMEM alone).

Then we do whatever variable setup we want, change PAGE back to &E00 and jump into the main game with GOTO (again leaving LOMEM alone). Its work done, the initialization program gets written over shortly afterwards when we change to MODE 2.

Changing so much stuff out from under BASIC tends to confuse it: running the relocator with CALL&50, running "OLD", and calling GOTO are all separate commands because putting them all on one colon-separated line has BASIC just give up with "Syntax error". I've temporarily removed the VDU21 (as a way of turning screen output off this is cheaper than *FX3) and added some diagnostics just so it's clearer what's going on.

Not using the function keys also frees up &B00-BFF for whatever we want.

Part two of getting more memory is, now that we have as much free variable initialization as we want, we can store VDU sequences in strings. "PRINTA$" is smaller than, e.g. "VDU4,28,0,31,19,27,17,143,12,26,28,0,28,19,27,17,132,12,26,5" even accounting for the storage requirements for A$, because decimal numbers take up so much space. Bonus: printing strings is also faster because parsing decimal numbers is expensive. Adding a trailing semicolon to the PRINT statement to suppress a newline may or may not be worthwhile.

(Note that you've always been able to simply PRINT"[some incomprehensible garbage]" (you can include any bytes you like other than the trailing quote) but not only does this render your program unlistable, beebasm will interpret some bytes you might want to have in your string as newlines.)

I also made a start on a more efficient sprite plotter but it seems clear that sprite plotting is not actually a bottleneck.

Tom.

[1] The picture is unchanged, and yes you can have more than two colours on screen in MODE 0! There's an entire demo built around this idea: https://www.youtube.com/watch?v=Ph4U2_E2F-c (someday I hope Dithertron will be able to make pictures like that!)

[sa_scott]

https://github.com/sassquad/polymer-picker-6502/pull/19 sez "Authored by screen now renders in Mode 1". It's more complicated than that
We actually render in MODE 0 same as before[1] but lie to the OS about what mode it's in. Then we change back to MODE 1 (again behind the OS's back) before printing the "press SPACEBAR" message, for which the OS needs to know the truth to be able to print correctly. Why? Because when you ask the OS to change MODE it also clears the screen we've just loaded.

This is why I should never write messages in a very short time window! Apologies for the oversimplification.

I'll digest the rest of your message when I have more than a sliver of minutes to read it

[sa_scott]

https://github.com/sassquad/polymer-picker-6502/pull/19 sez "Authored by screen now renders in Mode 1". It's more complicated than that
We actually render in MODE 0 same as before[1] but lie to the OS about what mode it's in. Then we change back to MODE 1 (again behind the OS's back) before printing the "press SPACEBAR" message, for which the OS needs to know the truth to be able to print correctly. Why? Because when you ask the OS to change MODE it also clears the screen we've just loaded.

I've amended the PR comment to reflect this now

Anyway. Part one of the "more memory" trick is to have a separate program just for variable initialization. How this works is kinda intricate: running a program with "RUN" clears the variables but running it with "GOTO" doesn't. So we load POLY3 and the new program POLY4, relocate POLY3, set PAGE to &E00 (which does nothing other than set a pointer), and run "OLD", which checks the program length and sets LOMEM, the location of BASIC variables, to the end of the program. Setting LOMEM clears all variables. Then we change PAGE again to wherever POLY4 was loaded (we have plenty of space in MODE 7, it's not important precisely where), and run it with GOTO (importantly, this leaves LOMEM alone).

Then we do whatever variable setup we want, change PAGE back to &E00 and jump into the main game with GOTO (again leaving LOMEM alone). Its work done, the initialization program gets written over shortly afterwards when we change to MODE 2.

I'll await more details on this - but it sounds like techniques that take advantage of 'frailties' of the OS. Would these techniques work on more than BBC B's? I recall your earlier work with key definitions, and supporting the Master, so I must assume it's safe to use there.

Changing so much stuff out from under BASIC tends to confuse it: running the relocator with CALL&50, running "OLD", and calling GOTO are all separate commands because putting them all on one colon-separated line has BASIC just give up with "Syntax error". I've temporarily removed the VDU21 (as a way of turning screen output off this is cheaper than *FX3) and added some diagnostics just so it's clearer what's going on.

I had wondered why some games used *FX3, while others used VDU21. When you say 'cheaper' do you mean it uses more memory, or is faster to run?

Not using the function keys also frees up &B00-BFF for whatever we want.

I did an earlier attempt at moving code around, but came unstuck trying to use &B00, but didn't realise it was the same space as the function keys. At least I can have some more sound by moving the sprite code there.

Part two of getting more memory is, now that we have as much free variable initialization as we want, we can store VDU sequences in strings. "PRINTA$" is smaller than, e.g. "VDU4,28,0,31,19,27,17,143,12,26,28,0,28,19,27,17,132,12,26,5" even accounting for the storage requirements for A$, because decimal numbers take up so much space. Bonus: printing strings is also faster because parsing decimal numbers is expensive. Adding a trailing semicolon to the PRINT statement to suppress a newline may or may not be worthwhile.

I had naturally assumed that VDU commands would be actually quicker to the OS, than strings. This is probably more true if the VDU codes were issued via assembler instead. I wonder if hex codes are quicker, and you can remove the commas, at the cost of readability. Not that my code is any more readable now

I also made a start on a more efficient sprite plotter but it seems clear that sprite plotting is not actually a bottleneck.

The routine itself was taken from Jonathan Griffiths' Creative Assembler book, I had to assume that he gifted us an optimised routine. It sounds like that may be the case.

There's an awful lot of interesting techniques you have outlined in recent days, which would be a boon to would-be developers, which I would never have been able to find elsewhere. Thank you for these comments.

[hexwab]

I'll await more details on this - but it sounds like techniques that take advantage of 'frailties' of the OS. Would these techniques work on more than BBC B's? I recall your earlier work with key definitions, and supporting the Master, so I must assume it's safe to use there.

I should've explicitly mentioned that details were on github, specifically here.

Yes it's safe. BASIC didn't change as much over the years as the OS did (I'd bet that this technique still works even on ARM BBC BASIC for RISC OS). I do try to remember to test on all of the various machines that b-em supports (model B, B+, Master with OS3.20, Master with OS3.50, maybe Tube if I'm feeling adventurous).

I had wondered why some games used *FX3, while others used VDU21. When you say 'cheaper' do you mean it uses more memory, or is faster to run?

More memory. *commands are awkward to call from BASIC as they have to be the last statement on a line. Using OSCLI or CALL&FFF4 also takes a lot of characters. VDU21 and VDU6 can much more easily be tacked on to other stuff you're printing. My initial relocation code snuck a ctrl+F (==VDU6) into the keyboard buffer just before the final RETURN keypress. Many programs BITD made themselves unlistable by simply including a byte value of 21 within a REM statement.

Or if they were really sneaky:

Code: Select all

10REM My Innocent Program[byte 21]
11code that's actually executed
[...]
19END:REM [byte 6]
20code that you think is being executed, based on LIST output

I had naturally assumed that VDU commands would be actually quicker to the OS, than strings. This is probably more true if the VDU codes were issued via assembler instead. I wonder if hex codes are quicker, and you can remove the commas, at the cost of readability. Not that my code is any more readable now :?

I was curious so measured it (attached):

Code: Select all

T%=TIME
FORA%=1TO1000:PRINT"Hello, world":NEXT
I%=TIME-T%
A$="Hello, world"
T%=TIME
FORA%=1TO1000:PRINTA$:NEXT
J%=TIME-T%
T%=TIME
FORA%=1TO1000:VDU72,101,108,108,111,44,32,119,111,114,108,100,10,13:NEXT
K%=TIME-T%
T%=TIME
FORA%=1TO1000:VDU&48,&65,&6C,&6C,&6F,&2C,&20,&77,&6F,&72,&6C,&64,&A,&D:NEXT
L%=TIME-T%
T%=TIME
FORA%=1TO1000:VDU&6548;&6C6C;&2C6F;&7720;&726F;&646C;&D0A;:NEXT
M%=TIME-T%
T%=TIME
FORA%=1TO1000:NEXT
N%=TIME-T%
@%=6
PRINT I%-N%,J%-N%,K%-N%,L%-N%,M%-N%

Results: 489 (inline string), 503 (string variable), 1029 (decimal VDU sequence), 915 (hex VDU sequence), 783 (double-byte hex VDU sequence) respectively. BBC B, printing in MODE 7. If you're, say, plotting triangles (expensive) instead of printing in teletext mode (cheap) the difference will be less pronounced.

The routine itself was taken from Jonathan Griffiths' Creative Assembler book, I had to assume that he gifted us an optimised routine. It sounds like that may be the case.

Interesting! Having just now had a look through Griffiths' book, I wonder whether this was the same plotter used in "such widely popular programs as Snapper and JCB Digger", or whether he was aiming for more comprehensible, generic code lacking in "gotchas". Little things like self-modification (great performance win) resulting in your code no longer working from a ROM cartridge, for example.[1] Less charitably, maybe he was trying to not give *all* his secrets away...

Either way doesn't necessarily mean much with the benefit of hindsight: knowledge was much patchier back then. As Toby put it in his Starship Command commentary (and there were a *lot* of optimizations we were able to make to Starship Command): As always, nothing written here is meant to denigrate the original work from 1983, which remains a remarkable achievement in the world before such things as the Internet, source control, fast reliable storage media, extensive information and a community about the inner workings of the BBC Micro, etc. It all just highlights the benefits we have today.

Tom.

[1] All of the super-optimized routines I'm aware of do really crazy stuff. See, e.g. this thread if you would like your mind blown.

[sa_scott]

I'll await more details on this - but it sounds like techniques that take advantage of 'frailties' of the OS. Would these techniques work on more than BBC B's? I recall your earlier work with key definitions, and supporting the Master, so I must assume it's safe to use there.

I should've explicitly mentioned that details were on github, specifically here.

Yes it's safe. BASIC didn't change as much over the years as the OS did (I'd bet that this technique still works even on ARM BBC BASIC for RISC OS). I do try to remember to test on all of the various machines that b-em supports (model B, B+, Master with OS3.20, Master with OS3.50, maybe Tube if I'm feeling adventurous).

I had wondered why some games used *FX3, while others used VDU21. When you say 'cheaper' do you mean it uses more memory, or is faster to run?

More memory. *commands are awkward to call from BASIC as they have to be the last statement on a line. Using OSCLI or CALL&FFF4 also takes a lot of characters. VDU21 and VDU6 can much more easily be tacked on to other stuff you're printing. My initial relocation code snuck a ctrl+F (==VDU6) into the keyboard buffer just before the final RETURN keypress. Many programs BITD made themselves unlistable by simply including a byte value of 21 within a REM statement.

Or if they were really sneaky:

Code: Select all

10REM My Innocent Program[byte 21]
11code that's actually executed
[...]
19END:REM [byte 6]
20code that you think is being executed, based on LIST output

I had naturally assumed that VDU commands would be actually quicker to the OS, than strings. This is probably more true if the VDU codes were issued via assembler instead. I wonder if hex codes are quicker, and you can remove the commas, at the cost of readability. Not that my code is any more readable now

I was curious so measured it (attached):

Code: Select all

T%=TIME
FORA%=1TO1000:PRINT"Hello, world":NEXT
I%=TIME-T%
A$="Hello, world"
T%=TIME
FORA%=1TO1000:PRINTA$:NEXT
J%=TIME-T%
T%=TIME
FORA%=1TO1000:VDU72,101,108,108,111,44,32,119,111,114,108,100,10,13:NEXT
K%=TIME-T%
T%=TIME
FORA%=1TO1000:VDU&48,&65,&6C,&6C,&6F,&2C,&20,&77,&6F,&72,&6C,&64,&A,&D:NEXT
L%=TIME-T%
T%=TIME
FORA%=1TO1000:VDU&6548;&6C6C;&2C6F;&7720;&726F;&646C;&D0A;:NEXT
M%=TIME-T%
T%=TIME
FORA%=1TO1000:NEXT
N%=TIME-T%
@%=6
PRINT I%-N%,J%-N%,K%-N%,L%-N%,M%-N%

Results: 489 (inline string), 503 (string variable), 1029 (decimal VDU sequence), 915 (hex VDU sequence), 783 (double-byte hex VDU sequence) respectively. BBC B, printing in MODE 7. If you're, say, plotting triangles (expensive) instead of printing in teletext mode (cheap) the difference will be less pronounced.

The routine itself was taken from Jonathan Griffiths' Creative Assembler book, I had to assume that he gifted us an optimised routine. It sounds like that may be the case.

Interesting! Having just now had a look through Griffiths' book, I wonder whether this was the same plotter used in "such widely popular programs as Snapper and JCB Digger", or whether he was aiming for more comprehensible, generic code lacking in "gotchas". Little things like self-modification (great performance win) resulting in your code no longer working from a ROM cartridge, for example.[1] Less charitably, maybe he was trying to not give *all* his secrets away...

Either way doesn't necessarily mean much with the benefit of hindsight: knowledge was much patchier back then. As Toby put it in his Starship Command commentary (and there were a *lot* of optimizations we were able to make to Starship Command): As always, nothing written here is meant to denigrate the original work from 1983, which remains a remarkable achievement in the world before such things as the Internet, source control, fast reliable storage media, extensive information and a community about the inner workings of the BBC Micro, etc. It all just highlights the benefits we have today.

Tom.

[1] All of the super-optimized routines I'm aware of do really crazy stuff. See, e.g. this thread if you would like your mind blown.

Apologies for giving the impression I left this thread hanging. I finally tried out hexwab's optimised sprite and VDU string routine in his fork of the game, and the speed increase was very noticeable.

I've created a Pull Request of v0.992 on my Github - I don't want to merge it yet, in case further optimisations are incoming. But you can download the SSD file in the PR (also attached below), and try out the optimisations yourself - the change in speed is quite remarkable

[sa_scott]

v0.992 attached. Link to Github repo

Play online

I have now merged the v0.992 changes to main, and updated accordingly on my website. Despite my last message, I was keen to share the fruits of Tom's labour so far to a wider audience. I'm not going to rush him either, but I look forward to what else he comes up with. The work so far has freed up about another 1.5k for further enhancements, which is awesome!