A.D.A. Amiga Demoscene Archive

@z5_

Nearly forgot, on "YACA", the State of the Art pisstake, and the '3' graphic are using the custom chips.

The only thing that makes scrolling so smooth on the Amiga is that you have a guarranteed 50 or 60Hz display, and you can sync your scrolling to it safe in the knowledge that it'll be the same speed everywhere.

The chipset can still aid the 060 in things like parallax scrolling, and rasterline effects, but how many recent demos do that kind of stuff?

I'm working on a 3d-engine that makes heavy use of cpu, fpu and blitter =) for soritng, rotating and drawing respectively

chipset owns!

@dalton
But surely the CPU would be faster for drawing? I know that you could be sorting and rotating data in fastmem, while the blitter is drawing the previous frame, but I can't see that being faster than a well written cpu/fpu only 3D engine.

Is this a flatshaded engine? Is it intended to be fast on 020+FPU?

@xeron

I don't really know how fast this will be, but it feels good. I'll reveal my plans as I don't think anyone would be interrested in ripping them =)

I use the s-buffer technique to get a nice optimized list of polygon segments. Then I plot the edges using cpu. Then, while rotating the next frame and generating the segment buffer, I do a fill on the entire screen and maybe copy it onto a background at the same time (all using blitter).

I could not use textures or any fancy shadings with this engine, but I don't have to do a c2p and I can use less bitplanes if it suits my needs. If not fast, this will at least be interresting =)

@dalton

Thinking about it, with clever coding, you could calculate the next frame while the blitter draws the previous one. Once the next frame is all calculated, you can check to see if the blitter made it all the way through the list of polygons, and if not, finish the drawing with the CPU.

This would automatically adjust, so on a slow CPU, the blitter will do more of the work, but on an 060, it will do less. It would be win-win... but of course it would only be flatshaded, or stencilvectors.

@xeron

interresting idea...we'll see where I end up =)

Btw has any of you hardware gurus tried to change 256 colours each rasterline using the cpu instead of the copper? Detecting a change of rasterline would be through polling the vertical bram counter. As soon as it changes line, write to the registers as fast as possible. I know the copper is too slow to change this many colours each line,but maybe the 060 can do it fast enough. If it works, one could have real 24bit pictures on max 18 bit amiga. I should try to code it myself, but it isi always easier to push it onto someone else :)

Aw man.... you stole my idea you bastard! :)
But seriously, I'v been thinking about the same but I'm no Amiga hardware guru my self and I've sort of quit coding on the Amiga anyway :) On the other hand I thought this truecolour trick sounded just too good to be true. If it was possible someone would have already thought of it and tried it out at least 10 years ago. Still I thought it was an interesting idea so I couldn't stop thinking about it :)

Anyway the idea was to use a 256 x 256 screen and draw a pattern to it once looking like this:

(the numbers are the colour indexes)

0 1 2 3 ... 255
0 1 2 3 ... 255
0 1 2 3 ... 255
0 1 2 3 ... 255
0 1 2 3 ... 255
.
.
.
Think of it as a fullscreen gradient from left to right.

For each rasterline change the whole colourmap. You still draw to a buffer in fastram but instead of c2p'ing the buffer to chipram as usual you update the colour regs with it.

A drawback is the screensize. If you want full 320 width you would have to think of some way to share colours, maybe through a kind of shadetable or something. But of course that would probably slow down the whole thing alot. Or maybe one could change the colourmap every 256 pixels?

Does any of this have any root in reality or am I only dreaming? :)

@off-topic:

and I've sort of quit coding on the Amiga anyway :)

ouch...this sucks. really enjoyed your style of making demos :(

off topic :

come on!!.. someone code that effect please

actually....

<mode twilightzone="true">

in graphics.library there are functions to access some copper-things
in a system-friendly way. demo coder never used these ones because direct accesse is always faster on A500.

... but once patched CORRECTLY with a picasso or cybergraphics , if the implementation is enough well done, we could imagine to code COPPERBARS on a clean, hardware independant, API.

(bullshit, but more reallistic for the blitter maybe.)

</mode>

[quote] Anyway the idea was to use a 256 x 256 screen and draw a pattern to it once looking like this:

(the numbers are the colour indexes)

0 1 2 3 ... 255
0 1 2 3 ... 255
0 1 2 3 ... 255
0 1 2 3 ... 255
0 1 2 3 ... 255
.
.
.
Think of it as a fullscreen gradient from left to right.
[/quote]

pfffbr.... :-) :-)

it works, and it was done in really many many many demos. the thing is that you could only do that in AGA because ECS has only 32.... but you could only change the color in a 12bit values, and actually you just "had the time" to change something like 96 colors and then it bugged for the other.... but maybe there was a way to get the whole 255 colors changed on a rasterline. but it was fast, yes. and the last unchanged colors could be used for nice bitmap sprites.
"aerial" and "scream thy last scream" from "mankind" used that, but we really were baaad bad bad at the times.

Hey, don't laugh, ok? :)
It comes as no surprise, as I said someone probably thought of something like this years ago and I'm not much of a hardware guru :) Why could you only do 12bit values on AGA btw? Won't there be time to change all colours even with 060 as Loaderror suggested? Please bear with me if these questions are stupid :) I'll check out those demos even if they might be bad :)

yeah. krabob. give us some language on this

what krabob said.
the "effect" (i'd rather call it a routine) is known as the copper chunky iirc.

some good examples can be seen in:
beyond the future/union (used all the way through for 3d)

generation x/haujobb (used on a waving zoom rotator)

fullmoon/virtual dreams (the fire)

and chaosland/virtual dreams has a copper chunky on an a500 (no aga)!

dr.skull/virtual dreams used copper chunky quite a lot. in the end, every coder that used it had his own pattern to use. e.g. the one in beyond the future is really ugly whereas the ones in fullmoon and generation x are quite nice.

I've seen those demos and the term "copper chunky" does ring a bell but I never knew much about it as you can see :) thanks for clearing it up. Hmmmm... wonder if there is still possible to do tricks on the Amiga that has never been done before? :)

try fading the power led :)

Fading power LED? Dr. Doom and I have a routine that does that. We've never used it, though.

Looks REALLY cool.

Damn, I thought that was my unique routine :0
I have used that in our 1994 music disc Cool Wave 2 while trackloading. Also thought it looked cool.

Ahh crap, then you beat us to it ;-) We were also thinking of making music with the floppy drive, but we figured it would probably kill the drive after a while.

I think there was a program called "Floppy Music". I think it was Thomas Lopatic who wrote that and I think it was released in an issue of the german "Amiga Magazin". But I never tried that.

but is it copper chunky if you do the colourchanging using the cpu?

rload:

Interesting point. Would the CPU enable you to change more palette entries per scanline? Would it make any difference if you're using Cyberstorm, Blizzard or Apollo?

OK...

first:

> pfffbr.... :-) :-)

I laughed because copper chunky was a sooo oooldschool effect... I have almost forgotten it.. I really didn't espect t talk about this in 2005. :-) And the trick is nice, but funny.

you actually didn't change the colour with the CPU, but with the copper !!!
you just (really!) draw '0 1 2 3 ... 255 ' lines on trhe screen, as said dran.

Then, your copperlist must look like:

change color0 to this, change color1 to this, change color2 to this,....
wait 2 or 3 lines...
change color0 to this, change color1 to this, change color2 to this,....
wait 2 or 3 lines...
change color0 to this, change color1 to this, change color2 to this,....
wait 2 or 3 lines...

...and actually, at each frame, you WRITE the new colors in the copperlist, from a chunky 12bit screen, at the places where I wrote "this". Well, just as you would do for copperbars with one color !!!

So, 1 copper instruction is used to change a 12 bit color if i remember well (r=4bit, G=4bit,B=4 bit), but for using the AGA 24bit colors, you would need to do the stupid copper swap for each "color pixel", to be able to change the 12 lower bits of the color. But you can't to do that because the copper is too slow to change so much things while scanning the screen.

Oh it was not scream thy mlast scream, it was BIG FAKE !!!

http://www.pouet.net/prod.php?which=11102

exactly.. the copper is too slow, but what about the 060 polling the beam counter for next line instead of using the copper for changing colours?

@rload

That would be useless anyway because still the CPU has to deal with the speed of chipset access :(


@all

[self-advertising]

Has anybody ever tried the tcs.library (TCS.lha & TCS_demo.lha on Aminet)?
It's a thing I created a few years ago and allows superfast c2p (50+ fps on 030, 76+ fps on 060), plus triple-buffering, blitter-aided rendering, graphic primitives and a lot more...

[/self-advertising]


Bye,
saimo

In the previous post I forgot to mention that TCS
- also permits to put a 256-color screen on top of another 256-color screen with fully variable 8-bit transparency at no CPU cost (no kidding: TCS_demo shows this effect)
- can be theoretically expanded to allow full 24-bit screens (although it would not be worth it quality- and speed-wise)
- does not look good through scan-doublers or graphic cards as it uses SHRES


saimo

Ok.. so register access is too slow then. Kind of guessed that it wasn't really possible.

tcs looks pretty cool. I'll try the demos and stuff tomorrow :)

Yep, chipset access is slow.
And, anyway, even if it had been superfast, an intrinsic characteristic of that technique is that the CPU can't do anything else for almost the whole frame.

As for TCS... well, I'd be glad of hearing your comments :)
Just remember: requires AGA an native video output.


saimo