Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

Game logic

Name: Anonymous 2010-05-16 5:18

How the fuck do they code games so that everything moves smoothly and at a consistent rate regardless of the speed of the machine you run it on, and still have tons of shit interacting with each other somehow?
Maybe I need to find a good open-source candidate to have a look at.

Also, I wish I knew the correct terms to describe what I'm talking about.

Name: Anonymous 2010-05-19 1:45

>>39
QueryPerformanceCounter is probably your best bet. No method is perfect though. rdtsc is a terrible idea that won't work at all: modern CPUs have variable clocks, and on top of that each core might have its own desynchronized counter. A lot of rdtsc-based stuff (mostly games) broke in recent years because of this.

Now, this is something that no soul should ever have to see, but behold: https://hg.mozilla.org/mozilla-central/file/f8a47845a0b8/js/src/prmjtime.cpp

Please see bug 363258 for why the win32 timing code is so complex.
 
     calibration mutex : Win32CriticalSection(spincount=0)
     data mutex : Win32CriticalSection(spincount=4096)
    
     def NowInit():
       init mutexes
       PRMJ_NowCalibration()
    
     def NowCalibration():
       expensive up-to-15ms call
    
     def PRMJ_Now():
       returnedTime = 0
       needCalibration = False
       cachedOffset = 0.0
       calibrated = False
       PR_CallOnce(PRMJ_NowInit)
       do
         if not global.calibrated or needCalibration:
           acquire calibration mutex
             acquire data mutex
    
               // Only recalibrate if someone didn't already
               if cachedOffset == calibration.offset:
                 // Have all waiting threads immediately wait
                 set data mutex spin count = 0
                 PRMJ_NowCalibrate()
                 calibrated = 1
    
                 set data mutex spin count = default
             release data mutex
           release calibration mutex
    
         calculate lowres time
    
         if highres timer available:
           acquire data mutex
             calculate highres time
             cachedOffset = calibration.offset
             highres time = calibration.last = max(highres time, calibration.last)
           release data mutex
    
           get kernel tick interval
    
           if abs(highres - lowres) < kernel tick:
             returnedTime = highres time
             needCalibration = False
           else:
             if calibrated:
               returnedTime = lowres
               needCalibration = False
             else:
               needCalibration = True
         else:
           returnedTime = lowres
       while needCalibration
    

Name: Anonymous 2010-05-19 5:51

>>41
Well, that is complicated and hideous.  I'll just stick with QueryPerformanceCounter for now I guess. I hear it has a few problems, such as "If there's heavy bus traffic, on many, common chip sets, [...] this timer may suddenly jump between one and four seconds forward in time" but it is probably the least shitty solution for now.

And now that I know "Game Speed dependent on Variable FPS" is the correct solution I can work on my little test game to help me get all this sorted out.  Thanks again!

Name: Anonymous 2010-05-19 5:56

>>42
Already found something to help with the random jumps:
http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q274323&;
Programs should watch for an unexpected jump by comparing the change in time as determined by successive calls to QueryPerformanceCounter  with the change in time as determined by successive calls to the GetTickCount  function. If there is a significant jump that is based on QueryPerformanceCounter(), but no similar increase that is based on GetTickCount, then it can be assumed that the performance counter just jumped forward. The code sample at the end of this article demonstrates how to do this.


So I can use GTC to make sure that QPC is in check, which is also simpler than having 3 separate kinds of timers to all have a vote (which is an idea I found on gamedev.net)

Name: Anonymous 2010-05-19 10:14

>>43
Here's a 77-line solution to this large problem we don't want to fix.
-- microsoft.com support

Name: Anonymous 2010-05-20 1:54

programmeur expert

Name: Anonymous 2010-05-20 2:30

>>46
I saw it on /f/, its was really hard.

Name: Anonymous 2010-05-20 18:52

What the hell happened to this thread?

Name: Anonymous 2010-05-20 20:02

>>50
(Some of) the spam was deleted.

Name: Anonymous 2010-05-20 21:39

>>51
Along with half of /prog/'s legitimate posters.

Name: Anonymous 2010-05-20 22:30

>>52
/prog/ has no legitimate posters. But some are more illegitimater than others.

Name: Anonymous 2010-05-20 22:35

>>52
3 posts were destroyed. They probably referred to one of two spam URLs. Was anything legitimate actually destroyed?

Name: Anonymous 2010-05-20 22:52

>>54
I scraped two of them before they got deleted, and they were both linkspam, so probably not. A lot of innocent people seem to have been banned, though:

http://twitter.com/progsnake/status/14389226548
http://twitter.com/Cairnarvon/status/14391272965

A bunch of people are complaining in the IRC channels too. It's all MrVacBob-tan's fault:

http://twitter.com/mrvacbob/status/14389759557

Name: Anonymous 2010-05-20 23:04

>>55
And he still hasn't fixed it

Name: Anonymous 2010-05-20 23:34

Name: Anonymous 2010-05-21 0:47

>>55
Anyone that would post about /prog/ on Twitter has no legitimate cause for being here. Case dismissed, move along.

Name: Anonymous 2010-05-21 1:18

>>55
Oh dear. This is the best example of "two problems" I've seen yet.

Name: Anonymous 2010-05-21 1:23

>>58
Twitter is just a very slow IRC with a saner protocol. And /prog/ without Xarn is no /prog/ at all.

Name: Anonymous 2010-05-21 1:48

>>60
How is it saner? IRC is more compact, more flexible, more secure, easier to scale, considerably more featureful and so on. The only thing twitter has on IRC is being http-based, and that can be interpreted as both good and bad.

Name: Anonymous 2010-05-21 1:50

>>61
Freenode tried to bridge the gap to being HTTP based by not rejecting HTTP connections.

Name: Anonymous 2010-05-21 1:58

>>62
I've seen some really nice IRCDs which when greeted with a HTTP request kindly issue a temporary kline to the user doing the request.

Name: Anonymous 2010-05-21 2:02

>>61
more compact, more flexible, more secure, easier to scale
I don't think you've ever actually looked at the IRC protocol.

Name: Anonymous 2010-05-21 2:05

>>64
I've read the IRC RFC's and various server-specific extensions.

Twitter is most certainly not a suitable IRC.

Name: Anonymous 2010-05-21 2:09

>>65
That's a different question altogether. Stop dodging the issue.

Name: Anonymous 2010-05-21 4:18

>>58
What's wrong with Twitter? It's just a slightly more verbose picoup (pre-fuckup).

Name: Anonymous 2010-05-21 4:25

Shitdang, looks like the framerate will need to be capped somewhere to avoid using 100% CPU.  That's ok though, just need to find a good method of doing that which hopefully keeps the framerate steadier than it is right now.

Name: Anonymous 2010-05-21 4:41

>>13,33
Does this not succumb to rounding error at some point or other? Or do periodic server corrections account for this? Seems like this would only be good for FPS games, where RTS games for instance have way more entities that can't constantly be corrected so a fixed tickrate would be better.

Name: Anonymous 2010-05-21 4:54

>>68
Have you tried using any of the methods described in this thread?

Name: Anonymous 2010-05-21 4:56

>>68
Looks like this is fucking impossible under Windows :|  Guess I'll check how other games/engines go about it

Name: Anonymous 2010-05-21 5:08

>>70
Of capping the framerate? I was mostly reading about the proper way of handling the game loop, which involved not capping anything. In any case, I think I've got it.

Name: Anonymous 2010-05-21 5:45

>>71
Sleep(...)

Name: Anonymous 2010-05-21 6:17

>>73
Yeah, I somehow got the idea into my head that Sleep()'s resolution was not enough.  Then when I was looking for a solution I realized that it would be fine.

Name: Anonymous 2010-05-21 12:43

>>74
sceDisplayWaitVblankStart; VBlankIntrWait

Name: Anonymous 2010-05-22 18:44

>>69
Any answer?

Name: Anonymous 2010-05-22 20:29

>>13
Pretty terrible, I remember moving the camera away to barren zones to make the game progress faster on occasions. No wonder EA bought them, they're made for each other.

I LOVE YOU! I LOVE YOUR POST! I READ IT 5 TIMES! KEEP POSTING!

Name: Anonymous 2010-05-22 21:46

>>76
Try it, let us know. I'm pretty sure you're overestimating the resolution capacity of the human mind.

Name: Anonymous 2010-05-25 8:59

Name: Anonymous 2010-05-30 18:08

"Anus" is a colloquial term for the codan receptacle, an orifice which is necessary for proper development of programmer ability. The anus is very sensitive to suboptimal conditions, meaning you must be careful to take proper care of it to prevent sudden data corruption, or the destruction of the anus altogether. This procedure requires the treatment fluid described in the attached attached document, form hatch sign 42016.† If you are not able to procure sufficient quantities of the ingredients necessary, please unintelligible a supervisor.

To assemble a codan, we generally use the sharp jagged edge of a bottle broken off at the neck coated in several layers of pages from SICP. This gives the codan structural integrity while also allowing it to absorb a surplus of embalming fluid for use in the procedure. Diagram 14 will indicate appropriate settings on the fellatio burner for applying this type of coating

Since even the smallest amount of contamination can result in the codan sparking, spitting, or pulling out, you'll want to wear your safety goggles at all times. Naturally you should do this anyway, but a disappointingly sizeable minority of people feel like they don't have to adhere to the safety protocols that every one of you signed on your first day here. Keep in mind that the deceptive statistical unlikelihood of a life-threatening accident is just that--deceptive. The original formulation of Murphy's Law should be in chapter 2 of your field manuals, and you're expected to memorize it.

After completing all other pre-anusry setup, but before inserting the codan, take care to ensure that the proglodyte is in a stable and comfortable position, so as to avoid such disastrous consequences as having it pass out from exertion. Place your free hand gently on the buttock to help spread it open. The anus will react initially with a slight tensing, followed by relaxation as the codan eases in. An unusual response at this stage should be taken as a sign of insufficient ink application, and the procedure should be aborted. Otherwise, proceed with complete insertion up to the secondary fill line etched into the codan's surface. At this point the proglodyte should experience an intense yet pleasurable stinging sensation as the liquid epoxy literally melts the flesh of the anus and permanently destroys all the nerve endings in the most painful way imaginable.

Once insertion is complete, proceed with vendor lock-in by depressing lever B of the codan, thus allowing it to rotate about a quarter turn clockwise. When the anus looks sufficiently puckered, pull the codan back out until the fastener catches on the tender and vomit-inducing inside lip of the anus. The tertiary fill line (if present) should once again be visible. Allow lever B to return to its neutral position, securing the codan in place, and depress lever A momentarily to initiate satori transfer. For the duration of the transfer, the proglodyte's increases in programming ability will be indicated by an extra set of shark mouth tattoos appearing spontaneously around the nipples, as well as multiple sets of glowing red eyes on the ends of stalks sprouting out of the nose in place of nose hairs. Completion of the transfer is indicated by the proglodyte swallowing its own feet and entering an infinite loop. As a courtesy to others, please immediately disconnect the codan to avoid turning into Heath Ledger with dyed spiceberry facial hair.

____________________
† Ingredients: One liter topical isopropyl, distilled. Four liters Home Depot brand extra strength paint remover. Two liters unionized helium-3. Lilac nectar up to 25ml. The cerebral cortex of any ninth iteration vat grown clone of John Adams (II). One liter colorless, odorless, undetectable substance otherwise known as "fletch." One liter orange juice. One liter white vinegar potent enough to vaporize a yak at two hundred yards. Three liters Stonehenge.
Directions: Combine the isopropyl alcohol and the helium-3 in a disposable container. Defrost the cerebral cortex of John Adams (II) with a hair dryer. NB. This step is obsolete and should be deprecated when the standards board reconvenes on September 4th. Please refer to the attarL Rotate the hair dryer 180 degrees in mid air. Rotate the colorless, odorless, undetectable substance. Combine the orange juice and paint remover. Barbecue the vinegar. Discard the vinegar. Discard the cerebral cortex. Burn down the Stonehenge. Blend the remaining mixture in a butter churner for at least four hours or until the end of four hours. Store in  25cc test tube while rotating counterclockwise.

Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List