People are still making stuff for the Sinclair related machines. Tell us about new games and other software that runs on the Spectrum, ZX80/ZX81, Pentagon and Next.
It almost looks too detailed ... but it does look good.
It is very nicely drawn and detailed as you say but for me it's too much monochrome. The original is more colourful
and maybe simpler but somehow nicer, at least for me.
I played it briefly but didn't know what I should do.
Are you supposed to open all doors and collect all stuff in one location and then move to another one through door? Or should you
work at many locations at the same time?
And how can you fight with enemies? What fire button does?
It almost looks too detailed ... but it does look good.
It is very nicely drawn and detailed as you say but for me it's too much monochrome. The original is more colourful
and maybe simpler but somehow nicer, at least for me.
I played it briefly but didn't know what I should do.
Are you supposed to open all doors and collect all stuff in one location and then move to another one through door? Or should you
work at many locations at the same time?
And how can you fight with enemies? What fire button does?
Have you never played an origional version, Rafal?
You must open all doors in every screen and take all treasures (125 pieces total).
You can't fight with enemies, you can use FIRE button if you go from one screen to another via system of doors.
And I must say this version is much more playable than original title. Especially if you can stand on ladders safely, if some pirate is approaching.
R-Tape wrote: ↑Mon Apr 08, 2019 9:46 pm
Yes - cool demo. I like the jiggery-pokery (or should get be jiggery-PUSHery?), but the graphics are most impressive.
I couldn't even really see the attributes scrolling either though, really smooth. Having said that, I might be one of those people with low fps eyesight.
DouglasReynholm wrote: ↑Mon Apr 08, 2019 11:48 pm
I couldn't even really see the attributes scrolling either though, really smooth. Having said that, I might be one of those people with low fps eyesight.
I thought the same thing, but your eyes are fine - that's a multicolour scroll, so it IS that smooth.
Yes, there is multicolour in several places in that demo. The scroll which we are talking about seems to use 8x2 multicolour, that is an attribute is assigned to 8x2 pixels area.
Wouldn't be so impressive as it was done several times before and even Nirvana engine uses 8x2 multicolour in full screen mode and here we have it only on a part of the screen.
But think about the scroll. Each frame it has to read and write both graphics and attributes. A lot of work, a lot of PUSH/POP stuff.
Maybe similar stuff was done before. Check Eye Ache 2 demo (below) But it's still impressive as hell, especially if you know the limitations. https://www.youtube.com/watch?v=6_27EJjjt48
There are a lot of LDIs and plain LDs in there as well. It looks like the PUSHes are mainly used for the parallax bars and the multicolour scrollers (the text on the right-hand side of the screen is also a multicolour scroller).
They've got an interesting attribute scrolling routine: due to the lack of registers available, it doesn't use a loop counter to detect when it reaches the bottom of the screen, but instead does a RET with SP pointing to a table of code addresses. This way the PC will normally just advance to the next unrolled loop iteration, but goes somewhere else when the loop is done. (I suppose there's some reason why a self-modifying JP wouldn't work?) PUSH AF is used to draw the first two columns, as only 15 columns are actually visible and the first is always black. (The routine doesn't modify any flags so F is always zero, but maybe this isn't necessary if the underlying bitmap is invisible?)
Did this one back in January, mostly so it could be converted to Amstrad and Commodore. It's a standalone version of one of the embedded mini-games from Microfair Madness 128K.
Scrolling multicolour attributes is fairly easy - you have to redraw all the attributes every frame anyway, so changing what is drawn isn't usually much of a problem. My first multicolour demo scrolled. The trick is updating all the pixel data to match, which I didn't do - I just used a patterned background and let the attributes roll over it, with the occasional sprite drawn in during top-border time then erased in bottom-border time.
In this demo, it's only half the screen width (or less) like 8x1 multicolour, but it's actually 8x2 attributes. That means for every two lines of the screen being displayed, it can (a) change one line of attributes and (b) re-write one line of pixels. That achieves 8x2 multicolour with half the pixels re-drawn; the other half must be re-drawn during top & bottom border-time.
What inhibits scrolling is if all the addresses for each line of the multicolour routine are hard-coded; that makes them harder to change. Nirvana does this out of necessity, to have time to re-write the whole row of attributes. My River Raid scroller encoded the address of the next line of data after each row of attribute data, so it could be obtained with an extra POP. So you could point your multicolour processor to any line in the buffer, and it would not only display the buffer from that point on, but automatically wrap-around, from the bottom of the buffer to the top. But then it wasn't as wide a multicolour band.
As for terminating the colours conditionally, the Buzzsaw+ menu does something like this. It's a loop, and at then end of the colour buffer, the FLASH bit is set in a last dummy line of the attributes, which is POPped into AF, thus setting the SIGNED flag in F straight away, so a simple RET M will then exit. (Actually what I do is run onto a second multicolour routine, that splits the colours on the bottom row to show the high-score, then exit after that). But it's an efficient way of doing looped mutlicolour rather than unrolled as you don't need to DEC or even test a value - the flag is set during the POP of the colour data.
Thanks for the explanations, it's always intriguing to hear about stuff like this.
(Derailing the topic further) I was just reminded of this (mostly) full-screen multicolour scrolling demo that looked quite promising. Only the author pre-calculated everything on a PC beforehand and it's non-interactive. It would be really cool if something like that were able to run in real time, but I guess it would be too much for the Speccy to handle.
EDIT: Interesting game too, reminds me of Scuba Dive. And the tiny sprites are quite nicely designed.
djnzx48 wrote: ↑Tue Apr 16, 2019 11:27 pm
It would be really cool if something like that were able to run in real time, but I guess it would be too much for the Speccy to handle.
That's a different technique isn't it? The tech demo is using 28 columns of the screen and it's doing horizontal scrolling as well. Granted, it's not 8x2 multicolour or even 8x4, but surely it's a lot of work doing all that pixel scrolling at 50fps?
Horizontal scrolling isn’t difficult as far as color attributes are concerned if the background is just solid black. You just need to swap the ink and paper colors at cell boundaries. The scrolling itself at 50 fps is pretty impressive, I agree, but the active window size is fairly small.
Hikaru made a truly impressive horizontal scrolling multicolor demo soon after we sorted out the floating bus business: