brett@sylvester.umd.edu (Brett S Bourbin) (12/17/88)
Oh boy! After spending a full five days trying to track down a item I concidered to be a "bug" in my code, I found out it really wasn't. I have been trying to build a custom View HAM screen, which would also have sprites on it. So like every good programmer (i.e. NOT HACKER. 8^)), I followed the RKM and initialized everything, including V_SPRITES!V_HAM in the View and ViewPort structures. This should tell the MakeVPort function that I want HAM in the bplcon0 register (for the hardware hackers), and that I want the sprite color registers loaded in the Copper list. Well, to make a long story short, (I know, TO LATE) this was not the case. What I got was a screen with sprites, but the colors of the sprites were all wrong. They all were shades of grey (i.e. the default palette). So I tried to change them AFTER the View was built and loaded (LoadView) with the SetRGB4 call on all the sprite registers with still no result. Now I have to think that I am doing something wrong. After about 20 more edits of the subs.asm file (the one that builds the View), I decided to test one more thing -- removing the V_HAM from the View and ViewPort. Know what, I got the sprite colors that I wanted! So tell me CATS, why if I specifiy a HAM screen are the sprite color registers not loaded in the Copper list? I looked at the Copper list and found it was actually loading the grey colors, after I told it twice, (once in the LoadRGB4 and then SetRGB4) to change them? Is this a bug with the system software, or does something else have to be specified that is not in the manuals. The one solution I might have to fall back on is creating a user copper list to change the colors, but that seems like cheating. 8^) --Brett S Bourbin __ __ _ __ _ Instructional Computing Programs -- Univ of Maryland | || | / || || \ | || || || || | INTERNET: brett@SYLVESTER.UMD.EDU | || || || || | bbourbin@UMD5.UMD.EDU \_||_/ |__||__||__| BIX: brettb College Park BITNET: bbourbin@UMDD
jamiep@ncoast.UUCP (Rich Garrett) (12/25/88)
This is true for 1.2 software (don't know about 1.3 since I'm using a different method now): The copper list will not include the sprite color setup code for ham screens/viewports under ALL conditions. It may even work correctly sometimes. In general, though, HamViewPort sprite color register setup stuff is ignored. A workable (but not nice! fix) is to write the hardware sprite color16,17 etc registers directly. This clears up the "bug" but is not "nice" to the system...anyone could come along and re-change the sprite colors on you. You are not the only developer who has spent many days tracking this one down....it IS rather esoteric, though, eh? Jamie Purdon