Thanks! I still enjoy playing this game on my Amstrad CPC, and like the C64 & ZX Spectrum versions too. I even drew out my own map for the CPC version as a teenager, so as to find the teleporter rooms easily.
Semi unrelated info.. I used to like 4x4 tiles in regular character mode for none-diagonal/8-way scrolling maps. If I assigned each 4x4 block it's own unique colour in colour ram, you could optimise the colour scroll by only copying 4 bytes of data out of the 16 to the left/right/up/down, depending on the scroll direction, as the other 12 would keep the same colour information. This worked best in games that scrolled one direction like Commando or R-Type. I probably didn't explain that very well after 30+ years away from 6502.
Makes sense to me :) SEUCK is an example of a game (engine) that does that kind of minimal colour RAM update for its 5x5 tiles. When it scroll vertically it just copies a row and then skips ahead five rows for the whole screen.
Have you ever analysed how Spindizzy stores its map? The game is huge and each screen seems to be pretty unique, not just big chunks of larger tiles (but never looked myself). And of course each screen has angled tiles too and sections on top of others. I'd love to know how that game works.
Spindizzy (1986 Electric Dreams) is using a multicolour bitmap screen, not a character screen, at memory address $e000. Between screens there seems to be a lot of calculation going on into memory around $ab00 to $b600 as well. I'll look into this in more detail later. :)
@@jmp01a24 It seems like so many coders ended up being scammed by the publishers. When the publisher can simply pretend sales didn't occur and pay nothing, it's pretty disgusting really. Or simply stop replying to them.
@@jmp01a24 I haven't found the article you speak of so far but did find this quote from Paul Shirley when asked, "What was the coolest part of the game, technically speaking?" Paul replied: "The level coding structures. Levels are "sculpted" with an internal interpreted script. It's more like programming than anything else. Fitting 386 levels into 11K was satisfying."
Assembly has fascinated me since the days of inputting seemingly endless Data statements in Basic programs. I still have little clue how it works, and have the utmost admiration for those that do. Starquake was one of my favourite games back in the day and does indeed seem a little better than the Spectrum version. A question (unrelated to Starquake) - was there a technical reason why there were no conversions of Ultimate games such as Knightlore or Alien 8? Did the Spectrum have an edge over the 64 with this style of game, or was it purely commercial?
Knightlore and alien 8 have now both been converted to the c64, so the decision was essentially commercial. The stamper brothers knew z80, some claim there is a benefit to z80 over 6502 in how these games work & lots of spectrum games were only single color while almost no c64 games were and that could affect sales. They could have tried to adapt it to multicolor mode, like last ninja, but they were making lots of money from the spectrum and it would have been a huge risk. They knocked out a load of games based on their isometric engine, sold the company and moved to the more lucrative console market. Prior to making spectrum games, they wrote some games for arcade machines. They followed the money. The c64 games released on their label were (as far as I know) just published by them and the developers just approached them with a finished game.
Well given there were isometric style C64 versions of other similar games, it's certainly technically possible. It was probably just down to commercial aspects.
property about 800ish (play area was 38x20) bytes per level or around. Intermission is about 14x10), and there was 20 levels. Not a memeory issue at all. But clewer done. Levels may been compressed eventuelly.
Great stuff! Twelve bytes are used for the layout of each screen, but that is not all, is it? Few additional must have been spent for enemy and objects information... Maybe 16 bytes in total, which would take 16 x 512= 8Kb for the whole map?
Yes, there is some extra data for object positions, there is some special case drawing code for the reactor core, all of this adds up. The enemies could be "random with seed" or could be specified per screen, I've not looked at that in detail yet.
Thanks! I still enjoy playing this game on my Amstrad CPC, and like the C64 & ZX Spectrum versions too. I even drew out my own map for the CPC version as a teenager, so as to find the teleporter rooms easily.
Thanks a lot (again) for this really cool stuff. such exploration is always a real pleasure to watch and so stimulating :)
Thank you again for the support. :)
I liked this game! Tried to draw the map in my childhood, but never be able to reach all zones :D
You and me both!
Great stuff, as always, Martin!
Glad you enjoyed it
Semi unrelated info.. I used to like 4x4 tiles in regular character mode for none-diagonal/8-way scrolling maps. If I assigned each 4x4 block it's own unique colour in colour ram, you could optimise the colour scroll by only copying 4 bytes of data out of the 16 to the left/right/up/down, depending on the scroll direction, as the other 12 would keep the same colour information. This worked best in games that scrolled one direction like Commando or R-Type. I probably didn't explain that very well after 30+ years away from 6502.
Makes sense to me :) SEUCK is an example of a game (engine) that does that kind of minimal colour RAM update for its 5x5 tiles. When it scroll vertically it just copies a row and then skips ahead five rows for the whole screen.
@@MartinPiper6502 That said, on the Amiga, I used 16x16 pixel tiles (2x2 in C64 terms for non-programmers that may be reading this)
Have you ever analysed how Spindizzy stores its map? The game is huge and each screen seems to be pretty unique, not just big chunks of larger tiles (but never looked myself). And of course each screen has angled tiles too and sections on top of others. I'd love to know how that game works.
@@Codetapper good idea. I'll add it to the list.
I actually reverse engineered spin-dizzy back to source code on the Amiga! It has a built in map editor and doesn't compress it's maps (on the Amiga).
Spindizzy (1986 Electric Dreams) is using a multicolour bitmap screen, not a character screen, at memory address $e000. Between screens there seems to be a lot of calculation going on into memory around $ab00 to $b600 as well. I'll look into this in more detail later. :)
@@jmp01a24 It seems like so many coders ended up being scammed by the publishers. When the publisher can simply pretend sales didn't occur and pay nothing, it's pretty disgusting really. Or simply stop replying to them.
@@jmp01a24 I haven't found the article you speak of so far but did find this quote from Paul Shirley when asked, "What was the coolest part of the game, technically speaking?"
Paul replied: "The level coding structures. Levels are "sculpted" with an internal interpreted script. It's more like programming than anything else. Fitting 386 levels into 11K was satisfying."
I'd love to see a 2nd part where you carve out all 512 levels with python code.
@@mariadelossantos1960 good idea!
Assembly has fascinated me since the days of inputting seemingly endless Data statements in Basic programs. I still have little clue how it works, and have the utmost admiration for those that do. Starquake was one of my favourite games back in the day and does indeed seem a little better than the Spectrum version. A question (unrelated to Starquake) - was there a technical reason why there were no conversions of Ultimate games such as Knightlore or Alien 8? Did the Spectrum have an edge over the 64 with this style of game, or was it purely commercial?
Knightlore and alien 8 have now both been converted to the c64, so the decision was essentially commercial. The stamper brothers knew z80, some claim there is a benefit to z80 over 6502 in how these games work & lots of spectrum games were only single color while almost no c64 games were and that could affect sales.
They could have tried to adapt it to multicolor mode, like last ninja, but they were making lots of money from the spectrum and it would have been a huge risk. They knocked out a load of games based on their isometric engine, sold the company and moved to the more lucrative console market.
Prior to making spectrum games, they wrote some games for arcade machines. They followed the money.
The c64 games released on their label were (as far as I know) just published by them and the developers just approached them with a finished game.
Well given there were isometric style C64 versions of other similar games, it's certainly technically possible. It was probably just down to commercial aspects.
Knightlore did eventually get a C64 version :) ruclips.net/video/QuCFHThI-zQ/видео.html
interesting to see how they stored the map :) Didn't boulderdash have a really cool system for storing big levels too? :)
I'll look into it
property about 800ish (play area was 38x20) bytes per level or around. Intermission is about 14x10), and there was 20 levels. Not a memeory issue at all. But clewer done. Levels may been compressed eventuelly.
Great stuff! Twelve bytes are used for the layout of each screen, but that is not all, is it? Few additional must have been spent for enemy and objects information... Maybe 16 bytes in total, which would take 16 x 512= 8Kb for the whole map?
Yes, there is some extra data for object positions, there is some special case drawing code for the reactor core, all of this adds up. The enemies could be "random with seed" or could be specified per screen, I've not looked at that in detail yet.