Fridge Racer - Gomie v. Gomie

Write and read reviews of games that have been uploaded to Slime Salad.

Moderators: Bob the Hamster, marionline, SDHawk

Post Reply
User avatar
Gizmog
Metal King Slime
Posts: 2622
Joined: Tue Feb 19, 2008 5:41 am

Fridge Racer - Gomie v. Gomie

Post by Gizmog »

I don't remember ever reviewing one of my games where I didn't have to explain what a hideous failure it was, so I'm not sure what to do here. I guess I'll try to take it in three parts. I'll write an "objective" and "neutral" review of the gameplay, follow that up with a brief and emotional retrospective on making the damn thing, and conclude with an explanation of what the hell the LoveTester was all about.

Part One: Playing Fridge Racer

Note: There's two versions of this game, an easy mode and a hard mode. I went for the Hard One and found the margin for error to be pretty slim. It's beatable, I've seen worse, but it could be frustrating. Easy mode seems to be identical except the cars are a little faster and the time limits a little more lenient. Well, except maybe on the third stage. That felt a little harder in easy mode. I might be crazy

I'll never forget the first time I played Gran Turismo. At the start of the game you get 5,000 bucks to buy a car. There was this nimble, sexy little red thing, but I was in love with this cheaper black Nissan. By buying the cheaper car, I was able to upgrade the engine. It wasn't very good goin' around corners, but that piece of slime was FAST. After a little bit of getting to know each other, I was winning races left and right in that thing. With all the money coming in, I was going to upgrade the hell out of that car and tackle the tougher challenges. It wasn't meant to be. I upgraded the suspension and messed it up so bad that the corners were no longer a problem: I'd spun out into the sand way before getting to them.

Got plenty of other memories too. Going insane beating F-Zero GX's story mode. The arcade back home that had some kinda racing cabinet in it, I don't even know which one. But what I do remember is the feel of the gear shift and how it kinda rumbled when you popped it from low into high. I could go on and on, but the important thing is: I know racing games, I've played racing games and I love racing games. Fridge Racer is not a racing game: It is a rhythm game in disguise.

Make no mistake, it's a very good disguise. The game runs at a crisp 60 FPS, just like a racing game should. The road rolls by in pretty good 3D condition, like a racing game should. There's a weird "chunkiness" to the road, but somehow I know what the author was going for and at speed you don't notice it as much. But a racing game involves memorizing the course, dodging obstacles, learning the idiosyncracies of your machine. Due to its limited course geometry and the nature of its character select, Fridge Racer doesn't have any of those things.

By limited course geometry, I mean that the road doesn't really twist and turn so much as it wavers. It goes exactly X units right, re-centers and goes exactly X units to the left. It goes exactly Y units up, recenters and goes exactly Y units down. It shows off the "3D" effect nicely and it feels kinda like one of those "driving on a country road" ads you see the big car companies use. The issue is that it's such a perfectly rhythmic waver that you aren't reacting to the road, you're just cancelling it out to stay in the middle.

That wouldn't prevent it from being a racing game in a lot of cases. Car selection adds variables that can make it more interesting. Maybe one car is speedier than the others. It's more likely to go off the road, but it's better able to recover from mistakes and if you don't make any mistakes you're going to be going insanely fast. Have another car be the opposite of that. It's slower, but easier to keep on the road.. of course if you STILL end up off the road, it's going to be harder to recover from your boo-boo. Hell, maybe there's even a 4x4 that doesn't care about going off the road but doesn't like going uphill (Which reminds me, there's no slow-down on up hills or speed-up on down-hills. It's merely cosmetic). The basic idea is that by putting different cars onto the same course, you expose their differences and that can be interesting.

Fridge Racer has multiple vehicles (3 real ones and one joke) and multiple "courses" (variations in how far it waggles one way or the other) but the courses are locked to the vehicles. Vehicle 1 can only race on Track 1, Vehicle 2 on Track 2 and so on. Since each course requires you to travel a certain distance in a certain time it kind of makes sense, from a balance perspective. On the other hand, it'd be more fun to mix and match, and in so doing, the game's effective length could've been tripled.

So ultimately, the gameplay boils down to holding down Up, (there are brakes but there's never a reason to use them), and figuring out how long you need to hold left, how long you need to hold right to counter (there's a weird slippiness to the controls.. it'd probably feel better with a wheel to whip back and forth than a keyboard), to avoid going into the snow on either side of the road. Dipping one wheel into the snow slows you down a little and going totally off the road slows you down a lot. The screech of going into the snow is the only sound effect in the game and it alerts you that you're breaking out of your rhthym.

I've been pretty rough so far, but only because the game bills itself as a racing game. As a rhythm game, Fridge Racer does a lot of things right. The tire screech is a good touch, it's just annoying enough to make you want to fix it. There's no engine noise, which would be distracting and obnoxious in a long game session. I personally love the music, a track by RMSephy. It's the only song in the game, but it perfectly encapsulates the kind of hijinks going on and the high-speed balancing act the player's dealing with. There's an option to turn it off if it gets too annoying. The speedometer has a needle that moves rather than just a number, and in addition to a speedometer the game also shows you the time limit and distance to go. Between the three you can calculate whether or not you're going to make it on time and that adds a kind of tension, knowing that you're getting behind schedule. That tension can throw you off your rhythm. The snow effect is pretty neat too, and I'm all for any game with unlockables and autosaving.

There's a high score list too, but it's kind of pointless. Winning numbers in hard mode are going to tend to be the same due to the tight time limit. Easy mode allows a wider variety of winning scores, but who wants to admit they played on Easy Mode? I'd recommend this game to basically anyone. It's scripted pretty nicely, the graphics are decent. If you stay away from Hard Mode it won't take too much time out of your day. My only problem is that it isn't a damn racing game.
Attachments
Whee confetti!
Whee confetti!
Snowdriver0130.png (4.88 KiB) Viewed 6724 times
Look ma, the speedometer just rolled over
Look ma, the speedometer just rolled over
Snowdriver0118.png (5.19 KiB) Viewed 6724 times
That's good advice.
That's good advice.
fridgeracerv12easy0001.png (5.28 KiB) Viewed 6725 times
User avatar
Gizmog
Metal King Slime
Posts: 2622
Joined: Tue Feb 19, 2008 5:41 am

Post by Gizmog »

This is probably boring and braggy. I'm mostly writing it for myself, to try to figure out what the hell I did to try to do the same thing next time, because I'm happy with my end results. I'm also going to try to defend some of the design decisions I made and spit on some of the others.

Part Two: slime that review!

I forget how much of this I've already blathered on about, but basically Fridge Racer is a plotscripting experiment that got away from me. I've you been stalking the OHR Screensaver directory, you know how that usually turns out. Strangely, I've PLANNED to make a racing game for a long time, but none of those plannings ever got anywhere.

What started this was the final level of Super Return of the Jedi. If you haven't ever seen it, there's a great Youtube Video of it here. Now, this impressed the hell out of me as a kid. It also traumatized me because I always bounced off the wall and ended up in the damn fire. What's worse is that my brother, me own flesh and blood, lied to me and said he'd beaten it. Told me all about the "ending" and how it was an extra level where you ran around Endor celebrating. He'd chosen Chewbacca, and instead of his "Spin" special attack, he had a "Bear Hug" special attack.

I was a curious little punk, so I axed him: Why'd you choose Chewie? What would've happened if you'd chosen Han Solo? Or Princess Leia? Or even Wicket? And my brother had the best possible answer: "I don't know"! So, I busted my slime for hours until I beat it and of course I didn't see any of the slime he'd talked about. But I did pick up an eternal appreciation for that sequence of the game.

So, I noticed at some point that the OHR could have transparencies in a backdrop slice. And that backdrop slices could be "Squash" dissolved the same as any other slice. And I wondered, could you emulate the SROTJ Mode Seven effect by "Squashing" a Backdrop slice with a transparency in the middle? As the transparency widens, you'd see more of the smaller slice in the hole and so on and so forth.

I wrote a very simple script to test and I was excited because you COULD squash a transparent backdrop and you COULD see the other backdrop underneath. But as the backdrop got bigger, as it grew from 0% of its intended 320x200 to 100% it seemed like it was getting slower. There was a mathematical reason for that, and I knew it. I just couldn't put my finger on what it was. So I did what I always do and asked IRC.

Feenicks had the first answer: 1% -> 10% is a tenfold increase. 90%->100% takes the same amount of time but isn't as big of a difference. That's exactly what I couldn't think of the words for, but it raised a new question: How could you make it maintain a steady speed as it approached the "camera"? TMC effortlessly had the answer for that, an equation I don't even remember. I wasn't able to get it to work with the backdrop (and I still haven't, partially because I don't "feel" like it'll work, so I haven't tried very hard. That's a pretty common problem with me.), but I was able to get it to work with some simple rectangle slices and I uploaded a quick demo to show TMC the fruits of his labor. I think that's in the OHR Screensaver directory too.

TMC's equation reminded me of this tutorial I'd read (mostly for the pictures) about fake 3D stuff and racing games. I put two and two together and got 5, maybe even 6. I did neither the tutorial or my IRC advisors justice. I don't even remember how I got to a racing game.. my initial plan was Afterburner or Space Harrier or something where you'd go up and down and left and right and shoot stuff while dodging pillars. Maybe I wanted to stick closer to the tutorial. Or maybe I was remembering older plans and was trying to make good on 'em.

The end result was Snow Driver, name stolen from my brother (who some of you might remember as my Santa Goes Extreme cohort). It was a prototype Fridge Racer with some major differences. Fridge Racer generates all of the slices it's going to use for track at the start and simply reshapes and positions them left/right as appropriate given their apparent depth and position on the map. IE: The bottommost slice is always indicative of what's X amount of units ahead of you.

Snow Driver was different: It was constantly creating slices, positioning them, moving them, and then deleting them and adding a new one when it was in position. It was also using a sine-wave as a placeholder track geometery, but based on a timer rather than position on the track. Meaning that if you slowed down, the road would be more wildly left/right because the sine wave was progressing faster than you were moving, and as you sped up the road got straighter. I wasted so much time fussing around with that thing and it only got worse and worse and uglier. My biggest problem was that the game didn't care where you were: To start the game you drove until it generated enough road to be underneath of you. And the way I had done it, there was no way to START on the road. And then I implemented the off-road logic and it took 40 seconds just to get to where you could test and I was fed up. Quit the whole god damn thing. Except I wanted to try one last thing and add a Y level to it, just to see the road go up and down.

And in my stubbornness, that Y Level turned into a retooling of the code to be able to generate road at the start, to go up and down, I tried adding AI Cars but I had weird problems when they got behind you... but basically turned into Fridge Racer. My original plan was that there'd be two levels and then the pig joke. Two hot blondes and then the Virtual School guys. Since the chance of opponent cars was gone, I'd decided it'd be a time trial.

My inspiration was Gran Turismo's license tests which were BRUTALLY HARD and mandatory if you wanted to play the game. My twisted, crazy-man logic was that the first level would be the hardest. Beating the first level earned you the easier, and thus more fun second level, earned you the beatable but bizarre pig level. Unfortunately, that's where I hit the next snag.

I wanted to do courses that were more than just sine wave. I was using the sine wave as a means to make sure that my rendering was okay for the road moving left and right and for the player moving left and right ojn the road. The downside is that I had been using it since the game was going to be like Afterburner and the sine was going to be for canyon walls or something. I had built the damn thing around it and it was very comfortable where it was. Trying to change things just made it worse, I was afraid I would break what I have, and after a lot of time I gave up and decided I'd just stick with the wavy roads... or making a game about boats.

So, resigned to that, I found values for the waves that I liked, I tweaked the cars until I liked how they felt and then played the races and tweaked the timer until I could win consistently with about 5 seconds left. In my mind, this meant that a guy could screw up for 5 seconds and still win. What I didn't consider was recovery time. It only takes .5 seconds to go into the snow, but it might take 4 seconds to get your speed back. That makes the margin for error way slimmer than it seems. I could've fixed it to be more lenient, but I was afraid that if I did, someone would super-easily beat the first level and then plow through the second level which I'd deliberately made even easier and never be challenged at all. Right or wrong, the first level was gonna be a bitch.

I think it was while I was testing that and worrying that I added the "Holy slime" level and then changed "Holy slime" to "Holy Smokes" 'cause I was afraid somehow a kid would get past the first two levels. I'd been working a whole lot on the game and I was starting to get weird ideas like that. I had the weird idea too that someone was going to release an identical project and I was going to look like a jackass or a rip-off man.

At any rate, I felt like that was a neat, trolly design: The first level is super hard, the second level balancing turned out to be easier, but slower than the first because of the curves. Player sits there thinking "Yeah it works okay, but only if go so god damn slow" and then level 3 comes along and is fast as hell. I couldn't give up the damn pig, though. I had to put SOME element of random megaslime onto this game. It couldn't be unapologetically normal.

Originally I had hoped the players would take advantage of the time in the pig level to smash all the buttons and find one that did something and then replay the game to see if it worked on the other racers (Which of course it wouldn't). I think the high score screen hint made that more fun.

Anyway, the paranoia was setting in pretty bad, the game was finished, the menus were finished, RMSephy had agreed to let me use his kickass song. I decided it was as good a time as any to release, even though I hadn't added the high score screen. What good would high scores be with such a narrow margin of error?

The reception was very complimentary. People said it was hard and I was okay with that, that was the design. Feenicks wondered if it was even beatable and given my reputation, it was a legitimate concern. I felt vindicated when TMC said he'd won without too much trouble... until he discovered he'd accidentally been playing the game at half its intended framerate. Hawk had "beaten the game" and deleted it, not realizing there were multiple levels. His replay took him a LOT of hours and the music started to piss him off.

I love the music, I was super grateful to Sephy for letting me use it, so I didn't want to have an option to turn it off. But, he was right: It would get annoying in the long run and it'd be nice for people to be able to listen to their own music. So, I decided I needed to release an update to address these issues.

The high score screen was going to be the biggest step. It would reveal not only your highest score, even on a failed attempt, but show that there were other characters to unlock with "???" blocks. By showing other characters, people would know there was something they were missing. They might not believe it was real, but if they did manage to beat the first level, they'd know to read the menu carefully and see the "Press 1" message. And would know then that Press 2 and Press 3 were going to be there too. The high score aspect might also add some replayability, which I think is the original reason I wanted it.

I still didn't want to change the race balance. *I* was happy with where it was. But I accepted that other people weren't and I hate games that seem promising but are so difficult they push you away. So I decided rather than making the game easier for everyone, I'd have an Easy Type like Final Fantasy IV did. People could choose whichever version they wanted and everyone would be happy.

My brother got home from college not too long after the Version 1.2 release, and so I got to see another human being playing the game and I got to see the game played on a computer that wasn't my own. He tried Hard Type but wasn't able to beat it. He came super god damn close multiple times but always lost just a second or so before the finish line. I was glad I'd made the Easy Type then, but I was also terrified that in making maybe the only real game I've ever made and probably the only good game I've ever made I had STILL accidentally trolled and made something unwinnable.

But I didn't worry about that. Not until Hawk tried his Charbile impression and tried to talk motivational slime at me in February 2016.
Attachments
This snow test was color coded so I could see which depth/height/latitude looked best. And it gave me the idea for confetti
This snow test was color coded so I could see which depth/height/latitude looked best. And it gave me the idea for confetti
Snowdriver0064.png (3.54 KiB) Viewed 6699 times
I wouldn't quit until I had re-added all the features. The rumble strip and road lines had to be different from how Snow Driver handled it. But, the new way let me do land..
I wouldn't quit until I had re-added all the features. The rumble strip and road lines had to be different from how Snow Driver handled it. But, the new way let me do land..
Snowdriver0036.png (2.55 KiB) Viewed 6700 times
The only screenshot I have of the other cars. They looked pretty nice so long as you didn't get close. Note that I didn't have land yet.
The only screenshot I have of the other cars. They looked pretty nice so long as you didn't get close. Note that I didn't have land yet.
Snowdriver0034.png (2.49 KiB) Viewed 6700 times
When you went slow in Snow Driver, the road went crazy.
When you went slow in Snow Driver, the road went crazy.
FridgeRacerExample02.png (2.15 KiB) Viewed 6701 times
First screenshot where it looked like a racing game. A transitional stage from Afterburner to Snow Driver.
First screenshot where it looked like a racing game. A transitional stage from Afterburner to Snow Driver.
Snowdriver0009.png (3.59 KiB) Viewed 6701 times
Last edited by Gizmog on Sun Feb 14, 2016 12:12 pm, edited 2 times in total.
User avatar
Gizmog
Metal King Slime
Posts: 2622
Joined: Tue Feb 19, 2008 5:41 am

Post by Gizmog »

Since it's Valentine's Day, I'll reveal my secrets!

Part Three: What the slime was Gomie's LoveTester?

To recap from Part Two, there were rumors that Fridge Racer was unbeatable and that worried me enough to make an Easy Type. When I watched my brother play Hard Mode on his laptop, he seemed to fall just short and I got worried that maybe the rumors were true. I had a theory as to why it might be broken and it all boiled down to a bad coding habit.

When I first started plotscripting stuff, I used KeyIsPressed. But everything I did rapid fired, because with KeyIsPressed, if you hold the key down for 2 ticks, it's going to register as true two times.

As soon as I learned about KeyVal I used that exclusively. The way I used it (which is something I was told and never tried to fully understand) made sure that it would only register true on a New Key Press or Type-Matic Repeat. But what is a TypeMatic Repeat?

I've always assumed it's what happens you hold down the rrrrrrrrrrr key. Windows has a setting to make it faster or slower and I always keep mine pretty fast. But then when I saw my brother struggle I wondered.. is my typematic repeat faster than his typematic repeat? If so, I would be accelerating and steering more times per tick than he possibly could. And since I'd balanced the game to be extremely frickin hard for me, that could be impossible for someone with slower keys.

As I understand, most real games get around this by tying limitations into the game engine itself. When you press Up, you set a "PushedUp,Don'tPushUpAgain" timer that won't come down for however many game ticks. In that way, performance is identical from machine to machine. In the future, that's how I should do it.

To help figure it out, I wrote a script that would watch across a period of time and record which ticks KeyVal was returning true and which ticks KeVal was returning false. From that, I figured, I would be able to figure out how "fast" my keyboard was and manually add a timer to make sure that no matter who you are, your performance would be equal to mine.

To test, I turned my windows Keyboard Repeat to its slowest setting and recorded the results. Then I set to the fastest setting and recorded the results. They were damn near identical! It didn't seem like that setting was having any effect, which makes perfect sense: the OHR is on Mac and Linux too. Surely Mac and Linux have different keyboard settings than Windows (which probably varies version to version too) and it'd be silly to check each one. James and TMC and the other devs are too smart to fall into that trap, so there must be some more universal way its checking.

BUT, could that universal way still vary keyboard to keyboard? PC to PC? Could it render the game unwinnable? WOULD I have to reprogram the rats nest that is the Fridge Racer code? There was only one way to find out. A scientific survey of people's keyboards. If EVERYONE ran my script, we could compare results in a professional and scientific manner. Feenicks and my brother had the most problems, so if their results were markedly slower than everyone else, the problem would be solved.

But I didn't wanna be professional and scientific, I wanted to have a giggle. So I gussied the thing up as one of those Palm Reader machines they used to have in bars (which frankly I always wanted to program anyway) and added a silly way to collect the results.

The way it works is simple. Just like Fridge Racer, LoveTester runs at 60 frames per second. When you hit up, you start the game. Over the next two seconds, it checks 120 times whether or not (KeyVal (Key:Up) >> 1). If it is, you get a point. If you release up at any time (Checking via KeyIsPressed) the background changes color, so I know that low result can probably be ignored. Don't know what kinda cuck wants to score low on a LoveTest, but they're out there.

To keep people from cheating the score high, I added the codenames as a kind of code check. They're characters from the Dragon Ball series put into a weird order. I think it goes Master Roshi > King Kai > Picollo > Vegeta > Goku > Krillin > Yamcha > Tien > Chao Tzu > Bulma.

I was worried too because my results kept bouncing back and forth between 36 Yamcha and 35 Tien. So I upped my time limit from 2 seconds to 40 seconds. Still only saw a 1 tick difference (935-934), so I assume it's just luck of the draw as to which tick the game starts on.

As for the results? Well, let's go all scientific:

My hypothesis was that Feenicks and Sno, who'd seen issues with Fridge Racer, would post lower Love Scores than the general public. Further, I expected to see a range of scores based on different kinds of keyboards and PC Speeds. This is why we've got so many ranks that nobody will ever see.

The results were shocking, but also a relief: Almost everyone had 36 meaning that their gameplay experience in Fridge Racer would've been the same. There were some outliers, of course.

BMR had 37, but that would make his game a tick easier and might be the same luck of the draw that bounces the rest of us between 36 and 35.

Feenicks and my brother both had 36s, so their gameplay was definitely unaffected.

James looks like he played on an android or something and got a 34. Only one tick slow and I wasn't too worried about Mobile Gaming with Fridge Racer anyway.

There is one case I worry about and that's Shizuma. He didn't post in the thread, but in IRC he had a few scores in the 96 range. That means he was getting nearly a whole second's worth of (KeyVal (Key:Up) >> 1) action than the rest of us. He repeated the test and did score multiple 36s in a row, but had a 96 about one time in five. I have no idea what's going on with him, but he would have a MASSIVE advantage in the game. My only guess is some kind of hiccup on game start, which would be exacerbated by the fact that I didn't script a cool "Press Up to start" thing.. I just took advantage of the fact that any key will start an OHR Game.

But, everybody had a good time and it was way more fun than boring ol' science would've been. For a nerdy good time, run the game again and hit Ctrl+F4 to open the Slice Collection editor. There'll be a container with a bunch of containers inside, and on the right hand side of the screen you'll see a vertical 1x1,0x0,0x0,1x1 pattern that is the pulse of the TypeMatic repeat.

Happy Valentine's Day!
User avatar
Bob the Hamster
Lord of the Slimes
Posts: 7658
Joined: Tue Oct 16, 2007 2:34 pm
Location: Hamster Republic (Ontario Enclave)
Contact:

Post by Bob the Hamster »

I bet a lot of my script suffer from this too. I tend to use keyval in the same way you do.

I was not fully aware that changing typmatic repeat was a thing that people can actually do.

I suspect SDL and/or Directx is probably doing it?
User avatar
BMR
Metal King Slime
Posts: 3310
Joined: Mon Feb 27, 2012 2:46 pm
Location: The Philippines
Contact:

Post by BMR »

Interesting. For what it's worth, I'm on Linux and I've got a Microsoft Natural Ergonomic 4000. Also, the only score I would ever get was 37, never a 36 or 35.
Being from the third world, I reserve the right to speak in the third person.

Using Editor version wip 20170527 gfx_sdl+fb music_sdl
User avatar
Gizmog
Metal King Slime
Posts: 2622
Joined: Tue Feb 19, 2008 5:41 am

Post by Gizmog »

Bob the Hamster wrote:I bet a lot of my script suffer from this too. I tend to use keyval in the same way you do.

I was not fully aware that changing typmatic repeat was a thing that people can actually do.

I suspect SDL and/or Directx is probably doing it?
The weird part is that you can't! I can make it so that I type say.. 2 r's in a 10 second period. I can amke it so I type damn near 50. Neither of those settings had any effect! My score was still 36-35, either way. No effect.

The only real anomaly is Shizuma and I'm wondering, if Sephy and the other dude's shenanigans are any indicator, whether or not timing may be involved. If something was bumping the game below 60 FPS, that could make something weird happen.
User avatar
Mogri
Super Slime
Posts: 4668
Joined: Mon Oct 15, 2007 6:38 pm
Location: Austin, TX
Contact:

Post by Mogri »

In Windows, Control Panel > Keyboard lets you set repeat delay and repeat rate. I would imagine OHR honors those settings, since I don't know how else it could vary.
User avatar
Gizmog
Metal King Slime
Posts: 2622
Joined: Tue Feb 19, 2008 5:41 am

Post by Gizmog »

Mogri wrote:In Windows, Control Panel > Keyboard lets you set repeat delay and repeat rate. I would imagine OHR honors those settings, since I don't know how else it could vary.
It doesn't, though. Set it any way you like and try the love-tester: No significant difference. The only thing I didn't try was setting my keyboard settings and restarting. I can assure you that I was typing damnably slow and lickety-quick, and my LoveTester scores remained the same.

EDIT: By no significant difference I mean, I get 36 or 35 at slowest settings and I get 36-35 at fastest settings and I didn't observe one value or the other being more or less common at either end of the spectrum.
Last edited by Gizmog on Tue Feb 16, 2016 6:10 am, edited 1 time in total.
User avatar
Gizmog
Metal King Slime
Posts: 2622
Joined: Tue Feb 19, 2008 5:41 am

Post by Gizmog »

Double posting. Here's my theory of why there's a 36-35 variation.

Let's assume the input is a pattern. Hyphens just for organizational purposes.

Code: Select all

KeyIsPressed Pattern
11111-11111-11111-11111-11111

KeyVal Pattern
10001-00010-00100-01000-10001

00010-00100-01000-10001-00010
So in 25 ticks, KeyIsPressed is true 25 times.

I have to count for KeyVal and I'm bad at counting but I think that in the first example there's Seven Trues and in the second example there's only six.

It's the same 10001000 pattern, but based on where we start and stop measuring, the results can be different.
User avatar
Mogri
Super Slime
Posts: 4668
Joined: Mon Oct 15, 2007 6:38 pm
Location: Austin, TX
Contact:

Post by Mogri »

If accuracy is a real concern, it wouldn't be hard to implement your own keyval function so long as you either A) called it exactly once per tick or B) gave it access to a global tick counter. There's no built-in support for anything like that, but it's not too much of a pain -- just bake it into your wait wrapper script. (You do have a wait wrapper, right?)
User avatar
Gizmog
Metal King Slime
Posts: 2622
Joined: Tue Feb 19, 2008 5:41 am

Post by Gizmog »

Mogri wrote:If accuracy is a real concern, it wouldn't be hard to implement your own keyval function so long as you either A) called it exactly once per tick or B) gave it access to a global tick counter. There's no built-in support for anything like that, but it's not too much of a pain -- just bake it into your wait wrapper script. (You do have a wait wrapper, right?)
Naw! Haven't needed one yet! At any rate, most of my technical babbling was just to prove to Hawk that I was "close enough" and that I didn't need to take any heroic measures to fix the god damn thing. If Hawk told me I was a bad programmer, I'd just die.
TMC
Metal King Slime
Posts: 4308
Joined: Sun Apr 10, 2011 9:19 am

Post by TMC »

So far I've only read the part of this thread about key repeat; pretty busy here. So weighing in on that:

The key repeat rate is independent of any OS settings, but it does depend on frame rate: it triggers every 55ms. The delay before key repeat starts is 500ms. (It would be trivial to add some extra arguments to the keyval command to let you customise these if anyone wanted.) The reason I made it adjust to frame rate is so that changing your game's framerate setting causes things like scrolling through menus and typing to happen at the same rate as before. However it's a serious problem if the frame rate dips, so basically you should never use keyval repeat for anything affecting gameplay unless the rest of your game is also framerate adjusted/independent. It may have been a mistake to make keyval depend on actual frame rate rather than intended frame rate, but key repeat is mostly only used for scrolling menus so it made sense at the time. I think we could change it, but I want to replace keyval with one or more nicer functions anyway.

It will very rarely make sense to make a game framerate-independent, only when the game is doing a lot of processing so likely won't hit the target frame rate but you don't want it to slow down when that happens. It's extra work as you can't use things like slice velocity commands or builtin hero and NPC movement, and need to count milliseconds everywhere.

Shiz's reading of 96 corresponds to a frame rate of 120frames/(0.055sec * 96) = 23fps. Now, 30fps I could understand, but 23 a fifth of the time is an alarming glitch. Maybe a directx issue? g_debug.txt would likely show some warnings if something in the graphics backend is taking far longer than expected.

If you type text (using inputstring) then the OS's key repeat rate is used, unless native text input is disabled entirely (as we had to do on Linux due to X11 problems).

If you don't want a wait wrapper, here is how I calculate the tick number (this will surely appeal to Giz's sensibilities):

Code: Select all

  tick counter slice := create container
  set slice velocity x(tick counter slice, 1, 1000000)
  ...
  tick := slicex(tick counter slice)
Last edited by TMC on Wed Feb 17, 2016 8:46 am, edited 2 times in total.
User avatar
Gizmog
Metal King Slime
Posts: 2622
Joined: Tue Feb 19, 2008 5:41 am

Post by Gizmog »

TMC wrote:So far I've only read the part of this thread about key repeat; pretty busy here. So weighing in on that:

The key repeat rate is independent of any OS settings, but it does depend on frame rate: it triggers every 55ms. The delay before key repeat starts is 500ms. (It would be trivial to add some extra arguments to the keyval command to let you customise these if anyone wanted.) The reason I made it adjust to frame rate is so that changing your game's framerate setting causes things like scrolling through menus and typing to happen at the same rate as before. However it's a serious problem if the frame rate dips, so basically you should never use keyval repeat for anything affecting gameplay unless the rest of your game is also framerate adjusted/independent. It may have been a mistake to make keyval depend on actual frame rate rather than intended frame rate, but key repeat is mostly only used for scrolling menus so it made sense at the time. I think we could change it, but I want to replace keyval with one or more nicer functions anyway.

It will very rarely make sense to make a game framerate-independent, only when the game is doing a lot of processing so likely won't hit the target frame rate but you don't want it to slow down when that happens. It's extra work as you can't use things like slice velocity commands or builtin hero and NPC movement, and need to count milliseconds everywhere.

Shiz's reading of 96 corresponds to a frame rate of 120frames/(0.055sec * 96) = 23fps. Now, 30fps I could understand, but 23 a fifth of the time is an alarming glitch. Maybe a directx issue? g_debug.txt would likely show some warnings if something in the graphics backend is taking far longer than expected.

If you type text (using inputstring) then the OS's key repeat rate is used, unless native text input is disabled entirely (as we had to do on Linux due to X11 problems).

If you don't want a wait wrapper, here is how I calculate the tick number (this will surely appeal to Giz's sensibilities):

Code: Select all

  tick counter slice := create container
  set slice velocity x(tick counter slice, 1, 1000000)
  ...
  tick := slicex(tick counter slice)
This is an excellent post that answers every question I had, and your solution indeed appeals to my sensibilities! I think your KeyVal Solution is the correct one, it's right 99.9% of the time, including this case! I only went to all this science and megaslime 'cause I was curious how it worked.
Post Reply