Svenska ElektronikForumet

Min rutin kräver som mest en tabell som motsvaras skärmens pixelhöjd.

Klipp polygonen i överkant och underkant (och även sidorna) du kan ju ändå inte rita utanför skärmen.
Jag har glömt vad denna klipprutin heter, men den klipper linjer längs skärmkanter, eller andra valda områden.
Det är i och för sig ingen svår beräkning.
Men eftersom du redan har linjedragning så har du säkert koll på både Bresenham och linjeklippning.

Metoden att läsa från skärm är inte bra, det kan funka för enkla tillämpningar, men med en riktig beräkning kan man med vektorgrafik rita över hur stor yta som helst. Det som platsar på skärmen klipps ut på nolltid.

victor_passe skrev:Du kan ju börja högst upp på vänster av skärmen.
Gå pixel för pixel åt höger och när du stöter på en pixel som redan är svart(En av dina linjer) så sätter du flaggan inside=1.
Nu fortsätter du till höger men färglägger varje punkt. När du träffar på en punkt som redan var svart(En annan av dina linjer) så sätter du inside=0 och slutar att färglägga.
Fortsätt med detta för hela raden och sedan varje rad.

Den rutinen skulle ju i många fall resultera i något som ser ut ungefär såhär: När "markören" kommer fram till översta hörnet så finner den en svart pixel, sätter flaggan inside=1 och fortsätter sedan att färglägga raden ut. Nollas inte flaggan för varje linje kommer den även fortsätta färglägga på nästa rad.

Tips: wikipedia.org/../Bresenham's line algorithm

Hanns linjealgoritm har jag bra koll på
Jag ska testa lite olika av era metoder och återkomma. Ska se om jag inte lyckas få detta att fungera.

kolla i "foleyvandam" din bästa referens till grafikalgorithmer
googla "foley van dam"

alternativt kanske kolla i såsen till gimp

victor_passe skrev:Gå pixel för pixel åt höger och när du stöter på en pixel som redan är svart(En av dina linjer) så sätter du flaggan inside=1.
Nu fortsätter du till höger men färglägger varje punkt. När du träffar på en punkt som redan var svart(En annan av dina linjer) så sätter du inside=0 och slutar att färglägga.
Fortsätt med detta för hela raden och sedan varje rad.

Det var så här som vektorgrafik fungerade på den gamla Amiga-datorn, men i hårdvara. Men man var tvungen att förstå hur hårdvaran fungerade för att kunna göra rätt.
Det var länge sedan... Hmm.. låt se nu hur det var:
- Om du ska transformera punkter, gör det på punkterna ("vertices") först, sedan ritar du mellan de färdiga skärmkordinaterna. Varje vertex ska höra till precis två linjer i varje polygon, varken mer eller mindre. Om det är det minsta gap mellan linjerna blir figuren fel.
- När du ritar linjer så är det enkel interpolation som gäller. Till skillnad från en "rita linje-algoritm" så är det högst en bildpunkt per rad och linje. (Men det kanske är mer effektivt att göra på andra ledden, så kan man fylla flera pixels samtidigt)
- Rita alltid linjer i samma "riktning". Uppifrån och ner, eller från vänster till höger.
- Rita aldrig den nedersta (resp mest högra) punkten i samma linje.
- XOR'a varje bildpunkt.

Det andra sättet att göra det på är att dela upp varje polygon i konvexa former och när man ritar, dela upp dessa i trapezoider på skärmen som var och en är jätteenkel att rita och klippa mot skärmens kanter.
Den enklaste konvexa formen är en triangel -- den är garanterat konvex, vilka avrundningsfel man än har. 3D-hårdvara på PC arbetar bara med trianglar -- alla andra former delas upp i trianglar innan de skickas till hårdvaran.

stenD skrev:kolla i "foleyvandam" din bästa referens till grafikalgorithmer
googla "foley van dam"

alternativt kanske kolla i såsen till gimp

Det var väl han som höll på med fraktaler?
Han är väl ok, men han trodde ju att all bildutsändning skulle kunna omvandlas till fraktaler för att spara plats.
Men vissa av hans tankegångar kan man ju ta vara på.
Hur många högskolepoäng lade man nu på kurser som baserades på hans teorier...?

Hans idé om fraktalkompression var inte helt tagen ur luften. Hadde det lyckats hadde mediautbudet blivit rejält förändrat. Mpeg4 hadde fått äta upp hela hattfabriken.

Min mattelärare berättade om några han kände som skrev algoritmer för att komprimera en bild mha fraktaler.
Går det med en bild så borde det ju gå med en video ström?

Ingen aning om han pysslat med fraktaler, bara att boken är väldigt omfattande och att den användes av en kille som skrev en fönsterhanterare.
Förövrigt tror jag inte han har gjort alla algoritmerna i den boken

Hur går det för Korken?
Inte hört något på ett tag .

Oj har glömt av den här tråden lite, jodå, har testat ett par metoder!
Jag har än inte testat någon iterativ funktion, men jag testade en som var nästan som floodfill, fast att den drog hela linjer.
Den fungerade riktigt bra, och håller på och testar den mer. (den fungerar inte 100% än)