Any A8 demo doing this?

[emkay]

On many C demos (64 and Plus 4 ) you see fast animations. Faster than on the A8 .... somehow.

C64 can not be (CPU wise) and the Plus 4 has too much Cycle stealing from the VIC 3 to handle it.

 

 

The demo runs on a Plus 4, thats why is has so much colours.... The music runs obviously from a C64 (the Plus 4 doesn't even have sound inside)...

Passing this "self lying" , please watch the movement. It looks like "50 fps" but it isn't. Every other line is changed every 2nd frame. So it "in real" runs at the half fps.

 

Many demos of the C64 use this ( 2nd Reality f.e. , too )

 

 

I wonder whether A8 demos exist with this technique.

[Heaven/TQA]

isn't Veronika doing similar things?

 

http://atari.fandal.cz/detail.php?files_id=3732

[miker]

Or The Top #3 (this part even uses additional 64k of memory).

[Heaven/TQA]

ah. forgot top #3 but simply because at that time i had a 64k machine only... btw. in the animation part press option or start to see the char depacker...

[Rybags]

25 frames/second is actually OK if it's done against a complex background.

 

It just looks choppy if the objects are simple or the background is sparse.

 

And, let's not forget that cinema movies are still done in 24 FPS.

[emkay]

The "dancing" girl uses a fixed amount of chars and switches them.

 

The Plus 4 animation seems to do it in "normal" graphics. Thus it has many different animations available, running on a stock 64KB machine.

 

 

 

Looking at the "dancer" you see lines outside the shape. They are part of the movement, suggesting a full framerate movement to the eye.

 

Seen this, I ask myself why it souldn't be possible on the A8, using one GTIA mode and the dancer is built on PMg? When using this "trick" .

 

In other C64 demos you see the same "trick" when objects are rotating. Like a cube in 2nd Reality 64 and many others.

[Rybags]

Just do it in GTIA mode with characters in OS mode 0.

 

Possibly one of the least utilized features of the A8.

 

Although you effectively halve your H-pos resolution.

 

I wonder though - are the combing effects intended, or the result of running the demo on a real machine and using a video-capture card?

[miker]

Additionally each animation is probably stored compressed. IMO.

[twh/f2]

Actually I wonder how they handle all the data in less than 64k. I think they are constantly loading from disk and play music the same time.

 

using PMG for the animations would be very limited, because the max horizontal size would be only 40 pixels (5*.

 

i think all these background / foreground effects only work out, because the c64/plus have more sprites-data on a single line.

 

or do you see a good way to multiplex atari pmg's for such kind of animation ??

[Rybags]

Check the original post -

 

the sound is obviously coming from a C-64 and the graphics are from a Plus-4.

 

The C-16 and Plus-4 don't have any sprite capability, and a vastly reduced sound capability compared to the C-64.

 

But, they have a much better colour palette and better colour-mapping capability.

[Rybags]

Just ran it in the +4 emulator in WinVice 1.15

 

Sadly, it seems to crash about 20 seconds into the demo.

 

The combing effects are real. Weird. I suppose they wanted them that way.

 

No sound whatsoever though. Strange that it would win a demo comp. It's good, but without sound, rather lacking.

[Fröhn]

C64 can not be (CPU wise) and the Plus 4 has too much Cycle stealing from the VIC 3 to handle it.

The C264 series (C16/C116/Plus4) have a TED inside, not a "VIC3".

 

The demo runs on a Plus 4, thats why is has so much colours.... The music runs obviously from a C64 (the Plus 4 doesn't even have sound inside)...

The TED is not only for graphics and DMA, but it also has sound output.

 

the sound is obviously coming from a C-64 and the graphics are from a Plus-4.

The sound is from a SID-card, which is quite common in the Plus4 scene because the TED produces really horrible sound.

 

The C-16 and Plus-4 don't have any sprite capability, and a vastly reduced sound capability compared to the C-64.

 

But, they have a much better colour palette and better colour-mapping capability.

The color mapping is mostly the same as on C64 and slightly worse in multicolor bitmap mode due to lack of extra color SRAM. This reduces the amount of 3 unique colors per color cell and one global background color (C64) to 2 unique colors per cell and 2 global colors (Plus4). All other modes are the same except for the bigger palette. Oh, and color resolution in FLI modes is half as low as on C64 too.

 

Just ran it in the +4 emulator in WinVice 1.15

 

Sadly, it seems to crash about 20 seconds into the demo.

Use Yape. Vice +4 emulation is still not good enough for most demos.

 

No sound whatsoever though. Strange that it would win a demo comp. It's good, but without sound, rather lacking.

Vice has no SID-card emulation for +4.

[atarixle]

No sound whatsoever though. Strange that it would win a demo comp. It's good, but without sound, rather lacking.

 

I run this demo on Vice for Mac OS X / X11 ... it's also crashing some seconds after the start ... this Demo runs only on PAL machines, so may be, we have to switch somewere to PAL emulation.

 

To hear sound, you have to turn on the SID-Cartridge-Emulation. This must be something similar to the second pokey in ATARI-8-Bits.

[twh/f2]

the emulation runs well with yape 0.76. it's obviously important to activate "parallel 1541 emulation" under settings/Drive 8 setup/

 

but still, I think it would be cool to have these animation implemented using PMG. this would allow to create smooth transitions between the screens and allows much better flexibility for the background effects.

 

i think there are several multiplexing techniques for creating more PMG gfx on a single line. what techniques could be used here?

 

grtx,

\twh

[JamesD]

Check the original post -

 

the sound is obviously coming from a C-64 and the graphics are from a Plus-4.

 

The C-16 and Plus-4 don't have any sprite capability, and a vastly reduced sound capability compared to the C-64.

 

But, they have a much better colour palette and better colour-mapping capability.

Actually, the sound is probably from the Plus/4. It might use a SID add on card though. SID music has also been emulated on the TED chip pretty well too so it might just be the standard TED sound. The TED internal registers are all modifiable by the CPU so you can do all sorts of crazy things with it that were never intended.

A lot of C64 titles have been ported to it by hackers in spite of it's lack of sprites or a SID.

The demo is available for download if you want to check it out on an emulator.

http://plus4.emucamp.com/home

 

<edit>

looks like someone beat my reply and it uses a SID card.

Edited August 26, 2007 by JamesD

[pps]

I got this demo with Plus4Emu running.

 

Looks & sounds really cool.

 

The animations are really very fast. Thumbs up for this piece of work. Would be cool to have something like that on our machine too.

[kenfused]

the emulation runs well with yape 0.76. it's obviously important to activate "parallel 1541 emulation" under settings/Drive 8 setup/

 

but still, I think it would be cool to have these animation implemented using PMG. this would allow to create smooth transitions between the screens and allows much better flexibility for the background effects.

 

i think there are several multiplexing techniques for creating more PMG gfx on a single line. what techniques could be used here?

 

grtx,

\twh

You can also make some of the players or missiles double or quad width, using the remaining players and missiles to fine tune the width. You can still position the wide players with pixel accuracy. This would not allow just any combination of stuff on a scan line so it might require some artistic tweaks or compromises to get what you want within the limitations. You also might be limited to what registers you could change on a scan line since you could potentially need to manipulate 8 position registers and 5 size registers.

Edited August 26, 2007 by kenfused

[emkay]

You can also make some of the players or missiles double or quad width, using the remaining players and missiles to fine tune the width. You can still position the wide players with pixel accuracy. This would not allow just any combination of stuff on a scan line so it might require some artistic tweaks or compromises to get what you want within the limitations. You also might be limited to what registers you could change on a scan line since you could potentially need to manipulate 8 position registers and 5 size registers.

 

I would stick to a fixed width of the player. Missiles should be left out. With single width the dancers would be a bit smaller and with double width the dancer could be much bigger.

With double width players the position and the bits could be set. Due to the fact that the dancer always has to be updated, a "DLI" programming of the position and shape of the players would give the perfect animation.

This means 8 registers (8 bytes) to be changed for one scanline, which is easily possible, because no DMA for the players is used. This means also that graphicsmode for the background is requiered and the backgound could be used by sometimes changing between the three GTIA modes. The whole VBI time would be free for things like Music, depacking and/or graphics animations.... perhaps loading by Disk or else...

[twh/f2]

emkay,

 

could you rephrase a bit your ideas? are you talking about doubling the pmg gfx field by inline re-positioning of the players?

 

still , single or double size, the 4 players width would be in total only 32 px .. far to less to do some good video effects

 

grtx,

\twh

[emkay]

emkay,

 

could you rephrase a bit your ideas? are you talking about doubling the pmg gfx field by inline re-positioning of the players?

 

still , single or double size, the 4 players width would be in total only 32 px .. far to less to do some good video effects

 

grtx,

\twh

 

A test would be needed how this looks with every "other" line changed.

Don't forget that the positon still can be set to a "half" pixel per line, when the Player are at double width.

 

Instead of saving CPU cycles on the Plus 4 , this "technique" may be used for "interlaced resolution enhancement" for the players.

[Allas]

Better should be mix 2 modes as Gr.9,10 or 11 (for background colors) with narrow hi-res Gr.8 (for dancer graphics). Something like Total Daze demo into, look at LOADING word.

 

Even maybe can be used a APAC mode for background.

 

Total daze

Edited August 26, 2007 by Allas

[analmux]

...

Edited September 17, 2007 by BRK

[Rybags]

SIO speed (bytes per second) is the baud rate / 10 : remember that start/stop bits are transmitted.

 

You can have some lag in reading SERIN. So long as it's read before the next byte is ready, you can avoid Serial Input OverRun errors.

 

So, if we have a baud rate of 19,200 that is 1,920 bytes per second during transmission of a data block.

 

That's 38.4 IRQs per frame in PAL, which equates to about 1 every 8 scanlines.

 

There aren't "checkbits", only a checksum byte at the end of each block.

 

One problem with doing the demo is that PMGs don't work properly in GR. 10.

[JamesD]

I think their inspiration for this demo is obvious.

 

[emkay]

Well, Player DMA means that 4 cycles are stolen by antic every rasterline. For doing all the Player data by hand (i.e. 'realtime') you'd need at least 7 cycles per Player for its shape data.

 

Yes, but when the routines manipulate the Players every scanline for this animations, you can save the DMA cycles, because the 7 cycles have to be used anyways.

The player "writing" routine reads from the memory where the data is stored from disk then, where every 2nd line is changed.

56 cyles were used for the changes. And when using 32 bytes for the screen width there must be enough time for some more code (like iny and LDA xxxx,y ...) and some time for other interrupts after the DLI is finished.

 

Remember that the animations possibly must rely on some sort of indexing logic and/or a decompression algorithm for all the shapes. So, I suspect some buffering should be needed also, which should/could be done in the VBI time. Then just use normal Player (and evt. Missile) DMA and then PMBASE is the needed decompression buffer.

 

Why buffering? Writing the PM directly, shortly before they were displayed, there will be no flicker or else.

 

The real "hard" work, perhaps would be to adjust data transfer working almost in the VB.

And there was a "pre work" necessary to make a data stream for the changes at every "other" line only. Reducing the data would make decompressing obsolete.