Dragon's Lair appears on the Sinclair ZX81!

[Neil79]

This amazing demo was created for the ZX81 and shown exclusively at the Retro Computer Museum Valentine's Event 2015 at Snibston Discovery Centre in Leicester. It's incredible to see a game such as this on an 1 kB-16kb memory system so hopefully we see a release this year!

Indie Retro News: The latest free games, indie games and retro news: Dragon's

[sigh]

 

WHAT?!?! WAIT?? HOW??!?!?

This is probably one of the most amazing things I've seen on an 8 bit machine.

[MacDeath]

what extra hardware is needed ?
I bet it needs some Hard disk sort of thing or massive ROM/RAM.
And it is just a demo, it's like playing a movie in low resolution monocolour.


Jim Bagley...  ok I remember his speccy ports, some weren't too bad.

[sigh]

what extra hardware is needed ?
I bet it needs some Hard disk sort of thing or massive ROM/RAM.
And it is just a demo, it's like playing a movie in low resolution monocolour.


Jim Bagley...  ok I remember his speccy ports, some weren't too bad.

They said that it will be actually playable.

[Neil79]

They said that it will be actually playable.

It's the full version demo'd on the ZX81, it will be fully playable this year 

[Baggers69]

Hi guys, thanks for the comments.
It's a standard 1K ZX81 with the ZXpand which gives it more RAM and access to an SD card.
On the ZX81 the Z80 has to generate the TV display also, so most of it's processing time is taken up by that.
The 256x192 bitmap screen is 6K the stream is 128x96 so 1.5K per image is streamed per frame.
Code is about 1K.

[Gryzor]

I don't see why it couldn't be fully playable; given the nature of the game all you got to do is scan for the correct input at the correct time window and load the corresponding scene.

I like it even without sound (so, losing a lot of its cinematic appeal) it's a clever way to show how you can shoehorn something down to a very lowly machine!

[TFM]

Well, the speccy has a small screen RAM size. So it's pretty easy to play full screen stuff. Of course this was done before for CPC's too.

To make it interactive one just has to switch to the next file to play.

On CPC side this should be no problem at all using X-MASS f.e.

[MaV]

... the speccy ...

ZX81. And that's why the game is quite a feat, because hi-res is difficult. Of course, it would not be possible without the ZXpand as a mass medium, but still an achievement.

[MacDeath]

Yeah, the game is mostly Data-pushing into video... so any fast HardDisk like solution can suffice.
That's the beauty of those modern Mass Data solutions : we can see the true potential of humbly awesome Z80 systems from 30 years ago.

Wasn't possible with Tapes and very low RAM/ROM/Flash capacities of the time...

Also here we can see the "gamezone" is not really in full screen... this must really help. I mean, it is in 1bpp.
Wasn't Spec... I mean ZX81 basically a monocolour ZX speccy with actually even less inbuilt RAM and perhaps not even a buzzer ?

I guess a Speccy48 with proper added SD card access (HDD/SSD like solution) could perform quite well in monocolour as well, with even bigger playscreen size.

A CPC trying this in 160x200xmode0 would really have a hard time to get into 5 frames per seconds...



questions : Video Reading performances on CPC : what are the well obtainable specs ?
Resolution, frames per second, rest of machien time for sound, controls and code...?

As usual, CPC wouldn't perform as fast as Speccy because, well... twice the bits per pixels (discounting atributes) in classic speccy port sized screen (256x192 or 128x192), actually even 4x times more bits per pixel if you consider the 192x256xmode0 humongus 24k sized screen.

I saw some nice video readers on both SymbOs and FutureOS...they mostly use HDD like solutions.
could this technology be applied to such interactive movies as Dragon's Lair / Space Ace ?
In, say... double or Triple Buffering perhaps, even quad buffering ?

I guess some sequences could/would be optimized on order to have some zones not changing if colours/tiles stay the same, but still... So a lot of precalculating and Data pushing optimisation would be in order.

Biggest job would be to convert the whole movies into a nice compression so it would be optimised.

Also : don't you mind if I post the video here as well :

[Prodatron]

I don't see why it couldn't be fully playable; given the nature of the game all you got to do is scan for the correct input at the correct time window and load the corresponding scene.

Yes, the magic behind the original Dragons Lair is quite simple and has a nice effect It's already implemented in the SymbOS VID format:

;### 128 byte frame header
frminfbeg
frminfxln   dw 0    ;frame width  (only valid, if movinfdyn[bit0]==1)
frminfyln   dw 0    ;frame height (only valid, if movinfdyn[bit0]==1)
frminfmod   db 0    ;screen mode  (only valid, if movinfdyn[bit1]==1)
frminfcol   ds 2*16 ;colour table -> 16 x 12bit cpc plus colours (only valid, if movinfdyn[bit2]==1)
frminfsiz   dw 0    ;size of this frame in bytes without header  (only valid, if movinfcrn!=0)
frminfact   ds 4    ;byte0=action -> 0=continue playing, 1=stop movie here (byte1=reason), 2=jump to frame [byte1-3]
frmkeynum   db 0    ;number of possible keys (0-8)
frmkeyfrm   ds 8*4  ;keycode (1byte) + destination frame (24bit)
frmtitact   db 0    ;0=don't change last subtitle, 1=delete last subtitle
frmtitdat   ds 128-frmtitdat+frminfbeg  ;subtitle data (maximum is about 50 bytes)
                    ;-> 1 byte=text length (0=data terminator), 1 byte=language id, x bytes=text

So if anyone is interested in helping with converting Dragons Lair to the CPC just tell me.

[Prodatron]

A CPC trying this in 160x200xmode0 would really have a hard time to get into 5 frames per seconds...

No, when reading from FAT32 you get about 7-8fps for 16K frames:

[MacDeath]

Also, because you are not alone in this thing :








Damn you germans are so creepy... 

Also don't forget the possible benefit from Play-City extra sound capabilities.
could it stream sampled sounds as well during a big video streaming ?



Also those videos are in Mode1 with heavy ditherings... I guess each frame is fully loaded and unique... as I told, some more cartoonish render in mode0  may sometimes enable for actualy more smooth frame sequances, provided ther is a fixed background, and some larges zones not really changing from frames to frames.

Gotta remember the way Dragon's Lair or Space ace lost a lot of details in translation into ST/Amiga, but still were impressive.

A bit like modernly compressed videos...
Of course some transitions or sequances wouldn't be able to gain with this, but some other would definitaly.


Not sure how all your streaming things are done, but a clever mix of the two techniques may be nice I guess, yet this would need a lot of work in the making of the movie file.


BTW, couldn't find Atari ST lngplays...

Amiga :


Arcade :


MegaSTE with HDD (must be Atari ST compliant anyway)


MS-Dos EGA :

yeah yeah... fixed palette and beeper can be bitches...

due to the large difference in Hardware from the Arcade, the 16bits performed quite well indeed.

I mean, the Arcade read from CD... this wasn't available until early 90's on some consoles and then computers...
CD-ROM got democratized around 1992-1993 if I remember well... perhaps actually a bit after, on computers.

So yeah, far less sequences with actually dynamic scrollings or camera effects, more fixed background cell with overlayered Cell, a bit as real old school anitation films...

And as those versions were most probably cross ported, larges differences in graphics (despite using same graphics most of time) due to palette issues (EGA per exemple).

The Floppy tech at its best... with computers in 512K (or 640k or 1024k at best)...



I remember when CD-Roms started... they couldn't even imagine how they could fill so much space... just like when VGA was democratized... they couldn't understand what to do with 256 colours, jsut like when Atari ST was released... it was a huge gap compaired to attributed very low resolution palette extremely limited 8biters from jsut before... took a few years to have real impressive 320x200x16 graphics.

Even CPC was really powerfull at release, they simply had no tool to do proper stuffs while in 1900 until now we can see its true potential.
And it was plagued by poor graphic ports from other systems (inadequate palette when trying to straightly port C64, inadequate speccy when porting speccy into CPC... ouch)


so...yeah... let's dream again.

[TFM]

Samples are really consuming a lot of time. So it's better to either show a movie and play AY + PlayCity _OR_ show somthing with few animations and play a sample.


You could "wire" the code together, but it's always a trade off some how. But that's the fun in doing it then nevertheless. 

[MacDeath]

Also I guess a "video oriented" strip poker could really be great...

Need to find a convincing and compliant" model an do some personal movie sequences perhaps, to port it in a CPC friendly format... then... well... add some poker and artificial intelligence to that.


Really, the potential of modern Data technology is a blessing for old computers.
Hope it doesn't kill prematurely the CPCs to have some much data flows... would it ?
Would be need to add radiator on those Z80 and ASICs and Gate arrays ?

[TFM]

Well, as long as the model of your choice holds a CPC6128 keyboard I'm totally fine with your idea. 

[MacDeath]

(when I told germans are creepy...)




(should be great port on PCW16 or even classic PCW...)

[Prodatron]

Also, because you are not alone in this thing :

Yes, nice special examples, too, though one is an Emu-only feature (nothing real), and the other requires 4MB + full prebuffering and therefore very limited regarding the video length.
The best way is to use a mass storage interface (IDE or something like this) to play any kind and any length of video at once.

Also those videos are in Mode1 with heavy ditherings... I guess each frame is fully loaded and unique... as I told, some more cartoonish render in mode0  may sometimes enable for actualy more smooth frame sequances, provided ther is a fixed background, and some larges zones not really changing from frames to frames.

That's a good question. Back in 2004 Trebmint and me tried different ways to use compressed/"diffed" video data to make loading frames from harddisc faster, but it didn't increase the speed at all for "high-resolution" stuff. If you have the data already in ram you can decrompress/dif it quite fast, but the combination of loading from HD + decompressing it on the fly doesn't seem to bring any improvements for the speed compared to raw-loading it from HD directly into the video ram. TBH we didn't invest too much time in it, so maybe there are still some possibilities, especially if you already include the decompressor into the low-level-sector routines. I don't remember how less of the picture has to change (much less than 50%) to get a speed improvement while loading.
On the other hand 7-8fps is already quite nice for 16K frames, and it could be improved by lowering the resolution a little bit without loosing the linear frame buffer by decreasing CRTC register 9. 8K frames at 15fps + AY sound could be quite cool?

CU,
Prodatron

[MacDeath]

I wasn't especially talking about compressed datas uncompressed during copy into "VRAM"...

was also thinkking about the compression that lets chuncks of picture staying the same.
Like the visual artefacts with old compressed mpeg vids... I guess.



I know this demo is a bit slow and so on, but actually only the shape changes, the surfaces stays from frame to frame until changed... this enables for a lot of content in less RAM.
Not usable in real movie in heavily dithered realistic Mode1, but cartoonish Mode0 could...


actually a mix of streaming and tile based engine.

If you look at 16bit conversions from Dragon's lair, you clearly see the fixed background and animated cells overlayered on those... like real Animation cartoons...
With such fixed backgrounds, you loose cinematic effects (scrollings and so on) but gain... well... most of time less than half of the screen is actually refreshed...

Of course to have a proper Hardsprite layer wouldn't hurt...


But yeah, to produce a nice thing woudl mean to actually cleverly mix between each different techniques.

I mean, like in real animation or cinema, or any artistic media : you have to craft with different techniques, according to what you want to render...

A scrolling/travelling sequence ?
A fixed sequence ?
dark shadowy or bright sequences ?
transitions ? visual effects ?

a good exemple of Cinematic heavy games... SCUMM games like LOOM and most especially Monkey island.

Most sequences are pretty standard, but you would have some big animated things sometimes just for one sequence or special sprites just for one scene.



But yeah, those are more generic conceptions, not just "Dragon's Lair port" oriented ideas.

I soemtimes feel that a moden medium or even long movie fully produced in 8bit graphic specifications but still with modrn tools help could get quite an appeal, but would also means a lot of lot of work as any traditional animation work.

still to have a low resolution, limited palette and some classique computer animation tricks could actually be usefull.


(dreamer mode)


Remember the effect you had first time you saw "Another World" ?


There are quite some video clips in pseudo pixel art, this is awesome :

Warning : graphic content... T_T

oops, sorry I reviewed it and it is not quite... suitable, ask and I remove it...





(yeah this one is a pure creepy visual porn of awesomness)

But I doubt old school machines could actually display this, maybe wrong though.
seems to have too many colours than possible on those 256 colour max things of the past...


I like the way they redo some pixel art flavour liek that, But I guess it would be even more cooler if they stuck to real old machines specifications.


For this I guess soem Amstrad PLUS 192x272x16 (rasters, some hardsprties patches here and there) could really be quite enough for a great visual.

Batman Demo was really great in that it really included "animation" sequences rarely seen on CPC.


Mixed a lot of visual techniques, video modes, and wasn't all about hardware effects.

[Prodatron]

was also thinkking about the compression that lets chuncks of picture staying the same.
Like the visual artefacts with old compressed mpeg vids... I guess.

I know this demo is a bit slow and so on, but actually only the shape changes, the surfaces stays from frame to frame until changed... this enables for a lot of content in less RAM.
Not usable in real movie in heavily dithered realistic Mode1, but cartoonish Mode0 could...

Yes, this is exactly the opposite of "high resolution" I was talking about. It's very impressive for such specific demos but not a choice for real videos like the Dragons Lair clips. Anyway, what's the problem, a SF2/X-MASS based video would probably have a similiar speed

[MacDeath]

But an X-Mass can enable massive rely on multi-loading, while this demo only used the native 128K of the CPC6128...
Also I guess this video spoils some CPU cycles and ressources because of the masked sprites overlayed (the dirts on the screen).
I'm pretty sure the same effect done with hardsprites from a PLUS would imply a massive gain in RAM and other ressources...
Same with the background raster effects.
Some cartoon animation would perhaps not rely on those things.

Back to singe's castle.
With a clever mix of the X-MASS and X-MEM there may be a huge gain in animation for each sequences, despite having a few seconds between each different sequences I gues (or not ?)

That's why I ask to you all who already did some tries at videos on CPC... always interesting to know the actual limitations and tricks.


is it better to pre-store into the 444k RAM disk some elements ?

main RAM (the main 64k) are important because you need to have screen video and perhaps sounds as well in those (not sure if so with PlayCity though).

But extra RAM banks can store the code, lists and tables as the Z80 can access extra banks, while Video and built-in sound cannot if I remember well.

Gotta remember that what graphic content (and sound) a 512K 16bit machine in 320x200x16 can store, a CPC would need half the datas for same screen surface, and mode0 can quite well have some sweet enough gorgeous looking screens...

Well used CPC/PLUS can actually compete with badly use Atari ST or badly ported EGA.
(instead of being a speccy poor parent)


or even CGA...



Warning graphic contents.. oops...
couldn't find any video of this game in CGA though... not sure I miss something.


also :





EGA (ouch, epic palette fail) :


VGA :


No wonder everybody switched to VGA soon after 1991...

Also, Guy Spy, somewhat in the same vein...
Guy Spy and the Crystals of Armageddon (1992) screenshots - MobyGames

[Prodatron]

The first 64K is only required for the video display, only this area can be addressed by the CRTC. Sound is I/O port based (even the internal one , there is no memory mapping on CPC).
When streaming movies from harddisc directly into the video ram there is no need for additional buffers in memory, so the extra 512K are not used especially for the video data, they are free for anything else.
I am sure such an original Dragons Lair port would only require a 464 + X-MASS, nothing else.