abonnement Unibet Coolblue Bitvavo
pi_87133711
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
pi_87134377
quote:
Op zondag 3 oktober 2010 15:24 schreef Diabox het volgende:
Leuk weetje.
[..]


:')

Komt ie daar weer mee.
Of toch du vader?
  zondag 3 oktober 2010 @ 15:57:08 #28
189216 netolk
maar dan andersom
pi_87134715
quote:
Op zondag 3 oktober 2010 15:46 schreef Luchtkoker het volgende:

[..]

:')

Komt ie daar weer mee.
Het is toch een leuk weetje ??
Beware of the Raping Zebra's
pi_87134793
quote:
Op zondag 3 oktober 2010 15:57 schreef netolk het volgende:

[..]

Het is toch een leuk weetje ??
Ja, hij wordt na een aantal honderd keer zien alleen een beetje saai. Hé, Diabox? :(
Of toch du vader?
pi_87135352
quote:
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? :(
homo :(
pi_87135605
quote:
Op zondag 3 oktober 2010 16:17 schreef Diabox het volgende:

[..]

homo :(
Gereport :(
Of toch du vader?
pi_87136757
quote:
Op zondag 3 oktober 2010 15:24 schreef Diabox het volgende:
Leuk weetje.
[..]
Wat heb ik medelijden met die programmeurs...
Finally, someone let me out of my cage
pi_87137515
quote:
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).
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 :P)
Finally, someone let me out of my cage
pi_87137768
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 :P)
Ja, DLLs dus (dynamic linked libraries), Object files, etc.
Of toch du vader?
pi_87137898
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 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. :P
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 :P)
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.
pi_87158693
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 :P)
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.
pi_87158790
quote:
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).
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 je :D

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
pi_87158811
quote:
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?
Voor elke proc alles dubbel schrijven en/of een doolhof aan #ifdef :D
pi_87161711
ah bedankt voor de reacties ^O^
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
pi_87168238
quote:
Op maandag 4 oktober 2010 10:47 schreef minibeer het volgende:
ah bedankt voor de reacties ^O^
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?
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. ;) 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. :)
pi_87176991
quote:
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. ;) 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 het :Y.
Ik dacht dat asm zo erg verschilde dat je zo ongeveer per computer echt sowieso opnieuw moest compileren, maar dat valt dus wel mee :s) .
Finally, someone let me out of my cage
pi_87177078
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?
  maandag 4 oktober 2010 @ 21:27:12 #43
189216 netolk
maar dan andersom
pi_87185488
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. :)
Gelukkig wel zeg anders zou het wel heel rot programmeren zijn...
Beware of the Raping Zebra's
pi_87197527
quote:
Op maandag 4 oktober 2010 18:09 schreef minibeer het volgende:

[..]

Ok, nu begrijp ik het :Y.
Ik dacht dat asm zo erg verschilde dat je zo ongeveer per computer echt sowieso opnieuw moest compileren, maar dat valt dus wel mee :s) .
Ja, dat zou ook wel raar zijn want gecompileerd c(++) is even portable als gecompileerd ASM.
  woensdag 6 oktober 2010 @ 17:25:20 #45
189216 netolk
maar dan andersom
pi_87252889
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.
Komt het niet (ongeveer) op het zelfde neer?
Beware of the Raping Zebra's
pi_87267929
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
pi_87268213
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 :D
pi_87268455
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. :) Als je dan echt iets tofs maakt kan je het altijd nog op de Xbox zetten :D
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.
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
pi_87269366
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.
pi_87269546
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.
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.
Maargoed, genoeg microsoftbashen voor vandaag. weltrusten :s)
Finally, someone let me out of my cage
abonnement Unibet Coolblue Bitvavo
Forum Opties
Forumhop:
Hop naar:
(afkorting, bv 'KLB')