Hej!

Jag programmerar ett bilspel i C++ med Allegro's grafiska bibliotek. Nu har jag dock stött på patrull gällande en snutt jag har som räknar hur många varv man kört och skriver ut det på skärmen.

Jag har gjort det så att själva banan är en bild som laddas in och ritas ut, likaså bilen. Det jag gör är att kolla en viss pixel på bilen och jämföra den med mållinjens pixel-färgkod. Så ifall bilen "överträder" mållinjen så räknas varvräknaren upp med 1.

Nu är det dock så att denna räknare funkar inte alltid som den bör, den räknar inte alltid upp varv fast man överträder mållinjen med hela bilen. Jag gjorde ett test och ritade en liten orange kub och laddade in den istället för bilen (hela kuben har samma färgkod) och när jag kör med den så räknas varven upp i de allra flesta fall! Varför görs inte detta med min bil (som inte har samma färgkod på hela såklart, men det ska ju inte spela någon roll).

Jag ritar ut bilen med funktionen rotate_sprite, så här ser koden för utritningen av bilen ut:

rotate_sprite(buffer,bil1,objekt.x,objekt.y,itofix(objekt.rotate));

buffer = själva "bakgrundslagret" som banan ritas ut på
bil1 = bilen (är en bild)
objekt.x = den x-koordinat på banan där bilen ska ritas ut
objekt.y = den y-koordinat på banan där bilen ska ritas ut
objekt.rotate = anger rotationen, som jag ställt till 320 (men detta är egentligen oväsentligt i detta sammanhang)

Så här ser koden ut för raderna som räknar upp antal varv man kört:

               if(key[KEY_UP] || key[KEY_LEFT] || key[KEY_RIGHT])
               {
                    if((pixR==255 && pixG==254 && pixB==255) && (objekt.aktuelltVarv<=objekt.antalVarv))
                    {
                         objekt.aktuelltVarv++;
                    }             
               } 

255,254,255 är alltså färgkoden på mållinjen. objekt.aktuelltVarv är en varibel dit jag sparar antal körda varv.

Jag vet inte varför varven inte alltid räknas, och varför den räknas när jag kör med kuben? Rotate_sprite ritar ju ut bilen med dess vänstra hörd i de kordinater jag angett (se ovan), saken är dock den att bilens alla hörn är rosa (för att de ska vara transparenta på banan), men detta kan väl inte ge upphov till buggen? Sen undrar jag vilken pixel på bilen som kollas ifall den passerat färgkoden för mållinjen? Är det den pixel där bilen ritas ut på banan? Har funderat på att kanske skapa ett lager under bilen som är lite större än bilen (ett transparent lager) som man kollar med istället, då kanske det skulle fungera?

Jag fick ett tips av en person att lösa det så här istället:
Att jag istället för att använda pixlars färgkod för att detektera om man kört över mållinjen, så borde jag istället använda bilens position från nuvarande och förra (eller nuvarande och nästa) frame och jämföra med mållinjen för att se om bilen passerat.

Det låter ju instressant men jag förstår inte riktigt hur jag ska kunna lösa det så, med if-satser? Har frågat honom på det andra forumet, men han har inte svarat...


Jag är väldigt tacksam för tips då jag måste fixa denna bugg! (bilspelet är ett enmansprojekt jag gör i en kurs på högskolan, spelet är klart enligt kravspecen men jag vill inte lämna in den innan jag fixat denna bugg då varvtidsräknaren inte blir så intressant när det buggar sig så här). Är det något jag missat så fråga gärna, eller om ni har tips på bättre lösningar så tipsa mig gärna!

Mvh Ramon

Att kolla pixeln är i allmänhet dumt, ja. Dels så kan det av massa olika anledningar i ett "riktigt spel" vara så att pixeln ändrar färg (låt säga att du vill lägga till dimma till spelet) utan att något har kört förbi, dels kan det vara så att någon pixel inte ändrar färg när bilen kör förbi (bilen kanske har likadana pixlar som den du vill kolla, eller så kan en transformation av bilden leda till att du får likadana pixlar).
Du bör sen absolut inte använda hårdkodade värden för din koll-pixel.
Vidare saknar du då kontroll för om bilen kör åt fel håll.

Det framgår inte heller hur du kontrollerar att varvräknaren slår upp två gånger.


<b>>Är det den pixel där bilen ritas ut på banan?</b>
Vet du inte själv vilken pixel du kollar?


I princip är förmodligen orsaken till problemet att du låter bilen färdas mer än en pixel åt gången.
Då kan hela bilen vara före mållinjen vid en tidpunkt, och hela vara efter mållinjen vid nästa, eller specialfallet att en specifik pixel på din bild har samma färg, och att du träffar just den.

Lösningen är precis som personen i det andra forumet föreslår.

Börja med att definiera ett streck över banan. Lämpligt är väl kanske ett vertikalt eller horisontellt för att göra det enkelt.

Sen utgår du från någon punkt på bilen. Längst bak, längst fram, eller någonstans i mitten. Hur som helst ser du hela tiden till att få en punkt.

Sen kontrollerar du helt enkelt vilken sida om strecket punkten är.

Säg att strecket ligger på x=15 och går från y=15 till y=30
Sen har du din kontrollpunkt. Först ligger den på x=12, y=20. Sen x=18, y=24.
Eftersom y i båda fallen ligger mellan 15 och 30 så har man inte kört "förbi" strecket. Eftersom x först ligger till vänster om strecket, och sen till höger, så måste man ha kört förbi.

>Säg att strecket ligger på x=15 och går från y=15 till y=30
>Sen har du din kontrollpunkt. Först ligger den på x=12, y=20. Sen x=18, y=24.
>Eftersom y i båda fallen ligger mellan 15 och 30 så har man inte kört "förbi" strecket. Eftersom x först
>ligger till vänster om strecket, och sen till höger, så måste man ha kört förbi.

Beroende på hur ens bana kan se ut och hur långt bilen kan förflyttas mellan två uppdateringar så kan man även behöva kolla fallet då en eller båda punkterna har ett y värde som ligger utanför 15-30 intervallet. Undantaget är om det i båda fallen ligger utanför på samma sida.

Med tanke på att det tidigare försöket var pixelfärgen, tyckte jag att det inte var nödvändigt att börja diskutera skärningspunkter mellan linjer.

Det är naturligtvis korrekt, men då bör man ju också studera alla fyra hörnpunkterna på bilen för att verkligen förstå vad det är som händer, och förmodligen också hantera sidorna, och även eventuella avvikelser från en rektangulär form. Det är en bra approximation för att få spelet att inte reagera på "andra sidan brädet".

>Med tanke på att det tidigare försöket var pixelfärgen, tyckte jag att det
>inte var nödvändigt att börja diskutera skärningspunkter mellan linjer.

Mitt inlägg var inte någon form av kritik av ditt inlägg. Jag bara påtalade (inte primärt till dig utan alla som kunde vara intresserade) om att fler "tester" kan vara nödvändiga. Kan ju ha funnits andra, inklusive den första postaren som är intresserad av ämnet.

Jo, jo, jag menade inte så. Ville bara klargöra att det inte ger _så_ mycket utan att ha en radda andra tester också. Och att det därför snart blir ett ganska stort problem.

Har man kommit så långt är man nog lika gärna inne på allmän kollisionsdetektion osv.