[Prog] Collision Detection

[Warsocket]

Ik ben in Masm een soort asteroids aan het schrijven

en er zit al een standaard collision detection in

die dus met de xy width height van je schip en de asteroide
kijkt of 2 vierkante hitboxen elkaar raken

mar met een transparant hoekje van je schip een transparante hoek raken van zon stuk steen is niet cool

daarom had ik iets bedacht met 2 masks 1 rode(FF) en 1 groene(FF00)
en dan een srcpaint te doen bmet bitblt op de backbuffer
en dan te checken op gele pixels

maar binnen 2 hitboxen checken op gele pixels is dankzei getpixel lekker langzaam

iemand nog een idee hoe dit snaller kan zonder directdraw en zonder dib-sections

alvast bedankt

edit
en iemand een idee om fatsoenlijk mp3 muziek te spelen bij de game

mp3 uitpakken en als wave spelen vreet teveel geheugen
en een ocx in assembler zuigt gewoon

dus heeft iemand daar ook een oplossing voor, dat scheelt alvast weer een probleem

[GVR]

wat gebruik je, bitmaps of polygonen.

[Fade of Light]

Je kan het middelpunt bepalen en een cirkel eromheen tekenen. Een cirkel sluit meestal (zeker bij asteroids, lijkt me) beter aan op de echte vorm. Ik ben vergeten wat wij gebruikte voor het geluid bij onze multi-player 3d shooter...ik geloof een standaard delphi library van een of andere media player die er zo bij zat.

[Marcade]

Nee ik ken alleen de oplossing die in Basic gebruikt word.

Dat is inderdaad .. eerst de rectangles .. hitboxen checken of ze overlappen .. zo ja, dan de pixels in het overlappende gebied checken of twee nontranspante pixels elkaar raken.

In basic is het snel genoeg iig.

[Marcade]

Fade of Light schreef op 20-01-2005 @ 17:01 :
Je kan het middelpunt bepalen en een cirkel eromheen tekenen. Een cirkel sluit meestal (zeker bij asteroids, lijkt me) beter aan op de echte vorm.

Tekenen?

Je bedoeld hoop ik () gewoon een pythagoras berekening doen.

(Absolute(X1 - X2)^2) + (Absolute(Y1 - Y2)^2) < ((Size1 + Size2)^2)

Diamant vorm is sneller

Absolute(X1 - X2) + Absolute(Y1 - Y2) < (Size1 + Size2)

[Warsocket]

GVR schreef op 20-01-2005 @ 16:22 :
wat gebruik je, bitmaps of polygonen.

tis me 1e spel in assembler
dus gewoon form, standaard windhoos gdi dingen (BitBlt etc)

en ja het zijn dus bitpmaps (die in een DC staan)

edit: en snelheid hij moet best veel berekenen
omdat me schip heel snel gaat (ja dat is de beodeling)

en dus draait het spelletje op 100 fps (en dan beweegt me schip al 4 pixels per gameloop, langzamer gaat het er gewoon brak uitzien)

maar het moet dus snel
en GetPixel zit me een beetje in me maag, want echt snel is die functie niet

[GVR]

Kan je niet gewoon in een buffertje ernaast die pixels checken?

en gewoon uit nieuwsgierigheid, waarom schrijf je asm als je alleen windows-calls gaat maken? Eigen sowieso, waarom asm?

[Fade of Light]

Marcade schreef op 20-01-2005 @ 17:17 :
Tekenen?

Je bedoeld hoop ik () gewoon een pythagoras berekening doen.

Woops, dat bedoel ik natuurlijk Tenzij je een of andere shield nodig hebt

[JaJ]

2dimensionaal heb ik nooit iets van collision detection gedaan, maar voor 3d betsaan er geen erg snelle functies eigenlijk. kun je niet bepalen welke pixels van bijde plaatjes het dichtst bij elkaar liggen aan de hand van de coordinaten van de plaatjes? dan hoef je alleen te checken of die twee overlappen.

[Fade of Light]

JaJ schreef op 20-01-2005 @ 18:37 :
2dimensionaal heb ik nooit iets van collision detection gedaan, maar voor 3d betsaan er geen erg snelle functies eigenlijk. kun je niet bepalen welke pixels van bijde plaatjes het dichtst bij elkaar liggen aan de hand van de coordinaten van de plaatjes? dan hoef je alleen te checken of die twee overlappen.

"Onzin". Er zijn genoeg 3d-dingen (en vooral n00b-games) die (simpele) 2d-collision detection algoritmes kunnen gebruiken. Dan kan het dus wel 'snel'

[Marcade]

Fade of Light schreef op 20-01-2005 @ 18:40 :
"Onzin". Er zijn genoeg 3d-dingen (en vooral n00b-games) die (simpele) 2d-collision detection algoritmes kunnen gebruiken. Dan kan het dus wel 'snel'

Yup; ook pythagoras

(Absolute(X1 - X2)^2) + (Absolute(Y1 - Y2)^2) + (Absolute(Z1 - Z2)^2) < ((Size1 + Size2)^2)

[Warsocket]

GVR schreef op 20-01-2005 @ 17:55 :
Kan je niet gewoon in een buffertje ernaast die pixels checken?

en gewoon uit nieuwsgierigheid, waarom schrijf je asm als je alleen windows-calls gaat maken? Eigen sowieso, waarom asm?

Omdat ik eerst wat basics aan wil leren
voordat ik ga zitten pielen met DirectX

en waarom asm, omdat ik het graag in asm schrijf
iederen heeft zo zijn favo taal

of wou je ook nog de discussie gaan voeren, waarom assembler 1 van mijn favoriete talen is ?

[[/quote]]

http://www.flipcode.com/articles/tp_issue01.shtml
http://www.flipcode.com/articles/tp_issue02.shtml

misschien dat je daar wat aan hebt... er staat best veel over op internet.. zoek op "collision detection" + 2d + convex ofzo

[Warsocket]

schreef op 21-01-2005 @ 02:54 :
http://www.flipcode.com/articles/tp_issue01.shtml
http://www.flipcode.com/articles/tp_issue02.shtml

misschien dat je daar wat aan hebt... er staat best veel over op internet.. zoek op "collision detection" + 2d + convex ofzo

das voor polygonen

ik zoek dus een collision detection voor sprites
dus eigk een snel stuk tehorie of code

om heel snel te chekcne of 2 niet transparente pixels elkaar overlappen

en of een menier om dat effect te bereiken

[ExVaal]

Sprites zijn voor Japanners

[MightyMarcel]

zolang je die standaard gdi dingen gebruikt blijft t traag.

[Warsocket]

MightyMarcel schreef op 22-01-2005 @ 18:33 :
zolang je die standaard gdi dingen gebruikt blijft t traag.

dat vroeg ik niet
ik vroeg (het liefst) de snelste manier moglijk met gdi shit

[MightyMarcel]

Warsocket schreef op 22-01-2005 @ 19:51 :
dat vroeg ik niet
ik vroeg (het liefst) de snelste manier moglijk met gdi shit

die is er dus niet.

MightyMarcel schreef op 23-01-2005 @ 10:16 :
die is er dus niet.

er is altijd een snelst mogelijke manier (of minst langzame dan maar dat staat wel voor hetzelfde).

Offtopic: welke andere manier zou je dan gebruiken compleet buiten GDI om? directdraw?

[GVR]

Jawel, je kan gewoon een bitmapje nemen (zelf, geen windows ding) en daarop alle pixels(bits) die je wil testen (niet transparant) 1 zetten en de anderen op nul. Zodra je dan in je box zit bereken je de relatieve posities en ga je lekker shiften en ANDen. Als er 0 uitkomt is het mis, anders raak.

Als je het niet begrijp (volgens mij druk ik me niet helemaal duidelijk uit) kan ik eventueel nog wat pseudo-code voor je schrijven.

[MightyMarcel]

GVR schreef op 23-01-2005 @ 13:41 :
Jawel, je kan gewoon een bitmapje nemen (zelf, geen windows ding) en daarop alle pixels(bits) die je wil testen (niet transparant) 1 zetten en de anderen op nul. Zodra je dan in je box zit bereken je de relatieve posities en ga je lekker shiften en ANDen. Als er 0 uitkomt is het mis, anders raak.

Als je het niet begrijp (volgens mij druk ik me niet helemaal duidelijk uit) kan ik eventueel nog wat pseudo-code voor je schrijven.

jawel, maar hij zegt zelluf dat-ie gdi dingen wil gebruiken...

[GVR]

Ja, je gebruikt dan ook GDI voor renderen en je eigen bitmapjes alleen voor collision detection.

Volgens mij kan je ook met gdi bij de bitmappen komen maar het lijkt met niet echt een charmante oplossing.

[[/quote]]

Warsocket schreef op 22-01-2005 @ 00:52 :
das voor polygonen

ik zoek dus een collision detection voor sprites
dus eigk een snel stuk tehorie of code

om heel snel te chekcne of 2 niet transparente pixels elkaar overlappen

en of een menier om dat effect te bereiken

met polygonen is veeeeeeeeeeeel sneller, en ik dacht dat je juist een performance probleem had? maargoed als je pixel per pixel wil vergelijken moet je het zelf weten... is op zich een eitje: eerst kijken of er overlappende bounding boxes zijn van objecten, en als dat zo is, alle pixels van het overlappende vlak langslopen en controleren of in beide sprites die pixel zichtbaar is

[[/quote]]

Warsocket schreef op 22-01-2005 @ 19:51 :
dat vroeg ik niet
ik vroeg (het liefst) de snelste manier moglijk met gdi shit

wat wil je met GDI doen dan? dit heeft helemaal niks met GDI te maken.. je controleert geheugen toch? of ga je eerst alles naar je dc wegschrijven en daarna controleren of het eigenlijk wel goed was wat je deed?

[Warsocket]

schreef op 23-01-2005 @ 21:13 :
wat wil je met GDI doen dan? dit heeft helemaal niks met GDI te maken.. je controleert geheugen toch? of ga je eerst alles naar je dc wegschrijven en daarna controleren of het eigenlijk wel goed was wat je deed? [/QUOTE]

ik dacht aan mijn manier
dan staan er al masks (monochrone bitmaps)
in een dc (die zet ik er bij het opstarten al in)

en dan lekker SRCAND blitten en kijken of er witte pixels overblijven
allen dat word dus getpixelen

dat is mijn manier ik vraag me alen af of er een snellere manier is
zonder dat ik gelijk met polygonen en of direct draw moet gaan werken

[[/quote]]

Warsocket schreef op 23-01-2005 @ 21:41 :
ik dacht aan mijn manier
dan staan er al masks (monochrone bitmaps)
in een dc (die zet ik er bij het opstarten al in)

en dan lekker SRCAND blitten en kijken of er witte pixels overblijven
allen dat word dus getpixelen

dat is mijn manier ik vraag me alen af of er een snellere manier is
zonder dat ik gelijk met polygonen en of direct draw moet gaan werken

dan kan je toch all het geheugen van je mask doorlopen? een kwestie van welke bits in de mask van beide sprites elkaar overlappen, die met elkaar ANDen en dan kijken kijken of er iets overlapt met JNZ

maar waarom gebruik je geen polygonen?

Warsocket schreef op 23-01-2005 @ 21:41 :
schreef op 23-01-2005 @ 21:13 :
ik dacht aan mijn manier
dan staan er al masks (monochrone bitmaps)
in een dc (die zet ik er bij het opstarten al in)

en dan lekker SRCAND blitten en kijken of er witte pixels overblijven
allen dat word dus getpixelen

dat is mijn manier ik vraag me alen af of er een snellere manier is
zonder dat ik gelijk met polygonen en of direct draw moet gaan werken

getpixel is zeer langzaam, DC omzetten naar een dibsection en dan idd wat /quote zegt, doorlopen met JNZ

[[/quote]]

ja of gewoon vanuit het geheugen van je mask -> BITMAP.bmBits