62 replies to this topic

[Pixelboy]

opcode, on Fri Dec 12, 2008 11:59 AM, said:

Btw, there is another problem: I had said that the original movie was 12 frames/s. That isn't completely true. Most the time animation is indeed 12 frames/s, but during some segments it is 24 frames/s. So probably I would also need a tool to blend frames together.

Can't you just skip every odd frame?

[opcode]

Pixelboy, on Fri Dec 12, 2008 1:19 PM, said:

opcode, on Fri Dec 12, 2008 11:59 AM, said:

Btw, there is another problem: I had said that the original movie was 12 frames/s. That isn't completely true. Most the time animation is indeed 12 frames/s, but during some segments it is 24 frames/s. So probably I would also need a tool to blend frames together.

Can't you just skip every odd frame?

That's what I am doing with the gif files, but I am afraid that animation quality could suffer...

[opcode]

Ok, time for some very heavy technical stuff...

Lets start with a NTSC ColecoVision (60Hz):
Z80 Frequency: 3,579,545
Scanlines per frame: 262.5
Active scanlines: 192
VBlank scanlines: 70.5
Z80 cycles per frame: ~59,671
Z80 cycles per scanline: ~227
Necessary delay between VDP accesses during active display: 28 cycles
Maximum number of VDP accesses during active scanline: 227/28 = 8 -> 1.5KB for all 192 active scanlines (worst case for 262 scanlies -> 2KB)

Sound:
1 sample/scanline -> 262 lines x 60 frames = 15.35kHz

So, total transfer rate from CF:
- video: 9KB/movie frame x 12 movie frames = 108KB/s
- sound: 15.35KB/s
- Total: 123.35KB/s

All would be fine if it wasn't for the game logic. The movie format is 256x144, which needs to be loaded during 5 frames. That means 28~29 movie lines per frame. A movie line is 64 bytes long (32 bytes pattern, 32 bytes color), so we need 1856 VDP transfer per frame, plus 262 audio transfers per frame, for a total of 2118 transfer. Now supposing that each transfer takes 28 cycles (which isn't always true), we get 59,304 CPU cycles per frames. Very close to the total available cycles per frame. Now, if I can get 9 transfers per scanline (8 bytes for video and a byte for sound), then I would reduce the number of used cycles to: 232 scanlines worth of video/audio * 227 cycles/scanline + 30 scanlines worth of audio only * 28 cycles (worst case) = 53504 cycles.
That gives us 6,000 free cycles per frame. If the code is broken into 5 pieces (because we need 5 frames for each movie frame), that would give us 30,000 free cycles per movie frame for game logic. That is basically half of the total CPU cycles we normally get per frame, which is reasonable for a simple game like DL.
While I believe the video player would be fairly simple to implement, integrating the player with game logic and still keeping everything in sync would be quite a challenge, though an interesting one...

[Pixelboy]

Sounds doable to me. I was just about to ask what you expect the transfer rate will be between the CF and VRAM, via the video player. I hope it's as fast as it needs to be...

[Kurt_Woloch]

I think the toughest challenge here would actually be the sound transfer, which should occur in exactly even intervals (i.e. once per scanline, as you wrote), or else the sound would be horribly distorted. One problem here is that, to my knowledge, the Colecovision VDP has no scanline counter... it only generates one interrupt per frame. Or is there a timer in the Colecovision which would be able to generate interrupts that often? If not, you're in for some serious cycle counting...
Where did you get the 28 cycle count between VDP accesses? I've written a demo for the Creativision, which uses the same VDP, and the first version of it overloaded the VDP with data, that is, it wrote data faster than the VDP could handle it, so the VDP dropped some of those writes which occured outside of the vertical blanking interval. However, I managed to solve that problem by blanking the VDP output while the picture gets drawn. This, however, obviously isn't an option here.
The Creativision uses a 6502 CPU, I think running at 2 MHz (or was it 1 Mhz? I'm not exactly sure...), and for all you cycle counters out there, the code overloading the VDP in the active display area, but not in the blanking area, ran as follows (note: VDP_Data_Write is not a zeropage address, but GraphicsPointer is):

	LDX #$00
	LDY #$03	;3 x 256 bytes
VDP_Write_Outer_Loop	
	STX VDP_Data_Write
	INX
	BNE VDP_Write_Outer_Loop
	DEY
	BNE VDP_Write_Outer_Loop

(This writes the pattern name table)

However, the VDP was not overloaded by the following code, which copies the pattern and color tables:

	LDX #$18		;prepare loop - we have to write $1800 bytes of data (that is, 6K for each loop)
	LDY #$00
GraphicsCopy1
	LDA (GraphicsPointer),Y
	STA VDP_Data_Write
	INY
	BNE GraphicsCopy1	;end of inner loop
	INC GraphicsPointer+1
	DEX
	BNE GraphicsCopy1
	RTS			;end outer loop

[opcode]

Kurt_Woloch, on Fri Dec 12, 2008 4:52 PM, said:

I think the toughest challenge here would actually be the sound transfer, which should occur in exactly even intervals (i.e. once per scanline, as you wrote), or else the sound would be horribly distorted. One problem here is that, to my knowledge, the Colecovision VDP has no scanline counter... it only generates one interrupt per frame. Or is there a timer in the Colecovision which would be able to generate interrupts that often? If not, you're in for some serious cycle counting...

Yep, no timer. It would be all cycle counting.

Quote

Where did you get the 28 cycle count between VDP accesses?

The TMS9918 datasheet says that VDP access window in Graphics II is 8us during active display. The CV Z80 runs at 3,579,545Hz. That means that a CPU cycle takes 0.279us. If you divide 8us by 0.279us, you get 28~29 cycles. However the CV Z80 adds a wait state per instruction byte (or M1 cycle), so you can take that into account when doing the math.

[opcode]

Hm, interesting... The TMS9918 also says that 8us is the worst case time, and happens when sprites are being used.
Since DL doesn't need sprites, I would disable them and see how fast I can go....
Anyway the fastest I could go is:

IN A,(IDE_DATA_LOW)	  ;11 cycles + 2 wait states
OUT (VDPDTA),A			   ;11 cycles + 2 wait states
IN A,(IDE_DATA_HIGH)	 ;11 cycles + 2 wait states
OUT (VDPDTA),A			  ;11 cycles + 2 wait states

So in the end I need 52 cycles for two transfers, or 26 cycles per transfer. Since we have 227 cycles per scanline, I would transfer almost 9 bytes per scanline, which sounds bad at first...
Ok, I need to send 1856 bytes of video per frame. That are 48,256 cycles. If I transfer a sound byte every 8 video bytes, I get 234 cycles per A/V block transfer. That means that I can transfer 255 of those blocks per frame, which in turn means that sound will be exactly 15kHz, not 15.35kHz as I said before.
Now, with 255 data blocks per frame I just need to use 232 of them to get the video transfer rate I mentioned. So 23 of them would be used for general game logic, for a total of 23,920 cycles every movie frame. I still think it's ok for a simple game like this.
And moving the data blocks and logic blocks around I can also minimize video tearing... Maybe I could use NMIs every 5th frame to keep things in perfect sync...

[STGuy1040]

Any further developments on this project?

[Royalshin]

So your doing is basically what they did with the Gameboy color as for the

Intro of Rayman
Lufia animations

Removing colors
Shrinking each individual frame
having a separate program run the video
alternating sounds with mods or alike sounds


Dragon Slayer sounds cool but what about that other FMV game. The one where the guy loses his muscles, where he's in space fighting to get back his "man hood"

If that ever releases. I will be there to enjoy as long as it is a single cart

You will make heads roll if you could get it to look like the Sega CD animation from the get go.

Or maybe the entire animation could be sprites then all you would have to worry about is adding the extra hardware.

[STGuy1040]

Royalshin, on Tue Jan 20, 2009 1:22 PM, said:

Dragon Slayer sounds cool but what about that other FMV game. The one where the guy loses his muscles, where he's in space fighting to get back his "man hood"

I think you mean Dragon's Lair!

I'm not trying to be some anal retentive tool here just so you know! I just wanted to point it out in a friendly manner.

The other FMV game where the guy tries to get back his manhood is Space Ace; it was developed by Don Bluth, the same person that also developed Dragon's Lair (the same game this thread is about).

Edited by STGuy1040, Tue Jan 20, 2009 4:25 PM.

[jeremysart]

opcode, on Sun Dec 7, 2008 7:43 PM, said:

joyrex, on Sun Dec 7, 2008 6:06 PM, said:

I think the MSX Dragon's Lair had the same approach as you probably have in mind; converting every frame with its own tileset. Looking at the screenshots, it looks like you also changed the palette (v99x8?).

Another interesting approach is done by Arturo Ragozini. He created a video encoder that does a search for the optimum tileset for a couple of frames, rather than an optimum tileset for a single frame of video. You don't really require that if you take the flashcard as a medium, but it can provide you more cpu time during playback (and dedicate that to eg. sound).

Interesting reads about his approach;

http://www.msx.org/forumtopic7309.html
http://ragozini.googlepages.com/vdpenc

Thanks a lot, joyrex. I am going to check that. In the meantime, I created this animated gif, just to see how the final video would look. It's just 5s, but probably enough to show the quality of the video (which isn't that great, btw). I suggest to watch it full screen, from some distance. Perhaps I should try to increase error diffusion, from .25 to .43... More dithering but better colors...

Wow, that was quite impressive. Definitely a good project for the future!

[youki]

I just saw this thread and i didn't read it totally as it is a old one, so may be it has been already stated previously , if it is the case : sorry.

But speaking of D.L on Coleco , i read somewhere that the project has been started and some prototype existed. But not a version as we can see on ADAM.

The prototype was a Expension Module that allowed to plug a Lazer Disc Device. The Arcade Game was on the Lazer Disc , and the coleco was just here to manage input and control the video sequence to display.

the video was displayed on screen via the coleco thanks to the Color #15 (Transparent color) the VDC behaving as a Genlock. Additionnal information and graphism can be displayed above the video using other colors.

I have found this project very interresting . It is pity it has been canceled and only the Adam version (hower quite good) appeared.

Nowadays , it could be funny to do that same thing but using a DVD reader and it is really easy to find Dragon's lair edition on DVD.

[the.golden.ax]

Looks every bit as good as Sega CD FMV

AX