This fake demo is not possible on ECS... But AGA?

[arpz]

http://www.youtube.com/watch?v=WRLN-altyM0

What do you guys think?

[StingRay]

Perfectly possible on OCS.

[Schlachtwerk]

I think this is not possible on AGA.

[StingRay]

This is perfectly possible even on OCS, the effects are very simple, starfield, rasters, scroller and sine scroller. And it looks quite ugly too!

[arpz]

It looks like too many colours, though?

[Samurai_Crow]

Originally Posted by Schlachtwerk

I think this is not possible on AGA.

Why not? The smooth parts of the color gradients in the color bars were opaque so you could disable the display DMA while they were being displayed to get fast copper. The backdrop would probably be blitter-based. The moving text in the middle would be sprites and therefore would be unaffected by the display DMA being disabled for the color bars.

I say it's perfectly doable on AGA. It's even possible on OCS if you didn't have the smooth color gradients used on the color bars.

[s2325]

I think it's OldSkool Demo Maker for PC.

[StingRay]

Of course it is, the effects say it all.

[Thorham]

Originally Posted by arpz

It looks like too many colours, though?

That's probably the crappy encoding quality causing the gradients to become smooth.

You could try cracked Shadow of the Beasts 2 adfs in WinUae and see if any of them have this intro.

[pmc]

I second StingRay - definitely do-able on OCS.

Personally though, I'd get rid of, or at least modify, the 3d star effect. The stars that become large circles firing quickly past the front of the screen make things look messy in my opinion.

[StingRay]

Originally Posted by Thorham

You could try cracked Shadow of the Beasts 2 adfs in WinUae and see if any of them have this intro.

That's a PC "demo" made with Oldschool Demomaker.

Originally Posted by pmc

The stars that become large circles firing quickly past the front of the screen make things look messy in my opinion.

The whole thing looks messy IMHO.

[pmc]

Originally Posted by StingRay

The whole thing looks messy IMHO.

You meanie

[arpz]

Originally Posted by Thorham

That's probably the crappy encoding quality causing the gradients to become smooth.

You could try cracked Shadow of the Beasts 2 adfs in WinUae and see if any of them have this intro.

nah, the guy actually stated that its fake elsewhere.

as for the everyone else, yes, I don't really like the stars, I'm not massively impressed or anything but the smoothness of the bars had me wondering if it could be achievable.

[khph_re]

The copper bars are multi coloured, but the copper can change (I think) up to 16 palette entries per line. Everything else on there looks pretty standard for OCS.

[Mrs Beanbag]

Originally Posted by khph_re

The copper bars are multi coloured, but the copper can change (I think) up to 16 palette entries per line. Everything else on there looks pretty standard for OCS.

Nobody has yet suggested that HAM might be being used here... if you put a single pixel of say colour 1 on the left and put component-change codes along the rest of the line to make a gradient, you'd only have to change one palette entry and the whole line would change.

[Thorham]

Originally Posted by khph_re

but the copper can change (I think) up to 16 palette entries per line.

OCS/ECS can change a color (or other chipset register) per eight lowres pixels, as long as the screen is 16 color lowres (don't know how many colors for highres, but less than 16). This means you can get reasonably close to the copper bar effect in this intro.

[Djay]

maybe this is good idea for a little project, make an "Amiga" version of this cracktro

could be a joint effort or a compo for the leet coders?

[Leffmann]

Gradients would have to be much more coarse, and you'd never get the same frame rate if you were to do all the drawing going on in the video, with the stars in the background zooming up to large filled circles.

[Mrs Beanbag]

Not necessarily true Leffmann it's only one bitplane, it's only half-height and you could draw all the outlines first and fill the whole thing on one go. Although where two circles overlapped they'd cancel out, not sure if there's an easy way round that.

The gradients could easily be dithered with a clever use of bitplanes.

[Lonewolf10]

I think it's pretty cool. Plus you could cheat (and be lame) and pre-render the star bit (say 20 frames of half-screens), thus leaving everything else to be done in realtime


Regards,
Lonewolf10

[Mrs Beanbag]

I think the starfield is doable in realtime. I'm concocting a way in my head right now to draw a whole bunch of stars with one blitter operation. Put it into line mode and screw with the modulo registers.

[Galahad/FLT]

For a start, very few of the stars onscreen get to full size, and the star circles are only 1 colour, so i'm fairly confident an A500 could cope with that easily.

Secondly, where the stars are generated from the centre is mostly garbage, so could be disguised with a simple anim in the centre instead of plotting lots of stars in the centre.

The shadowed sine scroller has been done to death on Amiga.

The copper bars in the background I think on A500 could be very nearly replicated colourwise, but on AGA could be done 100% spot on.

A combination of copper bars and real graphics reloaded with colours should give you most of the steps that are required to get a close approximation to that in that fake cracktro.

[alexh]

Interesting that the scroll text is actually the Wikipedia review of the game....

http://en.wikipedia.org/wiki/Shadow_...f_the_Beast_II

[Mrs Beanbag]

haha that's some good detective work right there!

still doesn't mean it isn't possible though...

[Codetapper]

The starfield in the demo moves so fast that you could probably fake the whole thing with about 10 frames of animation in a loop (and even mirror the top and bottom half) and perhaps plot the odd big circle star to make it appear that it's not an anim.

Like a number of people on here, I don't see the big deal about this intro either. An A500 could easily do a very similar version without too much hassle.

[Mrs Beanbag]

Originally Posted by Codetapper

The starfield in the demo moves so fast that you could probably fake the whole thing with about 10 frames of animation in a loop (and even mirror the top and bottom half) and perhaps plot the odd big circle star to make it appear that it's not an anim.

Like a number of people on here, I don't see the big deal about this intro either. An A500 could easily do a very similar version without too much hassle.

I think a real starfield is possible using the blitter. The blitter can plot a lot of points in a frame by clever use of line mode. Just make the starfield out of lines of up to 16 stars instead of individual stars, it probably wouldn't be noticed. Use 1-pixel per scanline mode but set the modulo so that they all come out on the same line, put a random value in BLTBDAT... if you can do 50 stars in a frame you can do 500.

The sinewave scroller is trivial. I've googled to see what other people's technique is, everyone seems to suggest blitting the vertical columns one at a time, thus a 16-pixel wide section needs 16 blits. It can be done in four. Yes and still retain 1-pixel resolution. It's only blitting one bitplane each frame, the other bitplanes are just previous versions through which it cycles, making a trail effect.

The copper effects can be done by changing the palette every 20 pixels easily, use a single bitplane with a dithering pattern on it, and blit pre-rendered lines into the copperlist. The copperlist is in Chip Ram right, you can blit into it.

[pmc]

Originally Posted by Mrs Beanbag

It can be done in four. Yes and still retain 1-pixel resolution.

This might be my misreading but are you saying you can do only four blits per word and still get a 1 pixel resolution sinescroller?

How?

[discomeats]

someone should just do the demo

[Mrs Beanbag]

Originally Posted by pmc

This might be my misreading but are you saying you can do only four blits per word and still get a 1 pixel resolution sinescroller?

How?

yes.

blit up and down with a mask. first mask covers all columns that have to go down 8 pixels. next cover all columns that have to go up by four pixels, then up by 2, then up by 1. as long as the slope never exceeds 1:1, this is sufficient.

example: first mask = $FF00, second mask $0F0F, third mask $3333, fourth mask $5555, this would give a straight 1:1 slope.

to calculate the values of the masks, do a quick "chunky-to-planar" type conversion on the y-data. (Could precalculate all these)

sometimes it is useful to think deeper inside the box.

[pmc]

Cool.

Make the demo and post the code

[Akira]

Mrs. Beanbag's full of wisdom :O

[StingRay]

Originally Posted by Mrs Beanbag

yes.

blit up and down with a mask. first mask covers all columns that have to go down 8 pixels. next cover all columns that have to go up by four pixels, then up by 2, then up by 1. as long as the slope never exceeds 1:1, this is sufficient.

example: first mask = $FF00, second mask $0F0F, third mask $3333, fourth mask $5555, this would give a straight 1:1 slope.

to calculate the values of the masks, do a quick "chunky-to-planar" type conversion on the y-data. (Could precalculate all these)

sometimes it is useful to think deeper inside the box.

I can't see how this is going to work. In a normal 1pixel sine scroller each slice can have a different y position so you need 16 different blits for a 16 pixel wide char. Also, they can have any y position, i.e. they don't move in just 1/2/4/8 pixels. Might be that I am missing something obvious but without a working example I don't believe that your approach will work.

[pmc]

Yep, me neither - hence me wanting to see the code. I can't say for sure it wouldn't work so I'd love to be proved wrong with a working example.

[Mrs Beanbag]

1, 2, 4 and 8 covers all the numbers from 0 to 15... the first blit can position the 16-pixel wide block anywhere on the y-axis, with an additional 8-pixel shift of any of the columns (use two blitter sources, one 8 lines higher than the other, with a mask of $FF00).

Then shift upwards progressively in place like this (only showing 8 pixels wide here):

after 2nd blit (00001111):
________________
________________
________________
________________
________[][][][]
________[][][][]
________[][][][]
________[][][][]
[][][][][][][][]
[][][][][][][][]
[][][][][][][][]
[][][][][][][][]
[][][][]________
[][][][]________
[][][][]________
[][][][]________

3rd blit (mask 00110011):
________________
________________
____________[][]
____________[][]
________[][][][]
________[][][][]
____[][][][][][]
____[][][][][][]
[][][][][][][][]
[][][][][][][][]
[][][][][][]____
[][][][][][]____
[][][][]________
[][][][]________
[][]____________
[][]____________

4th blit (mask 01010101):
________________
______________[]
____________[][]
__________[][][]
________[][][][]
______[][][][][]
____[][][][][][]
__[][][][][][][]
[][][][][][][][]
[][][][][][][]__
[][][][][][]____
[][][][][]______
[][][][]________
[][][]__________
[][]____________
[]______________

with different mask combinations one can make any shape, so long as it is within a 16-pixel range. Most sine scrollers don't exceed 1:1 gradients (a 2:1 gradient could be done but it would need 5 blits).

In fact four blits per 16 pixel columns is WORST CASE behaviour, sometimes the mask will be zero so you can skip those blits altogether.

[pmc]

Looks to be a very interesting solution. Forget the rest of the demo, just make the sinescroller so we can see this in action. Would be cool.

[StingRay]

An interesting thought indeed, however, I am still not convinced it will look like a normal sine scroller. Any of the 16 slices can have any y-position, e.g. col1 = y, col2=y+(whatever). As far as I can see Mrs. Beanbag's approach will give a somewhat static scroller but yes, it depends on the used masks. Also, I'm not sure if it will be much faster since it requires one additional blitter source = more DMA used = slow down.

It would be interesting to see an example of this approach though so it can be compared with the speed of a highly optimised sine scroller.

[Mrs Beanbag]

Sine scroller needs to use two sources and a mask already anyway, in order to blit a single column of pixels, you need a mask with one bit set and combine it with the graphics that's already there from previous blits. Any of the 16 slices can have any position with a 16 pixel range. As long as the wavelength isn't too short there is no problem.

But. Yes. I shall write it and post the source.

[StingRay]

Originally Posted by Mrs Beanbag

Sine scroller needs to use two sources and a mask already anyway, in order to blit a single column of pixels, you need a mask with one bit set and combine it with the graphics that's already there from previous blits.

Yes of course, I know how a sine scroller works. As I understood it your approach needs one additional source to the already used 2 sources. If that isn't the case it'll be interesting to see the result indeed.

[Lonewolf10]

Originally Posted by Codetapper

The starfield in the demo moves so fast that you could probably fake the whole thing with about 10 frames of animation in a loop

I said the same thing yesterday - though perhaps I didn't word it clearly enough:

Originally Posted by Lonewolf10

Plus you could cheat (and be lame) and pre-render the star bit (say 20 frames of half-screens)

Originally Posted by discomeats

someone should just do the demo

I agree


Regards,
Lonewolf10

[Mrs Beanbag]

no only 2 sources, one in the same place as the destination as usual and one 4/2/1 pixels higher. The mask is put straight into BLTBDAT so no DMA needed.

The FIRST blit is slightly different however because it doesn't need to combine with the background at all. That uses two sources pointing into the original graphics, one 8 pixels higher than the other.