Leaderboard

Good eye, this is indeed using Denis's Engine he originally developed for Ringo, which he open-sourced here: https://github.com/DenisGrachev/Ringo-8 I've added the 'scroller', as the original engine is limited to a small level map, so this can do the much wider map required for a shmup. Also been experimenting with additional pseudo-sprites that will be drawn in spare cycles for the player's bullets/laser. Struggling a bit with spare cycles though, as I'm aiming to do a lot more than RIngo did, but still limited to the same damn Z80 CPU haha If I can figure out it, should be pretty crazy for a Speccy shmup, I may have to compromise on the audio though. It is showing an illusion of parallax scrolling, it's fairly limited parallax (same repeating tile on faraway 'layer'), but I have an idea to work around to some extent that with tilestrips. Haha yep, no color clash with this rendering technique. It involves both beam-racing and using a form of double-buffer. So there are two screens, that do obey the Speccy limitations of only two colors in every 8x8 attribute square. But then we toggle betweeen which one is being displayed in sync with the raster beam, every 8 pixels horizontally starting from x=4, and also every 4 pixels vertically starting from y=4, and so that gives us an effective resolution of 4x4 pseudo-pixels, that can display any of the 8 color values with no color clash. What you see: An example of one of the real buffer screens, that is rendering the above display:

Had a little tinker with my shelved Speccy shmup prototype - looking at impact of adding AY music. General conclusion being that I'll barely have any cycles left over to do collision detection! So I suspect next will be looking if I can get more efficiency by running very basic 1 channel music, and then sound effects on the other two channels... The music here is a little basic remix I did of a couple of tracks by Chris Huelsbeck, from the game Apidya on the Amiga. The plan is to do: - an alternative method for drawing the player ship 'laser' - get some config of AY sound working that is performant enough to allow for full collision detection - write that performant collision detection So then I could have a single playable complete level+boss as a vertical slice proof-of-concept. Here's an older video showing sprites moving and some test collision detection code (no audio implemented in this one):

Oh, I’m sure you’ll crack it dude J

The app on Google Play is not an emulator, it's a simulator. Only MFME has the ability to emulate the machine using the original program ROMs. The app will actually teach you the secret / magic nudge setups - it plays a small guitar sample from 'Its a Kind Of Magic' by Queen when there is a magic nudge setup on screen (even if you don't have nudges that spin). There's a few of them! When you get nudges with that sound, see what the best win would be from say 4 to 6 nudges, use the first two nudges and then leave the machine and let the nudges time out. Don't be surprised if you get a few wrong and the machine just seems to nudge for ages towards nothing That way you get to learn them, rather than someone sharing a list (even if there is such a thing!) I'll also note that despite being a lo-tech player, I didn't even know the proper setups until pretty recently, and still managed some amazing results. I don't think the magic nudges are massively important - they are a 'quick win', but if the machine wants to go bonkers it'll still go bonkers, magic nudges or not. Conversely a dead machine will still be dead even If you know all the setups. It's not some magic way to make money

On a real Speccy it runs at a locked 25 FPS. It usually looks a bit stuttery on PC monitors that a frame locked at 60 FPS (but correct on a PAL TV running at 50 FPS, since 50 / 2 = 25 ) Bit of both man Writing code on a modern computer/monitor is better than the olden days. Those who could afford a second computer and an interface to inject the compiled code into Speccy memory did that, for some poor souls, they had to write on the same machine they were using to test, which must have been hellish! I'm currently using VS Code, and an emulator called ZEsarUX - which means I can actually debug the running code with breakpoints etc, which is crazy useful: And yeah, there's so much code and guides online, it's relatively straightforward to do the cool stuff like beam-racing multicolor without having to start from scratch. That said, all this leads to trying to do historically impossible things like this shmup Definitely think I'll end up having to compromise on the sound, though I think I might have figured out a way to make the collision detection feasible. Most of the CPU cycles are being burnt just to do the rendering, but I want to make it like a 'bullet hell' shmup with up to 16 enemy bullets onscreen, plus up to 8 enemies onscreen, then 2-6 player bullets. Thinking with some limitations on the background tilemap palette I can pull it off, by doing direct to screen color comparisons, which kinda gives us a free-ish version of hardware collision detection. The trick is to disguise the compromises/constraints into the style of the game, I think it might be doable

Compared to old ZX Spectrum game production newer games released seem so much better, technically at least, is this partly down to people sharing code and more powerful development tools? J

It astounds me what people can eek out of the ZX Spectrum’s fairly limited specs. This looks pretty damn cool!! Looks silky smooth J

Wow, that's on Speecy 128? Where's the colour / attribute clash? It's almost hard to believe it's a Speccy if the player character doesn't change to the colour of the whatever it passes over

That looks so pretty ! I like if the term is right, the parallex scrolling - and assuming the sprite is the top layer, the animated sprites on the middle layer of the fan going around. This looks very much like Ringo type graphics in terms of style - I would buy this when released if you released on Itch.io for a few quid.