Hänga Gubbe C++ SDL

Funkar i Vista 32 utan problem. En vanlig applikation kan inte orsaka blåskärmar då endast kernelkod kan trigga en BSOD. Om man får det så beror det snarare på dåliga drivrutiner.

Har gjort ett Hangmanspel jag med, fast inte lika snyggt med grafiken och skrivit i C#.

http://www.speedyshare.com/data/905974852/17740539/14299502/e...

Jag använde en ordlista från en textfil och läste in det till en array som jag sedan slumpade ett ord ur. Vilket var något krävande då den måste läsa in alla tusen ord...

Tips: öppna textfilen, välj slumpmässigt en position mellan 0 och filens längd, leta upp närmaste radbryt och läs av ordet. Kommer gå en hel del snabbare

Om man inte har den i XML- eller RSS-format eller liknande, får man crawla sidan - alltså låta sin applikation hämta ner sidan och läsa ut ett ord. Det går i Java, C#, C, JavaScript etc.

Jo har tänkt på att det skulle gå att göra så, men jag har inte fattat hur bara.

Skulle du kunna skriva lite snabbt koden för det? Lär ju inte vara mer än någon rad eller två

Titta till exempel på
"System.IO.StreamReader"
och dess egenskap
"BaseStream.Position"

Du lär dig mer på att lista ut det själv. Använd Visual Studio till att ta reda på vilka metoder som objekten har, börja med en StreamReader som Elgot föreslår. Om du fastnar, googlar du på "c# read text file", så får du fram bra träffar.

Skulle vara lite kul om någon gjorde ett hängagubbe med dator/teknikord och liknande endast, skulle kunna vara rätt skoj och skulle sticka ut från alla andra hänga gubben spel.

Om man söker på det viset kommer det ju vara större sannolikhet för längre ord (eller ord som kommer efter ett långt ord, beroende på hur man bygger det). Skulle bli lite bättre om man tog en slumpmässig position + ett slumpmässigt antal ord.

Även om man har filen i XML-format måste den ju fortfarande läsa in och parse:a hela filen (om man inte kör typ SAX eller nåt, men då måste man veta hur många ord man ska "stega förbi" och måste i genomsnitt ändå söka igenom halva filen).

Ett sätt att snabba upp sökningen skulle vara att dela upp filen i lika stora stycken som alla innehåller lika många ord. T.ex. dela upp den i stycken om 100 ord, och pad:a alla såna stycken med blanksteg/radbryt så de alla är 1000 bytes långa (eller vad som nu råkar vara storleken på det största stycket). Sen tar man filen, söker till en slumpmässig jämn multipel av 1000 (eventuellt med nån korrigering för att den sista klumpen kanske har färre ord), läser in hela det stycket (bara 1000 bytes / 100 ord, går fort), och väljer ett slumpmässigt ord däri.
Då har man i princip byggt en något förenklad indexerad databas.

Jag har iofs svårt att tro att det ska vara något problem att suga i sig hela filen rakt av. Jag har ett program som läser in en ordlista (en några utgåvor gammal SAOL) på 90000 ord/1MB, och det steget tar mindre än 1/10 sekund. Svårt att mäta exakt, men det verkar vara typ 4-6 hundradels sekunder.

Ju komplexare format man väljer desto mer behöver man förmodligen läsa för att kunna tolka det. Om man har en ren textfil kan man börja läsa var som helst.

Jag skulle säga tvärtom, med ett mer komplext format (t.ex. en fil med ett komplett index) kan man klara sig med ytterst få filaccesser (typ tre). Just i det här fallet vore det nog overkill, då det bara är nån megabyte data.

Om du jämför XML och textfil så är XML det mer komplexa formatet, och kräver långt många fler läsningar för att få ut en bit enkel data. Att generalisera och säga att det ena eller andra är bättre går inte, ett komplext dataformat kan vara optimerat för snabb inläsning, eller inte.

Jo men jag orkar nog personligen inte byta ut alla orden. Om det nu inte finns någon färdig lista av det slaget men det tror jag inte.

sist jag spelade hangman var på min vic 20!