| Author |
Message |
astrofra
Member |
Dear all, I'm currently working on a little demoscene project, using the C language exclusively along with the graphics.library. So far, I've been able to do some hardware scrolling, blitting with mask, copper-generated sky gradients and whats not ('Hi' to the #Amycoders fellow for their numerous advices)... However, I'm wondering how to program a user copper list in *AGA*. Afaik, the graphics.library allows the pogrammer to build a custom copper list that cooperates with the whole system, thanks to a few C macros (CINIT, CWAIT, CMOVE, CEND), but I couldn't find any mention regarding the AGA color registers (24bits colors instead of 12bits). Any advice would be appreciated (url, piece of C code...) (Oh, my... Lamest typo ever in the post's title.) |
Angry Retired Bastard
Member |
You have to split the 24bit color into 2x12bit writes to the same register, first the 444 most significant bits and then the 444 low bits. Inbetween those writes you change bit9 of $dff106. Pseudocode:
hirgb = (rgb24 & $f00000)>>12 | (rgb24 & $f000) >> 8 | (rgb24 & $f0) >> 4;
lorgb = (rgb24 & $0f0000)>>8 | (rgb24 & $0f00) >> 4 | (rgb24 & $0f);
CMOVE( $dff180, hirgb);
CMOVE( $dff106, $0200);
CMOVE( $dff180, lorgb);
This sets the background color to a 24bit value. A couple of things to keep in mind: - When setting multiple colors you don't want to switch dff106 for ever single value (wasted bytes and cycles for the copperlist). Instead you clear bit9 of $dff106 first, then set the high-bits for all color regs, then set bit9 of $dff106, then set all the low-bits. - You always set the high-bits *before* the low-bits. (The low-bits are implicitly set to the same as the high-bits due to AGA backwards compatibility with OCS/ECS). |
astrofra
Member |
Wow, that's exactly what I was looking for.
Thanks!
I will post the result as soon as I get it working.
(Mr Modo, if you read this, feel free to edit the title of the post, so that I won't endure the endless shame of my horrible typo :))
|
z5
Admin |
@astrofra: i would gladly change the title if only i could find the option to do so. I could have sworn there once was an option to edit thread titles.
I was curious though: are you planning on releasing your demo sometime in the future? Would be cool if you did! Also, do you have previous experience in (demo) coding or is this your first project?
Edit: nevermind those questions. I just read demo_strings.c :) Looking forward to your next amiga demo, Fra. Hopefully with some more of that lovely pixel art from Ptoing.
|
astrofra
Member |
Hey z5!
Yes, as you probably saw in the source code, this demo should be released soon, in a few months at least.
It won't probably meet the AGA standards people are used too (even on a stock 1200) but it will run at 50fps.
My previous Amiga demo (coded in C as well) was really slow even on a 020 and loaded with memory leaks. Demoscene people are kinda forgiving with Amiga demos but I won't allow that a second time :)
I'll keep you posted.
|
astrofra
Member |
Dear all! I released the demo I was working on. After many considerations I finally decided to cut all "AGA features" from this one and try to make it work on an A500. Next one might be in AGA :) Thanks anyway for your help above. http://www.pouet.net/prod.php?which=65580 |
corial
Member |
Well done, Fra! Really nice to have some more active Amiga coders. Looking forward to see what you can do with the AGA chipset too.
|
z5
Admin |
What Corial said. Quite a neat little intro and i'm quite jealous about that C coding you have going on. Also, it's always interesting to see a graphician doing code (it shows in the design and colors). The only thing that bothers me a bit is the music in a sense that it is really nice but so short. It's basically one pattern continually repeating for more than 7 minutes?
Looking forward to the next one (hopefully on AGA this time)!
|
astrofra
Member |
Thanks guys :)
Indeed, I need to explore what the graphics.lib can do with AGA :)
About the music, I totally plead guilty. My code eats so much CPU so there wasn't any cycle left to replay a protracker. That's why I used a short sample :')
Quite lame, even if it sounds OK, thanks to Paula...
See you guys on AGA and thanks for the great support!
|
rloaderror
Member |
I tried using this system approach to making copper lists. It works nicely for 1 shot copper list setup, but I discovered that when changing copperlist every frame there is a performance penalty.
// Alloc virtual copper list
cop = (struct UCopList *)AllocMem( sizeof(struct UCopList), MEMF_PUBLIC|MEMF_CLEAR );
CINIT(cop, num_cop_instructions)
CWAIT(cop, 0,0 )
CMOVE(cop, color0, mycolor )
CWAIT(cop, 1,0 )
CMOVE(cop, color1, mycolor2 )
:
CEND(cop)
// Put it in the viewport
screen->ViewPort.UCopIns = cop
// This makes the new copper list visible, however it is very heavy
RethinkDisplay()
I've tried exchanging the RethinkDisplay() with MrgCop(view) which seems lighter and it works if the list was first installed using RethinkDisplay and then subsequently updated using MrgCop. Still it is quite slow. Is there any more efficient way to do this using the system? |
rloaderror
Member |
I found the actual copper list being executed at ViewAddress()->LOFCprList->start. It doesn't appear to change address between frames. So as a last resort I could perhaps poke this one directly.
|
dodke
Member |
How about poking $dff080 directly?)
|
rloaderror
Member |
That's the traditional way :)
I find now that whenever I poke registers directly, there is a system function that pokes them back into something else in the shadows. Not sure how to stop it except adding the typical amiga demo startup. (maybe LoadView(NULL) makes me able to control this part myself?).
I started coding with a system friendly startup from previous demos, so I just continued in this fashion. I found ways to do most things I wanted (screen modes/sprites) quite easily so it is only this thing remaining.
Poking that copper list I mentioned above works now. However I'm having visions of it crashing and burning some time in the future already.
|
Blueberry
Member |
LoadView(NULL) does exactly that: it tells the system (nicely) to stay away from display stuff.
I would say LoadView(NULL) + poking $dff080 is more system friendly (and robust) than poking into the system's copperlists.
The latter approach sounds to me a bit like "It is rude to use the horn to tell people to get out of the way, so I just run them over instead." :)
|
rloaderror
Member |
I call it working from _within_ the system! :D Similarly to when I made a system friendly sprite engine for overlays just recently. Nicely reserve the sprite and check for errors. BUT WHAT!? It REFUSED me sprite 0 because it is reserved for that *#@$% mouse pointer?! Come on! The system doesn't understand my needs! Is that ugly mouse pointer going to ruin my vacation demo experience? // Reserve sprite from system
LONG sprite_num = GetExtSprite(hws_img->hwsprite[s],GSTAG_SPRITE_NUM,s,TAG_END);
if ( -1 == sprite_num )
{
printf( "Warning: Sprite %d already allocated, but stealing it anywayn", (int)sprite_num );
hws_img->hwsprite[s]->es_SimpleSprite.num = s;
} else {
printf( "Allocated sprite: %dn", (int)sprite_num );
}
Anyone know how to make the system give up the mouse pointer sprite ? :D |
astrofra
Member |
Sorry for the late reply, Rloaderror. I think I'm going this to claim back the mouse pointer. Not super clean, but it worked : https://github.com/voitureblanche/projet-secret/blob/master/src/fx_routines.c#L130
CMOVE(copper, *((UWORD *)SPR0PTH_ADDR), (LONG)&blank_pointer);
CMOVE(copper, *((UWORD *)SPR0PTL_ADDR), (LONG)&blank_pointer);
|
rloaderro
Member |
Thanks :) I'll try this the next time I'm getting the idea of doing system friendly amiga coding.
|
