Question about sprite flickering, frame rate, and the meaning of life...

[+GroovyBee]

Thanks. Yes cost is an important factor. I'm thinking a faster cpu would have made life easier for the programmers. Its not an easy thing to do but people are always trying to compare cpu performance. I wonder how the intellivision cpu performance compared with alternatives of the time and was it a good choice.

What killed its raw performance was the CP1610's multiplexed address and data bus. Like its competitor 8-bit processors of the day e.g. 6502, Z80, 6800, 2650 etc. its instruction lengths occupy one or more consecutive address locations (bytes/words). Arguably it could do more with the data once its had been acquired (it was 16 bits after all) but it still needed twice as many bus address/data cycles to get to that point.

 

I suspect that its possible to over clock a CP1610. GI probably made all CP1600's using the same process and then during testing they would be speed graded. Much like 486DXs were downgraded to 486SXs if their FPU wouldn't work.

[DZ-Jay]

Thanks. Yes cost is an important factor. I'm thinking a faster cpu would have made life easier for the programmers. Its not an easy thing to do but people are always trying to compare cpu performance. I wonder how the intellivision cpu performance compared with alternatives of the time and was it a good choice.

 

I don't think performance is all that important in the context of the Intellivision, in that the CP-1610 is good enough for what we use it. If I had a choice, I would have asked for a non-multiplexed bus between the STIC and RAM (to avoid the VBLANK constraint), higher resolution, multi-colour MOBs, hardware support for per-voice filters and envelopes, or many other things that would have enhanced the games themselves.

 

However, the Intellivision is very good for what it has.

 

 

What killed its raw performance was the CP1610's multiplexed address and data bus. Like its competitor 8-bit processors of the day e.g. 6502, Z80, 6800, 2650 etc. its instruction lengths occupy one or more consecutive address locations (bytes/words). Arguably it could do more with the data once its had been acquired (it was 16 bits after all) but it still needed twice as many bus address/data cycles to get to that point.

 

I suspect that its possible to over clock a CP1610. GI probably made all CP1600's using the same process and then during testing they would be speed graded. Much like 486DXs were downgraded to 486SXs if their FPU wouldn't work.

Exactly!

-dZ.

Edited June 25, 2016 by DZ-Jay

[DZ-Jay]

 

On a separate note, I think the sluggishness is due to the "pipelining" of the hand-controller decoder. For instance, one thing I've learned is that, if you read the hand-controller on an ISR event, at the end of frame processing (n + 0) (which seems to be practical, considering that the VBLANK period is precious), the input decoded will apply to the next frame (n + 1). Sampling multiple times to "debounce" the signal will compound this problem (n + 2, n + 3, etc.). Also, I believe (though I am not sure, so please correct me if necessary) that the EXEC samples the hand-controller once per "tick," or at 20 Hz, which adds to the delay in response.

 

You could read and decode the input at the top of the ISR, but this is not practical since it takes away from the previous time available to update the STIC and moving objects.

 

The approach I have taken is to process hand-controller input during the "idle" task of the "main" process queue. The notion is that when the process queue is empty, the game state has been updated and a frame is ready for rendering. Therefore, acquiring input at this time gives the engine a chance to update the game state prior to rendering, essentially applying the input on "n + 0" instead of "n + 1".

 

Of course, this requires the "main" game processing to be shorter than the time between ISR events, in order to have enough room to process hand-controller input. Given enough time, multiple samples can be acquired and "debouncing" the signal is possible. (Even though the samples are taken faster than at 60 Hz, this still works well in practice.) I appreciate that this may not be possible on every single game, especially if they are trying to squeeze out every single cycle available; but my own "arcade speed" game serves as proof that it is practical on at least some applications.

 

As counter-intuitive or trivial as this approach may sound, it actually works in practice, and gives a noticeable "perception" of responsiveness. I have verified this empirically with various people performing "A/B testing" on the simple difference of A) sampling controller input during "idle" task (n + 0); and B) sampling at the bottom of the ISR (n + 1).

 

Coupled with a sophisticated yet light-weight decoder that employs a state-machine to discern between "disc+action buttons" and "keypad" modes based on simple heuristics, the whole thing can identify all different inputs distinctly.

 

That is for a generalized routine. Specific game states may have lesser or more focused requirements than this, so "short-cuts" and additional liberties can be taken when specializing the decoder for a game.

 

Again, not to take anything away from Mr. Rolfe's accomplishments with the Exec. I have a luxury never afforded him: the collective experience, research, and analysis of a 30 year-old industry; plus the assistance, guidance, and influence of many brilliant and experienced people on the subject.

 

-dZ.

 

Oh, one more thing I forgot to mention. To "debounce" the signal, it is sufficient to sample the input directly from the hand-controller port multiple times until the value acquired is sustained over a certain period (possibly along with additional heuristics). Once the input signal is thus validated, it can then be decoded. It is not necessary to go through the trouble of decoding it in order to simply discard it if determined "glitchy."

 

This simplifies the routine and speeds up decoding.

 

-dZ.

[mr_me]

...

I know you must have been trying to get the most out of the controller, and to have to distinguish between UPPER, LEFT, and RIGHT buttons can actually take several frames (and be interpreted as keypad presses in the interim). Quite a nightmare! But your approach worked, most of the time (see Space Hawk and those invisible black holes :-)

...

This is a hardware problem and it would be tough for a programmer to work around. An incomplete side button press combined with a disc direction can result in a keypad signal being sent from the controller. It can be solved by improving the contact at the side button in the controller.

[+opcode]

Try and be nice to people, avoid eating fat, read a good book every now and then, get some walking in, and try and live together in peace and harmony with people of all creeds and nations.

 

 

Finally, the answer I was looking for! Thanks Mr. Rolfe! BTW, big fan, played Beamrider to death on at least 2 different platforms. Isn't kind of surreal when 30 years later we can interact somehow with our childhood heroes? I remember reading Beamrider's manual and seeing some of your advises to get to sector 26... Man, time sure goes fast.... I never got that far btw...

[DZ-Jay]

This is a hardware problem and it would be tough for a programmer to work around. An incomplete side button press combined with a disc direction can result in a keypad signal being sent from the controller. It can be solved by improving the contact at the side button in the controller.

 

It can also be mitigated with some simple heuristics and a state machine. For instance, if the user last pressed the disc or an action button, you can assume that he is using "disc + action" and expect one of those as the next input. You can then filter out anything that doesn't look like one of those -- at least until an unambiguous signal is finally acquired that decidedly changes the state and declares the user intent.

 

Remember, it doesn't have to be perfect, and you don't have to consider every single possible combination, or flawed case: in practice, people will re-try pressing a button again if they feel their previous input did not produce an adequate and timely response. These are edge cases that can be absorbed or mitigated rather easily in practice.

 

-dZ.

Edited June 25, 2016 by DZ-Jay

[mr_me]

It can also be mitigated with some simple heuristics and a state machine. For instance, if the user last pressed the disc or an action button, you can assume that he is using "disc + action" and expect one of those as the next input. You can then filter out anything that doesn't look like one of those -- at least until an unambiguous signal is finally acquired that decidedly changes the state and declares the user intent.

 

Remember, it doesn't have to be perfect, and you don't have to consider every single possible combination, or flawed case: in practice, people will re-try pressing a button again if they feel their previous input did not produce an adequate and timely response. These are edge cases that can be absorbed or mitigated rather easily in practice.

 

-dZ.

With this problem not only does the player have to try again but the unintended action can be frustrating. If the keypad is not part of the game the player would never know theres a problem so it only affects certain games. eg. AD&D, B17 Bomber, Space Hawk. But it can be fixed.

 

Edit: Its good you can address it programmatically.

Edited June 26, 2016 by mr_me

[DZ-Jay]

With this problem not only does the player have to try again but the unintended action can be frustrating. If the keypad is not part of the game the player would never know theres a problem so it only affects certain games. eg. AD&D, B17 Bomber, Space Hawk. But it can be fixed.

 

Edit: Its good you can address it programmatically.

 

It's not that the keypad is not part of the game, it's that it is not being pressed at the same time as the disc or action buttons. It is possible to make a distinction between letting go of the disc and pressing a keypad, and a "stray" keypad signal coming when the disc was still being pressed. You just have to make some common sense assumptions within your game-world, such as "if the player was just pressing the disc and shooting with the action button, why would he press the 'Enter' key? I'll assume it was unintended or in error." Of course, in code this is much simpler, since it's just a list of valid transitions you can accept from one state to another.

 

Apart from the fact that... it's a human playing. That means that he learns new behaviour. If he presses a combination often that doesn't work, he probably won't do it again. (It goes without saying that the programmer should also not make bone-headed decisions in his control scheme that puts the player in a position of pressing an invalid input all the time. For example, if pressing a key after the disc is valid for some action, then make sure that the key allowed is not one that could spuriously be triggered inadvertently when pressing a completely different "disc + action button" combo.)

 

I'll give you an example. In TRON Deadly Discs, you run with the disc pad but shoot with the keypad. One of the most frustrating things in this game is when you naïvely try to do them at the same time, and get some unexpected behaviour. It's TRON, it feels like it should be an arcade "run & shoot" game, but you can't run and shoot simultaneously. I recall as a kid that I ended learning to move, then let go of the disc completely, then press the keypad to shoot. As a consequence, my game-play was rather static, concentrating on picking a position from where I could combat effectively and avoid moving much. This indeed feels like a different game than if it were "run and shoot"; it requires more strategy and careful observation. It works well.

 

Of course, it takes some creativity and thought to design a proper control scheme for a game (unless you are doing something quite simple): the programmer should put himself in the shoes of his player and make sure that the ergonomics of the hand-controller (and the normal finger movements) support what he is after.

 

Apart from the edge cases of irrevocably broken controllers and crazy apes bashing the hand-controllers, these things do work quite well in practice. Trust me. There are glitchy and broken controllers out there, and there is very little we can do about those, but we can work on making games playable in the general cases with interesting control schemes that utilize the hand-controller to its advantage, while mitigating the side-effects and glitches on the edge-cases.

 

-dZ.

Edited June 26, 2016 by DZ-Jay

[mr_me]

In the three games I listed there are valid reasons for a keypad press immediately after disc/action button. With this problem every keypad button can be affected but it does depend on which side button the player favors. ie. Top right side button can get you a right collumn keypad press. I assume in your program you would check for a minimum delay between the disc/action and keypad as a human cant be that fast. That might have solved the "black holes" in space hawk. I don't know if my controllers were any more glitchy than others but I was able to elminate this specific problem through hardware. With Deadly Discs most people get use to the controls and move as much as they want (just like basketball), Deadly Discs is not affected by this problem anyway.

[DZ-Jay]

In the three games I listed there are valid reasons for a keypad press immediately after disc/action button. With this problem every keypad button can be affected but it does depend on which side button the player favors. ie. Top right side button can get you a right collumn keypad press. I assume in your program you would check for a minimum delay between the disc/action and keypad as a human cant be that fast. That might have solved the "black holes" in space hawk. I don't know if my controllers were any more glitchy than others but I was able to elminate this specific problem through hardware. With Deadly Discs most people get use to the controls and move as much as they want (just like basketball), Deadly Discs is not affected by this problem anyway.

 

Of course there are valid reasons. However, as you suggest with your assumption, there are some practical limitations due to a) human behaviour, b) controller ergonomics, or c) game-play expectations.

 

My point is that it is not a "free for all" where every single possible combination is valid. Games and humans are not really that chaotic in the real world, and assumptions and trade-offs can be made to conform to practical use cases. And here's the kicker: a missed input or spuriously decoded signal that occurs in an odd and rare situation will not cause the entire game to fail, nor does it invalidate all the other valid situations in which it worked correctly.

 

We're not programming nuclear reactors or missile guidance systems -- these are games, and as long as they are reasonably responsive and reasonably accurate (as perceived by the player), it does not have to be perfect. However, they do have to be well thought out from the player's perspective and tested accordingly.

 

-dZ.

Edited June 26, 2016 by DZ-Jay

[David Rolfe]

Thanks to all for the good words. Yes, I'm pleased with how well the Exec served as an adequate framework for what was to come. But we tend to agonize over the flaws in our work; it's silly, but it's part of the temperament that encourages us to do our best. You know what I mean.

 

In 1978, of course, I had no idea how far this thing was going to go. The Intellivision was a dubious prototype; a big box full of wires. It limped along as a project, unclear whether it would ever come together or be sold. I got the task because I was pretty much the sole full-time resource at the time. This is the sort of happenstance that makes me wonder about that "meaning of life" thing. I mean, in retrospect, I get the feeling that the plans I've made have never gone as expected, but the amazing things that have happened and the things that have worked out wonderfully; these were all random chance or acts of God.

 

So what practical lesson am I supposed to learn from that? That I should never plan ahead, and just react? No, that can't be right. I guess I don't know. But regardless of lessons learned or not learned, I'd like to think there's a greater order to the universe; however this quest for faith must be balanced against the self-centered arrogance of asserting that the Creator of the Universe decided He needed me to program the Exec.

 

Anyway, the factors aligned to put me there, so I did my part. And other people did their parts, and here we are. (For further contemplation of the "who's in charge here?" question, I would urge all seekers to at some point during their corporeal sojourns pick up a copy of Tolstoy's "War & Peace" and see if it grabs you. After a false start (Maude, blah!), I found a translation I liked (Rosemary Edmonds), and it drew me in. This book captures the characters in all their strengths and weaknesses and messy complexities, and at the same time gives an insight into the greater forces that may be at work; the patterns that people are part of, but that they themselves lack the vantage to perceive. Amazing stuff.)

[Utopia]

Looks like the dealers shirt collar ha been replaced by a greying beard in the avatar (30 years of age will do that). Always loved the shifty eyes!

[DZ-Jay]

So what practical lesson am I supposed to learn from that? That I should never plan ahead, and just react? No, that can't be right. I guess I don't know. But regardless of lessons learned or not learned, I'd like to think there's a greater order to the universe; however this quest for faith must be balanced against the self-centered arrogance of asserting that the Creator of the Universe decided He needed me to program the Exec.

 

 

Interesting perspective. Thanks for sharing, Mr. Rolfe.

 

In my opinion, regardless of the Grand Scheme Of Things, your individual contributions to our beloved platform are still invaluable and worthy of celebration.

 

-dZ.

[+nurmix]

 

I'll give you an example. In TRON Deadly Discs, you run with the disc pad but shoot with the keypad. One of the most frustrating things in this game is when you naïvely try to do them at the same time, and get some unexpected behaviour. It's TRON, it feels like it should be an arcade "run & shoot" game, but you can't run and shoot simultaneously. I recall as a kid that I ended learning to move, then let go of the disc completely, then press the keypad to shoot. As a consequence, my game-play was rather static, concentrating on picking a position from where I could combat effectively and avoid moving much. This indeed feels like a different game than if it were "run and shoot"; it requires more strategy and careful observation. It works well.

 

-dZ.

I need the send you a Dual Action Controller to try, dZ. It does require retraining your brain for the games that it supports (like TRON Deadly Discs), but once you get used to it, the games play so much better and more fluidly than they do with the standard controller.

 

If you're interested, send me a PM and we'll work something out.

 

BTW, really enjoying the discussion in this thread. And glad to see you popped in here too, Dave Rolfe!

 

 

 

Sent from my Intellivision ECS using Intelli-Tapatalk

Edited July 2, 2016 by nurmix