Archief - [PROG][JAVA] grafisch gedoe

Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.

MilM

Legacy Member
Gewoon twee opmerkingen:

1) In plaats van een array, kun je ook aan ArrayList gebruiken.
Wanneer een blokje geraakt wordt, dan kun hem uit die ArrayList verwijderen in plaats van hem op destroyed te zetten.
Nu loopt hij alle blokjes telkens af, ook al zijn ze vernietigd

2) Nog beter zou zijn om het speeldveld bij te houden in plaats van de blokjes.

Stel je hebt bv 10 rijen van 10 blokjes.
Dan hou je een 2D-array bij van booleans van 10x10 (boolean[][] array = new boolean[10][10]; )

Nu neem je gewoon uw balleke en aan de hand van zijn coordinaten, bepaal je het blokje en hoef je enkel dat blokje te controleren.

Bv.

Uw speelveld is 200x200 en binnen dat speelveld bevinden zich de blokjes in een 100x100 vierkant. (dus links, recht, boven, onder 50 pixels vrije ruimte)
maw, het veld ligt tussen [50,150] hoogte/breedte.

Je hebt nu de x,y coordinaten van uw balleke.
Het eerste wat je moet doen is checken of beiden >= 50 zijn EN =< 150.
Indien nee -> doe niets

Indien ja:
Bepaal de coordinaten in het 100x100 vierkant.
Das simpel, gewoon x -50 en y -50.

Nu elk vierkant is 10x10 in dit voorbeeld.
Het enigste wat je nu nog moet doen dus, is
a = x/10;
b = y/10;

En je hebt uw blokje in het rooster overeenkomstig met de positie van het balletje, namelijk array[a].
Je controleert dus telkens maar één blokje ipv alle blokjes.

Uw oplossing werkt natuurlijk ook, het is dus niet dat je het moet gaan veranderen.
Is enkel eens ter info.

Trouwens straf dat je paar dagen geleden die vraag stelde en nu al zoiets gemaakt heb.
Volledig zelf gedaan ?

sabaoth

Legacy Member
@ hierbove
Bedankt voor die info, ik wou eerst een arraylist gebruike maar dan had ik moeilijkhede om door al die blokjes te gaan, uw oplossing ga ik toch is proberen thx :)

*edit*
mmm ik snap het toch nog ni zo goe, uw oplossing :p
Ik kan wel kijk of het balleke in "het vierkant" komt, maar daarna :s

En ja kheb het zelf helemaal gedaan :p Ik kon al wel vb.net , C# enz van die dinge hoor :)

killgore

Legacy Member
Het komt erop neer dat je met een grid werkt.

Stel bv dat je je veld opdeelt in een grid van 200x200 blokjes.

Nu, geef elk blokje een coördinaat, het logische is die linksonder (0,0) te geven en dan naar rechts uw x-coördinaat en naar boven uw y-coördinaat te verhogen. Zo kan je dus je hele speelveld indien gewenst in een array steken.

Nu, in ons geval lijkt het nogal 'dom' om het speelveld in een array te steken omdat we weten dat enkel de coördinaten (50,50)->(149,149) zullen gebruikt worden. Dus maken we in plaats van een 200x200 array enkel nog een 100x100 array aan. Deze array kan er zo uitzien:

Block[][] blocksInField = new Block[100][100];

Nu kan je deze array gaan opvullen met Block-objecten die jij hebt aangemaakt, als een veld groter is dan 1 vierkantje (vaak zullen het er al meer in de breedte zijn, soms wil ook eentje hoger), dan steek je gewoon dezelfde referentie in meerdere plaatsen op de array!

De andere waarden blijven op null staan.

Belangrijk is om uit te vinden waar je balletje zich in het veld bevindt. Dit is dus een korte transformatie tussen je "gewoon" coördinatenstelsel (dat continu kan zijn, pixel-based, ...) en dat raster van vierkantjes dat we hebben opgebouwd. Over het algemeen is dit niet meer als wat vermenigvuldigen en afronden.

Nu wordt het even tricky.
Je doet eerst je framebased berekening om je balletje te verplaatsen in x-richting (wat iets zal zijn als bal.x += elapsedTime*bal.vx). Dan kijk je of op die positie zich een vierkantje in met een blokje in. Zoja, dan vernietig je dit blokje (of trek je een puntje af van de blokjes die wat langer mogen leven). Als er een blokje was draai je ook even zin van x-richting om (bal.vx=-bal.vx), je maakt ook eventueel onmiddellijk die verplaatsing die je al had gedaan terug ongedaan.
Daarna herhaal je compleet dezelfde procedure voor de y-richting (vertrek hiervan best vanuit de originele positie imho).
Als er nog geen detectie is geweest herhaal je die procedure ook eens voor zowel x, als y-richting.
Op die manier zijn de x-richting, de y-richting, en de gezamenlijke richting gecontroleerd. Als je immers 1 van de richtingen niet controleert kan je over een blokje heenspringen! Al je de x en y richting ook niet apart controleert kan je onmogelijk weten welke zin omgedraaid moet worden.

Let wel op dat hierbij enige problemen zijn:
1) Je blokjes hebben dus vaste size, maar dit is in zo een spel meestal de bedoeling.
2) Ik reken hier time-based ipv frame based. Als je dus een frame hebt dat zeer lang erover doet om berekend te worden zal de elapsedTime vrij groot zijn en kan het zijn dat je over blokjes heen springt. In dat geval moet je aan path-overlapping doen, wat al iets complexer is. Imho echter is dit in zo een eenvoudig spel een te verwaarlozen kans op fout.
3) Je moet transformeren. Je balletje bevindt zich alicht in een gewoon floating-point coördinatenstelsel, omdat het vrij "smooth" moet kunnen bewegen en niet van vierkantje naar vierkantje. Daardoor moet je op elk moment berekenen op welk(e) vierkantje(s) het zich bevindt.

het is iets anders als wat Milm uitlegde, omdat ik geen array van bools maar van blocks bijhoudt, maar komt veruit op hetzelfde neer imho.
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
Terug
Bovenaan