Archief - Even snel op alle computers? (c++)

Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.

Krueger

Legacy Member
Kben wat bezig met in direct3d te prutsen met c++. Dat lukt redelijk tot nu toe, maar nu zit ik met het probleem dat de snelheid waarmee alles beweegt afhangt van de computer snelheid. Hoe kan je ervoor zorgen dat alles evensnel gaat op gelijk welke computer, dus onafhankelijk van uw fps?

.bal

Legacy Member
Recentelijk had ik hetzelfde probleem. De oplossing is time-based movement waarbij je aan de hand van een formule rendert. Maar veel verder dan de (in mijn geval niet-werkende) gamedev.net voorbeelden/artikels ben ik ook nog niet gekomen... Een deftig en werkend antwoord op deze vraag zou zeer welkom zijn :).

Krueger

Legacy Member
Grayfox zei:
in 4D werken dus ipv 3D :)
Dat ik daar nog niet had aangedacht :wtf:
Kheb ook al wat zitten rondkijken in een directX vb, en daarin wordt het commando Sleep(100) gebruikt, maar dit geeft toch een verre van optimaal resultaat en ik twijfel of dit wel een goede oplossing is. Kdenk dat ik eens ga kijken in de directX demo's die met de SDK worden meegegeven...

Litheon

Legacy Member
Zoals .bal zegt; time-based movement;

je kan ook proberen je FPS vast te leggen op een bepaalde waarde, maar ik denk dat dit meer gesukkel zal te weeg brengen dan dat dit fatsoenlijk zou werken (dus op een tragere pc zal het toch nog altijd trager gaan dan normaal; logisch; met time-based niet)

gewoon op gametutorials.com (bv. OpenGL tutorials en dan FPS tut. en/of time-based mov.) en gamedev.net kan men daarover genoeg informatie over vinden

RipTor

Legacy Member
Idd timebased movement...
Iedere keer dat ge uwe functie aanroept die het scherm update checken hoeveel tijd er verstreken is sinds de vorige aanroep van die functie en aan de hand daarvan (en de snelheid in pixels/sec van uw objecten) de nieuwe posities berekenen....

Is eigenlijk basiskennis voor ne 2D engine met Sprites hé :-)

killgore

Legacy Member
Nu laat jij je beweging e.d. afhangen van uw refreshrate.

Je moet gewoon via timebased (in windows dus via GetTickCount) functies je beweging limiteren, bv. vooruitgaan mag maar 10 units per seconde zijn of zo :).
Je refreshrate laat je best op non-timebased staan :).

Krueger

Legacy Member
killgore zei:
Nu laat jij je beweging e.d. afhangen van uw refreshrate.

Je moet gewoon via timebased (in windows dus via GetTickCount) functies je beweging limiteren, bv. vooruitgaan mag maar 10 units per seconde zijn of zo :).
Je refreshrate laat je best op non-timebased staan :).
Hangt het niet eerder af van uw framerate dan van uw refreshrate?
Maar kheb er nu al een aantal artikels over gelezen en het werkt toch aardig momenteel.

Is eigenlijk basiskennis voor ne 2D engine met Sprites hé :-)
Mjah, kheb nog nooit met sprites gewerkt, kben direct met Direct3D begonnen :)

RipTor

Legacy Member
Krueger zei:
Mjah, kheb nog nooit met sprites gewerkt, kben direct met Direct3D begonnen :)
Mjah... Eigenlijk moet ge eerst 2D goed onder de knie hebben voor ge tegoei aan 3D kunt beginnen (kijk maar naar John Carmack... Die is ook begonnen met 2D (uitvinden van 2D side-scrolling op pc trouwens (en parallax scrolling ook)) en nu maakt diene vrij goede 3D engines :).

Voor de ouderen is da geen probleem want die moesten wel met 2D beginnen maar als ge nu begint is de verleiding groot om 3D te beginnen (maar da is dus een slechte keuze).

killgore

Legacy Member
Krueger zei:
Hangt het niet eerder af van uw framerate dan van uw refreshrate?
Maar kheb er nu al een aantal artikels over gelezen en het werkt toch aardig momenteel.
refreshrate=hz=screen
framerate = hoeveel frames uw wonder engine per seconde kan berekenen.

Ik vind ook dat reeds enige 2D ervaring je zeker en vast helpt in de 3D.

Krueger

Legacy Member
killgore zei:
refreshrate=hz=screen
framerate = hoeveel frames uw wonder engine per seconde kan berekenen.

Ik vind ook dat reeds enige 2D ervaring je zeker en vast helpt in de 3D.
Dat eerste wist ik ook wel, wat wil je er juist mee zeggen? Het is toch niet omdat niet alle beelden op uw scherm gaan getekend worden, doordat uw refresh rate lager is, dat dit de snelheid gaat verminderen? Het aantal instructies die worden uitgevoerd zijn toch onafhankelijk van de refresh rate, dus zal dit er toch geen invloed op hebben?

Ergens hebde natuurlijk wel gelijk dat het beter is om te beginnen met 2D, en dan over te stappen naar 3D.
Vorige zomer ben ikl direct begonnen met direct3D (ik kende wel al wat C++), en na een goeie 2 maand had ik toch al iets kunnen programmeren. Kwas begonnen aan een 3D rts. Khad al code voor mijn camera, die kon je bewegen in alle richtingen (links-rechts, boven-onder, inzoomen-uitzoomen, en hem platleggen) Ook kon je al tankskes bewegen adhv de muis, en gebouwen neerzetten. Maar aangezien ik tegelijkertijd moddeler, texture maker en coder was, is het nooit echt afgeraakt :) Daarmee dat ik nu van plan ben iets simpelder te maken :)
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
Terug
Bovenaan