Full screen video?

[Ecernosoft]

Hello guys!
I know I've also asked this on the lynx page too, but I'm also going to ask it here (because antic D...?) too. 

Anyway, with ANTIC D looking like this:

; This is DMA.

and it being 2bpp at 160*96 (Yes, I know about ANTIC E, but that takes twice as long to do a draw as D does.), I thought "hey, how about this too?"

I understand that the Atari 8bit has to deal with DMA and that the CPU is already slower than the lynx (it's still fast for 1979 though.), but hey, why not?

 

I'm mostly asking because as I was programming Conner&Anthony for Atari 8bit, I thought about a sequel to it, a Conner&Anthony 2 if you will, which would be for 130xe only. (Heck, I'm thinking about making C&A for 65xe/800xl+ as it is instead of 800+ so I can include 16Khz samples in the $C000-$FFFF region AND use NMI for my code.)
 

So, have any of you tried this? Just asking. 😃

(A Conner&Anthony for Atari 130xe would be freaking awesome!!! Would give us a game FOR that platform, and if I'm not wrong, you CAN have the CPU only in that region for SUPER FAST processing!)

 

Thanks guys, and merry christmas!

[R0ger]

Uh .. what exactly are you asking ?

[Ecernosoft]

10 hours ago, R0ger said:

Uh .. what exactly are you asking ?

I'm asking about playing video using ANTIC D.

 

Like, a cutscene. But animated. Full screen video.

[phaeron]

Fundamentally, the main bottleneck is going to be size. You can play ANTIC D video at 60 fps with 16KHz sound, but at 246KB/sec it's going to be less than a half second long on a 130XE unless you have a source that can stream data at high speed. A disk drive isn't going to cut it at 1KB/sec. And the minute you try to process the video with the 6502 for any reason such as compression or PIO transfer, it's going to take >10 cycles/byte, which will limit frame rate.

 

[r_chase]

Honestly, what phaeron said. If you're gonna, say, add a cutscene, you might want to keep size in mind. Then again, I'm no expert at developing stuff for any platform. Sorry in advance.

[+CharlieChaplin]

Fullscreen movies with 50fps / 60fps and sound can't be used from within a game, unless your target is SIDE-3, AVG, etc. with SD-card or a harddisk drive.

 

In the 80s we did have small + simple animations with 3 - 5 pictures (mostly 4 colours) that did run on a 48k or 64k Atari (e.g. Alien, Max Headroom, Smurf, etc.), later we did have simple animations with 8 or more pictures that did run on a 130XE from its 64k XRAM (e.g. many Raytracing animations). Then came animations with 16-32 pictures for a 320k machine. Nowadays we have 1MB demos that are full of animations.

 

So, if you target 64k or 128k Atari machines some small animation with pictures (frames) would be doable. There are also very nice animations (some would say small video clips) in Moviemaker format, alas it looks like these cannot be used in games (only in moviemaker shows) or no-one knows how. I also doubt that TIP animations can be used in games, allthough I have hundreds of them for 64k and 128k computers (and also for 320k, 576k and 1088k computers).

 

Take a look at the 128k version of "Break It 22 Reloaded" for example, it includes a nice animation of a bouncing ball in 256 colours. There do exist many other animations in Gr. 7, 8, 9, 15, HIP, TIP, etc. for various RAM configs, alas, there are very few A8 games that do include such fullscreen animations due to RAM requirements (e.g. in Artefakt Przodkow if you have 128k RAM:  https://a8.fandal.cz/detail.php?files_id=37 ). Most A8 games that make use of animated intros or intermissions use very small char. based animations, which can e.g. be seen in Pacman, Millipede, The Last Starfighter (intro), Donkey Kong, Archon and others. Aliants and Astro Chase seem to be an exception, but then again, these games are known for good intros but bad / boring gameplay. Mercenary however has a nice programmed intro, not based on pictures...

 

Maybe I should also mention the great intros of Prince of Persia, On Escape, Star Vagrant or Alternate Reality?  We also have (converted) A8 intros of  Bard's Tale and Bard's Tale 3, but no games yet.

 

[Ecernosoft]

14 hours ago, r_chase said:

Honestly, what phaeron said. If you're gonna, say, add a cutscene, you might want to keep size in mind. Then again, I'm no expert at developing stuff for any platform. Sorry in advance.

DATA. COMPRESSION.

 

how viable is that?

[dmsc]

Hi!

3 minutes ago, Ecernosoft said:

DATA. COMPRESSION.

 

how viable is that?

Phaeron already said: "And the minute you try to process the video with the 6502 for any reason such as compression or PIO transfer, it's going to take >10 cycles/byte, which will limit frame rate."

 

In reality, even a very fast decompressor like my ZX02 will average to more than 40 cycles/byte. If you have an ANTIC D screen at 3840 bytes, you are talking about 150k cycles for one frame, so you should expect less than 10 frames/second. And the compression would not be great, as the algorithm is very simple.

 

So no, forget about full motion video in the Atari without some kind of hardware addon.

 

Have Fun!

[Ecernosoft]

3 hours ago, dmsc said:

Hi!

Phaeron already said: "And the minute you try to process the video with the 6502 for any reason such as compression or PIO transfer, it's going to take >10 cycles/byte, which will limit frame rate."

 

In reality, even a very fast decompressor like my ZX02 will average to more than 40 cycles/byte. If you have an ANTIC D screen at 3840 bytes, you are talking about 150k cycles for one frame, so you should expect less than 10 frames/second. And the compression would not be great, as the algorithm is very simple.

 

So no, forget about full motion video in the Atari without some kind of hardware addon.

 

Have Fun!

wah. cry. ;D

I was expecting this answer.

[Ecernosoft]

4 hours ago, dmsc said:

Hi!

Phaeron already said: "And the minute you try to process the video with the 6502 for any reason such as compression or PIO transfer, it's going to take >10 cycles/byte, which will limit frame rate."

 

In reality, even a very fast decompressor like my ZX02 will average to more than 40 cycles/byte. If you have an ANTIC D screen at 3840 bytes, you are talking about 150k cycles for one frame, so you should expect less than 10 frames/second. And the compression would not be great, as the algorithm is very simple.

 

So no, forget about full motion video in the Atari without some kind of hardware addon.

 

Have Fun!

Wait, before I give up, how about ANTIC A? It would look blocky, BUT it would be faster! (And by faster, I mean 4x faster!)

[dmsc]

Hi!

12 minutes ago, Ecernosoft said:

Wait, before I give up, how about ANTIC A? It would look blocky, BUT it would be faster! (And by faster, I mean 4x faster!)

It would depend on what video you want to play....

 

See this example I did a long time ago: lz4vid8.xex

 

Have Fun!

[Ecernosoft]

3 hours ago, dmsc said:

Hi!

It would depend on what video you want to play....

 

See this example I did a long time ago: lz4vid8.xex

 

Have Fun!

Well, I was saying like a shorter version of say..... Sonic CD intro?

(And by shorter, I mean that it would need to fit into ~32K unless I used Disk loading routines.)

 

Speaking of, could you write a version for ANTIC A or ANTIC D?

Edited December 29, 2022 by Ecernosoft

[dmsc]

Hi!

3 minutes ago, Ecernosoft said:

Well, I was saying like a shorter version of say..... Sonic CD intro?

(And by shorter, I mean that it would need to fit into ~32K unless I used Disk loading routines.)

So, you want to fit several megabytes of data into 32K???? Imposible.

 

Have Fun!

[Ecernosoft]

3 hours ago, dmsc said:

Hi!

So, you want to fit several megabytes of data into 32K???? Imposible.

 

Have Fun!

No!

First off, It wouldn't be SONIC CD.

Second off, it would be ~15 seconds long.

Third of all, I should've said Sonic 3D.

 

Edit: And plus, the intro literally says "If you try..... you can do anything!"

Edited December 29, 2022 by Ecernosoft

[phaeron]

Back of the envelope calculations alone show you the feasibility of this.

 

15 seconds worth of video in 32K gives you a budget of 2.1K/sec. Even if you chopped it down to 5 fps, you're looking at ~430 bytes/frame even if you had no audio. A normal size mode A screen takes 960 bytes, so you need a compression ratio of at least 2.2:1. If you had simple line art with lots of white space and only small portions of the video changing each frame, it'd be doable. It's going to be a lot harder with something like the Sonic 3D intro with lots of detail and basically the whole screen updating constantly.

 

Additionally, while reducing the resolution reduces the total uncompressed frame size / bandwidth, it increases the detail -- which reduces the compression ratio you'll be able to get. Oh, by the way, dithering also does bad things to compression ratio.

 

That's the size calculations. On the CPU cycle calculations, 5 fps gives you 12 frames of CPU time, or about 350,000 cycles on NTSC. Subtract off 9/114ths (7.9%) or ~27,600 cycles for memory refresh, and 9,600 cycles for playfield DMA. This leaves 312,800 cycles per frame, or 325 cycles/byte. Which is actually not too bad, and indicates that data size is going to be more of a problem than CPU usage at this kind of profile. But again, a 2.2:1 ratio is going to require an aggressive and fast compression algorithm, and those cycles get eaten up faster than you think. I'm not even sure Deflate would be able to hit 2.2:1 on this kind of data and it's already a pretty expensive decompressor to run on a 6502.

 

Digital audio at the same time is basically infeasible. Bare minimum for any kind of recognizable audio is ~8KHz sampling rate (2 scanlines), and that'd probably be ~30% of the CPU just to play 4-bit raw volume-only samples -- with nasty tricks like declaring that your mainline code doesn't really need a Y register. But it would take 58KB of memory to store 15 seconds of it. To get this in the ballpark of fitting with video, you'd need somewhere around 5:1 to 10:1 compression ratio. That's in MPEG-1 territory. Not going to work on a CPU that might just be able to do ADPCM at best at 100% of the CPU.

 

Which is not to say that the overall idea's entirely hopeless, but you're going to have to adjust your expectations and parameters. Drop the audio or replace it with synth audio, reduce the video size to half the screen or smaller, aim for simpler animated content. Or just go for an animated intro instead of an FMV, which has more precedent on the A8 and would be a far more effective use of ~30 seconds of disk load time.

 

[Rybags]

IMO something like a lores wireframe rendered animation would probably work better.

The data requirements not huge - it could be loaded at the time needed.

Think something like the intro to Another World except somewhat simpler.

[Wrathchild]

Indeed, such as @R0ger's Rescue

 

 

[R0ger]

Well Antic D is certainly a good choice whenever you need speed. But it's no magic. It will give you few % of extra CPU because of the DMA. You gain much more by simply processing 50% of the data.

 

But as Phareon says .. memory is the problem for anything like a "cutscene".

Probably also presentation. Antic D has 4 colors. Not a lot. People usually go for more expensive modes and still images, to get more.

 

[r_chase]

1 hour ago, R0ger said:

Well Antic D is certainly a good choice whenever you need speed. But it's no magic. It will give you few % of extra CPU because of the DMA. You gain much more by simply processing 50% of the data.

 

But as Phareon says .. memory is the problem for anything like a "cutscene".

Probably also presentation. Antic D has 4 colors. Not a lot. People usually go for more expensive modes and still images, to get more.

 

This pretty much. Although there are tools for making VNs and IFs for Atari 8-bit.

For example, this one, which I didn't know had a post.

Even though this one was posted in the Lynx forums, it also applies to C=64 and A8 platforms too. I know this isn't a platformer example, but it's an example nonetheless.

[+CharlieChaplin]

21 hours ago, dmsc said:

Hi!

So, you want to fit several megabytes of data into 32K???? Imposible.

 

Have Fun!

 

We have the A8, so MPG-8 does the job!  😆

[+CharlieChaplin]

Some rough and stupid calculations...

 

1) A8 fullscreen with approx. a) 8k (e.g. Gr. 8, 9, 15, 9+11) or b) 4k (Gr. 7, etc.) per screen / frame

=> a) 1 second in NTSC with 60fps = 8*60 = 480K per second, in PAL with 50fps = 8*50 = 400K per second

      b) 1 second in NTSC with 60fps = 4x60 = 240K per second, in PAL with 50fps = 4x50 = 200K per second

 

2) lower the framerate to 30fps / 25fps

a) NTSC = 8x30 = 240K per second, PAL = 8x25 = 200K per second

b) NTSC = 4x30 = 120K per second, PAL = 4x25 = 100K per second

 

3) lower the framerate, lower the framerate and lower the framerate even more, e.g. 6fps for PAL and NTSC

a) 8x6 = 48K per second => 15 seconds = 15x48 = 720KBytes => 1MB RAM upgrade required!

b) 4x6 = 24K per second => 15 seconds = 15x24 = 360KBytes => 512k RAM upgrade required!

 

4) Loading time... lalalala... loading...

- standard SIO speed: approx. 1K per second,

- 3x SIO speed: approx. 3K per second,

- Pokey divisor 0/zero approx. 10K per second

- harddisk / CF / SD / (not using SIO!)... somewhere between 30K and 90k per second

 

So a short video based on example 3a) with standard (floppy) SIO speed has approx. 12 minutes of loading time for 15 seconds of video, not nice. It would also require a big RAM upgrade. The same thing on a harddisk with 80K per second however...

 

[Zolaerla]

In all likelihood, to get animations somewhat like this, you're probably looking at 1-bit or 2-bit output, and probably also aiming for double-buffer frames (at ~4KB each, that's 8KB just for the screen buffer) unless you want to let the user watch as you draw in the next frame. You could use line art with delta frames (changing only a rectangle on screen that moves) and RLE compression (eg, high-bit + 7-bits of length to repeat next byte, or no high-bit + 7-bits for length of raw output in the next bytes) to actually get a nice compression rate without sound involved, if almost everything is solid colors. These would be either low frame rate or very short, but they could look vaguely like the cutscenes from "Faith": https://store.steampowered.com/app/1179080/FAITH_The_Unholy_Trinity/ -- Some of that could be reduced way, way down in size. Still, it'd be a lot of work!

[Ecernosoft]

17 hours ago, R0ger said:

Well Antic D is certainly a good choice whenever you need speed. But it's no magic. It will give you few % of extra CPU because of the DMA. You gain much more by simply processing 50% of the data.

 

But as Phareon says .. memory is the problem for anything like a "cutscene".

Probably also presentation. Antic D has 4 colors. Not a lot. People usually go for more expensive modes and still images, to get more.

 

True.

But hey, most of the time I don't care about color.

Instead, if there is a C&A 2 I'll just use my still-image routine with ANTIC F-10.

For C&A 1 however, I'm using ANTIC A and "sprites" to draw my graphics.

I also think I might use PRIOR ????0000 and p/m graphics (Remember- they are always enabled in C&A. I never touch DMACTL except setting it to $3A once.) to get extra color.

I think I like ANTIC A. It might be low res but hey, if I ever port C&A to the 400/600xl, I'll still have 15K left!

 

(Keep in mind: if that ever were to happen, probably not since who uses those, the load times would exist and they would exist EVERYWHERE.)

Edited December 30, 2022 by Ecernosoft

[Ecernosoft]

5 hours ago, CharlieChaplin said:

Some rough and stupid calculations...

 

1) A8 fullscreen with approx. a) 8k (e.g. Gr. 8, 9, 15, 9+11) or b) 4k (Gr. 7, etc.) per screen / frame

=> a) 1 second in NTSC with 60fps = 8*60 = 480K per second, in PAL with 50fps = 8*50 = 400K per second

      b) 1 second in NTSC with 60fps = 4x60 = 240K per second, in PAL with 50fps = 4x50 = 200K per second

 

2) lower the framerate to 30fps / 25fps

a) NTSC = 8x30 = 240K per second, PAL = 8x25 = 200K per second

b) NTSC = 4x30 = 120K per second, PAL = 4x25 = 100K per second

 

3) lower the framerate, lower the framerate and lower the framerate even more, e.g. 6fps for PAL and NTSC

a) 8x6 = 48K per second => 15 seconds = 15x48 = 720KBytes => 1MB RAM upgrade required!

b) 4x6 = 24K per second => 15 seconds = 15x24 = 360KBytes => 512k RAM upgrade required!

 

4) Loading time... lalalala... loading...

- standard SIO speed: approx. 1K per second,

- 3x SIO speed: approx. 3K per second,

- Pokey divisor 0/zero approx. 10K per second

- harddisk / CF / SD / (not using SIO!)... somewhere between 30K and 90k per second

 

So a short video based on example 3a) with standard (floppy) SIO speed has approx. 12 minutes of loading time for 15 seconds of video, not nice. It would also require a big RAM upgrade. The same thing on a harddisk with 80K per second however...

 

X_X = Computer memory apparently.

 

Nope! No full screen video, I've given up.  

(for now.....)

[Ecernosoft]

3 hours ago, Zolaerla said:

In all likelihood, to get animations somewhat like this, you're probably looking at 1-bit or 2-bit output, and probably also aiming for double-buffer frames (at ~4KB each, that's 8KB just for the screen buffer) unless you want to let the user watch as you draw in the next frame. You could use line art with delta frames (changing only a rectangle on screen that moves) and RLE compression (eg, high-bit + 7-bits of length to repeat next byte, or no high-bit + 7-bits for length of raw output in the next bytes) to actually get a nice compression rate without sound involved, if almost everything is solid colors. These would be either low frame rate or very short, but they could look vaguely like the cutscenes from "Faith": https://store.steampowered.com/app/1179080/FAITH_The_Unholy_Trinity/ -- Some of that could be reduced way, way down in size. Still, it'd be a lot of work!

Yeah.

 

I think I'll go the sonic 2 sms route and instead of cutscenes, use ANTIC F-10 or ANTIC A (By the way, I'd be using ANTIC F-10 in ANTIC A resolution, so only double the memory of ANTIC A. I like square pixels, and I don't do good hires artwork.) for little images. If I use ANTIC A (Which is what I'm going to use for C&A 1 by the way) I'll probably also use P/M graphics and the GTIA "OR" capabilities with PRIOR 0 to get extra colors to help draw characters.

 

 

Some dumb math I did because I can:

 

ANTIC A = 4 colors

GTIA sprite = 1 (lousy) color

ANTIC A uses PF0, PF1, PF2, COLBK

PFx*PMx = 4 color

16 colors with ANTIC A, only using 2kb.

 

Edit: Heck, I can go even further!

 

*enables P/M oring capabilities*

*thinks about PF0/PM0/PM1/PF1 and PF2/PM2/PM3/PF3 using GPRIOR %xxxx0000*

so, 2 extra colors from the P/M oring.... and 4 MORE extra colors from the other combinations between P/M and the BK... that's 22 colors, using 2K of memory.

Take that ANTIC F/10! And C64!

 

(Wait, I can do it on F/10 as well  so I'll try that out sometime.)

Edited December 30, 2022 by Ecernosoft