Share
HTML er språket som nettet er bygd inn, og det er en slags merkelig dyr. Selv om det opprinnelig var ment som en måte å enkelt dele akademisk informasjon over på Internett, har den blitt sakte forvandlet for å imøtekomme det medierike miljøet vi kjenner og elsker. På grunn av den tilfeldige naturen til HTML (og JavaScript, programmeringsspråket som manipulerer elementer i HTML og gjør dem interaktive), noen ganger må vi tenke utenfor boksen litt. I denne opplæringsserien vil jeg vise deg hvordan du gjør cross-browser animasjon ved hjelp av en metode som kalles spriting. Og fordi dette er en læringsmulighet, vil vi gjøre alt uten noen eksterne biblioteker (som jQuery).
Dette vil bli en serie med fire deler. Jeg forklarer at jeg skriver i del ett (denne artikkelen) med noen grunnleggende JavaScript, men i senere avdrag vil vi flytte inn i noen mellomliggende teknikker som innkapsling, hendelseshåndtering og berøringsskjermstøtte.
Så la oss komme i gang!
Animasjon er basert på et fenomen som kalles persistens av visjon, som i utgangspunktet sier at hvis hjernen ser mange lignende stillbilder raskt nok, så vil det virke som om det er et bevegelige bilde. Alle slags film eller video bruker denne grunnleggende teknikken. Mange litt forskjellige rammer vises i rask rekkefølge for å få noe til å virke som å flytte. Film går vanligvis til 24 bilder per sekund (1), mens kringkastingstjeneste i Nord-Amerika blir vist på 29,97 bilder per sekund (2). Så med andre ord, hva vi vil gjøre er å lage noe som viser lignende rammer veldig raskt (flere ganger i sekundet).
Det er to grunner til at animasjon er vanskelig å bruke på nettet:
En vei rundt disse problemene er å lage et spritark. I elementer som divs, vi kan sette et bakgrunnsbilde for div som kan være større enn selve elementet. Vi kan også sette bakgrunnsposisjonen slik at vi bestemmer nøyaktig hvilken del av det større bildet som skal vises. Et spritark er et større bilde laget av flere mindre bilder som vi kan bevege oss rundt, slik at det kan erstatte mange små bilder. Ta en titt på eksemplet nedenfor, ved hjelp av J, maskot av firmaet Joust Multimedia:
Selv om det er ti forskjellige bilder av J, plasseres de sammen på en større PNG-fil (vi bruker PNGs fordi de kan vise gjennomsiktighet). Hvis vi har en div det er bare størrelsen på ett av bildene, og vi setter denne PNG som bakgrunn, den vil se ut som et enkelt bilde.
Se Hazdm på CodePen.
Selv om dette virker som en masse problemer med å gå gjennom for å vise et bilde, løser denne metoden de to problemene vi hadde før. Med svært lite JavaScript (en linje!) Kan du endre bakgrunnsposisjonen til a div, og det fungerer på alt. Da alle disse rammene er på samme bilde, vil det bare ta en forespørsel om å laste det bildet på siden. Så, når siden laster, kan den bytte mellom sprites uten problem i det hele tatt.
Så hvordan setter vi dette opp for å animere lett da? Det første trinnet er å lage sprite-arket. Du vil ønske å vite hva de endelige dimensjonene til bildet ditt skal være, og plass som sprites tilsvarende i et rutenett. For eksempel vil mitt J-bilde bli 40px bredt ved 50px høyt, så jeg la opp spritesne mine nøyaktig 40px fra hverandre horisontalt og nøyaktig 50px fra hverandre vertikalt. Det vil sannsynligvis være lettest hvis du setter startsprite i øverste venstre hjørne.
Da skal vi sette opp en div med litt CSS for å sikre at alt ser riktig ut:
Og her er vår CSS for å sikre at sprite viser riktig:
Accentsconagua
.karakter / * * Veldig viktig at vi stiller høyden og bredden på * våre tegn til høyden og bredden av sprites * / høyde: 50px; bredde: 40px; / * * Vi må plassere dem helt slik at vi kan få full kontroll over deres posisjon i scenen * / posisjon: absolutt; venstre: 100px; top: 120px; #j / * * Og nå setter vi bakgrunnsbildet for tegns div * for å være det første sprite (øverst til venstre) * / bakgrunnsbilde: url ('j.png'); background-repeat: no-repeat; bakgrunnsposisjon: 0 0; Legg merke til følgende:
div til størrelsen på vår sprite'No-repeat' '0 0'-Dette vil vise sprite i øverste venstre hjørneNå vil det bare ta en enkelt linje med JavaScript for å endre bakgrunnsposisjonen for å vise neste sprite.
document.getElementById ('j'). style.backgroundPosition = '-40px 0px'; Her velger vi elementet (med id = 'j'), og angi stilattributtet 'BackgroundPosition'. Legg merke til at det er stavet 'BackgroundPosition' i JavaScript, og ikke som 'Bakgrunns stilling' i CSS. Legg merke til at i JavaScript, den 'Px' er nødvendig for både x og y mengden-vi kan ikke bare passere tallene. Og fordi vi beveger bakgrunnsbildet, må vi flytte det i motsatt retning fra det du kan forvente. For å flytte til sprite til høyre, må vi få bildet til å flytte 40px til venstre.
Nå, hvis vi bare har noe enkelt å utføre denne koden (som en knapp), kan vi se at rammene endrer seg i handling: Kassen gjøres på Codepen.
I tillegg kan du være interessert i å ta en titt på kildekoden for denne siden også. Den har alle eksemplene her med grundige kommentarer. Og her er sprite-arket jeg bruker.
Det vi har dekket i denne opplæringen er en god start, men det er egentlig ikke en skikkelig animasjon. I del to av denne serien vil vi faktisk animere litt løp og hoppe, ved å lage løkker med de forskjellige sprites.
Ved del fire, vil vi skape mouseovers for litt robot handling. Se ByGtv Codepen for forhåndsvisning.
Selv om dette kan være en fin måte å animere på nettet, er det noen ulemper. For det første kan det kreve at du oppretter hver enkelt animasjonsramme, noe som kan være tidkrevende. For det andre har nettlesere ikke den mest nøyaktige timeren for animasjon, så hvis det er kritisk for animasjonen din å bli tidsbestemt, så virker dette kanskje ikke. Endelig har mobil Safari (brukt på iPhone og iPads) en "funksjon", der hvis du har et bakgrunnsbilde som er enten større enn 2 MB eller større enn 1024 x 1024 x 3 piksler (eller 3 145 728 totalt piksler), vil det automatisk rescale bilde, ødelegger spredningseffekten. Dette betyr at virkelig store sprites, eller animasjoner med et stort antall sprites, er ute av spørsmålet. Men for enkle, små animasjoner som du vil være veldig interaktiv, er dette en enkel og flott måte å få noe som fungerer overalt.
1. Før lyd ble introdusert med film, var det egentlig ikke en vanlig bildefrekvens. Kameraene ble betjent av en håndvev, så hvis du hadde en nybegynner kameramann, kan rammeprisen senke og øke utilsiktet. På samme måte var mindre anerkjente teatre beryktet for å fortelle sine projeksjonister å svekke projektoren raskere for å øke hastigheten på showet slik at de kunne passe inn i flere screeninger. Dette er også grunnen til at vi stereotypisk tenker på pre-sound-filmer som beveger seg komisk raskest, de fleste ble filmet rundt 16 til 18 fps, så når vi spiller dem i dag med 24 bilder per sekund, beveger de seg raskere enn de var opprinnelig ment.
2. TV ble opprinnelig sendt på 30 fps i Nord-Amerika, men farge-tv forårsaket en feil når den ble vist med den hastigheten. Ingeniører fant ut at de kunne fikse det ved å redusere bildesatsen med 0,1%, derfor er den nå satt til 29,97 fps. Dessuten, i tillegg til alle de tøffe tekniske problemene som er involvert i å konvertere en film i 24 fps for å vise på fjernsyn på 29,97 fps, har det vist en interessant effekt på publikum ved å vise fjernsyn på en raskere fps. Mange mennesker som ser på testfiltrene av "The Hobbit" på 48 fps, rapporterte at den økende bildesatsen gjorde filmen til å se "billigere", selv om den var mye høyere kvalitet enn en vanlig film, bare fordi de hadde vokst til å knytte raskere bildefrekvenser med å se noe på tv.
