A.D.A. Amiga Demoscene Archive

        Welcome guest!

  

  

  

log in with SceneID

  

Demos Amiga Demoscene Archive Forum / Coding / Some demo coding questions...

 

Author Message
BalrogSoft
Member
#1 - Posted: 10 Feb 2007 13:52
Reply Quote
Hi, i have some questions now i have my rotozoom working with chunky2planar conversion. I want to make a 64k intro, but i have some demo coding questions.

I have a effect on chunky screen, but i want to overlay a bitmap with transparent color, like smoke bomb demo (http://ada.untergrund.net/showdemo.php?demoid=84) . How it is coded?

Playfields isn't a solution, it leave very few colors for each playfield. Use the chunky screen isn't useful, because if you use a 2x1 c2p then your bitmap will be 2x1 also. And if you use 5 planes for chunky screen and 3 planes for overlayed bitmaps, but the contain of the chunky screen will affect to the bitmap colors, it is possible on AGA use a 5 planes playfield and a 3 planes playfield?, because AGA guide says about BPLCON0 that bit 10 is used for double playfield, odd planes is one playfield, and even planes is the other playfield, only 16 colors for each playfield.

And if i need a background, and a small chunky screen and overlayed bitmaps, how is painted the background?
Cefa
Member
#2 - Posted: 11 Feb 2007 01:40 - Edited
Reply Quote
Well maybe you could after the c2p is finished "OR" or was it xor (dont remember havent touched anything to do with coding for years :) then copy the "Picture" bitmap with the result of the c2p bitmap (you could also change the c2p routine to do this for you) . You will then merge the two bitmaps together and the "picture" bitmap would be on top of the c2p. Your "Picture" bitmap would of course use the same palette as the c2p bitmap so choose the colors carefully, but you would have access to all the palette of the screen.

If you only want to display some simple four color text maybe using the sprites could also work. But then you would lose cycles to the sprite chip.

//Cefa
sp_
Member
#3 - Posted: 11 Feb 2007 09:41 - Edited
Reply Quote
Forget the double playfield bit. Just make a routine that adjust the colormap. Then you can
have 2 playfields 7bpl 1bpl, 6bpl-2bpl, 5bpl-3bpl. etc.. Since you are using a 2x1 c2p I think
using sprites is the best option here. With the hardware you can set up a spritescreen of 256x256
pixels in 4bpl.
In my kindergarden 1996 vinning demo I use a 6bpl 1x1 c2p, and a mask in the upper 2 bitplanes
to produce more colours. The arnold images where displayed on a spritescreen. The demo is not good enough to be here on ada. ;) but here is a link if you want some inspiration. The production look quite ugly in winuae due to the lack of vblwait / and buggy shit code.:D

http://www.pouet.net/prod.php?which=9005
BalrogSoft
Member
#4 - Posted: 11 Feb 2007 14:51 - Edited
Reply Quote
Thanks a lot for your help.

Now i have more clear on my mind the options to make this. I found a problem with c2p, some pixels on texture show wrong colors, maybe is a fault on my picture to asm tool, but using a 320x200x8, with a 1x1 pixel, i have strange color problems, i found on Amycoders goraud compo that use Kalms c2p, and use a duplicated copper list, i tried this method, but it don't solve the problem.

Anyway this is the code and executable with a 2x1 pixel size, maybe someone found it useful:
Rotozoom.zip
Cefa
Member
#5 - Posted: 11 Feb 2007 16:46
Reply Quote
No i dont think my suggestion would work now that i think a litte more about it. Stupid of me :)
dalton
Member
#6 - Posted: 11 Feb 2007 18:30
Reply Quote
you could use wide 16 colour sprites..

but here's another suggestion:

create a one bitplane mask from the overlay picture and put it in fastmem. then (while rendering rotozoomer) for every 32 pixels read a longword from the mask. use add.l dX,dX and carry-branch (bcc or bcs) for each pixel to skip writing the masked out pixels.

some effects will allow you to avoid not only writing but also calculations of masked out pixels. now i did'nt check your code but since it's a rotozoomer i assume you will need to interpolate also over hidden pixels or the image will be scrambled.
sp_
Member
#7 - Posted: 12 Feb 2007 14:59
Reply Quote
Another solution will be to use the blitter. If you use a cpuonly c2p and have an amiga with fastmen. The blitter can work while doing the c2p. but at the cost of chipmemspeed.
krabob
Member
#8 - Posted: 22 Mar 2007 00:25
Reply Quote
> I want to overlay a bitmap with transparent color, like smoke bomb

hmmm... lots (most) of 68030 demos from the 1997/2000 period just uses a 256 color chunky screen, and precalculate colortables (256xshades->256 )
I mean something like:

move.w shadeindex,d0 ; shade force on bit 8-15.
move.b (screen),d0 ; previous color
move.b (colortable,d0.w),(screen)+

Sometimes we actually used tools to compute the table outside the demo,
(truecolor to 256color remap algorythm is another question.)
That's what the karate engine does btw. You were far more free thereafter to make different shades in the same screen.
so we were not using planes & palettes tricks at the time...

Don't believe the other coders here if they told you they used any copperlist/blitter effects for aga demos after 1996. They just all massively used 256 colors chunky screens.

ah... there was also the HAM6 screens on this period, in which case we were in full 18b truecolor...
sp_
Member
#9 - Posted: 22 Mar 2007 03:53 - Edited
Reply Quote
He asks for a 1x1 bitmap on top of a 2x1 chunkyto planar mode...

"Use the chunky screen isn't useful, because if you use a 2x1 c2p then your bitmap will be 2x1 also."
.
Shadetables are common in most modern demos. Some years ago I saw some democode by loaderror. He used 2 seperate buffers for the light, and the txture . For each frame he performed a shadetable lookup on every pixel..

The code was something like this:
(Not optimized example. To optimize place the mergecode between the memory writes so that it wll go copyspeed. On 030 50mhz I could pipline 6 cycles on every fastmem memwrite)

Performes shadetable lookup on 8 pixels.

move.l (a0)+,d1 ;chunkybuffer
move.l (a0)+,d3 ;chunkybuffer
move.l (a1)+,d0 ;lightbuffer
move.l (a1)+,d2 ;lightbuffer

move.l d3,d5
move.l d1,d7
lsr.l #8,d7
lsr.l #8,d5
eor.l d0,d7
eor.l d2,d5
and.l d6,d7
and.l d4,d5
eor.l d7,d0
eor.l d5,d2
lsl.l #8,d7
lsl.l #8,d5
eor.l d7,d1
eor.l d5,d3

move.b (a2,d0.w),(a3)+
move.b (a2,d1.w),(a3)+
swap d0
swap d1
move.b (a2,d0.w),(a3)+
move.b (a2,d1.w),(a3)+
move.b (a2,d2.w),(a3)+
move.b (a2,d3.w),(a3)+
swap d2
swap d3
move.b (a2,d2.w),(a3)+
move.b (a2,d3.w),(a3)+
sp_
Member
#10 - Posted: 22 Mar 2007 04:14 - Edited
Reply Quote
In some cases if the palette is sorted by intensity and less than 128 colors are used the following loop can be used..

move.l (a0)+,d0 ;chunkybuffer
move.l (a0)+,d1
move.l (a1)+,d2 ;lightbuffer
move.l (a1)+,d3

sub.l d2,d0
sub.l d3,d1

move.l d0,(a2)+
move.l d1,(a2)+

 

  Please log in to comment

  

  

  

 

A.D.A. Amiga Demoscene Archive, Version 3.0