Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
ik had een tijdje geleden deze vraag gesteld, maar nog geen antwoord gezien?TheGambler schreef op woensdag 15 november 2006 @ 20:55:
maar ff een serieuzere vraag:
sommige compilers/interpreters (borland c++, msvc++, vb, labview) gebruiken runtime dlls,
miss handig om aan te geven welke beschikbaar zijn?
of is het gewoon een verse windows install, met de standaard spullen erop
waarschijnlijk een beetje verloren geraakt tijdens de discussie een paar pagina's terug
Toch staat het antwoord wel ergens in dit topic. In principe moet het geen probleem zijn om je app te draaien (we devven allemaal) maar als je specifieke dingen nodig hebt doe je er verstandig aan om ze mee te leveren. En mochten we iets niet aan de praat krijgen dan zullen we dat allicht even overleggen met je voordat we je bij voorbaat "game-over" kwalificerenTheGambler schreef op donderdag 16 november 2006 @ 19:15:
[...]
ik had een tijdje geleden deze vraag gesteld, maar nog geen antwoord gezien?
waarschijnlijk een beetje verloren geraakt tijdens de discussie een paar pagina's terug
[ Voor 26% gewijzigd door RobIII op 16-11-2006 19:19 ]
There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.
Je eigen tweaker.me redirect
Over mij
Verwijderd
Dat is wel erg grappig eigenlijk, al dat geneuzel om het roteren terwijl we het eigenlijk over het line-clearen zouden moeten hebben gehad..oisyn schreef op donderdag 16 november 2006 @ 19:14:
[...]
Dat was dus ook exact bij mij het probleem. Of niet zozeer het line-clearen zelf, maar het bijhouden van de bijbehorende heightfield.
Wat mij trouwens wel opvalt uit de resultaten die ik dusver heb gezien is dat ik de 'hoogte' van een kolom anders bepaald als wat ik hier heb gezien. Bij mij is helemaal geen enkel blokje 40 en helemaal vol 0 terwijl dat bij de meeste mensen andersom is?
Is bij jullie de bovenkant van het veld dan ook 40-39 of 0? Bij mij is 0,0 dus de linkerbovenhoek zoals ook op een grafisch display het geval is.
Niet dat het uiteindelijk iets uitmaakt natuurlijk, maar ik vind het wel opvallend.
Hoe je het weergeeft heeft toch niets te maken met hoe het intern werkt?Verwijderd schreef op donderdag 16 november 2006 @ 20:11:
Wat mij trouwens wel opvalt uit de resultaten die ik dusver heb gezien is dat ik de 'hoogte' van een kolom anders bepaald als wat ik hier heb gezien. Bij mij is helemaal geen enkel blokje 40 en helemaal vol 0 terwijl dat bij de meeste mensen andersom is?
'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.
Verwijderd
Jij stelt je de vraag hoe hoog is de kerktoren, ik stelde me de vraag hoe diep is het gat ofwel hoe diep kan mijn blokje vallen
Bij mij heet de variable ook niet hoogte, maar top. (Hoe diep in het gat bevind de bovenkant of top van de kolom zich)
Ik stel mij het veld voor als een gat in de grond waar je blokjes in gooit.
Dan is de vraag hoe diep is het gat op die plek, en dan is mijn variable dus logischer.
[ Voor 41% gewijzigd door Verwijderd op 16-11-2006 20:28 ]
De plekken waar blokjes staan, heb je daar juist een 0 of een 1?
Je kan er 1'en neerzetten, en als je dan een stuk neerzet schiet je hem als het ware uit de muur, dan is het inzakken van een regel opeens een stuk logischer.
En omdat de tetris goden ons dwars zitten leggen ze er dan een nieuwe regel op.
Als je stuk niet meer past omdat je niet de goede vorm eruit kan schieten schiet je perongeluk een tetrisgod dood en doden de andere tetris goden dus jou, vandaar game-over.
Genoeg fantasy.. ik ga ook maar eens files inlezen
486DX2-50 16MB ECC RAM 4x 500MB Drive array 1.44MB FDD MS-Dos 6.22
486DX2-50 16MB ECC RAM 4x 500MB Drive array 1.44MB FDD MS-Dos 6.22
Laat me raden: je houdt per kolom een hoogte bij en als er een lijn gecleard wordt trek je daar één vanaf? Daar ging mijn code in ieder geval op stuk..oisyn schreef op donderdag 16 november 2006 @ 19:14:
Dat was dus ook exact bij mij het probleem. Of niet zozeer het line-clearen zelf, maar het bijhouden van de bijbehorende heightfield.
Is nu gefixt dus, met dank aan de handige debug output.
Verwijderd
Waarom niet? Een X is gewoon 88, aangezien ik niet met bits werkt maakt het dus niet zoveel uit of ik er nu 88 of 1 neer zet. Uiteindelijk is het toch gewoon 0 of niet 0PiepPiep schreef op donderdag 16 november 2006 @ 20:53:
Ik neem aan dat je intern niet met 0 en X werkt?
[ Voor 82% gewijzigd door Verwijderd op 16-11-2006 20:59 ]
Mja, het algoritme is belangrijker.
486DX2-50 16MB ECC RAM 4x 500MB Drive array 1.44MB FDD MS-Dos 6.22
[ Voor 3% gewijzigd door frickY op 16-11-2006 21:20 ]
Verwijderd
Nee, ik werk nog niet met bits omdat mijn huidige implementatie heel snel is opgezet en voornamelijk om te testen en te proberen.
De definitieve versie moet een stuk sneller zijn dus dan pak ik een andere taal en wellicht wel bits. Hoewel het verschil in snelheid tussen bits en int's wel mee gaat vallen gezien een 32 bit CPU toch 32 bits tegelijk moet verwerken.
Maar wellicht dat er met wat AND, OR, XOR etc operaties toch wel wat snelheidswinst te halen valt.
Er is in ieder geval een geheugen winst als er met bits gewerkt wordt, maar gezien ik nog geen plannen heb het multi-threaded op te zetten zal ik niet snel geheugen tekort hebben.
@Fricky:
Die snap ik niet helemaal, hoe doe je dat dan met 5 rijen tegelijk?
En er valt toch niet echt een rij aan de onderkant af, er valt een rij in het midden tussenuit.
[ Voor 12% gewijzigd door Verwijderd op 16-11-2006 21:23 ]
Zodat op het einde je onderste lijn ergens in de array op positie 0 staat en de bovenste op 4000 ofzo?frickY schreef op donderdag 16 november 2006 @ 21:19:
spoiler:Het is toch veel logischer om wanneer je een lijn gemaakt hebt het speelveld te vergroten naar 41 hoog, in plaats van letterlijk je lijn te clearen en alle blokjes lager te positioneren?
486DX2-50 16MB ECC RAM 4x 500MB Drive array 1.44MB FDD MS-Dos 6.22
Verwijderd
Mijn validator doet netjes die eerste run van .oisyn, precies dezelfde output en precies dezelfde score. Ook gechecked met die tussenversies zoals de mooie HTML bestandjes van Rob, dat klopt ook allemaal.
Nu heb ik die 2e set met enorm veel punten van .oisyn erin gestopt, maar die gaat mis na 3660 instructies.
Het kan toch haast niet dat ie de ene set helemaal goed doet en dan die nieuwe set niet?
Of ben ik nou gek?


Ok, gefixed... Nu haal ik nog maar 375 iteraties, hahaha.
[ Voor 24% gewijzigd door DaCoTa op 16-11-2006 21:36 ]
Verwijderd
En dan te bedenken dat je straks niet eens weet hoe de blokjes eruit gaan zien...

Ik vind het maar een lastige opgave en dat er dan al mensen zijn die zo flink scoren

Ach, zal al blij zijn als ik in de top 25 kom
ExactSoultaker schreef op donderdag 16 november 2006 @ 20:54:
[...]
Laat me raden: je houdt per kolom een hoogte bij en als er een lijn gecleard wordt trek je daar één vanaf? Daar ging mijn code in ieder geval op stuk.
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Wat voor probleem lost dat op dan? Want lijnen liggen niet per se op de onderste plek, dus nu moet je rijen onder de lijn die je weghaalt omhoog verplaatsen ipv de rijden die erboven liggen naar onder.frickY schreef op donderdag 16 november 2006 @ 21:19:
spoiler:Het is toch veel logischer om wanneer je een lijn gemaakt hebt het speelveld te vergroten naar 41 hoog, in plaats van letterlijk je lijn te clearen en alle blokjes lager te positioneren?
Over het bitsgedeelte, ik denk dat je er geen ene reet mee opschiet. Je loopt jezelf een ongeluk te anden en te shiften, terwijl het qua caching geen zak uitmaakt. Het wordt misschien voordelig op het moment dat je een hele oplossingsboom doorzoekt en daarbij veel kopiën maakt van je speelveld (en dus veel mem toucht), maar daar zijn imho betere oplossingen (zoals niet het hele speelveld kopieren, maar slechts de veranderingen als een overlay eroverheen te leggen - hoef je alleen nog maar de veranderingen op te slaan)
[ Voor 33% gewijzigd door .oisyn op 16-11-2006 21:45 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Verwijderd
In de meeste talen is werken met bits alleen maar lastig, of het is stiekum een wrapper voor een ander type.
Mits een goede implementatie natuurlijk.
486DX2-50 16MB ECC RAM 4x 500MB Drive array 1.44MB FDD MS-Dos 6.22
Verwijderd
Het probleem was dat wanneer een kolom helemaal leeg werd (dus tot op de bodem) ging dat mis.
Hij is alleen wel bagger traag zeg, die eerste sets deed ie lekker vlotjes maar die grote 6MB grote file doet ie erg lang over....
6Mb doet 'ie bij mij in <2000 msVerwijderd schreef op donderdag 16 november 2006 @ 22:07:
Ah mijn validator werkt nu wel goed.
Het probleem was dat wanneer een kolom helemaal leeg werd (dus tot op de bodem) ging dat mis.
Hij is alleen wel bagger traag zeg, die eerste sets deed ie lekker vlotjes maar die grote 6MB grote file doet ie erg lang over....
There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.
Je eigen tweaker.me redirect
Over mij
Verwijderd
En waar woon jij precies?
/me belt knokploeg om code te bemachtigen
[ Voor 1% gewijzigd door RobIII op 16-11-2006 22:17 . Reden: Fixed mijn eigen typo :X ]
Die set van .oisyn van 6Mb:Verwijderd schreef op donderdag 16 november 2006 @ 22:10:
[...]
En waar woon jij precies?
/me belt knokploeg om code te bemachtigen
Status | : | Finished; all blocks read and processed |
Score | : | 2277500 |
Discards | : | 0 |
Drops | : | 100000 |
Moves | : | 378481 |
Rotates | : | 52893 |
1-line clears | : | 21508 |
2-line clears | : | 1228 |
3-line clears | : | 53 |
4-line clears | : | 0 |
5-line clears | : | 0 |
Instructions | : | 631374 |
Execution time | : | 1563ms. |
There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.
Je eigen tweaker.me redirect
Over mij
Verwijderd
Done: End of sequence
Time: 90.3036367893 sec
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
| 00| | 01| | 02| | 03| | 04| | 05| | 06| | 07| | 08| | 09| | 10| | 11| | 12| | 13| | 14| | 15| | 16| | 17| | 18| | 19| | 20| | 21| | 22| | 23| | 24| | 25| | 26| | 27| | 28| | 29| | 30| | 31| | 32| | 33| | 34| | 35|[] | 36|[] [] [] | 37|[][][][][][][][][][][][] | 38|[][][][][][][][][][][][][][] | 39|[] [][][][][][][][][][][][][]| ------------------------------------ 00 02 04 06 08 10 12 14 01 03 05 07 09 11 13 ------------------------------------ 35 37 37 37 37 37 38 39 37 37 36 37 37 36 38 |
Lines cleared:
[1] => 21508
[2] => 1228
[3] => 53
[4] => 0
[5] => 0
Last Block: 2
Instruction count:631575
Drop count:100000
Score:2277500
Ik tel trouwens de laatste drop wel mee als zijnde drop maar niet mee in de puntentelling (omdat ie daar dus af gaat).
Ik tel ook de instructies van dat laatste blokje wel mee.
Dit in PHP, op de commandline op een Sempron 2800+ met 512MB geheugen, Debian thuisserver waar via VMWare ook een Windows Server 2003 op draait in de achtergrond.
Ik dacht PHP te pakken voor de validator zodat ik die online kon zetten voor de mensen hier, maar met resultaat bestanden van 6MB wordt dat een beetje lastig.
Ik kan em misschien wel ff ombakken naar een .exe dan kunnen mensen er thuis mee aan de gang.
[ Voor 255% gewijzigd door Verwijderd op 16-11-2006 22:42 ]
Game over!
Unknown move in move 631374 of which 0 where ignored.
1 liners : 21508
2 liners : 1228
3 liners : 53
4 liners : 0
5 liners : 0
discards : 5
Final score is 2277500
validating took 3594ms
Gedraait binnen eclipse op mijn XP2400+ (1.9Ghz) met 512Mb geheugen.
Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'
Kun je dat ook onderbouwen? Hier schiet ik niks mee op....
Ah, ik zie het al
Moment mal... effe kijken waar dat zit
Fix0red

IIG kan 'ie vanaf nu ook .png bestanden uitpoepen

[ Voor 50% gewijzigd door RobIII op 17-11-2006 00:44 ]
There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.
Je eigen tweaker.me redirect
Over mij
Verwijderd
Das heel handig!
Ga je dat ding ook nog ergens voor ons online zetten voor download? Wel zo handig.
Ik wil die van mij wel online zetten, maar of mensen daar blij van worden?
Kost me wel 5 minuten en 20 seconden op een Pentium M 1.6 Ghz. Het is een Java progsel en nog totaal niet geoptimaliseerd. Morgen maar eens door een profiler trekken.
Ik heb overigens ook nog steeds geen output en puntentelling, dus dat duurt nog ff
Verwijderd
Nu maar eens die PHP rommel achter me laten en in een iets stevigere taal beginnen.
Ben er nog altijd niet uit welke taal dat dan moet zijn, maar zoveel maakt dat ook weer niet uit.
Deze posts haken daar allemaal (min of meer) op in:Verwijderd schreef op donderdag 16 november 2006 @ 23:28:
Ga je dat ding ook nog ergens voor ons online zetten voor download? Wel zo handig.
RobIII in "Programming Contest Nieuwe Stijl: Contes..."
RobIII in "Programming Contest Nieuwe Stijl: Contes..."
Janoz in "Programming Contest Nieuwe Stijl: Contes..."
Als we het al doen, doen we dat "op onze eigen terms" en wanneer wij het daar tijd voor vinden. Maar niets weerhoudt je ervan om zelf een validator online te zetten.
Andere vraag, nu mensen een beetje op gang beginnen te komen: Is er al iemand die met een eigen testset werkt met (dus) eigen blokjes en game.txt? Of iemand die al een eigen willekeurige game.txt heeft gegenereerd en met een huidige set blokjes gecombineerd heeft?
Want vergeet niet dat we straks, tijdens de eigenlijke contest, jullie apps zullen voorzien van nieuwe blokjessets!!
* RobIII heeft al een blokje in gedachten:
1
2
3
4
5
| 10101 01010 10X01 01010 10101 |
[ Voor 32% gewijzigd door RobIII op 17-11-2006 01:05 ]
There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.
Je eigen tweaker.me redirect
Over mij
Verwijderd
Als jullie (of jij) een validator online zetten dan hebben ze ook die mogelijkheid om dat te doen, alleen dan gelijk fatsoenlijk.
De echte mensen maken toch zelf een validator aangezien je een groot deel daarvan ook nodig hebt in je uiteindelijke resultaat. Maar voor die mensen die gewoon eens wat resultaten willen bekijken of mensen die eigenlijk (nog) niet zoveel met de contest willen doen.
Het is natuurlijk jullie eigen keuze, van mij hoeft het niet hoor, maar het scheelt wel voor de mensen die potentieel mijn brakke ding zouden willen gebruiken.
Ik denk niet dat er al veel mensen zijn die een AI hebben die met de standaard set om kan gaan, laat staan een die nieuwe custom sets aan kan
We zijn pas net een paar dagen bezig he?
[ Voor 10% gewijzigd door Verwijderd op 17-11-2006 01:05 ]
Het scherm raakt wel iets voller zo, maar hij kan voldoelde compenseren door blokjes gewoon beter te plaatsen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |[] | |[] | #5 Lines: 0 |[][] [][] | #4 Lines: 17 |[][][][][] [][] | #3 Lines: 150 |[][][][][] [][][] []| #2 Lines: 2977 |[][][][][] [] [][][][][][]| #1 Lines: 17648 |[][][][][] [] [][][][][][][]| Blocks : 100000 |[][][][] [][][][][][][][][][]| Lines : 24120 |[][][][][][] [][][][][][][][]| Discards: 5 | [][][][][][][][][][][][][][]| Points : 2384450 +------------------------------+ 10 7 7 5 4 8 6 6 8 7 3 3 5 8 5 |
De reden van de verbetering is natuurlijk om tileset2 beter behapbaar te maken, maar vooralsnog blijft hij daar stranden na 466 turns
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
| | [] | | [] [][][] [][] | | [][][] [] [] [][] | | [] [][][] [][][][] | | [][] [][][][][][][][][]| | [][] [][][][][][][][][]| |[][][] [][][][][][][][][]| |[][][] [][][][][][][] [][]| |[][][][] [][][][][][][][][][]| |[][][][] [][][] [][][][][][]| |[][][][][] [][][][][][][][][]| |[][][][][][][][][][][][] [][]| |[][][][][][][][][][][][][][] | |[][][][][][][][] [][][][][][]| |[][][][][] [][][][][][][][][]| |[][][][][][][][][][] [][][][]| |[][] [][][][][][][][][][] []| |[][][][][][][] [][][][][][][]| |[][][][] [][][][][][][][][][]| |[][][] [][][][][][][][][][][]| |[][][][][][][][][] [] [][][]| |[][][][][][][][][][][] [][][]| |[][][] [][][][][][][][][][][]| |[][][][][][][][][][][][][][] | |[][][] [][][][][][][][][][][]| |[][][][][][][][][][] [][][][]| |[][][][][][][][][] [][][][][]| |[][] [][][][][][][][][][][][]| |[][][][][][][][][][][][][] []| |[][][][][][][][][][][] [] []| |[][][][][][][][][] [][][][][]| |[][][][] [][][][][][][][][][]| #5 Lines: 0 |[][][][][][][][][][] [][] []| #4 Lines: 0 |[][][][][][] [][][][][][][][]| #3 Lines: 4 |[][][] [][][][] [][][][][][]| #2 Lines: 24 |[][][][][][][][][][][] [][][]| #1 Lines: 61 |[][][][][][][][][][][] [][][]| Blocks : 466 |[][][][][][][] [][][][][][][]| Lines : 121 |[][][][][][][][] [][][][][][]| Discards: 5 |[][][][][][][][][][][][] [][]| Points : 14510 +------------------------------+ 34 38 30 40 39 37 39 36 38 39 33 39 36 39 37 |
[ Voor 116% gewijzigd door .oisyn op 17-11-2006 01:33 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Verwijderd
Nu zul je denken: VB is traag! maar niets is minder waar...
VB is (wanneer goed geschreven) net zo snel als C#, ze worden beide naar dezelfde CIL gecompiled dus er is geen reden waarom het trager zou zijn. Natuurlijk zitten er bepaalde dingen in VB die het de programmeur wat makkelijker maken maar de snelheid niet ten goede komen, maar als je daar even goed op let dan is dat geen enkel punt.
Ik heb het geheel nu object-oriented opgezet en de boel zoveel mogelijk geoptimaliseerd voor snelheid.
De grote 6MB file doet ie nu in 665 msec met correcte uitvoer.
Dat zijn bijna 1 miljoen instructies per sec...
En dat op mijn simpele laptopje Dothan 1.6 met 512MB geheugen en nog in de Visual Studio Debug omgeving. Wel krijg je pas die snelheden bij de 2e keer draaien, maar dat komt doordat ik op een laptop zit. Als de HDD nog moet opspinnen of z'n kop op de juiste plek moet zetten duurt het natuurlijk ff voordat die 6MB ook echt het programma binnen komt fietsen, das niet echt de schuld van het progje.
Natuurlijk doet mijne niet mooie PNG bestandjes uitpoepen en negeert hij het DEBUG commando volledig, maar het eindresultaat mag er zijn.
Ik zal deze validator even een beetje verder testen en aankleden en dan online zetten, dan kan iedereen zoveel validaten als ze maar willen.
Na verdere optimalisatie: 425 msec voor de 6MB grote file
Bijna anderhalf miljoen instructies per sec

Ook even een versie gemaakt die het DEBUG commando netjes doet.
En de executable is maar 32kb groot (exclusief de 54 MB voor .NET natuurlijk

Ff rondvragen voor een plekje om het te uppen...
En hier te vinden voor iedereen die er behoefte aan heeft.
Alles afgesloten, wat met prioriteiten gespeeld en nu het volgende resultaat:
359 msec voor de 6MB grote file

Dat zijn 1.758.702 instructies per sec
Das maar 250x zo snel als de PHP oplossing

[ Voor 22% gewijzigd door Verwijderd op 17-11-2006 07:44 ]
* Creepy is gisteren ook kort begonnen. Vandaag en vanavond geen tijd maar van het weekend hoop ik toch wel een entry + validator klaar te hebben.
"I had a problem, I solved it with regular expressions. Now I have two problems". That's shows a lack of appreciation for regular expressions: "I know have _star_ problems" --Kevlin Henney
Heb je een screenyVerwijderd schreef op vrijdag 17 november 2006 @ 06:18:
Nou de hele handel van 0 opnieuw geschreven in VB.net
Nu zul je denken: VB is traag! maar niets is minder waar...
VB is (wanneer goed geschreven) net zo snel als C#, ze worden beide naar dezelfde CIL gecompiled dus er is geen reden waarom het trager zou zijn. Natuurlijk zitten er bepaalde dingen in VB die het de programmeur wat makkelijker maken maar de snelheid niet ten goede komen, maar als je daar even goed op let dan is dat geen enkel punt.
Ik heb het geheel nu object-oriented opgezet en de boel zoveel mogelijk geoptimaliseerd voor snelheid.
De grote 6MB file doet ie nu in 665 msec met correcte uitvoer.
Dat zijn bijna 1 miljoen instructies per sec...![]()
En dat op mijn simpele laptopje Dothan 1.6 met 512MB geheugen en nog in de Visual Studio Debug omgeving. Wel krijg je pas die snelheden bij de 2e keer draaien, maar dat komt doordat ik op een laptop zit. Als de HDD nog moet opspinnen of z'n kop op de juiste plek moet zetten duurt het natuurlijk ff voordat die 6MB ook echt het programma binnen komt fietsen, das niet echt de schuld van het progje.
Natuurlijk doet mijne niet mooie PNG bestandjes uitpoepen en negeert hij het DEBUG commando volledig, maar het eindresultaat mag er zijn.
Ik zal deze validator even een beetje verder testen en aankleden en dan online zetten, dan kan iedereen zoveel validaten als ze maar willen.
Na verdere optimalisatie: 425 msec voor de 6MB grote file
Bijna anderhalf miljoen instructies per sec![]()
Ook even een versie gemaakt die het DEBUG commando netjes doet.
En de executable is maar 32kb groot (exclusief de 54 MB voor .NET natuurlijk)
Ff rondvragen voor een plekje om het te uppen...
En hier te vinden voor iedereen die er behoefte aan heeft.
Alles afgesloten, wat met prioriteiten gespeeld en nu het volgende resultaat:
359 msec voor de 6MB grote file
Dat zijn 1.758.702 instructies per sec
Das maar 250x zo snel als de PHP oplossing
Waarom gebruik in de klasse Block de array blockData niet als een twee dimensionale array?
Jawel, VB is traag. VB.Net echter, is idd gewoon .Net en dus net zo snel als elke andere .Net taal zolang je niet overal Variants en late binding e.d. gebruikt. M'n punt is dus: VB != VB.Net (en C++ != C++/CLI, etc.)Verwijderd schreef op vrijdag 17 november 2006 @ 06:18:
Nou de hele handel van 0 opnieuw geschreven in VB.net
Nu zul je denken: VB is traag! maar niets is minder waar...
Maar iig netjes. 't Valt me alleen op hoeveel mensen validators aan het schrijven zijn, ipv echt bezig zijn met het algoritme
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
[Wilde gok zonder de code te hebben gezien]Piels schreef op vrijdag 17 november 2006 @ 10:55:
[...]
Waarom gebruik in de klasse Block de array blockData niet als een twee dimensionale array?
Een 1 dimensionale array kan vrij simpel gebruikt worden in twee dimensies door als index (x + y * breedte) te gebruiken.
[/]
"I had a problem, I solved it with regular expressions. Now I have two problems". That's shows a lack of appreciation for regular expressions: "I know have _star_ problems" --Kevlin Henney
Ik was dus eerst met het algoritme begonnen en toen bleek dat ik iets toch fout zat te doen. Nu heb ik de validator gebouwd (met < 100 regels code, ik hergebruik mijn framework uiteraard) en toen bleek pas waar de fouten zaten. Nu werkt echter mijn validator perfect (hij geeft iig dezelfde output als die van RobIII)..oisyn schreef op vrijdag 17 november 2006 @ 11:40:
[...]
Jawel, VB is traag. VB.Net echter, is idd gewoon .Net en dus net zo snel als elke andere .Net taal zolang je niet overal Variants e.d. gebruikt. M'n punt is dus: VB != VB.Net (en C++ != C++/CLI, etc.)
Maar iig netjes. 't Valt me alleen op hoeveel mensen validators aan het schrijven zijn, ipv echt bezig zijn met het algoritme
Ik ben nu eerst maar weer de eerste testsuite helemaal aan het runnen en daarna gaan we de tweede verkennen
edit:
Het resultaat is niet slecht:
1
2
3
4
5
6
7
8
9
| |## # # # | |## # # #### # | ----------------- Score: 2881200 1-line clears: 6038 2-line clears: 5302 3-line clears: 2045 4-line clears: 337 5-line clears: 0 |
[ Voor 11% gewijzigd door Marcj op 17-11-2006 12:09 ]
https://oneerlijkewoz.nl
Op papier is hij aan het tekenen, maar in de praktijk...
dan zijn wij tenminste nog even verCodeCaster schreef op vrijdag 17 november 2006 @ 12:02:
Wat zijn jullie allemaal snel, ik ben nog bezig met de drop-code
klik
Van het weekend waarschijnlijk alleen geen tijd om aan te werken
Memories of yesterday, will grow, but never die
Verwijderd
Kun je in ieder geval tijd aan je vriendin besteden i.p.v. het hele weekend gaan zitten programmerenBintje809 schreef op vrijdag 17 november 2006 @ 12:13:
...
Van het weekend waarschijnlijk alleen geen tijd om aan te werkenDan ben ik bij mijn vriendin, en die hebben een not validated windows versie, waarop je dus geen SP2 kunt installeren. Gevolg --> geen visual studio 2005 --> kan dan dus niks ontwikkelen
Nou, lekker boeiendVerwijderd schreef op vrijdag 17 november 2006 @ 12:18:
Kun je in ieder geval tijd aan je vriendin besteden i.p.v. het hele weekend gaan zitten programmeren

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
SharpDevelop?Bintje809 schreef op vrijdag 17 november 2006 @ 12:13:
geen visual studio 2005 --> kan dan dus niks ontwikkelen
- "Als ik zou willen dat je het begreep, legde ik het wel beter uit!" | All number systems are base 10!
Verwijderd
Ik heb het idee dat de frustratie bij Bintje809 inmiddels zo hoog liggen omdat anderen al zo ver zijn dat het voor hem een lang weekend gaat worden
zo erg is het nu ook weer niet, maar mijn vriendin heeft, naast mijVerwijderd schreef op vrijdag 17 november 2006 @ 12:26:
[...]
Ik heb het idee dat de frustratie bij Bintje809 inmiddels zo hoog liggen omdat anderen al zo ver zijn dat het voor hem een lang weekend gaat worden![]()
.


back ontopic:
heb het idee uitgewerkt om te gaan droppen. En tevens een mooi, generiek idee uitgedacht om ze op de juiste plaats neer te kwakken. Alleen nog geen idee of het werkt
Memories of yesterday, will grow, but never die
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
| Step: 5318 | ##### #| | ###### ####| | #############| |# ############ | |############## | | ######## #### | |###### ## #### | |###### ## #### | |######### #### | |######### # ## | | ######## #####| | ##### ########| |############## | |############## | |## ######### ##| |############ ##| |########### ##| |############ ##| |## ############| |######## ######| |##### #########| |############## | |########### ## | |############## | |### ########## | |### ########## | |### ########## | |# ### #########| |############## | |######## ## ###| |######## ######| |# #############| |# #############| | #### ######## | | #### ######## | | ########### # | |############## | |############## | |############ ##| |#### ####### ##| ----------------- Score: 187780 1-line clears: 668 2-line clears: 269 3-line clears: 117 4-line clears: 34 5-line clears: 9 |
Verwijderd
Misschien nog wel sneller, mijn PC is prolly langzamer als die van Rob?Creepy schreef op vrijdag 17 november 2006 @ 08:52:
* Creepy mept Rob. Jouw VB oplossing is bijna drie keer zo traag als die van TRRoads. Doe eens fixen!
Maar die van mij maakt niet van die mooie resultaten dus het is niet helemaal eerlijk vergelijken.
Ja precies, VB 6 was echt erg traag vergeleken met de andere tools uit de Visual Studio suite. Maar .net is is inderdaad .net, late binding is puur evil maar gelukkig ook zo gefixed. Variants is een kwestie van goed programmeren dan heb je ze nooit nodig..oisyn schreef op vrijdag 17 november 2006 @ 11:40:
[...]
Jawel, VB is traag. VB.Net echter, is idd gewoon .Net en dus net zo snel als elke andere .Net taal zolang je niet overal Variants en late binding e.d. gebruikt. M'n punt is dus: VB != VB.Net (en C++ != C++/CLI, etc.)
Maar iig netjes. 't Valt me alleen op hoeveel mensen validators aan het schrijven zijn, ipv echt bezig zijn met het algoritme
Toch blijft bij veel mensen het idee leven dat VB.net ook VB is en dus per definitie traag is. Niets is dus minder waar.
Zoals ik al eerder zei, een validator gebruikt voor 90% de code die je toch al nodig hebt voor de administratie van een algoritme. Kleine moeite om dan even een validator te schrijven. Je hebt er toch een nodig om je eigen resultaten te checken.
Ik gebruik alleen maar simpele arrays van het type boolean, dit om overhead te voorkomen.Piels schreef op vrijdag 17 november 2006 @ 10:55:
[...]
Waarom gebruik in de klasse Block de array blockData niet als een twee dimensionale array?
PreciesCreepy schreef op vrijdag 17 november 2006 @ 11:56:
[...]
[Wilde gok zonder de code te hebben gezien]
Een 1 dimensionale array kan vrij simpel gebruikt worden in twee dimensies door als index (x + y * breedte) te gebruiken.
[/]
En zelfs zo ver dat het blockData(rotation * 25 + y * 5 + x) is, op die manier kunnen alle rotaties in 1 array.
Zal zometeen even naar een echte PC lopen en daar de boel op draaien, kijken of ie meer als 2 miljoen instructies per sec wil draaienevaarties schreef op vrijdag 17 november 2006 @ 10:08:
[...]
Heb je een screeny? Ik doe nl niet mee met de contest maar lees en kijk graag mee.
[ Voor 47% gewijzigd door Verwijderd op 17-11-2006 13:35 ]
Verwijderd

Overigens kan iedereen op zijn eigen PC het resultaat bekijken, in de rar file die ik gaf zit de volledige eerste tekenset + game.txt en daarbij ook de 6MB grote output (die nog maar 100kb is na compressie). Je kunt dus direct de .exe draaien (voor de no_debug versie hoef je zelfs niet eens een commandprompt te openen, hij wacht netjes op een toets) en het resultaat bekijken.
Wel even meerdere keren draaien zodat je weet wat het echte resultaat is ipv de snelheid van je hdd oid.
Helaas net geen 2 miljoen instructies per sec, maar een Core 2 Duo of een hoger geclockte X2 moet er geen moeite mee hebben om dat wel te halen.
[ Voor 14% gewijzigd door Verwijderd op 17-11-2006 14:03 ]
Nice, hoeveel blokken kijk jij vooruit?Marcj schreef op vrijdag 17 november 2006 @ 13:07:
Hmm, ik heb in de tweede test al een score gehaald van 187.780!
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'
Mijn PC is waarschijnlijk niet 's werelds snelste (2.0 Ghz PIV) maar het verschil zal 'm dan ook niet zitten in de "mooie resultaten" (die worden immers maar 1 keer, op het eind, gegenereerd).Verwijderd schreef op vrijdag 17 november 2006 @ 13:28:
Misschien nog wel sneller, mijn PC is prolly langzamer als die van Rob?
Maar die van mij maakt niet van die mooie resultaten dus het is niet helemaal eerlijk vergelijken.
Mijn code bestaat voor een fiks deel uit bounds-checks en vele andere "sanity-checks" om te voorkomen dat jullie, de deelnemers, straks ergens iets weten te omzeilen wat de validator of om zeep zou kunnen helpen of de resultaten zou kunnen opkrikken. Los daarvan is mijn code in principe in 1 keer geschreven en met wat schaven her en der (bugfixes) daarna tot final verklaard. Ik ben nog niet aan 't optimizen geslagen (ik vond de resultaten best netjes <1500ms voor 6Mb) en ik verwacht (met wat ideeën die ik heb) nog zeker een winst van 400 tot 1000% te kunnen halen
Helaas voor jullie (maar gelukkig voor mij) heb ik vandaag en morgen "papa-dag", dat houdt in dat IlseIII is werken en RobIII dus vandaag en morgen weinig contest zal doen omdat LucaIII aandacht nodig heeft
There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.
Je eigen tweaker.me redirect
Over mij
Voor deze keer 6 zetten vooruit. Hier wordt hij wel erg langzaam van, want ik ben voor elke zet rond de 100.000 velden aan het maken

edit:
Hmm, het lijkt er op dat mijn algorithme echt het beste werkt met 6 zetten voorruit. Met maar 5 is het spelletje na 320 zetten al over. Alleen nu haal ik nog maar ~5 zetten per seconde
edit2:
Ik heb even gekeken, maar er worden ~151.100 velden gerecycled per stap!
[ Voor 26% gewijzigd door Marcj op 17-11-2006 15:39 ]
Verwijderd
Nah smoesjesRobIII schreef op vrijdag 17 november 2006 @ 14:42:
[...]
Mijn PC is waarschijnlijk niet 's werelds snelste (2.0 Ghz PIV) maar het verschil zal 'm dan ook niet zitten in de "mooie resultaten" (die worden immers maar 1 keer, op het eind, gegenereerd).
Mijn code bestaat voor een fiks deel uit bounds-checks en vele andere "sanity-checks" om te voorkomen dat jullie, de deelnemers, straks ergens iets weten te omzeilen wat de validator of om zeep zou kunnen helpen of de resultaten zou kunnen opkrikken. Los daarvan is mijn code in principe in 1 keer geschreven en met wat schaven her en der (bugfixes) daarna tot final verklaard. Ik ben nog niet aan 't optimizen geslagen (ik vond de resultaten best netjes <1500ms voor 6Mb) en ik verwacht (met wat ideeën die ik heb) nog zeker een winst van 400 tot 1000% te kunnen halen
Helaas voor jullie (maar gelukkig voor mij) heb ik vandaag en morgen "papa-dag", dat houdt in dat IlseIII is werken en RobIII dus vandaag en morgen weinig contest zal doen omdat LucaIII aandacht nodig heeft
Maar je maakt toch ook plaatjes bij debug statements of niet? Sowieso heb ik die HTML bestandjes gezien, of was dat eenmalig?
Dat doe ik dus niet, ik geef maar een minimale output, niet zo netjes als jij dat doet
Bound checks en sanity-checks heb ik ook wel, maar waarschijnlijk een stuk minder als jij.
Ik heb alleen de basis, niet droppen voordat je iets gepakt hebt, niet 2x droppen, geen discard voordat je iets gepakt hebt, niet 2x discard, niet 2x new block etc en natuurlijk het vallen buiten het scherm.
Als je er een 400 a 1000% winst eruit weet te trekken is dat helemaal een prestatie
Maar als je het niet erg vind ga ik me nu richten op het algoritme en niet op het maken van een ubersnelle validator.
Trouwens wel nog 1 vraagje, want het viel me op dat de tijden in msec zegmaar afgerond werden, ik kreeg steeds dezelfde resultaten, bij het overclocken van de PC ging de tijd wel omlaag maar echt in stapjes.
Hoe meet jij de tijd?
Ik doe het zo:
Dim timeStart, timeEnd As DateTime
Dim Duration As TimeSpan
timeStart = DateTime.Now()
...reken reken reken...
timeEnd = DateTime.Now()
Duration = timeEnd.Subtract(timeStart)
Console.WriteLine(" Parsetime: " + (Duration.Milliseconds + Duration.Seconds * 1000).ToString + " msec ")
(Ik weet, duurt het langer als 1 min dan klopt de parsetime niet, aan de andere kant moet je je dan afvragen waar je mee bezig bent...)
[ Voor 15% gewijzigd door Verwijderd op 17-11-2006 15:00 ]
TimeSpan heeft o.a. ook TotalSeconds en TotalMilliseconds als property..Verwijderd schreef op vrijdag 17 november 2006 @ 14:57:
[...]
Console.WriteLine(" Parsetime: " + (Duration.Milliseconds + Duration.Seconds * 1000).ToString + " msec ")
(Ik weet, duurt het langer als 1 min dan klopt de parsetime niet, aan de andere kant moet je je dan afvragen waar je mee bezig bent...)
30Drie Web Design & IT Consultancy | Raven Consultancy Services
Plus dat je (v.z.i.w.) niet meet in echte milliseconden; de resolutie van die timers is volgens mij iets van 15ms ofzoMrSleeves schreef op vrijdag 17 november 2006 @ 15:16:
[...]
TimeSpan heeft o.a. ook TotalSeconds en TotalMilliseconds als property..
There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.
Je eigen tweaker.me redirect
Over mij
Verwijderd
Dat wist ik niet, ik heb werkelijkwaar nog nooit behoefte gehad om een tijdsduur te meten in VB
Het zal voor deze toepassing niet zoveel uitmaken aangezien het echt niet langer als 1 min hoort te duren.
Inderdaad, iets van 15ms dus het is niet echt eerlijk meten.RobIII schreef op vrijdag 17 november 2006 @ 15:35:
[...]
Plus dat je (v.z.i.w.) niet meet in echte milliseconden; de resolutie van die timers is volgens mij iets van 15ms ofzo
Daarom vraag ik: Hoe doe jij het?
Als jij het hetzelfde doet maakt het niet zoveel uit natuurlijk, maar gezien ik geen ervaring heb met tijdsmeting in VB had ik al zo'n idee dat ik iets obvious over het hoofd zie zoals de genoemde totalmilliseconds
Ik doe in essentie hezelfde; je hebt worst-case een afrondingsfout van die 15msVerwijderd schreef op vrijdag 17 november 2006 @ 15:49:
Daarom vraag ik: Hoe doe jij het?
Als jij het hetzelfde doet maakt het niet zoveel uit natuurlijk, maar gezien ik geen ervaring heb met tijdsmeting in VB had ik al zo'n idee dat ik iets obvious over het hoofd zie zoals de genoemde totalmilliseconds
There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.
Je eigen tweaker.me redirect
Over mij
Verwijderd
Ik ga weer verder dromen over hoe mijn AI iedereen gaat verslaan

Ik gebruik momenteel 3. Het kopiëren van de velden is bij mij echt met probleem niet, dat is na een minuut looptijd nog altijd een fractie van een seconde, dus het heeft ook geen nut om dat te optimaliseren. Het is echt de hoeveelheid combinaties die explodeert naarmate je de lookahead omhoog zet. Ik zal 'm vanavond ook eens op 6 proberen, kijken hoeveel blocks/sec ik haal.Marcj schreef op vrijdag 17 november 2006 @ 14:49:
Voor deze keer 6 zetten vooruit. Hier wordt hij wel erg langzaam van, want ik ben voor elke zet rond de 100.000 velden aan het maken. Gelukking werkt ik wel met een pool die de velden recycled, anders zou het helemaal niet gaan...
Overigens, hoe kom je aan zoveel velden per zet? Ga je met een breadth-first search door de mogelijkheden-boom heen? Ik doe depth-first, en dus heb ik maar n kopiën van m'n veld nodig, waarbij n m'n lookahead is.
[ Voor 5% gewijzigd door .oisyn op 17-11-2006 16:34 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Met een beetje vooruit-denken moet dat een stuk hoger kunnen. Strategie is nu nog ver te zoeken.
30Drie Web Design & IT Consultancy | Raven Consultancy Services
'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.
Lol!-NMe- schreef op vrijdag 17 november 2006 @ 17:37:
Voor de mensen die OO programmeren nog een tip: kijk eens naar het strategy design pattern. Dat DP maakt het erg eenvoudig om, als een strategie niet voldoet, even snel een andere te gebruiken en te kijken hoe die zich tot de andere verhoudt. Je zou in principe zelfs meerdere strategieën toe kunnen passen (je hebt immers 2 uur) en de best scorende strategie kunnen laten uitvoeren.
daar heb ik dus serieus over nagedacht
Welke technieken hebben jullie daar eigenlijk voor gebruikt? Ik heb namelijk echt het vermoeden dat ik dat echt veel te moeilijk doe.
Memories of yesterday, will grow, but never die
Script werkt alleen nog niet helemaal... Edit: toch wel. Moet wel vanaf de onderkant van het blokje rekenen
[ Voor 74% gewijzigd door CodeCaster op 17-11-2006 18:09 ]
https://oneerlijkewoz.nl
Op papier is hij aan het tekenen, maar in de praktijk...
ik kan nu droppen!
binnenkort maar eens in een mooi jasje gieten, zodat ik ook meesterlijk goed lijk
Memories of yesterday, will grow, but never die
Verwijderd
Het is niet heel moeilijk, het helpt bij deze situaties soms om het te tekenen.CodeCaster schreef op vrijdag 17 november 2006 @ 18:03:
Ik heb een array van 15 elementen, die de kolomhoogte bevat. Die bevat een getal tussen de 40 en 0. Daarna dus controleren op welke kolommen het blokje gaat vallen. Dan de positie uitrekenen per kolom waar gecollided gaat worden. Hoogste positie wint.
Script werkt alleen nog niet helemaal... Edit: toch wel. Moet wel vanaf de onderkant van het blokje rekenen
Let op: Spoiler over het droppen van blokjes, geen code hier maar het geeft wel eea weg.
Wil je alles zelf doen, dan vooral niet lezen!
Dan plaats je daar de onderkant van de 5x5 grid op, oftewel de eerste positie van de 5x5 grid komt op hoogte 35.
In je script weet je dus dat je moet beginnen met 35. Van die 35 trek je dan de kolomhoogte van de betreffende kolom die je gaat raken af (zoveel moet je immers omhoog).
Je hebt dan je 5x5 grid op de kolom liggen, maar moet nu dus dat grid nog een aantal blokjes omlaag verplaatsen, dit is de afstand tussen de onderkant van je 5x5 grid (normaal gezien 4) en het onderste blokje in de betreffende kolom van je 5x5 grid. Die afstand tel je bij je de 35 - kolomhoogte op, dit is de hoogte waarop je 5x5 grid moet beginnen met tekenen zodat ie op de juiste plek in het veld komt te staan.
Voor optimalisatie het dus handig om de kolom hoogte in je veld bij te houden, de kolom van het meest linkse blokje en de kolom van het meest rechtse blokje in je 5x5 grid en y-positie van het laagste blokje in een kolom van je 5x5 grid.
Om te bepalen waar het blokje je veld zal raken is ook heel simpel, je doorloopt even je 5 kolommen (of na optimalisatie minder kolommen enkel waar een blokje in de 5x5 grid staat). Je telt dan de kolomhoogte van je veld en de y-positie van het laagste blokje in je 5x5 grid op de betreffende kolom op, daar waar deze waarde het grootste is gaat je blokje raken.
Het kan ook helpen de meest bovenste positie van een blokje in je 5x5 grid bij te houden, dit helpt om te bepalen of je al door de bovenkant heen bent en dus game over. Zo ook dus de meest linkse en rechtse om te bepalen of je links of rechts te ver gaat en om alleen die kolommen te tellen waar er ook echt een blokje in je 5x5 grid staat.
En vergeet geen rekening te houden met blokken die uit 2 delen bestaan en dus een lege kolom in het midden hebben.
Dit is overigens niet de enige mogelijkheid, er zijn heel veel andere manieren. Maar ik gebruik deze methode en ben er erg tevreden over.
Het is mogelijk verder te optimaliseren maar gezien de performance zal dat niet zo'n probleem zijn.
---
Over de AI:
Ik denk niet dat je er onderuit komt om een vorm van genetisch gedrag te gebruiken. Je hebt immers geen enkel idee hoe de blokkenset eruit komt te zien.
Mijn idee is om em een paar duizend generaties te laten doorlopen met een aantal blokkensets die ik zelf ga ontwerpen. De beste resultaten daaruit zet ik in een lijst op volgorde van beste prestaties over de gehele linie van blokkensets.
Afhankelijk van de performance laat ik een 10.000 tot 25.000 blokjes doorlopen met een bepaalde gewichtenset (zoals eerder bepaald). Op die manier laat ik em zoveel mogelijk voorgedefineerde situaties doorlopen totdat ie (met een ruime marge natuurlijk) geen tijd meer over heeft. Dan laat ik em met het beste resultaat 1x final doorlopen en het resultaat uitpoepen.
Dit lijkt mij de beste opzet, maar de implementatie ervan en de implementatie van het algoritme zelf zijn natuurlijk geen koud kunstje.
[ Voor 17% gewijzigd door Verwijderd op 17-11-2006 21:09 ]
1
2
3
4
| x1111 1 1 1 111 |
[ Voor 35% gewijzigd door CodeCaster op 17-11-2006 19:31 ]
https://oneerlijkewoz.nl
Op papier is hij aan het tekenen, maar in de praktijk...
Verwijderd
De theorie erachter klopt ook dus zou niet weten waarom niet.
(Misschien moet ik het duidelijker in het stukje zetten, maar ik hoef niet alles helemaal weg te geven)
Verwijderd
In mijn ervaring is berekenen meestal sneller als testen.
- in het 5x5 array alles zo ver mogelijk naar links geshift
- in het 5x5 array alles zo ver mogelijk naar boven geshift, zodat het blokje zich altijd links bovenaan in het array bevindt.
bijhouden:
- meest bovenste blokje
- meest rechtse blokje
- onderste hokje
Voor het veld: een 1d array bijhouden met het laatste rijnummer van de eerste serie onafgebroken vrij plaatsen.
dus als in kolom 1 de plaatsen 0..20, 21, 23, 24...37 en 39 vrij zijn, dan krijgt dat array[0]= 20.
zo per kolom van een blokje, waar zich blokstukjes bevinden, controleren of het blokje er kan liggen of niet.
Memories of yesterday, will grow, but never die
Waarom zou je dat doen? En hoe lees je die regels uit? Zoals ik het me voorstel ben je dan telkens bezig om je integer weer uit te bouwen in een array, eventueel aan te passen, en dan weer terug in een integer te stoppen. Of heb ik dit mis?DaCoTa schreef op vrijdag 17 november 2006 @ 19:35:
Ben ik dan zo vreemd bezig met mijn bitrepresentatie? Oftewel, 1 regel is 1 integer, waarbij iedere bit een kolom is. Ik heb van alle mogelijk rotaties en verplaatsingen ook een array van integers gemaakt, van 1 tot max 5 en ik probeer gewoon beide representatie over elkaar heen te and-en. Als ik geen collision tegen kom (and != 0) dan kan ik omlaag. Enige optimalisatie die ik kan toevoegen is de hoogste positie onthouden en pas vanaf die plek omlaag laten vallen, maar dat is een minimale optimalisatie.
Dit lijkt me namelijk niet echt efficiënt, en voor het geheugengebruik zou ik het ook niet doen...
https://oneerlijkewoz.nl
Op papier is hij aan het tekenen, maar in de praktijk...
Verwijderd
Dit werkt op zich wel goed, maar berekenen is gewoon een stuk vlotter in deze situatie.
Je hoeft dus ook niet echt te kijken waar blokjes staan, gewoon even een rijtje getallen optellen en je weet het al.
EDIT: stond dus al op pagina 1

[ Voor 6% gewijzigd door CoolGamer op 17-11-2006 19:56 ]
¸.·´¯`·.¸.·´¯`·.¸><(((º>¸.·´¯`·.¸><(((º>¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸<º)))><¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸
https://oneerlijkewoz.nl
Op papier is hij aan het tekenen, maar in de praktijk...
Verwijderd
Jups, dat is zeker toegestaan en wordt ook wel gebruikt.
De vraag is alleen of je de performance goed genoeg kunt krijgen om het vooruit kijken de moeite waard te maken.
1, 2 of 3 blokjes vooruit kijken moet te doen zijn, maar 4 a 5 gaat toch al wel lastig worden (hoe meer hoe groter je domein wordt en dat gaat harder als je denkt).
Maar er is hier dus al iemand (of misschien inmiddels 2) die 6 blokjes vooruit aan het kijken zijn.
In dit geval denk ik dat testen toch sneller is. Worst-case moet je 4 situaties testen en dan 5x AND uitvoeren om het block in het veld te krijgen and je met bits werkt. In jouw geval moet je eerst rekenen (vast aantal operaties), gevolgd door maximaal 25 assignments in je array (met een loop dus).Verwijderd schreef op vrijdag 17 november 2006 @ 19:39:
In mijn ervaring is berekenen meestal sneller als testen.
Een AND operatie kan in 1 CPU instructie, een array assignment ook, maar de worst case van het ANDen (5 tests + 5 ANDS = 10 operaties) is sneller dan de best-case van je berekenmethode (x berekeningen + 1 assignment, als x >= 10 is dat al minimaal 10 operaties).
Overgens gaat dit nergens over, want hier zal je bottleneck echt niet liggen, in geen van beide gevallen.
- "Als ik zou willen dat je het begreep, legde ik het wel beter uit!" | All number systems are base 10!
Verwijderd
Lees het verhaaltje wat ik postte maar eens goed, er hoeft echt bijna niets te gebeuren.
Het betreft allemaal integers.
Dit terwijl als je het rij voor rij gaat doen je worst case 40 rijen moet gaan testen.
Naar mijn weten is 40 nog altijd meer als 5.
In de praktijk komt in mijn geval de worst case nooit voor, terwijl in de rij voor rij situatie de worst case zeer zeker voor gaat komen.
[ Voor 8% gewijzigd door Verwijderd op 17-11-2006 20:21 ]
Ik snap het. Dan ga ik eens kijken of ik een hybride variant kan maken, want het speelveld updaten gaat met een paar xors natuurlijk wel snellerVerwijderd schreef op vrijdag 17 november 2006 @ 19:39:
Nou niet zo vreemd, maar wat jij doet is testen (voelen) waar het blokje terecht komt, terwijl je dit ook kunt berekenen.
In mijn ervaring is berekenen meestal sneller als testen.
Je houd natuurlijk wel de hoogte van het veld bij, 40 keer testen is natuurlijk zinloos als je weet dat er de eerste 34 rijen toch niets ligt. Het speelveld updaten gaat idd wel lekker snel met een paar ors (xor is niet nodig als je eerst getest hebt of het past.Verwijderd schreef op vrijdag 17 november 2006 @ 20:20:
Dit terwijl als je het rij voor rij gaat doen je worst case 40 rijen moet gaan testen.
- "Als ik zou willen dat je het begreep, legde ik het wel beter uit!" | All number systems are base 10!
Verwijderd
Inderdaad, dat is een optimalisatie die je erin kunt zetten (maar eerder werd al genoemd dat dat nog niet het geval was).Gerco schreef op vrijdag 17 november 2006 @ 20:24:
[...]
Je houd natuurlijk wel de hoogte van het veld bij, 40 keer testen is natuurlijk zinloos als je weet dat er de eerste 34 rijen toch niets ligt. Het speelveld updaten gaat idd wel lekker snel met een paar ors (xor is niet nodig als je eerst getest hebt of het past.
Hoewel het updaten van het speelveld ongetwijfeld sneller gaat met or's weet ik niet hoe handig het is om alles in integers te hebben tov een array van booleans in de andere stukken van het programma.
Ook weet ik zo goed als zeker dat het berekenen in dit geval veel sneller of minstens zo snel is als het voelen. Je hoeft gewoon minder te controleren en dus zou het sneller moeten zijn, dat de operatie zelf langzamer is maakt niet zoveel uit, die zal echt niet zoveel langzamer zijn dat het iets scheelt.
Maar je kunt zoals gezegd inderdaad goed een hybride versie schrijven die de integers gebruikt met het berekenen, dat zou de snelste oplossing zijn.
De totale winst hiervan is misschien 5%, maar dat kan het verschil gaan maken natuurlijk.
Trouwens: Niet mijn methode verwarren met die van Bintje809, bij mij wordt er dus best case 2 getallen bij elkaar opgeteld om het resultaat te krijgen en worst case 5x optellen, vergeleken en opgeslagen.
Ik sla dus helemaal niets op in een array bij het bepalen van de drop.
[ Voor 8% gewijzigd door Verwijderd op 17-11-2006 21:05 ]
Ja, ik doe breadth-first. Hiermee kan ik juist de hoeveelheid mogelijkheiden enigsinds beperken door van de huidige diepte de 5 of 6 best opties uit te zoeken en dan alleen deze verder uit te diepen. Ik heb net even depth-first geprobeerd: met 3 gaat het heel snel, met 4 al een stuk minder en 5 is al ondoenelijk traag... Het probleem is dat je echt alle mogelijkheden nazoekt, plus dat hele delen van de boom steeds opnieuw worden berekend. Met mijn breadth-first gaat dit wel helemaal goed..oisyn schreef op vrijdag 17 november 2006 @ 16:33:
[...]
Ik gebruik momenteel 3. Het kopiëren van de velden is bij mij echt met probleem niet, dat is na een minuut looptijd nog altijd een fractie van een seconde, dus het heeft ook geen nut om dat te optimaliseren. Het is echt de hoeveelheid combinaties die explodeert naarmate je de lookahead omhoog zet. Ik zal 'm vanavond ook eens op 6 proberen, kijken hoeveel blocks/sec ik haal.
Overigens, hoe kom je aan zoveel velden per zet? Ga je met een breadth-first search door de mogelijkheden-boom heen? Ik doe depth-first, en dus heb ik maar n kopiën van m'n veld nodig, waarbij n m'n lookahead is.
Ik zie niet in waarom dat met depth-first niet kan, daartoe had ik ook al besloten omdat alle combinaties vanaf 5 idd echt niet meer te doen is.Marcj schreef op zaterdag 18 november 2006 @ 00:32:
Ja, ik doe breadth-first. Hiermee kan ik juist de hoeveelheid mogelijkheiden enigsinds beperken door van de huidige diepte de 5 of 6 best opties uit te zoeken en dan alleen deze verder uit te diepen.
Bedoel je hiermee het plaatsen van een blokje? Ik zie namelijk niet in hoe dat met breadth-first anders is - ookal zet je blokje 2 op dezelfde plek, het resultaat is toch anders als blokje 1 in verschillende situaties op verschillende plekken staat.plus dat hele delen van de boom steeds opnieuw worden berekend.
.edit: zo, even gedaan wat ik al zei, gewoon een aantal beste combinaties proberen ipv allemaal. Met 7 blokken lookahead plaats ik ongeveer 10 blokken per seconde. Ik zie nu wel dat door deze wijziging (van 3 naar 7 lookahead) ik m'n heuristieken moet wijzigen aangezien de plaatsing van een enkel blokje wat nietig is in 'the big picture'
[ Voor 17% gewijzigd door .oisyn op 18-11-2006 01:49 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
![]() |
(Klik voor volledige versie, 24 mb, bijna 10 uur.
[ Voor 7% gewijzigd door Soultaker op 18-11-2006 03:00 ]
Verwijderd
De validator van mij is ook nog even geupdate, er bleek 1 uitzonderlijk geval te zijn waarin het line clearen mis kon gaan.
Ik heb mijn AI engine nu goed aan de praat maar ben nog bezig met tweaken van de gewichten. De bedoeling is dat ie dat uiteindelijk zelf gaat bepalen wat het beste is voor de set dat ie krijgt... en dat alles in 2 uur

Nah het gaat wel lukken, nog tijd zat.
Mijn eerste resultaat: (unoptimized in de visual studio omgeving op het trage laptopje met van alles en nogwat in de achtergrond vandaar de extreme parsetijd van iets meer als 1 min, de bedoeling is dit terug te brengen naar 1 a 2 sec maximaal).
Dit is trouwens met het basis algoritme, 7 variablen en geen vooruitkijk, zo goed als brute force. Dus er is nog veel werk aan de winkel, maar je moet een basis hebben om verder te werken.
Initializing...
No more blocks left
Score: 2235300
Drop count: 100000
Discard count: 0
1 line: 23058
2 line: 524
3 line: 6
4 line: 0
5 line: 0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
| 40| | 39| | 38| | 37| | 36| | 35| | 34| | 33| | 32| | 31| | 30| | 29| | 28| | 27| | 26| | 25| | 24| | 23| | 22| | 21| | 20| | 19| | 18| | 17| | 16| | 15| | 14| | 13| | 12| | 11| | 10| | 09| | 08| | 07| | 06| | 05| | 04| | 03| [][] | 02|[][][][] [][][][][][][][][] | 01| [][][][][][][][][][][][][][]| --+------------------------------+-- 00 02 04 06 08 10 12 14 01 03 05 07 09 11 13 --+------------------------------+-- 02 03 01 02 02 02 02 01 03 02 02 02 02 02 02 |
Shutting down...
Parsetime: 67385,3355 msec
[ Voor 71% gewijzigd door Verwijderd op 18-11-2006 05:23 ]
Hmm, misschien kan ik het nog wel wijzigen in een depth-first. Ik ga het iig nog wel even proberen. Het voordeel dat ik in breadth-first zag is dat ik de zoekboom gewoon kan bewaren en bij elke stap alleen de laatste laag moet uitbreiden. Daarentegen hoef ik voor depth-first bijna niets te onthouden (één veld voor elke stap in de diepte)..oisyn schreef op zaterdag 18 november 2006 @ 01:00:
[...]
Ik zie niet in waarom dat met depth-first niet kan, daartoe had ik ook al besloten omdat alle combinaties vanaf 5 idd echt niet meer te doen is.
[...]
Bedoel je hiermee het plaatsen van een blokje? Ik zie namelijk niet in hoe dat met breadth-first anders is - ookal zet je blokje 2 op dezelfde plek, het resultaat is toch anders als blokje 1 in verschillende situaties op verschillende plekken staat.
.edit: zo, even gedaan wat ik al zei, gewoon een aantal beste combinaties proberen ipv allemaal. Met 7 blokken lookahead plaats ik ongeveer 10 blokken per seconde. Ik zie nu wel dat door deze wijziging (van 3 naar 7 lookahead) ik m'n heuristieken moet wijzigen aangezien de plaatsing van een enkel blokje wat nietig is in 'the big picture'
Ik ga nog even kijken wat sneller is...
Daarmee heb ik mijn eerste stapje gezet naar .NET, en eigenlijk mijn eerste stapje buiten legacy-talen en -platforms. Dan tel ik voor het gemak VBa en QB even niet mee.
Geen betere aanleiding om eens een nieuwe taal te leren dan een contest
je kunt, als je wilt, ook visual studio express gratis downloaden. Ik vind het echt een geweldige editor!! (en vanuit mijn studie mag ik zelfs gratis visual studio 2005 professional gebruiken, thuisDido schreef op zaterdag 18 november 2006 @ 11:48:
* Dido heeft net SharpDevelop geinstalleerd.
Daarmee heb ik mijn eerste stapje gezet naar .NET, en eigenlijk mijn eerste stapje buiten legacy-talen en -platforms. Dan tel ik voor het gemak VBa en QB even niet mee.
Geen betere aanleiding om eens een nieuwe taal te leren dan een contest
Memories of yesterday, will grow, but never die
Ik hou hem in gedachten als SharpDevelop niet bevaltBintje809 schreef op zaterdag 18 november 2006 @ 11:56:
je kunt, als je wilt, ook visual studio express gratis downloaden. Ik vind het echt een geweldige editor!! (en vanuit mijn studie mag ik zelfs gratis visual studio 2005 professional gebruiken, thuis)
Ik heb geloof ik ook nog wel ergens VS liggen, maar in mijn beleving is dat een heleboel meuk om een simpel programmaatje te schrijven...
rant! welke klootviool heeft verzonnen dat alt+s opeens een menuoptie is in FF2

ach, ik ben niet anders gewendDido schreef op zaterdag 18 november 2006 @ 12:08:
[...]
Ik hou hem in gedachten als SharpDevelop niet bevalt
Ik heb geloof ik ook nog wel ergens VS liggen, maar in mijn beleving is dat een heleboel meuk om een simpel programmaatje te schrijven...
offtopic:
rant! welke klootviool heeft verzonnen dat alt+s opeens een menuoptie is in FF2
Memories of yesterday, will grow, but never die
Dido schreef op zaterdag 18 november 2006 @ 12:08:
[...]
offtopic:
rant! welke klootviool heeft verzonnen dat alt+s opeens een menuoptie is in FF2
Browsen naar about:config en daar ui.key.generalAccessKey op 18 instellen, dan ben je ervanaf.
'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.
En zo leer ik iedere dag weer wat bij. Thanks -NMe-
1
2
3
4
5
6
7
8
9
10
11
12
13
14
| | | | | | | #5 Lines: 15 | [] []| #4 Lines: 44 | [] [][][] []| #3 Lines: 176 | [] [][][] [][] [][]| #2 Lines: 598 | [][][][][][][][][][][][][][]| #1 Lines: 1445 | [][][][][][][][][][][][][][]| Blocks : 10277 | [][][][][][][][][][][][][][]| Lines : 3420 | [][][][][][][][][][][][][][]| Discards: 5 |[][][][][][][][] [][][][][][]| Points : 352770 +------------------------------+ 1 5 5 7 6 6 5 8 5 8 7 7 5 6 6 |
En hij loopt dus nog \o/
.edit: damnit, gameover. Ik dacht dat ik het zowaar ging halen

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
| | [] | | [] [] [][][] [] [] | | [][][] [][][] [][][][] | |[] [][][][][][][][][][][] | |[][][] [][][][][][] [] | |[][][][][][][][][][][][][] | |[][][][][][][][][][][][][][] | |[][][][][][][][][][][][][][] | |[][][][][][][][][][][][][][] | | [][][][][][][][][][][][][] | |[][][][][][][][][][][][][][] | |[][][][][][][][][][][][][][] | |[][][][][][][][][][][][][] []| |[][][][][][] [][][][][][][] | |[][][][][][] [][][][][][][][]| |[][][][][][][][][][][][][] []| |[][][][][][][][][][][][][] []| |[][] [][][][][][][][][][][][]| |[][][][][][][] [][][][][][][]| |[] [][][][][][][][][][][][][]| |[] [][][][][][][][][][][][][]| |[][][][][][][][][][] [] [][]| | [][][][][][][][][][][][][][]| |[][][][][][][][][][][][][] []| |[][][][][][][][][][][] [][][]| |[][][][][][][][][][][][][][] | |[][][][][][] [][][][][][][][]| |[][][][][][][][][][][] [][][]| |[][][][][][] [][][][][][][][]| |[][][][][][][][][] [][][][][]| |[][][][][][][][][][][][][][] | |[][] [][][][][][][][][][][][]| #5 Lines: 23 |[][][][][][][][][] [][][][][]| #4 Lines: 75 |[][][][][][][][][] [][][][][]| #3 Lines: 313 |[][][][][] [][][][][][][][][]| #2 Lines: 1028 |[][][][][][] [][][][][][][][]| #1 Lines: 2420 | [][][][][][][] [][][][][][]| Blocks : 17596 |[][][][][][][][][][][][][][] | Lines : 5830 |[][][][][] [][][][][][][][][]| Discards: 5 |[][][][][][][][][] [][][][][]| Points : 601810 +------------------------------+ 37 38 37 39 37 39 40 28 39 39 39 39 38 38 34 |
[ Voor 63% gewijzigd door .oisyn op 18-11-2006 14:25 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
edit: nog niet eens zo'n stom idee, als je weet dat je afgaat, kijk wat er gebruikt als je als noodoplossing wat discards gebruikt, en zo hoopt op een paar goeie stenen.. als je die lange van 5 blokjes had gekregen, kon je weer effe vooruit..
[ Voor 80% gewijzigd door Bint op 18-11-2006 14:27 ]
Memories of yesterday, will grow, but never die
Mijn algo had er misschien ook wel uit kunnen komen. Het punt is, als ik een blokje plaats en daardoor is ie gameover dan throw ik een exception. Maar de lookahead code vangt die niet op, dus zodra het blokje dat het meest 'in de toekomst' ligt op geen enkele manier geplaatst kan worden zonder een gameover dan stopt m'n algoritme, terwijl hij dat best had kunnen voorkomen door de blokjes die voorheen kwamen anders te rangschikken.Bintje809 schreef op zaterdag 18 november 2006 @ 14:26:
edit: nog niet eens zo'n stom idee, als je weet dat je afgaat, kijk wat er gebruikt als je als noodoplossing wat discards gebruikt, en zo hoopt op een paar goeie stenen.. als je die lange van 5 blokjes had gekregen, kon je weer effe vooruit..
Ik wist al van deze bug maar heb er tot nu toe nog niet echt aandacht aan besteed. Maar goed, ik heb de output.txt nog dus ik kan altijd nog de aanpassing maken en dan weer verder gaan waar ik bebleven was
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Dit topic is gesloten.
Er worden nogal wat vragen gesteld die tot nu toe allemaal in de TS worden beantwoord. Lees voor je je vraag stelt dus érg aandachtig de TS door want de kans is groot dat het er gewoon in staat. Uiteraard ben je vrij vragen te stellen, maar kijk dan niet raar op als je een "Zie TS" antwoord krijgt.
De kunst van deze contest is onder andere het goed lezen en interpreteren van de gegevens die je gekregen hebt.