Session end : 11h59m57s | Hide picture Sexe : OFF | ![]() | ![]() | ![]() | ![]() | Donations 2024 : 679.48 € |
I like old school coding, specially in assembrer, which make the old 8-bit systems ideal for me to create games.. but unfortunately I lack the artistic talent to create good graphics, let alone music. That's why I found interesting to make a Block Out clone..
But that didn't start with the Amstrad CPC.
Actually, I made a Block Out clone, named Blockaway, for mobile phones back in the mid 2000's, and later ported it to android phones. Blockaway is no longer on official websites but if you dig through google you may probably find it (as a .jar for old nokia-style phones, and as an .apk for android).
About two years ago I was wondering if it would be possible to make a Block Out clone for the ZX Spectrum, the computer of my childhood, so I decided to go for it. My previos experience was very helpful: I originally coded it using tabulated trigonometry (I don't remember if it was just for performance reasons or the devkit just didn't provide trig functions.. probably both) not just a sine / cosine table, but also a table to transform from cartesian to polar coordinates. As you can imagine, calculating trigonometry in real time would be too much for the good old Z80 processor.
Also, I already had the data to define all the blocks: that saved me time, even though I culdn't use all blocks and still I had to somehow "adapt" all data to work well on 8-bit systems. One little problem of this is that I had to reduce the precision of the tabulated values, causing deformations on larger blocks when rotating.
At first, I wanted It to be fully customizable but that would have been too slow and trick to implement, so I decided to stick to a fixed 5x5x10 board in order to make calculations simpler.
I used kind of "two threads" to run the game: One is interrupt driven and serves to provide timing regardless of the complexity of the hanlding of the block movement and rotarion. The other basically renders the graphics, but both threads perform other tasks as well.. and that is a problem, because sometimes the graphical data is not always consistent, causing slight glitches. Given the complexity (and dirtyness, I have to admit) of the code I decided to just leave it as is. I found it quite playable despite of the lack of color (that wouldn't be feasible on an Spectrum due to the color clash, you know..)
.. And now comes the CPC..
Well, I didn't own or have access to a CPC when I was a kid but not too long ago I checked the specs of the CPC 464 and gave me the impression it was an interesting machine, so I decided to port Retrobloc to CPC and take advantage of it's color-clash-less graphics modes. As you can imagine, large pieces of code were borrowed from the Speccy version, but most of it had to be adapted, and of course, all graphics code had to be redone.
On the Spectrum the blocks are drawn directly, and to erase them a backup copy of the board is redrawn (not the whole of it) before the next frame. This is relatively fast on an Spectrum since it uses 1 bit graphics. For the CPC I decided to draw the blocks on a "pixel list" so the previous list is erased pixel by pixel and the new list is redawn pixel by pixel as well, having all other calculations in between in order to have time to make it visible. I could probably have used a "double buffer" scheme but it seems the flicker is low enough to leave it the way it is.. and to be honest, I didn't feel like figuring out how to do it.
The reasons why I made it on mode 0 are:
- Less pixels to draw benefits performance
- More colorful
- Makes it feasible to use the pixel list method.. more on that later.
The drawbacks... well, only one and obvious: blockier graphics.
Regarding the pixel list drawing.. I decided to use one bit of each pixel to represent a white pixel for block drawing, so out of the 16 colors 8 of them are all white. That way, setting that bit to 1 makes the pixel white and setting it to 0 makes the pixel whatever color it was. Also, there is no need to redraw the board, which would take about 2.5 times longer than in the Spectrum version (the raster graphics memory of the spectrum is 6144 bytes long, compared to 16000 bytes long for the CPC). Obviously, this reduces the effective simultaneous colors from 16 to 9 (black, grey, white, RGB and CMY) but it's still a very nice amount of colors.
I started by coding the graphic routines and later on adapted the Spectrum code. I used the same "two threads" scheme which caused similar glitches o the CPC.. and unfortunately a new one: Sometimes a graphic byte (two pixels) gets corrupted. Not a big deal for playability but it would be a pain in the ass to fix it.
All in all, I think the result is decent, albeit a bit slower than the Spectrum counterpart, and way blockier (much more colorful on the other hand). It could be probably done better but it would be hard to improve performance. You may have probably noticed that the simple blocks rotate well but the larger ones rotate and move too slow when on the upper side of the board.
Well.. I think that kind of wraps it.. only one little fun fact: Atually, this is the first and only (for now) game for Amstrad CPC I've ever played.. guess I'm more of an Spectrumhead..
Best regards and greeting from Spain,
Jorge del Río / Krappygamez