Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 93 reacties

Programmeurs hebben naar eigen zeggen het meest compacte schaakprogramma ooit geschreven. De code van BootChess bestaat uit slechts 487 bytes, waar de vorige recordhouder nog 672 bytes nodig had om een werkend schaakprogramma te krijgen.

In 1983 werd door David Horne 1K ZX Chess uitgebracht. Deze schaaksoftware gebruikte op een Sinclair ZX81-homecomputer 672 bytes aan werkgeheugen en was decennialang de recordhouder als meest compacte schaaksoftware ooit geschreven. Maar het record is inmiddels gesneuveld: programmeurs van de groep Red Sector Inc., actief in de demoscene, hebben BootChess geschreven, een schaakcomputer waarvan de code 487 bytes telt.

De code van BootChess is geschreven in assembler. BootChess is een multiplatform-game, kan opstarten vanuit een bootsector en toont de gebruiker een uiterst kaal schaakbord. De speler moet door middel van getikte commando's de pionnen op het bord verzetten. Sommige ontwikkelaars die BootChess hebben uitgeprobeerd stellen echter dat de schaaksoftware nog een aantal fouten bevat waardoor het geen volledig en correct functionerende schaaksoftware genoemd zou mogen worden.

BootChess

Lees meer over

Moderatie-faq Wijzig weergave

Reacties (93)

Ik volg de scene al een aantal jaren (En weet dus dat mede-Tweaker ScaliBG daar ook post) en het is inderdaad een indrukwekkend stukje sizecoding. Dat gezegd hebbende is het niet een echte schaak implementatie, zie:
http://www.pouet.net/prod.php?which=64962#c715283

Overigens zijn er een paar mensen die binnen het hele sizecoding gebeuren erbovenuit steken. Zoals Mentor/TBC (http://www.pouet.net/user.php?who=3999) en rrrola (http://www.pouet.net/user.php?who=22889). Speciale vermelding (en voor wie meer wilt weten) voor Blueberry/Loonies (http://www.pouet.net/user.php?who=10883), welke Shrinkler voor de Amiga heeft gemaakt (http://www.pouet.net/prod.php?which=64851) en tevens met Mentor verantwoordelijk is voor Crinkler (http://www.pouet.net/prod.php?which=18158) welke tot de top van bestandscompressie behoren.
Ik zit daar ook op (pouet.net) maar ben meer geÔnteresseerd in games voor Android en games voor Windows. Buiten dat zoek ik naar leuke grafische demo's, 4kb procedural graphics, etc..
Ik moet zeggen, Kkrieger vind ik nog altijd de beste game voor maar 96kb! :)
Ik heb geen account op Pouet hoor ;) Maar ik volg het al jaren.
.Kkrieger is inderdaad een zeer indrukwekkend stuk techniek, helaas niet afgemaakt, en dat zal helaas niet meer gebeuren in ieder geval.

Een recente indrukwekkende demo is The Timeless by Mercury (http://www.pouet.net/prod.php?which=62935) en praktisch alles wat Fairlight, en in het bijzonder Smash maakt als het je om leuke grafische demo's gaat (http://www.pouet.net/groups.php?which=44&order=thumbup)
Elude heeft overigens een leuke Android demo: (http://www.pouet.net/prod.php?which=60242), tevens 1 van de groten op de Amiga.

Veel lees en kijkplezier!
Kijkplezier?
Lol, mijn Terabyte staat letterlijk vol. Alles geordend volgens hoe leuk ik het vind.
00 (Slecht) tot 04 (Excellent)
(Cocoon - Glon243, FAN - StillSuckingNature, Fr-063 Magellan V1.02, Smash Designs - Adrenalin, ..., gewoon om er een paar te kiezen, lijst gaat verder en verder...)

http://www.pouet.net/prod.php?which=62935 staat inderdaad bij 04 daar ik het echt wel een masterpiece vind.

Dan hebben we nog een mapje met muziek (mp3, 669, FAR, IT, Mid, Mod, Mtm, Ptm, S3m, Wav en XM)

Mapje met Programs om zelf scenes, demo's, screensavers, ... te maken

Mapje met Games (waaronder Kkrieger, Wormhol (Adinpsz), Dynablaster Revenge, Earworm, Springy, Superball Partyversion, TSS Demo (GTA Clone), Porrasturvat102, Truckdismount101, ...)

Mapje met Music Books, Magazines, Movies (tot 4GB groot), Art Packs, ...

Das zo wa int kort.
Deden ontwikkelaars voor smartphone apps hier ook maar eens hun best op...
Dat gaat vrij lastig tegenwoordig. Ik werk aan een app die vrij groot is, en in het begin wil je eerst de achterliggende classes op orde hebben en bouw je een spartaanse UI die gewoon doet wat het moet doen om te kijken of alles werkt. Resultaat: app is net 2.5MB oid.

Maar dan begint het werk pas echt: we willen niet meer de views van Gingerbread, we willen de layout van Material Design. En dan begint het feest. Libraries importeren voor views van Google om op oude versies van Android ook de layout te kunnen krijgen. Daarna blijkt dat er in hun libraries ook van alles mist, dus kan je zelf ook nog wat dingen bijschrijven, of soms heeft iemand anders dat al gedaan. Daarna moet je nog dingen versimpelen: automatisch afbeeldingen inladen? Asynctasks schrijven is wat tijdrovend, we gebruiken wel een kant-en-klare library waarvan de developer zich heeft toegespitst op de optimalisatie van de code en die fouten al voor ons afvangt.

Aan het eind van de dag heeft de app Material Design, ziet het er piekfijn uit, maar weegt hij wel 7MB. Ach, anno 2015 is die paar MB extra ook geen ramp als je er een hoop gemak voor terug krijgt (tenzij het overgrote deel van onze userbase wil dat we applicaties apart deployen voor Gingerbread, Jelly Bean tot Kitkat, en Lollipop, in dat geval valt er misschien een paar MB te besparen, maar da's zo lastig om te onderhouden :p)
Het is altijd nog beter dan gebruik maken van Crosswalk in combinatie met Android en Cordova. Dan mag je meteen 15 - 20 MB aan je applicatie van 1-2 MB toevoegen. En dat alles omdat Android qua browser c.q. webview het IE6 van de 21 eeuw is geworden...

Het feit dat men er serieus over nadenkt om een applicatie soms 20MB groter te maken dan 'noodzakelijk' geeft al aan in wat voor tijd we leven :)
Ik keek een hele tijd geleden in wat voor staat Cordova (en dat open-source alternatief dat iets soortgelijks deed, ben de naam even kwijt...) nou eigenlijk stond, en het valt vies tegen. De demo had een UI die geen enkele UI-standaard van Android aanhield (geen Holo, geen 'Gingerbread-stijl', geen Material), en door een listview scrollen ging al niet vloeiend op een Snapdragon 800.

Ik vraag me af of er apps zijn die echt bekend zijn geworden en met Cordova draaien, want het idee dat ik een complexe app van 7000+ regels moet opzetten met JavaScript, HTML en CSS in plaats van Java en kant-en-klare libraries van de meest bekende developers (o.a. Koush, Google zelf en een aantal commerciŽle bedrijven die open-source libraries aanbieden).
Cordova is het open-source alternatief, afgesplitst van PhoneGap.
Het grote voordeel blijft natuurlijk de gezamelijke codebase voor simpele apps. Ook zijn er veel plugins die i.i.g. voor iOS en Android goed geimplementeerd zijn (bijv. voor het tonen van Toasts, lokale en push Notificaties, etc.).

Het Ionic framework biedt daarbij weer een UI laag bovenop Cordova via Angular. En binnen Angular en Ionic wordt momenteel weer gewerkt aan een material laag:
https://material.angularj...al.components.bottomSheet

Maar ik ben met je eens dat vooral Android het erg moeilijk maakt tegenwoordig.

[Reactie gewijzigd door eborn op 28 januari 2015 16:55]

Ah, PhoneGap was die andere inderdaad :)

Ik zou het allemaal niet erg vinden als Google volwaardige support libraries aanleverde: geef me 1 library die door de beste programmeurs in elkaar is gedraaid, waarin echt alles van Material Design zit. Nee hoor, ik wil tabs, maar Material Design tabbladen zitten er niet in, dus kun je zelf een library zoeken die dat kan.

Simpele, doodnormale knoppen? Nope, ook die zitten niet in de support library. Die navigation drawer dan, geef me daar een manier voor zodat het lijkt op de manier die Google ook gebruikt in zijn eigen apps. Poor luck, de drawerlayout is gewoon een kale listview waarbij je zelf de layout mag regelen.

Zodra ik klaar ben met het ontwikkelen van mijn nieuwe app ga ik ook eens een tweakblog wijden aan mijn standaardset van libraries die al het hoognodige voor Material Design implementeren :)
In theorie is Spotify zo een applicatie die ontworpen is met html css en javascript. doormiddel van een opensource a la phonegap cordova etc

[Reactie gewijzigd door Vaniska op 28 januari 2015 15:48]

En in de praktijk?
Werkt het bijzonder matig, net als de Pebble app, er zijn overigens wel apps die het goed doen en ook geen 20 MB zijn, maar ze zijn net als fatsoenlijke Windows tools zeldzaam.
Browser/webview het IE van de 21e eeuw? Dat is tamelijk onzinnig. Waarschijnlijk baseer je dit op de berichtgeving dat Android de browser niet update voor oudere versies.

Als Android gebruiker, gebruik je Chrome. En die update wel.

Webviews moet je m.i. niet voor belangrijke zaken gebruiken.
Cordova/PhoneGap zijn gebouwd op een webview. Het feit dat Android inmiddels per Android versie bugs en andere onzin introduceert, kun je wat mij betreft vergelijken met het IE6 probleem. In iOS speelt dit misschien ook, maar daar worden gebruikers veel sneller richting de laatste iOS versie gepushed, waardoor het probleem minder groot is. Plus dat de webview in iOS sinds versie 6 eigenlijk gewoon snel en goed is. Ik heb er in ieder geval met testen nog geen grote problemen in gevonden. Android daarentegen weet in versie 4.1 de meest idiote dingen voor te schotelen die dan weer met specifieke CSS en/of Javascript fixes omzeild moeten worden.

Die problemen doen afbreuk aan het nut van tools als Cordova. Het alternatief, gebruik maken van een bundled webview, is m.i. in sommige gevallen een noodzakelijk kwaad.

Het niet updaten van de webview door Google speelt hierin overigens een grote rol. Ik snap hun keuze, maar ik snap niet waarom niemand daar bij Google eerder en beter over heeft nagedacht. Waarschijnlijk is dat zo'n geval van: "nu even snel in elkaar steken, eerst maar eens zien of dat Android echt iets wordt". Dat is een keuze. Een foute keuze is nu gebleken.

[Reactie gewijzigd door eborn op 28 januari 2015 17:15]

Ik gebruik geen Chrome, maar Opera. Die herschikt de tekst als je inzoomt zodat je niet hoeft te scrollen.
Onder Qt kon het naar mijn idee wel een stuk kleiner, maar dat wordt op Android waarschijnlijk niet gebruikt?
Qt-for-Android bestaat wel, Qt deed er ook best veel moeite voor, maar toen ik begon met Android development had het nog de UI van Android pre-Gingerbread. Daarnaast is de support ook veel lastiger, omdat je dan op StackOverflow e.d. veel minder mensen hebt die er over kunnen meepraten en er in het algemeen veel minder libraries beschikbaar zullen zijn.

Als je volgens Google's guidelines wilt werken, met Material Design, zit er niks anders op dan gewoon in Java te werken met een aantal libraries die elkaars tekortkomingen aanvullen. Maargoed, heel erg vind ik dat niet, mijn apps worden er hoogstens 4MB groter van, performance-wise merk je er niks meetbaars van en als ik aan een nieuwe app begin importeer ik altijd een bestand met daarin de libraries die ik altijd gebruik.
Je kan ook Polymer + Paper Elements + Cordova gebruiken. Material Design in HTML, CSS en Javascript icm toegang tot alle/belangrijkste API's van de platformen eronder (zoals camera ed).
Dit is nog best niet zo slecht.
Maar een app/game afleveren dat lijkt also het op een 286 nog vrij soepel zou kunnen draaien, qua graphics en interface dan. Dat deze app/game hapert op een Nexus 7 2013. Dat deze app de batterij in exact 68 min volledig leeg zuigt.
Dergelijke ontwikkelaars zouding zich moeten schamen.
Heaven-7 is een erg leuke demo binnen 64k geprogrammeerd. Voor mij is dat een voorbeeld dat het wel klein kan.
http://www.pouet.net/prod.php?which=5
Interessante uitleg. Bedankt.
2.5 mb is heel netjes.
Ik zie soms apps van 50 MB (en dat is klein), maar vaker rond de 100 MB.
En er zitten belachelijke uitschieters tussen die naar de 500 MB en zelfs meer gaan.

Nu zal daar veel grafisch tussen zitten, maar dan nog...
Nee, dat is veel te kort door de bocht. Softwareontwikkeling voor Android is echt niet zo erg als velen vroeger riepen, dat ieder toestel een andere layout had e.d., maar echt hinderlijk is dat niet. Het is alleen jammer dat Google zelf niet zorgt dat je met 1 library van hen altijd kunt programmeren voor de nieuwste UI guidelines. Met Material Design is dat gewoon doodzonde: het hele idee achter de layout is prima, en wanneer goed geÔmplementeerd ziet het er piekfijn uit. Maar ze geven allerlei richtlijnen, maar geen alomvattende library om op iedere versie van Android het te kunnen implementeren. Google trekt de kar voor Nexus-toestellen, iedereen die op een oudere versie zit kun je niet laten zitten als ontwikkelaar (anders loop je een enorm marktaandeel mis), waardoor je naar een boel hulpmiddelen grijpt om het toch bij iedereen te laten werken.

Maar ach, met ervaring en goed voorbereidend werk gaat het prima.
precies die gedachte had ik ook. Maar ook gewone software ontwikkelaars zijn een drama. Heb gister ff lopen vloeken toen ik een printer driver van HP moest downloaden. 142 MB hallo...... ik nog lang lopen zoeken of ik ergens de losse .inf kon vinden, maar nee... die lui die sporen niet dat is groter dan een gemiddeld OS van 15 jaar geleden, alleen om wat uit je printer te krijgen.....
Hp is dan ook koning om er allemaal bullshit bij te leveren. Allemaal utilities die linkjes plaatsen op je desktop en in je startmenu naar de winkel van HP, zaken als foto editors (ik wou gewoon printen..) en nog wat ongevraagde zooi... Owja, en de printer driver
Gemaakt door RSi -> Red Sector. Doet me gelijk denken aan die goede oude Amiga tijd:

https://www.youtube.com/watch?v=L_6dFgGHdNo

Meer Ontopic:
Maar dit laat wel even de kracht van assembly programmeren zien. Tegenwoordig is "programmeren" het aan elkaar linken van bestaande modules. Een programma wat 2 ingevoerde getallen bij elkaar op telt kost gelijk een paar MB, wat in assembly enkele 10-tallen bytes kan.
Maar een volledig schaakprogramma in 487 bytes. Pfff.. petje af....
Ik vermoed overigens als ik de code zo bekijk dat niet alle regels er in zitten (Rokade bv), maar toch... Het levert een speelbaar spel op.
De kracht/efficiŽntie van hand-geoptimaliseerde assembly weegt tegenwoordig (bijna) nooit meer op tegen de ontwikkelsnelheid en onderhoudbaarheid van talen met een hoger abstractieniveau.
Sterker nog, veelal werkt het tegen je want je hand-optimalisatie is bijna altijd gericht op 1 specifieke pc / cpu / gpu.
Terwijl een hoger abstractieniveau kan zeggen : O, het is cpu x dan pak ik optimalisatie x, oh het is cpu y dan pak ik optimalisatie y.

Alleen dan heb je het niet over simpele tech-demos (daar kan je wel meerdere hand-optimalisaties in invoeren) maar over reguliere projecten.
Uiteraard is een 100% hand-geoptimaliseerde assembly webserver met ingebakken specifieke scriptuitvoering tig keer sneller dan een apache / nginx + php / python + script, alleen je praat dan wel over een xxx manjaren kostend project waarbij je bij elke nieuwe cpu andere hand-optimalisaties mag toevoegen terwijl een apache enkel een recompile nodig heeft om gebruik te maken van de nieuwste foefjes.
Textfiles is ook een mooi archief waarin heel wat assembler stukjes zijn terug te vinden:
http://www.textfiles.com/programming/
Wij hadden die competitie allang gewonnen in jaren 90 met een nog korter programma in C code:
#include<stdio.h>
int main() {printf("I resign\n");return 0;}

Waarop misschien NOG een paar bytes vallen te winnen :)
Je include alweer zaken, dus het is meer dan die twee regels :P Daarnaast is een Hello World natuurlijk niet te vergelijken met een interactief schaakprogramma ;)
Het gaat niet om de broncode maar om de grootte van de resulterende binary.
Yes, maar als je met libraries gaat werken zal je binary toch zeker ook wel groter worden? ;)
Oh, dan schrijf ik een chess lib die ik reference en call. Dan krijg ik die 487 bytes echt wel klein.
Want een library is geen binary :?
8496 bytes!
gcc -Os -o resign resign.c
En dan linked hij ook nog met glibc :D.
Ik heb veel respect voor dit soort ontwikkelwerk. Ik kan bootchess.txt aanbevelen!

Toch vind ik het jammer dat deze 'schaaksoftware' niet alle regels implementeert, en bovendien sommige illegale zetten accepteert. Lijkt me interessant om te weten wat dan de kleinste volledige schaaksoftware is?

[Reactie gewijzigd door the_stickie op 28 januari 2015 15:42]

For the record, de recordhouder had regels zoals castling en promotion (sorry ben niet echt thuis in Nederlandse schaakterminologie) ook niet geÔmplementeerd :). Desalniettemin hadden ze nog 185 bytes over vergeleken met het oude record, het lijkt me dat er toch het een en ander mogelijk moet zijn om een vollediger programma te implementeren en toch nog onder het oude record te blijven.
Rokeren en promoveren, respectievelijk. De eerste is moeilijk omdat je 2 stukken tegelijjk beweegt, de tweede omdat je een pion vervangt door een (ander) stuk. Dat soort uitzonderingen zorgt nogal snel voor meer code.
In 1983 werd door David Horne 1K ZX Chess uitgebracht. Deze schaaksoftware gebruikte op een Sinclair ZX81-homecomputer 672 bytes aan werkgeheugen en was decennia lang de recordhouder als meest compacte schaaksoftware ooit geschreven
Hoewel er misschien nog wat bugs in zitten (als ik de comments zo eens doorlees via de bron) is dit toch wel een behoorlijk knap staaltje optimalisatie zeg. Onder een kb? Wanneer hebben we dat voor het laatst gezien? :P
In 1983 staat in het artikel.
Bedoel niet die specifieke applicatie maar over het algemeen. Hoeft dus niet perse een schaakapplicatie te zijn. Ik had dat inderdaad wat beter kunnen verwoorden.
In de demoscene ( http://nl.wikipedia.org/wiki/Demoscene ) werden vroeger ook altijd pareltjes gemaakt die zo klein mogelijk moesten zijn.
Wat ik me wel afvraag betreffende die demoscene.

Een hele tijd geleden heb ik zo ooit een FPS shooter voorbij zien komen die ook extreem klein was. Echter maakte ze wel gebruik van de standaard textures binnen DirectX. (edit: niet dus, mijn fout) Hoe zit het met die demoscene? Is dat daar ook toegelaten, gebruik maken van standaard zaken op een systeem of moeten ze volledig standalone zijn?

[Reactie gewijzigd door NightFox89 op 29 januari 2015 09:00]

Echter maakte ze wel gebruik van de standaard textures binnen DirectX
DirectX heeft helemaal geen "standaard textures".
Is dat daar ook toegelaten, gebruik maken van standaard zaken op een systeem of moeten ze volledig standalone zijn?
Bepaalde standaard API's zijn toegestaan. Uiteraard OS en stdlib calls, maar soms ook andere libraries. Maar je kunt dus niet gewoon een demo.dll meeleveren en dan in de executable simpelweg RunDemo() aanroepen ;)
Hmmz, ik meende echt dat ze die uit Direct X hadden geladen. Van de week eens zoeken of ik de shooter nog kan vinden, zal het destijds of verkeerd hebben gelezen dan of verkeerd hebben begrepen.
.kkrieger van Farbrausch (of eigenlijk een subdivisie genaamd .theprodukkt)? Die maakt gebruik van procedureel gegenereerde content, niet van standaard built-in content.

[Reactie gewijzigd door .oisyn op 28 januari 2015 17:06]

Klopt, de executable was erg klein maar je RAM werd vol gepropt met alle gegenereerde content nadat je het programma had gestart. Zag er trouwens er mooi uit.
( https://www.youtube.com/watch?v=2NBG-sKFaB0 )
Ah kijk, dat was het hem :) Inderdaad verkeerd onthouden :+)
dat is afhankelijk van welke competitie je mee doet in de demo scene.
niet iedere scene is het mogelijk om directx of opengl te gebruiken.
zeker niet directx als de competitie niet alleen werkt onder windows maar ook onder andere besturing systemen..

het is maar wat de eisen zijn van de competitie.
Is natuurlijk totaal geen vergelijk. Als je gebruik mag maken van allerlei externe componenten (zoals in jouw voorbeeld DirectX) is de uitdaging er direct uit. Dan is the Sky-the-limit, want zo'n beetje alles wat je nodig hebt voor wat dan ook is beschikbaar in een of andere library.

De uitdaging zou juist moeten zijn (zoals in dit geval ook) om zonder enige externe afhankelijkheiden (BIOS in dit geval) iets neer te zetten dat iets zinnigs doet.
Is natuurlijk totaal geen vergelijk. Als je gebruik mag maken van allerlei externe componenten (zoals in jouw voorbeeld DirectX) is de uitdaging er direct uit. Dan is the Sky-the-limit, want zo'n beetje alles wat je nodig hebt voor wat dan ook is beschikbaar in een of andere library.
Nou dat is ook weer onzin :). Er zijn zat 4k en 64k demo's die hele indrukwekkende audiovisuele dingen laten zien. Je vergeet even dat je niet alleen een API nodig hebt, maar ook content. En 3d content is over het algemeen redelijk geheugen-intensief, zeker textures.

[Reactie gewijzigd door .oisyn op 28 januari 2015 19:07]

Is natuurlijk totaal geen vergelijk. Als je gebruik mag maken van allerlei externe componenten (zoals in jouw voorbeeld DirectX) is de uitdaging er direct uit. Dan is the Sky-the-limit, want zo'n beetje alles wat je nodig hebt voor wat dan ook is beschikbaar in een of andere library.
De truc is dat nog steeds niet de sky the limit is, je moet alleen goed zijn in het verbergen van de mankementen.

Als je als voorbeeld neemt 69k (kkrieger) dan moet je dus in 69k alles beschrijven, wat je daarin kan beschrijven is nog steeds maar een erg beperkte subset met zichtbare mankementen, dan komt alleen de creativiteit om de hoek kijken, hoe kan je zonder de subset uit te breiden wel de mankementen maskeren en wat je in de subset hebt zitten maximaal gebruiken.
De uitdaging zou juist moeten zijn (zoals in dit geval ook) om zonder enige externe afhankelijkheiden (BIOS in dit geval) iets neer te zetten dat iets zinnigs doet.
Dan ga je automatisch over een heel ander segment praten, want een zinnig iets is er op hedendaagse hardware al niet snel meer te maken zonder externe afhankelijkheden.

Menig huidig hardware ding is juist gebouwd op basis van die externe afhankelijkheden en het zonder die externe afhankelijkheden aanspreken is al bijna niet meer mogelijk zonder dat je zelf die externe afhankelijkheid gaat moeten emuleren.
Menig windows videokaart driver kan alleen maar aangesproken worden via directx (of opengl) want dat is waar de fabrikanten zich op richten. Dan kan je directx ertussenuit schrijven, maar je calls naar de driver moeten nog steeds voldoen aan wat directx ook naar de driver zou schrijven.
.kriegerr ofzo was dat
Hoewel er misschien nog wat bugs in zitten (als ik de comments zo eens doorlees via de bron) is dit toch wel een behoorlijk knap staaltje optimalisatie zeg.
Als het niet goed hoeft te zijn is 'return 0' in assembly natuurlijk nog veel kleiner...
Wauw een schaak programma van maar 487 bytes, ik doe het ze niet na.

OfficiŽle download link: Site

[Reactie gewijzigd door basie op 28 januari 2015 15:19]

Thanks! Het spel downloaden ging ook snel.
Das ook niet erg raar he :+
het spel is waarschijnlijk iets mee dan 500 bytes
nee 13 minder
Ja dat weet ik, maar het kon zijn dat er nog iets bij in zit iets van handleiding of tekst.
recordhouder!

(13 bytes )
Das inderdaad een beetje dom van mij ja 8)7
Haha, no worries ;)
Kan je spelen tegen een AI? Of heb je 2 menselijke spelers nodig?
Je speelt tegen een AI inderdaad (anders is het geen schaakprogramma in de zin zoals het hier bedoeld wordt).
Ben je hier zeker van? Het is een wedstrijd om het zo klein mogelijk te houden zodat toch alles werkt. De spelregels van schaken zijn duidelijk te controleren of ze werken of niet. Maar bij AI heb je niet zoiets als een werkende AI of geen werkende AI. Ik neem aan dat een slechte AI minder code zal innemen. Dus even goed kan dit team gewonnen hebben door een slechtere AI te bouwen...
De vraag was of er AI aanwezig was (speel je dus tegen de computer?), niet hoe goed of slecht deze is.
AI is aanwezig, je speelt tegen de computer.

[Reactie gewijzigd door Scalibq op 28 januari 2015 15:58]

De demoscene is zeer interessant. De meest spectaculairste ' demo' die ik ooit heb gevonden is fr-041: debris. Dit 179kb bestand kan een vrij gedetailleerde en uitgebreide demo laten zien van meer dan vijf minuten! Ongelooflijk hoe ze dit voor elkaar krijgen.

Wikipedia heeft een vrij uitgebreid stuk geschreven over de demoscene.

[Reactie gewijzigd door ObAt op 28 januari 2015 15:21]

Er mist alleen nog wel van alles aan het programma. Ik heb er even naar gekeken, en het leek erop dat een koning zetten kon doen waarmee hij mat zou staan. Daarnaast ging rokeren ook niet, en ik betwijfel of promotie van stukken er dan wel in zit...

Leuk dat het kan, maar het simuleert meer een schaakbord en de valide zetten (de opties van de koning niet meegerekend), de AI is waarschijnlijk ook niet al te best.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True