Good question,
I think knightlore has to be up there, also Manic miner, (toon playing as u play was a breakthrough), Fairlight must be a nightmare to get in 48k, so many, and no brain this end to think of em....Great thread though.
Max.
On the other side, I remember being horrified that Manic Miner and/or JSW use LDIR for moving around display data. They kept a copy of the empty room, and for each frame they would LDIR that to a working space, then add the sprites, then LDIR to the main screen.
For us non programmers can you explain why using LDIR is so bad?
LDIR is an instruction that does transfer blocks of bits. What does manic miner do is:
a) Transferring (at least) 4096 bytes (two thirds of the screen) from a "void" level to a work area.
b) Drawing the sprites.
c) Transferring 4096 bytes from the work area to the screen.
Note that I'm assuming that the buffer uses only two thirds of the screen, and I do not account for the attributes...
That process is done every time the screen is redrawn.
The two transfers are very time consuming (although doing with LDIR saves some time, actually), and you need 8192 bytes of memory to use the method (4096 for the original "void" level, and other 4096 for the work area). That it's about 20% of the memory free in a 48K speccy, and about 80% of the memory free in the 16k speccy (providing you're using ALL the memory except the 6912 bytes of the memory screen... no system vars, no printer buffer...).
As you can see, the requirements are high. The approach in other games was drawing and erasing sprites in screen, to avoid the block transfers. It requires less memory and often less processor time.
I was there, too
An' you know what they said?
Well, some of it was true!
For us non programmers can you explain why using LDIR is so bad?
As Zup said, it was more about the wasteful large copies than the actual use of LDIR. It would have been more efficient to save and restore only the areas containing sprites, since most of the screen remains unchanged between frames.
I suppose the LDIR still could have been speeded up as an unrolled loop of LDIs, or the fancier stack copy method, but I think Manic Miner was released before people started to worry about things like that!
They're trying to tell you LDIR is a really slow way of transferring data about during a game, and buggers up your processor overheads. That's not to say Manic Miner isn't fantastic and a work of genius. It just could have been so much better. But, remember, it was writen in the early days.
As Zup said, it was more about the wasteful large copies than the actual use of LDIR. It would have been more efficient to save and restore only the areas containing sprites, since most of the screen remains unchanged between frames.
I suppose the LDIR still could have been speeded up as an unrolled loop of LDIs, or the fancier stack copy method, but I think Manic Miner was released before people started to worry about things like that!
At one point Mark Woodmass patched MM and JSW to use the stack copy method; it did increase the speed, but not very much.
One beneficial side-effect of using LDIR was that MM and JSW were two of the few games you could play at normal speed under emulation on a slow 386, by getting the host processor to do the LDIRs natively. That provided enough of a speed boost to make the games playable.
Well, having been involved with a few speccy games from the publisher's perspective, I'd have to say 'Bloodwych' on the Spectrum was an amazing coding job considering the restraints involved when compared to the 16-bit original. IIRC Philip Taglione ended up with just 7 bytes to spare when the game was running with the largest level data loaded up.
I'd also echo other people's comments re. 'Elite' and 'Robin of the Wood', and I'd throw 'Gyron' into the arena as well (pun intended!).
Just watching the bobby bearing tzx and admiring the beautiful programming involved. Which other games would you say had asthetic programming opposed to functional programming (even though this may still make a great game)
e.g. Starquake - beautifully programmed no flaws at all
Fairlight - brilliant game and well programmed but flawed - pauses in between screens, no sound, slows up too much etc.
Yeah he took ages to write ES and made sure it was really polished before he released it. Full Throttle 2 and Tai Chi Tortoise were a couple of projects he did that were for a bit of cash when he went to uni, not a labour of love like ES.
Michael has written a sequel, Worldshaker, in blitz basic, with hundreds of original blocks and features, its really good, I'll have to get him to release it. I was writing a speccy conversion and got about 75% of it written. All the engine, graphics and front end with tune are up and running but I abandoned it when I got a job as a teacher four years ago, lack of time etc. All that needs doing is the level data, I'll have to finish it these summer hols.
Can we make sure this post doesn't disappear into the internet ether please? This was shaping-up to be a fine little game. I can't believe there's that much more effort required to turn it into something really playable, even if it's just a jaunty little score-based shoot-em-up. The all important risk/reward element already seems to be in place - you risk time in the buggy to drill for jewels that give bigger scores, with the aim of each stage to simply drill all the jewels (and maybe have some other bonus items available that the player can drill for more score). Draw a bigger selection of enemy sprites, spread them over 20 stages, maybe have a few different power-ups appear when certain enemies are shot (dollar signs for score, temporary rapid fire, invincibility, temporary reverse controls, dual-way fire, smart bomb, etc.). Maybe even add-in a sub-game after each level to break-up the gameplay. Get Matthew Westcott to do some tunes, and Bob's your uncle!
Oh, and Fikee, about the 'R' register in the 'sound routines' / 'wait for fly back'...
Bit 7 of the refresh 'R' register is used as an interrupt 'flag'. If you set it it stays set or reset it it stays reset - no matter what part of memory is being refreshed at the time.
The 'flyback' interrupt routine sets the flag and I test for it each game loop to keep the timing constant and images flicker free.
But.
Instead of just waiting for the flag to be set I sometimes lock myself into a sound fx loop that only exits when the flag is set. This means that the time usually wasted doing nothing each game loop is used up doing sound processing instead.
I use bit 7 of the 'R' register because you can test for it quicker than doing any other flag test and speed is important in the middle of a sound loop...
ld a,r ; put the contents of the refresh register into the accumulator
; the plus/minus flag is automatically set
; no further instructions are necessary
ret m ; return if bit 7 is set
I always preferred Auf Wiedersehen Monty myself. It has a lot of nice features like the aeroplane flying sequences and the little missions you have to complete (e.g. taking the steering wheel to Monaco and fixing the ski lift in Austria). I always found it easier to play than Monty On The Run too, which was far too difficult, for me anyway. :)
Necros.
Yea i preferred Auf Wiederson Monty as well. I felt the graphics were slightly better than On the run. It's got a great 128K tune which also plays the national anthems when you visit different countries.
MAD Flunky has some really excellent graphics, quite funny too. But the controls are very sluggish and the game is almost impossible to complete without a complete solution (as is most DP games).
Where is good ol' Don Priestly these days?
Myth - A History In The Making is amazing for 48K, the lack of clash, the animation, the big monsters... The different weapons and the special effects like rain on some levels. You can just see the love put into it.
I don't think that's a good idea. It would spoil the flow of the game in a big way.
I think it would make the game more accessible. It wouldn't demand as much of your time in one go. Alternatively, you could perhaps have a password that stored your progress/location so you could come back to it later. This is something a lot of the bigger Spectrum games could have done with TBH.
Myth - A History In The Making is amazing for 48K, the lack of clash, the animation, the big monsters... The different weapons and the special effects like rain on some levels. You can just see the love put into it.
Comments
I think knightlore has to be up there, also Manic miner, (toon playing as u play was a breakthrough), Fairlight must be a nightmare to get in 48k, so many, and no brain this end to think of em....Great thread though.
Max.
For us non programmers can you explain why using LDIR is so bad?
a) Transferring (at least) 4096 bytes (two thirds of the screen) from a "void" level to a work area.
b) Drawing the sprites.
c) Transferring 4096 bytes from the work area to the screen.
Note that I'm assuming that the buffer uses only two thirds of the screen, and I do not account for the attributes...
That process is done every time the screen is redrawn.
The two transfers are very time consuming (although doing with LDIR saves some time, actually), and you need 8192 bytes of memory to use the method (4096 for the original "void" level, and other 4096 for the work area). That it's about 20% of the memory free in a 48K speccy, and about 80% of the memory free in the 16k speccy (providing you're using ALL the memory except the 6912 bytes of the memory screen... no system vars, no printer buffer...).
As you can see, the requirements are high. The approach in other games was drawing and erasing sprites in screen, to avoid the block transfers. It requires less memory and often less processor time.
An' you know what they said?
Well, some of it was true!
As Zup said, it was more about the wasteful large copies than the actual use of LDIR. It would have been more efficient to save and restore only the areas containing sprites, since most of the screen remains unchanged between frames.
I suppose the LDIR still could have been speeded up as an unrolled loop of LDIs, or the fancier stack copy method, but I think Manic Miner was released before people started to worry about things like that!
Si
http://myweb.tiscali.co.uk/frobush/saucer/Z80/Source/saucer.asm
http://myweb.tiscali.co.uk/frobush/saucer/Z80/Source/subs.asm
http://myweb.tiscali.co.uk/frobush/saucer/Z80/Source/contended.asm
http://myweb.tiscali.co.uk/frobush/saucer/Z80/Source/graphics.asm
http://myweb.tiscali.co.uk/frobush/saucer/Z80/Source/library.asm
http://myweb.tiscali.co.uk/frobush/saucer/Z80/Source/menu.asm
http://myweb.tiscali.co.uk/frobush/saucer/Z80/Source/debug.asm
http://myweb.tiscali.co.uk/frobush/saucer/Z80/Source/bigsprites.asm
http://myweb.tiscali.co.uk/frobush/saucer/Z80/Source/smallsprites.asm
http://myweb.tiscali.co.uk/frobush/saucer/pad2.bmp
Have fun!
*In best Alan Sugar/Donald Trump voice*
You're FIRED!!!
:D
Sorry to hear that though. I was hoping we'll have a Smifff game after all these years!
Bytes:Chuntey - Spectrum tech blog.
Well, Firefly 2 is on the cards, just after I finish Super Amidar!
At one point Mark Woodmass patched MM and JSW to use the stack copy method; it did increase the speed, but not very much.
One beneficial side-effect of using LDIR was that MM and JSW were two of the few games you could play at normal speed under emulation on a slow 386, by getting the host processor to do the LDIRs natively. That provided enough of a speed boost to make the games playable.
I'd also echo other people's comments re. 'Elite' and 'Robin of the Wood', and I'd throw 'Gyron' into the arena as well (pun intended!).
One brilliant game was Earth Shaker by -- erm -- your brother IIRC...
misteaksmistrakesmisyaleserrurs— oh, sod it.Michael has written a sequel, Worldshaker, in blitz basic, with hundreds of original blocks and features, its really good, I'll have to get him to release it. I was writing a speccy conversion and got about 75% of it written. All the engine, graphics and front end with tune are up and running but I abandoned it when I got a job as a teacher four years ago, lack of time etc. All that needs doing is the level data, I'll have to finish it these summer hols.
Can we make sure this post doesn't disappear into the internet ether please? This was shaping-up to be a fine little game. I can't believe there's that much more effort required to turn it into something really playable, even if it's just a jaunty little score-based shoot-em-up. The all important risk/reward element already seems to be in place - you risk time in the buggy to drill for jewels that give bigger scores, with the aim of each stage to simply drill all the jewels (and maybe have some other bonus items available that the player can drill for more score). Draw a bigger selection of enemy sprites, spread them over 20 stages, maybe have a few different power-ups appear when certain enemies are shot (dollar signs for score, temporary rapid fire, invincibility, temporary reverse controls, dual-way fire, smart bomb, etc.). Maybe even add-in a sub-game after each level to break-up the gameplay. Get Matthew Westcott to do some tunes, and Bob's your uncle!
Mike.
i don't understand the whole thing with R register in WaitVBlank and beeper routines. could you explain it ?
ahhhhh Joff, what happened? How the masses will mourn.
Cor blimey!
Oh, and Fikee, about the 'R' register in the 'sound routines' / 'wait for fly back'...
Bit 7 of the refresh 'R' register is used as an interrupt 'flag'. If you set it it stays set or reset it it stays reset - no matter what part of memory is being refreshed at the time.
The 'flyback' interrupt routine sets the flag and I test for it each game loop to keep the timing constant and images flicker free.
But.
Instead of just waiting for the flag to be set I sometimes lock myself into a sound fx loop that only exits when the flag is set. This means that the time usually wasted doing nothing each game loop is used up doing sound processing instead.
I use bit 7 of the 'R' register because you can test for it quicker than doing any other flag test and speed is important in the middle of a sound loop...
ld a,r ; put the contents of the refresh register into the accumulator ; the plus/minus flag is automatically set ; no further instructions are necessary ret m ; return if bit 7 is setYou have 2 months. Any longer and we'll send out the massive!
;-)
Yea i preferred Auf Wiederson Monty as well. I felt the graphics were slightly better than On the run. It's got a great 128K tune which also plays the national anthems when you visit different countries.
Where is good ol' Don Priestly these days?
Do you mean levels as in clumps of rooms per level, or like Manic Miner (single screen at a time)?
Necros.
Necros.
OH! God No! You'll be saying Frightmare next :p