Attributkrock
Attribut clash (även känd som färgclash eller bleeding ) är en skärmartefakt som orsakas av begränsningar i grafikkretsen hos vissa 8-bitars hemdatorer i färg , framför allt ZX Spectrum , där det innebar att endast två färger kunde användas i vilken 8:a som helst. × 8 brickor med pixlar. Effekten märktes även på MSX -programvaran och i vissa Commodore 64- titlar. Lösningar för att förhindra att denna gräns blir uppenbar har sedan dess ansetts vara en del av Spectrum-programmerarkulturen.
Det här problemet inträffar också med de "semigrafiska lägena" (textlägen med grafikfunktioner) i Color Computer och Dragon , men dessa datorer har också icke-tillskriven grafik och med bättre upplösning. Flera videospelskonsoler från eran hade sådana videolägen som orsakade sådana begränsningar, men tillät vanligtvis mer än två färger per bricka: NES (Famicom) hade bara ett läge, som också var "semigrafiskt", och tillät fyra färger per 16× 16 "block" (grupp om fyra 8×8 brickor) men 16 per skärm. Super NES tillät 16 färger per bricka men 256 per skärm (bland andra förbättringar), och detta gjorde artefakten mycket svårare att lägga märke till, om alls (förutom för de som var tvungna att programmera enheten).
Orsaker
Attributclash på ZX Spectrum orsakades av dess idiosynkratiska skärmminneslayout, designad på ett sådant sätt att den minimerar minnesanvändningen av rambufferten och optimerar för textvisning istället för grafik. Istället för att begränsa färgpaletten för att spara minne, lagrade Sinclairs design pixelbitmapp och färginformation i separata minnesområden. Medan bitmappen specificerade tillståndet för enskilda pixlar (antingen på eller av), motsvarade färginformationen (eller "attributen") textteckenmatrisen – 24 rader med 32 kolumner – med en byte per 8x8 pixlar teckencell . Denna byte kodade två 3-bitars värden, kända som INK (förgrundsfärg) och PAPER (bakgrundsfärg) efter de BASIC- instruktioner som användes för att definiera färgvärdena. Två andra binära värden inkluderades i ett attribut; en LJUS- bit som indikerar en av två ljusstyrkanivåer för de två färgerna, och en FLASH- bit, som, när den ställdes in, gjorde att de två färgerna byttes med jämna mellanrum. Detta schema gav 15 olika färger: de åtta kombinationerna av rött, grönt och blått på två ljusstyrkanivåer (förutom svart, som såg ut på samma sätt vid båda ljusstyrkorna). Således kan varje 8x8 pixelblock bara innehålla 2 färger av de 15 tillgängliga, som båda måste vara från antingen LJUSA eller icke-LJUSA halvorna av paletten. Att försöka lägga till en tredje färg i ett område på 8x8 pixlar skulle skriva över en av de tidigare färgerna.
ZX Spectrum använde 6144 byte för bitmappen, där en byte representerade åtta pixlar, och använde 768 byte för färgattributen. Detta ger totalt 6912 byte för hela grafikskärmen, en relativt liten summa för en dator från Spectrums era med "färg"-möjligheter. Denna grafikarkitektur behölls ända fram till Sinclairs och Amstrads senare omdesigner av Spectrum, fram till Amstrads slutliga modell, ZX Spectrum +3, trots att efterföljande modeller hade innehållit 128 KiB RAM, vilket minskade behovet av att spara minne på detta sätt . Arkitekturen behölls för att förhindra förlust av bakåtkompatibilitet .
Attribut användes av en mängd andra datorer och konsoler, inklusive Commodore 64 , MSX och NES , även om storleken på attributblocken och antalet färger per block varierade. Men med användning av hårdvarusprites kan attributkrock undvikas.
Thomson MO5- och TO7 -mikrodatorerna, Oric 1 , MSX 1 - arkitekturen och andra system baserade på Texas Instruments TMS9918- skärmkontroller visar en mycket liknande begränsning: för varje grupp om åtta pixlar horisontellt är endast två färger av 16 tillgängliga , vilket ger en liknande men mindre allvarlig effekt än med Spectrum. MSX 1 hade inte bara en enda färgattributbyte tillgänglig för en hel 8x8 pixelarea, som var fallet med Sinclair Spectrum, utan åtta, med en attributbyte för varje 8x1 pixelgrupp. Således, medan Spectrum var begränsat till ett färgpar för en kvadratisk yta på 8x8 pixlar, var MSX 1 endast begränsad till ett färgpar för en "linje" med åtta intilliggande pixlar. Dessutom kunde MSX1 använda sprites som inte var bundna till några attributclash-problem (även om MSX 1-sprites hade sina egna begränsningar, som att vara monokroma).
I praktiken hjälpte denna tekniska fördel ofta inte MSX 1-systemen att producera bättre bilder. Problemet för MSX 1 var att många europeiska mjukvaruföretag som konverterade Spectrum-spel till MSX 1 ignorerade alla förbättringar som MSX 1 hade jämfört med Spectrum, och därför hade de resulterande MSX 1-versionerna samma mängd attributkrockar som de ursprungliga Spectrum-spelen ( Jack the Nipper II: In Coconut Capers är ett exempel på detta). För att underlätta konverteringen kopierade mjukvaruutvecklarna helt enkelt det enkla attributbytevärdet för Spectrum till alla åtta motsvarande attributbyte i MSX 1. Av samma anledning ignorerade programvaruföretagen även sprite-funktionerna hos MSX 1, och eftersom videon skärmkapaciteten var annars ganska lika (256×192 upplösning, 16 färger), båda systemen producerade praktiskt taget identiska skärmar för samma spel. Däremot japanska MSX 1-spel [ vilka? ] använde alla funktioner i MSX 1, vilket ofta resulterade i snyggare spel [ citat behövs ] .
Effekter
För att undvika attributkrockar måste statiska grafiska displayer konstrueras med omsorg. Fint detaljerad färggrafik var omöjlig, eftersom färg bara kunde appliceras i 8×8 pixelblock. Noggrann design kan ge imponerande resultat, liksom synkronisering av färgförändringar till skärmens uppdateringsfrekvens - vanligtvis en tv-apparat.
Men animerade skärmar var svårare - en tydlig nackdel i en maskin vars primära användning var att spela videospel . Om bara en pixel i ett 8×8-block färgades om eftersom en rörlig del av skärmen rörde vid den, skulle hela blocket ändra färg. Så detaljerad rörlig grafik fick stora fula kanter av snabbt växlande färger att följa dem runt.
Lösningar
Tidig programvara ignorerade helt enkelt problemet. Senare var standardlösningen att använda färg för statiska visningselement – som en dekorativ kant runt skärmens kanter, som kan inkludera partiturvisningar och så vidare, eller någon form av instrumentering – med ett mindre centralt monokromt område som innehåller alla animerad grafik. Detta gjorde också grafiken snabbare, eftersom mindre av skärmen behövde uppdateras – både en mindre region, plus att endast pixelinformation ändrades och färgområdet lämnades orörd.
Vissa Spectrum-program, som FTLs Light Force , använde extremt noggrann grafisk design för att uppnå rörlig grafik i fullfärg, huvudsakligen genom att begränsa både designen av skärmelementen och deras rörelsevägar till gränser för 8×8 färgupplösning. De rörliga elementen var alltså relativt stora och ganska blockiga eller fyrkantiga, och deras rörelse var begränsad, men detta var inte visuellt uppenbart och åsynen av rörlig fullfärgsgrafik var enormt imponerande för Spectrum-ägare.
Inga mainstream-utvecklare lyckades hitta en lämplig allround-fix för attributclash-problemet, utan föredrar istället att använda den monokroma grafikmetoden när snabb och tydlig grafik behövdes, och fullfärgsgrafik när situationen tillät.
Det var möjligt genom att vara noggrann uppmärksam på timing för att modifiera attributområdet för RAM vid vissa specifika tidpunkter när displayen ritades - låt displayhårdvaran rita en rad på displayen, ändra sedan attributet RAM innan nästa rad dras för att ge effekten av olika attribut för varje enskild rad. Dessa ändringar måste göras i mjukvara och var tidskrävande att programmera, vilket innebär att denna teknik vanligtvis var begränsad till specialeffekter. Denna teknik var också mycket populär i demoscenen .
Problemet och lösningarna
De flesta spel före 1987 ignorerade attributkrockar. Vissa senare spel, som Knight Tyme och Three Weeks in Paradise, gjorde det möjligt för spelare att välja mellan två lägen för attributkrockar: ett som ignorerade huvudkaraktärens attribut, blandade karaktären i bakgrunden och vice versa, prioriterade karaktärernas färgschema framför bakgrundsbilderna. .
En annan lösning var att helt enkelt återge grafiken i två färger, även känd som monokrom, som gjordes med Spectrum-versionen av Knight Lore 1984.
Många spel använde fullfärgsbakgrunder och "karaktärsrullning" (där miljön rullades åtta pixlar åt gången), men monokroma sprites som var effektivt genomskinliga, som i Double Dragon , ritades på ett sådant sätt att de sticker ut och undviker beroende av färg. Många spel använde den här metoden med mjuk pixel-för-pixel-rullning, men attributkrocken när element i ett teckenblock "överfördes" till nästa var tydligt synliga.
Ett framträdande (och mindre framgångsrikt) exempel på användningen av fullfärgsgrafik var Spectrum-konverteringen av Altered Beast . Spelet lider av betydande attributkrockar.
Programmeraren Don Priestley utvecklade en distinkt stil för flera av sina spel genom att använda stora, tecknade serieliknande sprites som var noggrant designade för att sträcka sig över hela karaktärsblock utan att verka onödigt fyrkantiga. En nackdel med den här tekniken var att spelet måste utformas kring grafiken, och det var därför inte användbart för portar från andra plattformar. Spel som använde denna teknik inkluderar Popeye , The Trap Door , Through the Trapdoor och Flunky . Andra utvecklare som använde en liknande teknik var Mike Singleton , med Dark Sceptre , och Gang of Five, med Dan Dare: Pilot of the Future .
1994 utvecklade programmeraren Igor Maznitsa en multi-CPU konceptplattform "ZX-Poly" baserad på ZX-Spectrum-128; Plattformen gör det möjligt att undvika attributkrockar och kan till och med färglägga många gamla spel utan ändringar i körbar kod.
- "FAQ: Referens" . WorldOfSpectrum.org .
- Surman, David. "Arcade Colour, Illustration and Attribute Clash 1979 - 89" . Academia.edu .
- Smith, Tony (2012-04-23). "Grattis på 30-årsdagen, Sinclair ZX Spectrum" . Registret .
- Källor till ZX-Poly-emulatorn och beskrivning av plattformen