Redreamer: pågående

av **Redreamer** » 3 november 2017, 08:23

Har suttit fast i några dagar nu. Svajat mellan att lösa problemet i spelkoden eller bryta ur funktionen och skriva en testsuit till den. Men det senare är så tråkigt. Jag sitter just nu och funderar på om jag ska ta kvällen till att attackkoda lite. Dvs ge mig fan på att lösa det. Ofta hamnar jag annars i ett läge där jag ofokuserat testar runt utan att riktigt koppla in och just fokusera. Har ofta haft svårt för just att fokusera. Något som jag tror gått i arv till min äldre son och som jag troligen fått från min far. Ett karaktärsdrag som är svårt att bryta. Men som sagt attackkoda! Jag är så jävla nära känns det som!

av **Staffan** » 7 november 2017, 21:08

Själv är jag helt övertygad om att jag har add. Har du gjort något nättest? Men det var ett sidospår. Skall bli kul att få testa ditt spel snart

skall försöka slå svärdet genom väggen, och om jag misslyckas skall jag beundra den fina ingenjörskonsten.

av **bjonte** » 7 november 2017, 22:05

Kan du beskriva problemet som det ser ut just nu så kanske vi kan hjälpa till att komma med idéer om lösningar?

av **Redreamer** » 8 november 2017, 08:52

När jag funderade på det nu i bilen på vägen till jobbet så vet jag att jag har två funktioner som mer eller mindre gör samma sak. Om jag minns rätt så är det två hitbox funktioner där den ena tar xy från de spriterna man vill kontrollera samt xy justeringar för spritens "grafiska storlek". Den andra funktionen tror jag bara sätts upp med xy utan att man specificerar vilken sprite. Så man får mata in det själv innan man ropar på funktionen. En av funktionerna tror jag fungerar. Den andra fungerar ju uppenbarligen bara halvbra. Jag har klippt bort större delen av spelet och anpassat så det ska vara lättare att felsöka och testa funktionen. I vilket fall. Jag kan posta lite kod i kväll för den som är intresserad. Jag har pillat med det några kvällar i rad nu så jag kommer nog snart knäcka det

av **bjonte** » 8 november 2017, 18:09

Var det för att kolla kollision mot kanterna för att gå runt eller för att kolla kollision mellan vapen och vägg eller fiender?

av **Redreamer** » 8 november 2017, 22:04

Ja det är för när spelarna går in i varandra eller en projektil från ett vapen träffar. Men strunt samma. Jag får visa lite kod i morgon. Var igång och bytte däck på min och tjejens bil under kvällen så jag är lite för trött för att orka lägga upp begriplig kod i kväll, tyvärr.

av **bjonte** » 9 november 2017, 19:17

Jag kollade på hur kollisionerna löstes i Bruce Lee II. Jag hade specifik kod för varje typ av objekt som kunde kollidera med entiteter för att spara tid, men det skulle nog ha gått att göra generell kod med. Här är ett exempel:

Kod: Markera allt: ldx #MAX_FIREBALLS - 1 { lda state,x cmp #STATE_UNSPAWNED beq .not_spawned // check left of fireball against right of entity lda _x,x sec sbc #WIDTH/2 cmp .entity_right:#0 bcs .no_collision // check right of fireball against left of entity clc adc #WIDTH cmp .entity_left:#0 bcc .no_collision // check top of fireball against bottom of entity lda _y,x sec sbc #HEIGHT/2 cmp .entity_bottom:#0 bcs .no_collision // check bottom of fireball against top of entity clc adc #HEIGHT cmp .entity_top:#0 bcc .no_collision // remove fireball to avoid double collision when bruce respawns jsr despawn sec rts .not_spawned: .no_collision: dex bpl @loop }

Här loopar jag över alla eldbollar och kollar kollision mot en entitet, Bruce eller någon av de andra karaktärerna. I förväg har jag skrivit in vänster, höger, övre och nedre position på karaktären så att loopen inte behöver räkna på det också. Det blir bara krångligt.

Vill man ha ett generellt system skulle jag låta alla objekt skriva ner sina vänster, höger, övre och nedre gräns i fyra fält och så kan kollisionsfunktionen bara läsa värdena indexerat. Såhär kan det se ut:

Kod: Markera allt: // -> x: index of entity 1 // -> y: index of entity 2 // <- C: set if a collision occurred subroutine collides { // check left of entity 1 against right of entity 2 lda _left_positions,x cmp _right_positions,y bcs .no_collision // check right of entity 1 against left of entity 2 lda _right_positions,x cmp _left_positions,y bcc .no_collision // check top of entity 1 against bottom of entity 2 lda _top_positions,x cmp _bottom_positions,y bcs .no_collision // check bottom of entity 1 against top of entity 2 lda _bottom_positions,x cmp _top_positions,y bcc .no_collision sec rts .no_collision: clc rts }

Då är det ganska enkelt att göra det i en loop.

av **Redreamer** » 9 november 2017, 20:15

Utan att riktigt ännu ha tid att publicera kod så har jag i den ena funktionen blandat in msb x i samma uträkning. Vilket ju är bökigt. Vet inte hur du löst den biten. Men du kanske har någon förkalkylering för det?

av **bjonte** » 9 november 2017, 21:00

I Bruce Lee II rör sig (som tur är) alla figurer två pixlar i taget så jag har helt enkelt x-koordinater som spänner över hela skärmen och som ryms i åtta bitar. Alla x-positioner är halverade tills sprites ska ritas på skärmen, då skiftas positionerna och nionde biten hanteras.

I ditt spel kan du hålla alla koordinater i nio bitar om det behövs för spelet, men när du ska spara fältet med vänster- och högerkanter i mitt exempel så kan du skifta ner dem till åtta bitar. Då går kollisionsdetektionen snabbare, vilket är bra ifall det är många som ska göras, och det blir mycket enklare.

Ett annat sätt är att lagra positionerna med de åtta högsta bitarna i en byte och den lägsta i en annan byte. Som MSB, fast LSB istället. Då gör du snabbt kollisionsdetektion på övre byten och när du ska rita ut sprites skiftar du upp för att få en MSB-byte igen.

av **Redreamer** » 9 november 2017, 22:02

Det där sista knepet med att skifta ner msb och strunta i lsb var smart! Jag kollade just på min sunkiga kollisions detection kod och insåg att jag inte tror det är någon ide att fortsätta på den. Tror jag anpassar om koden så jag använder min senare skrivna "hitbox" funktion ist. Mer eller mindre samma tänk, bara att det krävs lite mer förarbete innan jag ropar på själva uträkningen. Hitbox funktionen ser ut så här, för den som orkar.

Kod: Markera allt: hitbox lda #$00 sta var_hitbox_collision sec lda var_hitbox_msb ;objekt1 sbc var_hitbox_msb + $01 ;objekt2 beq hitbox_same_msb ldx #$00 sec lda var_hitbox_x ;check if +01 is bigger. x, left side sbc var_hitbox_x + $01 bcs hitbox_different_msb inx sec ;check if 00 is bigger lda var_hitbox_x + $01 sbc var_hitbox_x hitbox_different_msb clc adc var_hitbox_x_length,x ;längden på x utifrån x, left side. bcs hitbox_x_hit jmp hitbox_end hitbox_same_msb sec lda var_hitbox_x + $01 sbc var_hitbox_x bcs hitbox_x_test1 sec lda var_hitbox_x sbc var_hitbox_x + $01 sbc var_hitbox_x_length + $01 bcc hitbox_x_hit jmp hitbox_end hitbox_x_test1 sbc var_hitbox_x_length bcc hitbox_x_hit jmp hitbox_end hitbox_x_hit sec lda var_hitbox_y + $01 sbc var_hitbox_y bcs hitbox_y_test1 sec lda var_hitbox_y sbc var_hitbox_y + $01 sbc var_hitbox_y_length + $01 bcc hitbox_y_hit jmp hitbox_end hitbox_y_test1 sbc var_hitbox_y_length bcc hitbox_y_hit jmp hitbox_end hitbox_y_hit inc var_hitbox_collision hitbox_end rts var_hitbox_x byte $00, $00 var_hitbox_y byte $00, $00 var_hitbox_msb byte $00, $00 var_hitbox_x_length byte $00, $00 var_hitbox_y_length byte $00, $00 var_hitbox_collision byte $00

av **bjonte** » 9 november 2017, 22:58

Jag fattar inte riktigt hur det funkar. Det verkar fel att jämföra MSB först. För sedan görs en jämförelse mellan de lägre åtta bitarna. Det känns som att det kan bli fel om de är på olika sidor om 256. Jag tycker att algoritmen som utesluter är lättare för att den bara jämför alla fyra kanterna och ser om de omöjligen kan överlappa (om vänstersidan på ena objektet är till höger om högersidan på andra objektet kan de omöjligt överlappa...). I det exemplet behövs bara 8-bitars cmp ersättas med en 16-bits subtraktion för att det ska funka med 9 bitars x-koordinater.

av **Redreamer** » 10 november 2017, 08:21

Det är förskräckligt ofint av mig att bara slänga ut kommenterad kod. Var lång dag igår men jag hade lovat kod så därför blev det iaf en snutt. Grejen är att jag i grunden tar sprite 1 - sprite 2 (x eller y) om det blir negativt gör jag sprite 2 - sprite 1 i stället.
Sedan tar jag resultatet - längden på sprite 1 (eller2 beroende vilken som hade det lägsta x. Om resultatet inte är negativt så är de överlappande varandra. Sedan blir det specialbehandling för msb om de ligger på varsin sida om gränsen. (För x då)

av **bjonte** » 10 november 2017, 10:18

Ok, då förstår jag. Jag tror att det finns problem ändå tyvärr. Om MSB är olika så måste den tas hänsyn till när du subtraherar de lägsta åtta bitarna. Det ser inte ut som att det görs.

av **Redreamer** » 14 november 2017, 11:09

Jo då. Det tror jag görs. Jag tror att jag hittade problemet igår. När jag kopierar över koordinater så gör jag det fel andra varvet i en loop. Hittade detta igår kväll så jag måste ta det ett extra varv i huvudet i kväll och försöka fixa koden. Det felet jag refererar till finns inte i den kod jag publicerade nyligen.

av **Redreamer** » 4 december 2017, 09:54

Har kommit igång ganska bra nu med ai rutinerna. Ganska roligt när man får en motståndare som börjar röra på sig

inser att det hade varit lättare om jag designat banan efter det. Men å andra sidan är det utmanande att skriva en "smart" ai.
Har skrivit i huvudsak tre rutiner. En som har koll på hur långt det är mellan spelarna. En som har koll på vad som finns framför ai. En som har koll på endast ur långa öppna ytor som finns åt respektive håll utifrån ai. Behöver skriva en som gör att ai söker upp Items också. Sen får jag se vad jag kommer på mer