DIG Digital Corner
Alles wat je altijd al over computers, hardware, software, internet en elektronische gadgets had willen weten, maar niet op Tweakers.net durft te vragen.
Leuk weetje.
quote:What language was RollerCoaster Tycoon programmed in?
It's 99% written in x86 assembler/machine code (yes, really!), with a small amount of C code used to interface to MS Windows and DirectX.
http://www.chrissawyergames.com/faq3.htm
Ja, hij wordt na een aantal honderd keer zien alleen een beetje saai. Hé, Diabox?quote:
Of toch du vader?
homoquote:Op zondag 3 oktober 2010 15:59 schreef Luchtkoker het volgende:
[..]
Ja, hij wordt na een aantal honderd keer zien alleen een beetje saai. Hé, Diabox?
ah... ik dacht dat c en c++ ook wel gebruikt werden om programma's op zichzelf mee te schrijven, maar ik bedenk net dat het een enorm gekloot is om in c++ een simpel window te openen. eigenlijk alle programma's die ik schrijf zijn gewoon in 1 programmeertaal... Hoe doet men dat dan, verschillende programmeertalen 'door elkaar' gebruiken? Libraries met methodes/functies erin ofzo? (dat is de manier waarop ik dat weleens heb gedaan met qbasic en assembleertaalquote:Op zondag 3 oktober 2010 15:01 schreef thabit het volgende:
[..]
Je moet de stukken die je in assembler wilt schrijven, ook in C schrijven, zodat het in elk geval voor elke processor compileert.
Je moet er een beetje een hiërarchie in zien. Alles in C(++) schrijven is ook onbegonnen werk, moet je alleen doen bij die stukken code die snel en geheugen-efficiënt dienen te zijn. Daarbovenop zet je een hogere programmeertaal (eentje met een fatsoenlijke syntax en garbage collecting). Binnen je C(++) kun je de meest kritieke stukken nog in inline-assembler schrijven, alleen zit je dan wel veel met #ifdef en zo te kloten. Zelfs tussen linux en windows is assembler niet hetzelfde (M$ doet er alles aan om dingen maar niet portable te maken, zelfs de syntax voor x86-assemblercode is anders).
)
Finally, someone let me out of my cage
Ja, DLLs dus (dynamic linked libraries), Object files, etc.quote:Op zondag 3 oktober 2010 17:22 schreef minibeer het volgende:
[..]
ah... ik dacht dat c en c++ ook wel gebruikt werden om programma's op zichzelf mee te schrijven, maar ik bedenk net dat het een enorm gekloot is om in c++ een simpel window te openen. eigenlijk alle programma's die ik schrijf zijn gewoon in 1 programmeertaal... Hoe doet men dat dan, verschillende programmeertalen 'door elkaar' gebruiken? Libraries met methodes/functies erin ofzo? (dat is de manier waarop ik dat weleens heb gedaan met qbasic en assembleertaal
Of toch du vader?
Dat wordt inderdaad gedaan, maar je geeft zelf al aan waarom dat niet handig is. Veel mensen blijven toch in oude patronen vastgeroest zitten: 20 jaar geleden deed men het zo, dus doen we het nu nog steeds zo.quote:Op zondag 3 oktober 2010 17:22 schreef minibeer het volgende:
[..]
ah... ik dacht dat c en c++ ook wel gebruikt werden om programma's op zichzelf mee te schrijven, maar ik bedenk net dat het een enorm gekloot is om in c++ een simpel window te openen.
Dat kan inderdaad met libraries. Vaak moet je dan wel bovenop je C-code nog een speciale interface schrijven waarmee je dan vanuit de hogere programmeertaal de C-code kan aanroepen.quote:eigenlijk alle programma's die ik schrijf zijn gewoon in 1 programmeertaal... Hoe doet men dat dan, verschillende programmeertalen 'door elkaar' gebruiken? Libraries met methodes/functies erin ofzo? (dat is de manier waarop ik dat weleens heb gedaan met qbasic en assembleertaal
Gebruik maken van libraries, die dus in elke taal kunnen zijn geschreven. Ikzelf schrijf alles in C++, en ik heb gewoon zelf een simpele wrapper lib geschreven voor het maken van vensters e.d. en die gebruikt op zijn beurt weer de standaard functies uit de windows headers. CreateWindowEx() etc.quote:Op zondag 3 oktober 2010 17:22 schreef minibeer het volgende:
[..]
ah... ik dacht dat c en c++ ook wel gebruikt werden om programma's op zichzelf mee te schrijven, maar ik bedenk net dat het een enorm gekloot is om in c++ een simpel window te openen. eigenlijk alle programma's die ik schrijf zijn gewoon in 1 programmeertaal... Hoe doet men dat dan, verschillende programmeertalen 'door elkaar' gebruiken? Libraries met methodes/functies erin ofzo? (dat is de manier waarop ik dat weleens heb gedaan met qbasic en assembleertaal
Meestal schrijf je "snelle" code in C(++) waar je gewoon goed nadenkt over je geheugen-access, branches, cache misses etc. Echt ASM programmeren is eigenlijk niet nodig op huidige PC/Console hardware, en als het al nodig is, dan is het voor je gedaan door de vendor en in een leuke lib gezet voor jequote:Op zondag 3 oktober 2010 15:01 schreef thabit het volgende:
[..]
Je moet de stukken die je in assembler wilt schrijven, ook in C schrijven, zodat het in elk geval voor elke processor compileert.
Je moet er een beetje een hiërarchie in zien. Alles in C(++) schrijven is ook onbegonnen werk, moet je alleen doen bij die stukken code die snel en geheugen-efficiënt dienen te zijn. Daarbovenop zet je een hogere programmeertaal (eentje met een fatsoenlijke syntax en garbage collecting). Binnen je C(++) kun je de meest kritieke stukken nog in inline-assembler schrijven, alleen zit je dan wel veel met #ifdef en zo te kloten. Zelfs tussen linux en windows is assembler niet hetzelfde (M$ doet er alles aan om dingen maar niet portable te maken, zelfs de syntax voor x86-assemblercode is anders).
Wat je tegenwoordig vaak ziet zijn intrinsics, dit zijn een soort super-basic functies die in je compiler zijn ingebakken en direct naar ASM worden omgezet voor verschillende procs:
http://msdn.microsoft.com/en-us/library/5704bbxw.aspx?ppud=4
Voor elke proc alles dubbel schrijven en/of een doolhof aan #ifdefquote:Op zondag 3 oktober 2010 14:51 schreef minibeer het volgende:
[..]
Ok. Zelf code in assembleertaal schrijven is dus eigenlijk onbegonnen werk, als je wil dat je programmatje compatibel is naar andere processoren?
ah bedankt voor de reacties 
maar hoe kan het dan dat rollercoaster tycoon het op verschillende processors doet (tenminste ik neem aan dat ie dat doet), terwijl het voor 99% in asm is geschreven?
maar hoe kan het dan dat rollercoaster tycoon het op verschillende processors doet (tenminste ik neem aan dat ie dat doet), terwijl het voor 99% in asm is geschreven?
Finally, someone let me out of my cage
De originele RCT doet het dan ook alleen op compatible 8086 processoren, denk ik. Maar dat was toentertijd ook de standaard, dat had iedereen thuis staan. Die basisset wordt tegenwoordig door elke CPU ondersteunt.quote:Op maandag 4 oktober 2010 10:47 schreef minibeer het volgende:
ah bedankt voor de reacties
maar hoe kan het dan dat rollercoaster tycoon het op verschillende processors doet (tenminste ik neem aan dat ie dat doet), terwijl het voor 99% in asm is geschreven?
Vergeet niet dat Intel en AMD misschien wel verschillende CPUs maken, maar ze ondersteunen allemaal (nagenoeg) precies dezelfde instructieset.
Pas als je echt naar andere architecturen gaat kijken, zoals embedded systemen, rare mainframes of Macs met PowerPCs krijg je problemen.Er zijn (nu nog?) kleine verschillen in de instruciesets tussen AMD en Intel, maar die instructies worden standaard niet gebruikt door je C++ compiler en als je ASM zit te klooien laatje die ook gewoon links liggen tenzij je echt hele specifieke redenen hebt.
Ik weet niet of je het hebt meegemaakt, maar toen de MMX processoren op de markt kwamen waren er spellen die alleen draaide op processoren die MMX instructies ondersteunden, zelfde met 3DNow instrucies en nog wat van die uitbreidingen.
Zelfs nu kan je bij het compileren van je programma in Visual Studio aangeven dat hij "modernere" instructies mag gebruiken, en dan werken je programma's dus niet op oudere PCs, bijv. niet op oude AMDs maar wel op oude intel CPUs. Laatst nog mee lopen klooien, en je kan er best wel wat procenten uitpersen.
Ok, nu begrijp ik hetquote:Op maandag 4 oktober 2010 14:07 schreef Cruise.Elroy het volgende:
[..]
De originele RCT doet het dan ook alleen op compatible 8086 processoren, denk ik. Maar dat was toentertijd ook de standaard, dat had iedereen thuis staan. Die basisset wordt tegenwoordig door elke CPU ondersteunt.
Vergeet niet dat Intel en AMD misschien wel verschillende CPUs maken, maar ze ondersteunen allemaal (nagenoeg) precies dezelfde instructieset.
Er zijn (nu nog?) kleine verschillen in de instruciesets tussen AMD en Intel, maar die instructies worden standaard niet gebruikt door je C++ compiler en als je ASM zit te klooien laatje die ook gewoon links liggen tenzij je echt hele specifieke redenen hebt.
Ik weet niet of je het hebt meegemaakt, maar toen de MMX processoren op de markt kwamen waren er spellen die alleen draaide op processoren die MMX instructies ondersteunden, zelfde met 3DNow instrucies en nog wat van die uitbreidingen.
Zelfs nu kan je bij het compileren van je programma in Visual Studio aangeven dat hij "modernere" instructies mag gebruiken, en dan werken je programma's dus niet op oudere PCs, bijv. niet op oude AMDs maar wel op oude intel CPUs. Laatst nog mee lopen klooien, en je kan er best wel wat procenten uitpersen.
.Ik dacht dat asm zo erg verschilde dat je zo ongeveer per computer echt sowieso opnieuw moest compileren, maar dat valt dus wel mee
.
Finally, someone let me out of my cage
Nee, er zit een verschil tussen een andere processor en een andere architectuur. Niet elke processor heeft een andere architectuur; er zijn vele malen meer processoren dan architecturen, bovendien is het (met name hedendaags) veelal gestandaardiseerd zoals Cruise.Elroy zegt, om cross-processor compatibility te maximaliseren.
Of toch du vader?
Gelukkig wel zeg anders zou het wel heel rot programmeren zijn...quote:Op maandag 4 oktober 2010 18:12 schreef Luchtkoker het volgende:
Nee, er zit een verschil tussen een andere processor en een andere architectuur. Niet elke processor heeft een andere architectuur; er zijn vele malen meer processoren dan architecturen, bovendien is het (met name hedendaags) veelal gestandaardiseerd zoals Cruise.Elroy zegt, om cross-processor compatibility te maximaliseren.
Beware of the Raping Zebra's
Ja, dat zou ook wel raar zijn want gecompileerd c(++) is even portable als gecompileerd ASM.quote:Op maandag 4 oktober 2010 18:09 schreef minibeer het volgende:
[..]
Ok, nu begrijp ik het
Ik dacht dat asm zo erg verschilde dat je zo ongeveer per computer echt sowieso opnieuw moest compileren, maar dat valt dus wel mee
Komt het niet (ongeveer) op het zelfde neer?quote:Op dinsdag 5 oktober 2010 08:32 schreef Cruise.Elroy het volgende:
[..]
Ja, dat zou ook wel raar zijn want gecompileerd c(++) is even portable als gecompileerd ASM.
Beware of the Raping Zebra's
ik hoorde dat je via de XNA-library dingen voor de xbox kon maken, dus daar heb ik eens wat over opgezocht. Blijkt dat je bij microsoft een abo moet afsluiten voor minstens 4 maanden bij de XNA Creators Club voor 50 dollar... Terwijl het enige wat je wil doen gewoon een paar bestandjes op je eigen xbox zetten
Finally, someone let me out of my cage
Met XNA kan je nog steeds gewoon leuke apps maken voor op de PC. Als je dan echt iets tofs maakt kan je het altijd nog op de Xbox zetten
Als je dan echt iets tofs maakt kan je het altijd nog op de Xbox zetten
Ja daswaar. Maar ik blijf het raar vinden, eerst een fakking dure xbox 360 kopen, dan ook nog veel geld moeten betalen om er iets op te zetten wat je zelf hebt geschreven. Ik vind 50 euro ook belachelijk veel te duur voor wat je ervoor terugkrijgt.quote:Op woensdag 6 oktober 2010 23:20 schreef Cruise.Elroy het volgende:
Met XNA kan je nog steeds gewoon leuke apps maken voor op de PC.
pff, ik vraag me af of er geen andere manier is om je xna dingetje aan de gang te krijgen op zo'n ding...
[ Bericht 6% gewijzigd door minibeer op 06-10-2010 23:38:18 ]
Finally, someone let me out of my cage
Euhm die XBOX koop je als spelsysteem, niet als devkit.
Er zijn andere manieren ja, maar 50 euro is een koopje vergeleken met het gedoe om het op andere manieren aan de praat te krijgen.
Er zijn andere manieren ja, maar 50 euro is een koopje vergeleken met het gedoe om het op andere manieren aan de praat te krijgen.
ja maar maakt niet uit toch, je betaalt ervoor, dan lijkt het me logisch dat je er dingen op mag zetten, net zoals bij een computer bijvoorbeeld. En als het nou iets eenmaligs was, of dat je er iets fysieks voor terugkrijgt, maar nee. Het is gewoon dat microsoft geld wil hebben, je betaalt verder niet omdat het hun geld kost ofzo. Voor kleine gamebedrijven is 50 euro goed te doen, maarja ik ben student en ik weet niet eens of ik er vaker dan 1 keer iets op wil zetten.quote:Op woensdag 6 oktober 2010 23:54 schreef Cruise.Elroy het volgende:
Euhm die XBOX koop je als spelsysteem, niet als devkit.
Er zijn andere manieren ja, maar 50 euro is een koopje vergeleken met het gedoe om het op andere manieren aan de praat te krijgen.
Maargoed, genoeg microsoftbashen voor vandaag. weltrusten
Finally, someone let me out of my cage
