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

[Carl Mueller Jr]

Why did it get sacrificed? Did the moving fruit tip the balance or something?

Actually, yes, the moving fruit does cut into the allotted number of cycles per frame; since it needs to move about the maze and bounce smoothly, it uses double-resolution positioning (as do things like the barrels in D2K) to give a very smooth appearance of motion.

　

Also, needing two MOBs for the player character cuts into the available processing time. The routines I have written for software MOBs (or SMOBs, as I call them) are still part of the Ms. Pac-Man source distribution, even though the routines are not used. They are very sophisticated, and allow you to place a SMOB anywhere on the screen (effectively treating them just as if they were normal MOBs), and they are allowed to be of pretty much any size. The VBLANK support routines are slow, because the background needs to be preserved; so you need to read in the bitmaps of cards that are overlapped, XOR them with the SMOB bitmaps, and then move them back out (it also needs to preserve the original BACKTAB attribute words). It's very, very complicated and as a result fairly slow.

　

In the end, I opted for arcade speed; if I hadn't, the game would not be anywhere near as smooth, and would probably be criticized (imagine people saying "see, the Intellivision can't even handle Pac-Man!"). I believe I made the right decision; however, in the case of something like "Pac-Man Arcade", the fruits do not need to bounce around the maze, and it does not require a second MOB detail for the player character (Pac-Man), so there may just be enough time to pull off the effect in that case. This would make a very good project if someone wanted to take it up; using the source I provided, it could probably be put together fairly quickly.

　

Carl

[DZ-Jay]

Actually, yes, the moving fruit does cut into the allotted number of cycles per frame; since it needs to move about the maze and bounce smoothly, it uses double-resolution positioning (as do things like the barrels in D2K) to give a very smooth appearance of motion.

　

Also, needing two MOBs for the player character cuts into the available processing time. The routines I have written for software MOBs (or SMOBs, as I call them) are still part of the Ms. Pac-Man source distribution, even though the routines are not used. They are very sophisticated, and allow you to place a SMOB anywhere on the screen (effectively treating them just as if they were normal MOBs), and they are allowed to be of pretty much any size. The VBLANK support routines are slow, because the background needs to be preserved; so you need to read in the bitmaps of cards that are overlapped, XOR them with the SMOB bitmaps, and then move them back out (it also needs to preserve the original BACKTAB attribute words). It's very, very complicated and as a result fairly slow.

　

In the end, I opted for arcade speed; if I hadn't, the game would not be anywhere near as smooth, and would probably be criticized (imagine people saying "see, the Intellivision can't even handle Pac-Man!"). I believe I made the right decision; however, in the case of something like "Pac-Man Arcade", the fruits do not need to bounce around the maze, and it does not require a second MOB detail for the player character (Pac-Man), so there may just be enough time to pull off the effect in that case. This would make a very good project if someone wanted to take it up; using the source I provided, it could probably be put together fairly quickly.

　

Carl

 

What about if instead of such a sophisticated "SMOB" mechanism, it were just pre-computed shifted cards that could be alternated between the existing background cards? After all, the ghosts don't move arbitrarily across the screen, they only move within the corridors and there is ever just blank space or a "dot" card there.

 

-dZ.

[Carl Mueller Jr]

 

What about if instead of such a sophisticated "SMOB" mechanism, it were just pre-computed shifted cards that could be alternated between the existing background cards? After all, the ghosts don't move arbitrarily across the screen, they only move within the corridors and there is ever just blank space or a "dot" card there.

 

-dZ.

Yes, it is using precomputed shifted bitmap patterns; the code never does more than it has to, so yes, just shifting right/left or up/down are special cases it is optimized for.

　

You could of course, obliterate the background rather than preserving the patterns underneath, but I don't think that would look very good.

　

Perhaps I'll post a video of what it used to look like (at very slow speed).

　

Anyway, SMOBs do have a lot of potential, but can only be used in very special cases or in very few numbers.

　

Carl

[+opcode]

Thanks for all the feedback. We have our designer working on Castlevania Inty graphics, and we plan to run the game in two possible modes, lower def with very little flickering, high def with a bit more flickering, our patented IntelliFlicker^TM algorithm for optimum multiplexing (way better than the NES version). This way I hope everybody should be happy. And no matter what the game will run on a steady 60fps. We will be offering two modes, Arcade (similar to the NES, but with a few twists), and Adventure (different stage layout requiring a lot more exploration and use of special items).

[+cmart604]

Thanks for all the feedback. We have our designer working on Castlevania Inty graphics, and we plan to run the game in two possible modes, lower def with very little flickering, high def with a bit more flickering, our patented IntelliFlicker^TM algorithm for optimum multiplexing (way better than the NES version). This way I hope everybody should be happy. And no matter what the game will run on a steady 60fps. We will be offering two modes, Arcade (similar to the NES, but with a few twists), and Adventure (different stage layout requiring a lot more exploration and use of special items).

Oooh, that sounds cool. Can't wait to see what you guys come up with.

[+Lathe26]

Cool. You probably were already considering this, but be sure to also handle 50Hz PAL.

[BBWW]

Never thought of the effect of color blindness especially in early gaming systems...

i think black bombs would make the flicker tolerable. Red was just hard to see on green anyway and im not color blind. I would like to see 8 bombs in black with flicker. If you ever decide to make a video doing that.

[Kiwi]

if i remember the video correctly your bombs were red or something. I think i remember thinking if you had black bombs it would be easier to see. And i dont think flicker would be so hard on the eyes with black

Here's an old video I made to show someone. This is before I added a variable to turn on the pastel color switch for the MOBs. In the new version, the red color are bright pink and the pipe bomb are cyan. The dark blue missile is now redrawn to be solid shaded white. The grenade is now Olive color. I added WAIT command to the game loop so I can capture the game at 30 fps. This computer is not fast enough to capture in HD at 60 fps therefore youtube would set the encode the video at 30fps. To get around the 30 fps limitation, I uploaded to youtube, and then hit the gear to bring up the menu, select speed and set it from Normal to x2. The video runs at 60 showing off the flickering correctly. Of course when the bomb explode, the game is no longer in the gameloop so it is 2x fast.

[+Tarzilla]

Here's an old video I made to show someone. This is before I added a variable to turn on the pastel color switch for the MOBs. In the new version, the red color are bright pink and the pipe bomb are cyan. The dark blue missile is now redrawn to be solid shaded white. The grenade is now Olive color. I added WAIT command to the game loop so I can capture the game at 30 fps. This computer is not fast enough to capture in HD at 60 fps therefore youtube would set the encode the video at 30fps. To get around the 30 fps limitation, I uploaded to youtube, and then hit the gear to bring up the menu, select speed and set it from Normal to x2. The video runs at 60 showing off the flickering correctly. Of course when the bomb explode, the game is no longer in the gameloop so it is 2x fast.

Try the new jzintv that was recently posted, it has native 60 fps avi capture, then post a link to let us download the avi, or keep it short to post as an upload here

http://atariage.com/forums/topic/234017-imvtogif/?p=3520684

[Kiwi]

MadBomber60fps.zip

 

I found the later build that had multiplexing bombs and the updated graphics and successfully made an avi with jzintv. I took out multiplexing bombs in the one I'm working on and testing gravity on bombs for round 2 because there at most 5 bombs on screen at once, I am using subpixel-x positioning from Oscar's example for the bombs so they aren't fixed at 0.5, 1, and 1.5 pixel a frame speed. I am playing on Control scheme 2, which is selectable on the keypad 7,8,9, with control scheme 2 with key selectable fixed speed. Scheme 1 and 3, I need to use the real disc to get feel for it.

[DZ-Jay]

You could of course, obliterate the background rather than preserving the patterns underneath, but I don't think that would look very good.

 

But, what are those "patterns underneath"? I thought they would be merely dot patterns, since the Ghost (and by extension, their eyes), cannot traverse outside the corridors. If this is the case, the combinations of eyes over dots can be pre-computed as well. Or am I missing something?

[Carl Mueller Jr]

 

But, what are those "patterns underneath"? I thought they would be merely dot patterns, since the Ghost (and by extension, their eyes), cannot traverse outside the corridors. If this is the case, the combinations of eyes over dots can be pre-computed as well. Or am I missing something?

The ghosts' eyes can also overlap the walls of the ghost box, in which case they would take on the color of the background (for example, pink on the first board).

　

By pre-computing I suppose you mean that you would have bitmaps for every possible position, eyes shifting over tiles that can contain from zero to three dots, and some of which can be power pellets. That's a lot of precomputed bitmaps.

 

Perhaps I was trying to do too much with it, but when I write code like that I want to make it as reusable and accessible as possible. And I wanted to be able to treat SMOBs pretty much as if they are ordinary MOBs. That way they can be commanded about in the same way, colored, sequenced, etc. all using the same code.

　

Carl

Edited June 24, 2016 by Carl Mueller Jr

[DZ-Jay]

The ghosts' eyes can also overlap the walls of the ghost box, in which case they would take on the color of the background (for example, pink on the first board).

 

 

Overlap the walls of the Ghost box? Hmmm... I don't know what you mean, I don't recall that in Ms. Pac-Man. Can you provide a screenshot?

 

 

By pre-computing I suppose you mean that you would have bitmaps for every possible position, eyes shifting over tiles that can contain from zero to three dots, and some of which can be power pellets. That's a lot of precomputed bitmaps.

 

 

 

Yes, indeed a lot of bitmaps. However, they are only 4 decles each. Considering that the alternative wasn't really good enough in performance, perhaps it has merit as a plausible solution.

 

-dZ.

[Carl Mueller Jr]

 

Overlap the walls of the Ghost box? Hmmm... I don't know what you mean, I don't recall that in Ms. Pac-Man. Can you provide a screenshot?

 

 

 

 

Yes, indeed a lot of bitmaps. However, they are only 4 decles each. Considering that the alternative wasn't really good enough in performance, perhaps it has merit as a plausible solution.

 

-dZ.

Actually, they would be 8 words (rather than decles) each, and that's not counting for the fact that they can be split across tiles horizontally or vertically.

　

The major flaw with this approach is that… The eyes can also overlap each other! So in my opinion, my approach made the best sense.

　

Like I said, if I were to do a Pac-Man Arcade, there might be just enough cycles available to pull off the effect, but for Ms. Pac-Man it was pretty hopeless. I estimated needing another 2 to 3000 cycles per frame, and there just wasn't anywhere to pull them from. Maybe if the sound engine wasn't so adamant about being compact, I could have squeezed a few cycles there, but nowhere near 2 to 3000.

　

I'll try to post a video later to show you what I mean about overlapping the ghost box's walls. But basically, the box is only two cards high and the ghosts have to fit inside. Any SMOB would naturally overlap these pieces.

　

Thanks for the input though.

　

Carl

　

[DZ-Jay]

Actually, they would be 8 words (rather than decles) each, and that's not counting for the fact that they can be split across tiles horizontally or vertically.

 

I meant "decles" as in the statement to store "words," nobody uses 10-bits anymore.

 

And, I meant 4 words per background card, irrespective if you need two per MOB.

 

　

The major flaw with this approach is that… The eyes can also overlap each other! So in my opinion, my approach made the best sense.

 

The eyes are mostly hidden behind the Ghost bodies, and there are specific cases where they overlap, so certain compromises could be taken to support it.

 

I understand that your approach is superior for a generalized mechanism for software-sprites. I am not arguing against that. However, since the game you made was Ms. Pac-Man and your SMOBs approach would not work well with it (at least this is what I gather from your comments), I was offering a different approach that may be less resource-intensive, which I believe could have worked.

 

In a thread discussing the merits and trade-offs of flickering sprites, I think it's appropriate to offer practical alternatives to multiplexing rather than a single silver-bullet.

 

Thanks for sharing your own approach and code.

 

-dZ.

[Carl Mueller Jr]

 

I meant "decles" as in the statement to store "words," nobody uses 10-bits anymore.

 

And, I meant 4 words per background card, irrespective if you need two per MOB.

 

 

The eyes are mostly hidden behind the Ghost bodies, and there are specific cases where they overlap, so certain compromises could be taken to support it.

 

I understand that your approach is superior for a generalized mechanism for software-sprites. I am not arguing against that. However, since the game you made was Ms. Pac-Man and your SMOBs approach would not work well with it (at least this is what I gather from your comments), I was offering a different approach that may be less resource-intensive, which I believe could have worked.

 

In a thread discussing the merits and trade-offs of flickering sprites, I think it's appropriate to offer practical alternatives to multiplexing rather than a single silver-bullet.

 

Thanks for sharing your own approach and code.

 

-dZ.

You could be right, but until I see it working with the Ms. Pac-Man code (at 60 fps) I will still have my doubts.

　

And you are right, it would take 4 words if they are packed, but when they split across two cards, it does double.

　

Carl

 

Here's what Ms. Pac-Man used to look like with the software MOBs:

https://www.youtube.com/watch?v=ujc-qy-hjuc&feature=youtu.be

[David Rolfe]

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.

 

In retrospect, I lament the Exec's 20 Hz tick pace; 30 Hz probably would have been achievable; however there was greater flexibility in allowing a larger processing interval for the unknown generic games to come. The post-Mattel games that I know of ran at 30 Hz (or better?), but of course they were customized (and had 8k of ROM) and didn't have the overhead of the Exec.

[+cmart604]

Let me be the first to say....great to see you posting here in the Inty forums, and a big thank you for your very significant contribution to our favourite gaming system.

[mr_me]

...In retrospect, I lament the Exec's 20 Hz tick pace; 30 Hz probably would have been achievable; however there was greater flexibility in allowing a larger processing interval for the unknown generic games to come. The post-Mattel games that I know of ran at 30 Hz (or better?), but of course they were customized (and had 8k of ROM) and didn't have the overhead of the Exec.

Does Beamrider go at 30hz or 60hz? It's very smooth. Wikipedia describes the cpu as being "de-tuned" for the Intellivision. I had the impression that GI made the Intellivision hardware slower than necessary.

[+GroovyBee]

Wikipedia describes the cpu as being "de-tuned" for the Intellivision. I had the impression that GI made the Intellivision hardware slower than necessary.

I think "de-tuned" is the wrong word to use. The GI CP1600 series came in 3 speed grades which are all compatible with each other. Mattel opted for the slowest (and therefore cheapest) by going for the CP1610.

[DZ-Jay]

In retrospect, I lament the Exec's 20 Hz tick pace; 30 Hz probably would have been achievable; however there was greater flexibility in allowing a larger processing interval for the unknown generic games to come. The post-Mattel games that I know of ran at 30 Hz (or better?), but of course they were customized (and had 8k of ROM) and didn't have the overhead of the Exec.

 

Dear Mr. Rolfe,

 

There is nothing to lament. The Exec is a marvelous piece of engineering that performed it duty well and strongly at the necessary time. It is very easy for us to consider and highlight its flaws when we've had 30 years of additional research, technological advancements, and industry maturity on which to base our views.

 

Nonetheless, I admire the work you put into the Exec and the early Mattel games. For those not acquainted with it, the Exec is not just an "operating system" or a collection of useful libraries: it is a fully formed game engine and generalized programming framework (what the kids nowadays call an "API"), with its own programming model capable of supporting many different types of games. It may be primitive, but it is one-of-a-kind, and light-years ahead from its contemporaries.

 

I apologize if some of our comments in this thread and others (mine included) describe the Exec in a negative light. That is unintentional. I personally admire its capabilities. Of course, with 30 years of hind-sight, we can pick apart its flaws and suggest alternatives; but I wouldn't want to take away from its actual achievements.

 

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.

Words of wisdom to live by. Thank you.

 

Best regards,

- j.

Edited June 25, 2016 by DZ-Jay

[Carl Mueller Jr]

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.

 

In retrospect, I lament the Exec's 20 Hz tick pace; 30 Hz probably would have been achievable; however there was greater flexibility in allowing a larger processing interval for the unknown generic games to come. The post-Mattel games that I know of ran at 30 Hz (or better?), but of course they were customized (and had 8k of ROM) and didn't have the overhead of the Exec.

 

David Rolfe, the greatest Intellivision programmer there ever was or will be! Welcome.

　

I think most of the people here can appreciate your design decisions, the goal being to write routines to support a variety of games (yet to be written) and their different needs. I can understand why the controls would generally be thought of as sluggish, and that would mostly have to do with debouncing the side buttons. 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 :-).

　

In fact, it is impossible to write a hand controller routine that can distinguish ALL keys independently; something has to be ignored in order to get that extra responsiveness.

　

Very, very nice to have you here.

　

Carl

[DZ-Jay]

 

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 :-).

 

 

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.

Edited June 25, 2016 by DZ-Jay

[mr_me]

I think "de-tuned" is the wrong word to use. The GI CP1600 series came in 3 speed grades which are all compatible with each other. Mattel opted for the slowest (and therefore cheapest) by going for the CP1610.

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.

[First Spear]

Hindsight is always 20/20. I can look at code I have written 6 months ago and said "ew, who did that?!" and you can be sure there will be no forum or collector's discussion about what I made 30 years from now.

 

Sir, you built something from nothing, and we all spent a good percentage of our waking hours benefitting from your work.

 

 

Based on what you might have seen in the Intellivision Programming Subforum here, what do you think is the biggest thing missing from our efforts and approaches to making new games?

 

 

 

 

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.

 

In retrospect, I lament the Exec's 20 Hz tick pace; 30 Hz probably would have been achievable; however there was greater flexibility in allowing a larger processing interval for the unknown generic games to come. The post-Mattel games that I know of ran at 30 Hz (or better?), but of course they were customized (and had 8k of ROM) and didn't have the overhead of the Exec.