vectrex animation, game programming

[gliptitude]

I've been messing with the animation feature on Art Master, making some observations, and wondering if anyone here knows if what I'm observing is unique to Art Master animation, or if it is common to the Vectrex (ie : does this apply to game programming in any respect?).

In Art Master animation each frame must contain the same number of vectors. What ever movements each vector makes from one frame to the next are evidenced in the playback, meaning you are not actually drawing every "frame" that is contained in the animation, rather the program is providing "in-betweens".

Cinema animation is 24 distinct static frames per second and animators commonly reduce this to 12 frames per second by photographing each picture twice. When you watch a film of such animation you are seeing nothing but the sequence of each of those static pictures and each frame can be as unique as the animator feels is appropriate. Television/video has a different frame rate, but animation is still done to film specs, at least in the past it was. ... I've read of Vectrex sprites containing such and such numbers of frames of animation, always certainly a lower number than the number of "frames" the machine is producing over that period of time. But I notice that most of what I see in Vectrex games seems to retain the same particular vectors from one frame to the next in animated sprites, like Art Master does.

... Is there a reason for this? Is it necessary or advantageous that animated sprites in Vectrex games retain the same vectors from "frame to frame"? Does animating sprites in Vectrex games always entail automatic "in-betweening"?

[sj]

My brain hurts...

[gliptitude]

Mar 17, 2012 5:20:41 GMT -5 sj said:

My brain hurts...

Heh well thanks for the bump. The answer to my question is probably overwhelmingly technical, but the question itself is more simple than it might seem. I think if we were sitting in front of my vectrex with a pen and paper handy i could explain it to a child. But articulating it remotely with text is what it is.

I kind of anticipate that if someone qualified to answer this actually does so, they will give a deflective answer, suggesting basically that this should be the last of my concerns in programming a vectrex game, which is not what I want to hear. (But still maybe the best answer) It's a pipe dream I guess, but still sustaining my interest at this point. I've already been advised that it will be very very difficult to make my own vectrex game and that it may be just as difficult to convince someone else to program it. Also been advised though, even in the later route, to study the system and learn it's traits and capabilities. So...

Traditional animation is something I understand and have experience with. If you follow my question you might wonder why it matters that I can't make a vector disappear from one frame to the next. ..Well if you imagine a drawing of a three dimensional object rotating (a very fundamental movement), lines on the front of the figure will vanish out of view as that face moves to the side and then behind the figure.

Perhaps a more concise question would be "what does a vectrex sprite consist of?". And then, if the figure is animated, does this figure consist of as many sprites as there are frames of animation? (Does one frame = one sprite?)

It's hard for me to imagine there is only one way of doing it. But it is easy for me to imagine that there may be advantages to sustaining the vectors of the original sprite, and programming the vectrex to move the existing vectors it has already been programmed to draw. ...

[fury]

I think I can answer your question.

When I used the word "frames" to describe the animation in War of the Worlds, I was referring to the number of individual drawings that I did for the walk cycle. A 15 frame walk cycle simply means that I did 15 individual drawings. I was not referring to how long each one of those drawings was displayed on screen.

In film animation, the frame is 1/24 (or 1/25 PAL) of a second. If an animator wants the character to appear to move slowly, the increments of movement are decreased (or multiple frames are shot, as you've mentioned). The opposite is true for fast movements.

Same idea here, in that I will increase/decrease the length of time a drawing is shown by using a counter. It's all there in WOTW. When the Tripods start out, they're fast moving. By the time they get cut down by your fire, they move very slowly and the drawings are displayed longer. In film terms, the drawings are shown for an increased number of frames in order to produce a slower movement effect.

The reality is that I did 45 different drawings for the Tripods! 15 for each of 3 different walk cycles (tall, medium and short).

Hope this makes sense!

[celtroniclabs]

Some long winded answers to your questions (thanks to Siri on my iPhone):

The traditional use of the term sprite in video games refers to a bitmap image made up of pixels which represents a character or game object on the screen. Like Mario from Donkey Kong.

In our beloved vector games, our game objects or characters are not made up of pixels, they consist of vector lines.

Each line is defined by a pair of vertices, defining an X and Y position for two points on a Cartesian coordinate grid that define the start and ending points of a single vector line. The classic vector display systems are only capable of drawing straight lines between two points they can not do curved lines or solid fills. I believe some later vector display systems could do solid fills.

All game objects are made up of a collective group of these vector lines. which are all defined mathematically by points in either a two or three dimensional space. With vector games there are no bitmap sprite images and there are no sprite sheets.

There are two methods by which we generate visual movement of these Vector line objects around the screen.

The first is to use a matrix transform to manipulate the vertices in two-dimensional or three-dimensional space. The matrix transform allows us to transform (fancy way of saying move), rotate and scale the object on screen.

Matrix transformations are done programmatically with code, and can be done with increments on a per frame basis (of any frame rate), or as fast as the CPU can manipulate them. No keyframes are used, no tweening is used the transform is done in real time based on a timed interval.

The second method is what Fury is talking about. This is more like traditional cell animation. He has already explained this method fairly well. His tripod object is probably being moved and scaled on screen by matrix transform calculations. In addition, within that matrix transform movement a series of 15 frames made up of those tripod object lines are being animated at a particular frame rate as he stated in his post. He, of course, could confirm this but I believe that's what's going on in his case and on the Cinematronics arcade version.

What he did not mention was that you do Not need to have the same amount of Vector lines on the screen for each given frame of the animation (at least not on the engine I am creating). Your object could be made up of 18 lines on the first frame, then only 15 of those lines could be visible on the second frame, then only 12 on the third frame etc. All 18 lines are always there in the computer's memory but only the actual number of lines that need to be visible on screen would be sent to the draw routine to actually be drawn on the screen.

Normally each frame of the animation has the same number of lines visible on screen though. So the answer to that question is yes normally the same amount of lines are on screen for each frame, but it does not have to be that way.

Hidden line removal on three-dimensional objects, like you mentioned above, would have to be implemented by custom coding. There is no automatic way to do that.

The whole process should entail the following:

1) define object lines in 2 or 3D space

2) manipulate those lines via code based upon game logic and player control input.

3) draw those lines on the screen.

4) repeat steps two through three for each cycle of the main game loop.

Of course you have audio and sound effects to throw into the mix, and collision detection as well. If your strong point in school was mathematics, algebra and geometry you will grasp all of this much easier than if your background is primarily in the arts. Thinking about all this and trying to program a video game can make your head explode if you're more of a right brain dominant person. I am more of a right brained person, and it is taken me a while, and lots of reading, to figure all this stuff out.

Lastly all of my above comments are based on my knowledge of the Cinematronics Vectorbeam system, and my experience coding my own vector game engine (for iOS). I have no specific experience with the Vectrex, nor have I ever owned one. My assumption is that its display workings are similar to the Cinematronics and other vector game display systems of the time period.

[VectorX]

Your brain hurt again, sj?

Mar 18, 2012 17:08:12 GMT -5 celtroniclabs said:

Lastly all of my above comments are based on my knowledge of the Cinematronics Vectorbeam system, and my experience coding my own vector game engine (for iOS).

Cool, you going to make any games or anything?

[fury]

Unfortunately the Vectrex has some limitations, and is a bit different from the arcade vector games in terms of display. Zonn (creator of the Zektor ZVG) explained it to me once years ago. The Vectrex does a poor job of regulating high voltage, and the low voltage power supply is too low to allow the vectors to be reliably drawn off the edges of the screen. This is why in some games we get scrunched up vectors at the screen edges. It also has trouble displaying images where vectors are not drawn in order, which is why some of the arcade games played using ZVG have visual flaws.

Small samples of matrix math animation can be done, but in order to implement it as a core part of the game play, I lean towards the adapter that Kokovec is working on:

www.youtube.com/watch?v=6009wwKVDlA&context=C4bc6b4eADvjVQa1PpcFMMrXt9NGifkLkvZ2trClOxLa6x3NrFX18=

For my tripod movements, each complete walk cycle is drawn at the exact same location. Traditional animation techniques provide the illusion of lateral movement. When the cycle starts again, the tripod is drawn at the corresponding new x-coordinate, continuing the walk. Video of the animation on youtube (uploaded by Extralounge):

www.youtube.com/watch?v=v5MWAe9s-q4

I'm sure that the original question regarding the number of vectors is referring to matrix math animation. With the technique that I've described you can do whatever you want. You can draw a square, then a triangle, then a square again and it won't matter that the triangle has one less line.

[sj]

What an incredible amount of knowledge you programmers have!!

I just wanna turn it on and shoot stuff...

I'm gonna go now and have a little weep in the corner.

[gliptitude]

EDIT: (the following reply was written following fury's first reply, prior to reading the other replies)

Mar 17, 2012 12:46:16 GMT -5 fury said:

The reality is that I did 45 different drawings for the Tripods! 15 for each of 3 different walk cycles (tall, medium and short).

Hope this makes sense!

Yes this does make sense. Thank you for your reply, fury.

(in terms of my question(s)): I think you indicate that each frame of the animated Tripod is a separate and unique drawing, so that the effect of movement is created in this case in an identical method as film animation: a series of static drawings, designed and drafted entirely by the human animator. In the case of your Tripods there is no "in-betweening" besides the static frames you yourself programmed the Vectrex to draw. ... The Vectrex itself is showing us the first drawing for a period of time, then the second drawing for a similar period of time, then the third, etc, with nothing besides your 15 drawings appearing in between.

I'm still unclear though if this is always how it works, or if the other stuff I was talking about applies at all.

Maybe I should refer to the things that are moving on the screen during the game, which we do not refer to as "animated". For example in I,Cyborg when the player is walking forward through the Corridor, the lines that define the walls of the Corridor are moving closer/changing location and size.

If you eliminated all of the vectors appearing on the screen, except for one of the (incomplete) hexagons during this sequence, you would just see the small hexagon off in the distance getting bigger on the screen. ... In Art Master terms, this might be "animated" with only TWO "drawings", even though the lines are clearly drawn (by the machine) in dozens of different positions in between the two at the beginning and end.

So my question is, are animated game sprites ever done this way? In Web Wars, for example, the winged player looks to be two or three "key frames" that morph from one to the next. So the programmer possibly drew one drawing, then mapped each vector in that drawing to move from it's original position, to the desired position for the next drawing. In doing this, the course each vector takes to move from its prior position to the next one IS VISIBLE, as the machine draws each vector in each place (and length) it appears in as it changes from the first key frame to the next key frame.

So if you imagine that potentially it works this way on some occasions, you see maybe it is most convenient that each 'key frame' drawing has the same number of vectors as one another, and that the path that each of those vectors takes in moving from one key frame to the next must be logical, in order for the animation to appear to make sense. In other words, a vector that constitutes the top of the left wing in the first key frame should also constitute the top of the left wing in the second key frame. If the top left wing vector in the first key frame constituted rather the top right wing in the second key frame, you would see it moving across the players body in between these two key frames in the animation, and this would ruin the effect. That's how it works in Art Master and this struck me as possibly something unique to and justified by vector imaging.

Trying to animate this way contrasted sharply with my experience animating drawings for film. The method described for animating Tripods in WOTW recalls the traditional notion of film animation. But the way Art Master works makes me think that maybe it is advantageous sometimes to conceive of it differently. For example maybe it is less work to program morphing key frames. Or maybe it is leaner programming?

[gliptitude]

Mar 18, 2012 17:08:12 GMT -5 celtroniclabs said:

Of course you have audio and sound effects to throw into the mix, and collision detection as well. If your strong point in school was mathematics, algebra and geometry you will grasp all of this much easier than if your background is primarily in the arts. Thinking about all this and trying to program a video game can make your head explode if you're more of a right brain dominant person. I am more of a right brained person, and it is taken me a while, and lots of reading, to figure all this stuff out.

Outstanding answers. Thank you very much for your reply. This what I was looking for. ... Yes I was a LITTLE mathematically advanced in my younger years. Say that I had fairly high aptitude but no ambition basically. Casually taking my SAT one time with no preparation I think I got 690 math (vs 510 verbal) at a time when 1600 was perfect score. Was always on the accelerated track for math classes, but stopped taking them as soon as this became an option. So never took calculus. Studied matrices only briefly. ... Subsequent years of cultural, artistic and literary study have mostly degraded my intuitive notions of quantity though.

You laid it out pretty well I think what I ought to be studying for this endeavor.

[gliptitude]

I guess when I use terms such as "key frame" and "sprite", these are mainly conceptual in this context.

I've previously been advised to design my Vectrex "sprites" before I start trying to communicate with a prospective programmer, meaning I suppose that a game designer might stick with this familiar word for a moving game element, even though that element is not composed of an array of pixels.

"Key frames" or "in-betweens" you should see in my descriptions are not any kind of computing processing function, rather just intuitive ways of conceiving of the plotting process, using familiar terms from film animation. I only mean that each vertice is mapped over a period of time from one most essential position to another. In terms of the overall "animated sprite" that the vectors define, this animation could be thought of as consisting of a series of key images that the vectors collectively constitute, with coordinated movements that the vectors make in-between each of these key images.

[fury]

Art Master and AnimAction are simply programs that were made for kids to get a taste of early computer animation. Nothing more. The methods used in those programs are not the same as those used when actually programming. As a kid, I liked these, but I always felt that AnimAction should have had some kind of save-to-cart feature.

In WOTW I needed it to be a snappy piece of animation in order to recreate the feel of the original arcade game. As far as doing it the other way, it would have taken longer and used up too many resources because there are several different angles of movement occurring in each new image. Figuring out the mathematical changes would have required me to first draw the image and then work out the math. The way I did it cuts out all the math and also saves resources. A game like BattleZone would require the other method.

The corridors in I, Cyborg simply change in size, which provides a form of animation. For scaling you increase or decrease the scale factor that's used when the image is drawn. It's very simple to do. The same is true when you move an entire object on the screen. You increase or decrease the x or y factor that's used when drawing. It's the simplest way to move an entire object. The ship in Zantis is moved this way. Rotation is done the same way. So scaling, rotation, and x/y movements are very simple forms of animation that can use the built-in drawing routines.

My suggestion to you is to Google "Vectrex tutorial" and fully read through both of them. Chris Salomon and Chris Tumber are the authors.

[gliptitude]

Yes I know Art Master/Animaction are toys and I don't expect to learn programming from them. Not sure that makes them irrelevant though. They seem like useful design tools to me. ...I have been reading those two tutorials and it will take me a long time to decipher them.

...At least one of those tutorials has simple sample codes to copy and make the Vectrex draw a line, move it etc.

If I have a vecmulti sd card/cart (i don't), is testing these sample codes on a Vectrex as simple as pasting the text of the code in an assembler program and then exporting a resulting binary file to the cart?

[fury]

Well, I'd say they're useful to visualize vector drawings but I'd hesitate calling them useful tools For me, a pen and paper is the fastest way to visualize an image. If you prefer to use software, download Chris Tumber's V-Model program. It spits out Vectrex-ready vector lists.

For the most part, the sample code should work, but you might have to fiddle with them a bit.

Am I understanding correctly that you're looking to have someone program something for you? If that's the case, send me a private message and I'll let you know what I can do.

[gliptitude]

Mar 19, 2012 14:11:45 GMT -5 fury said:

In WOTW I needed it to be a snappy piece of animation in order to recreate the feel of the original arcade game. As far as doing it the other way, it would have taken longer and used up too many resources because there are several different angles of movement occurring in each new image. Figuring out the mathematical changes would have required me to first draw the image and then work out the math. The way I did it cuts out all the math and also saves resources. A game like BattleZone would require the other method.

Ok, I understand and this is useful to know that this method eliminates a lot of math for the programmer. Do you find that this method is generally the best, and that the other method is more of a special application?