Also a quad every frame IS overkill for most cases.

I don't think it is, I still see some segmentation, but not enough for it to be not good enough, I think .

Just Google additive hash functions, mine is a derivation of it, will get the source code online soon if you are interested...

I did, and all I could find is the naive hash function of simply adding up the bytes of whatever you are hashing, which is not what you are describing.

I'm working on a glowing trail that follows the mouse cursor.

SWEET BABY JESUS this is hard to get right. I thought this would take me like an hour or so. NOOOOO SIR. Its been days and days of trying and scrapping one approach after the next, mounting frustration, despair looming larger and larger. If I knew it would be this hard, I would never have bothered. But now I have to see it through. I *think* I finally see the light at the end of the tunnel. But good god, this sucked.

game/rendering engine? Also what have you tried so far, and why did it fail in your opinion?

This is for my own game and engine. The basic problem I think has been the instability and jerkiness of mouse input. And the fact that even a little bit of overlap in the trail causes a noticible artifact.

Every frame I'm emitting a quad whose vertices are manually placed. My solution now is to keep a running average of the last 5 mouse positions, and use the vector form that to the current position to determine the direction of the segment as well as the orientation of the leading edge. This means that the trail can stray from the mouse when moving quickly. Too much "kinkiness" between quads becomes very noticable, but I thought that resorting to bezier curves was overkill, since I'm outputting a quad every frame. I might have to anyway, since I want to port to low-fps platforms (mobile).

I'm doing a horrible job explaining this, partly because it is still a muddle in my head. I have a feeling that this problem is trivial for everyone but me anyway.

My own hashtable  

That's a fun project - I made one of my own not too long ago. Pretty satisfying experience.

Ugh. I *think* I have this working perfectly now, and I've had this class for years.  A *lot* of subtle bugs are possible.

One hint: When removing an entry, make sure you re-hash adjacent entries previous to after (a bug in my bug description) the one you removed. This threw me for a loop. And then thinking I fixed it, I forgot to wrap around back to the end beginning when the adjacencies straddled the edges of the table, another crazy once in 10000 times bug. (Assuming you are using a flat hash table).

All the possible 32bit combinations will fit in 256kb, no collisions, thus getters and setters are almost the same (one addition, one compare and one lookup, that's it) and no need to rehash anything, at least that's how the algorithm should work

Please explain this algorithm, it doesn't seem possible from your description.

I'm working on a glowing trail that follows the mouse cursor.

SWEET BABY JESUS this is hard to get right. I thought this would take me like an hour or so. NOOOOO SIR. Its been days and days of trying and scrapping one approach after the next, mounting frustration, despair looming larger and larger. If I knew it would be this hard, I would never have bothered. But now I have to see it through. I *think* I finally see the light at the end of the tunnel. But good god, this sucked.

My own hashtable  

That's a fun project - I made one of my own not too long ago. Pretty satisfying experience.

Ugh. I *think* I have this working perfectly now, and I've had this class for years.  A *lot* of subtle bugs are possible.

One hint: When removing an entry, make sure you re-hash adjacent entries previous to after (a bug in my bug description) the one you removed. This threw me for a loop. And then thinking I fixed it, I forgot to wrap around back to the end beginning when the adjacencies straddled the edges of the table, another crazy once in 10000 times bug. (Assuming you are using a flat hash table).

I want make this screen look more polished and professional.
The game is a casual sci-fi RTS, and my idea is to have each of the main 3 displays be monitors, and surround them with futuristic, technological trappings, as if these displays were on a space ship. I'm not quite sure what to do with the information in the middle, and in general I am open to other ideas.

If interested Please send me a quote and examples of your work.  



Gameplay:

For the 10 billionth time I used min when I should have used max, and vice-versa. There's some kind of mental block going on, I just can't get it right.

I agree, I don't like the trend towards console-like simplification of options. But given the choice between supporting windows/multiple refresh rates, and smooth motion, I think smooth motion is much more important.

I think a lot of games would do themselves a world of good by only supporting fullscreen (I never understood the trend of gaming in a tiny window), setting the refresh-rate themselves, and if the game slows down, too bad. Most indie games have absolutely no excuse for dropping below 60fps on any semi-modern computer.

So, simply plug in the time elapsed since the last frame to calculate this frame's positions. Nothing non-deterministic about it, or difficult. You wouldn't get different results, except maybe a LSB or two due to rounding, and if those matter you have problems anyway.

That's pretty untrue. Depending on how the game logic is built, a different frame rate can totally change the outcome of the same set of events.

A simple example: let's say there's an object moving quickly toward a thin wall, and at 60Hz, the collision will be detected with simple AABB collision detection. But if the frame rate dips to 30Hz, it's now moving at double the speed as far as the engine is concerned, so the object might skip straight past the wall and never detect the collision. You'd need an entirely different collision detection system, or you'd need to find another way to handle frame interpolation. In either case, it's definitely not "simply plugging in" the time elapsed.

I know you can't just plug in the time delta for all cases, like collision or multi-body physics. But you can still call your collision/physics code multiple times per frame when lagging, which might take some tweaking but is certainly better than settling for crappy, skippy scrolling.

Mainly to keep the core mechanics deterministic: ideally each input should produce an exactly defined outcome. That is my motivation. But the actual reason for the majority of devs is the reduced difficulty in dealing with things being in motion (physics).

If you let the game update with vsync you need to make sure it keeps the same speed on a 60hz or a 120hz etc. monitor. It involves scaling the speed of objects being in motion: if you move the game from a 60hz monitor to a 120hz monitor then all the speeds must be halfed (and that is only considering ideal linear motion, acceleration is more difficult). However, in general, this scaling cannot result in identical game mechanics. As a logical consequence mechanical states will vary across different set ups.

I'm convinced you are right, that this is the reason most games skip frames.

I'm also convinced that it is almost always unnecessary. Halving all speeds and quartering all accelerations is the wrong way to think about it. Distance traveled at a given velocity for time T is V*T, and acceleration is (A*T^2)/2. So, simply plug in the time elapsed since the last frame to calculate this frame's positions. Nothing non-deterministic about it, or difficult. You wouldn't get different results, except maybe a LSB or two due to rounding, and if those matter you have problems anyway.

Though then again, I can see where you might run into some trouble, where an event is supposed to occur exactly at some time, which happens to be in the middle of two v-sync cycles. I could see this maybe breaking gameplay in a game like TrapThem, without extra effort to take this into account.

Looks very amiga-ish, I like it.

One problem with the common implementation of fixed update loops is that they are "not so fixed" if you look closely. Let's say the game claims to run at constant 60fps and your monitor is around 60 hz. You expect the game to smoothly move along with your refresh rate, but with unstable implementations it will be less frequently the case. At worst moments the game can even be trapped in ugly stutter cicles between 30 - 120 fps, but keeping 60fps on the macroscopic average.
That is not good.

Why would you decouple timing from vsync like this?

wrt Frogatto:
I think we dropped the framerate to 50 when it was ported to the original iPhone, because for the game as developed until then it was a very limited platform in terms of memory and cpu. The drop to 50 gave just that extra little bit of wiggle-room. (I might be mistaken, it was a long time ago.) Of course, since the current version of Frogatto doesn't run on the original iPhone any more, it's at 50fps for purely historical reasons. We haven't changed it because we haven't noticed it tearing too badly, so the general consensus is that it's no big deal. I think if you full-screen it, and if the video card and drivers support it, the monitor will run at 50fps. No clue if it'll actually synch refreshes though.

The engine itself supports running at any framerate your video card can handle, so you can run the game with --set-fps=60 or --set-fps 60, I forget. I think it's the first one if you want to see the difference.

Anyway, if it helps, our engine programmer regrets the decision, and you can make a new game in the engine that runs at the standard 60fps. Or 120, if you have a high refresh-rate monitor.

Thanks for the reply.

--set-fps=60 does in fact change the frame-rate to sixty, but it still jerks like crazy, even in fullscreen. It certainly sounds like your engine is calculating the frame times itself, rather than letting v-sync drive the timing. This is incorrect, and can never produce smooth motion.

Looking at your webpage, you guys spent about as long working on this as Michelangelo spent working on the Sistine Chapel. So from my perspective, this is like painting a masterpiece (your game is beautiful, and shows much love), and then as a finishing touch taking a piece of shit and smearing it across the center of the canvas. Sure, if I squint the right way I can kind of look around the streak, and I can always breathe through my mouth. But I can never truly forget that the shit is there. Sorry if that is harsh, but this issue drives me insane.

In other words, I strongly encourage you to fix it 

Game maker also likes to limit fps to some stupid amount. How could they get this so wrong?

Yes, that is certainly an issue. Unfortunately, a lot of devs use engines with suboptimal (for my standards at least) game loops nowadays to pump out stuff more quickly. Game loops certainly deserve more attention than they receive.

I honestly don't understand how it is possible to write such a suboptimal game loop.

(Trap them moves perfectly, btw. Great game.)

You're not describing the issue well enough or even providing examples, you're just getting angry.

Can you provide an example of a game that didn't scroll very well?

It is so endemic, I thought it was obvious. Sometimes I wonder if most people don't really perceive bad scrolling.

The issue is low fps, skipping frames and/or no v-sync, leading to jerky, skippy, bad scrolling. I'm definitely more sensitive than most people, even a single skipped frame is noticeable and annoying to me.

If you really need an example, just go to any flash portal and play a scrolling game. Flash seems totally incapable of smooth scrolling.

If you played the old dos games commander keen or jazz jackrabbit, they were horrible offenders. Some random examples of indie games I've recently played are frogatto, 8-bit commando, robotriot, adventure apes. All games I would have enjoyed/paid for. Some games like frogatto limit fps to 50 for whatever reason, ruining the scrolling.

What the hell is up with this? Every other scrolling game out there can't even manage to scroll properly. SUCH a pet peeve for me.

"Look at me, I'm retro! Pixels!"

Except real retro games managed to scroll flawlessly at 60fps on a 2mhz cpu, and you somehow manage to screw it up on a 2ghz+ machine? This was unacceptable 20 years ago, now its just absurd.

Developers, you have to get this right, or your hard work is wasted on a lot of people. If you are making a scroller with some shitty ass tool that can't manage smooth scrolling, it's NOT GOOD ENOUGH.

 

Up to the last world, it's getting so damn hard. How do you come up with these?