GForce calls still images (jpgs) and motion video (.mov and .avi formats) Sprites, and I’ve applied jaypro’s technique to both formats.
Jaypro’s Technique
The technique involves embedding a special .txt config. file in the Sprite Folder and attaching it to the jpg or .mov file by giving it the same name...i.e. almost the same name. I call this special config file a Sprite-.txt. I then embellish the sprites’ movements by adding various blending/masking effects that are invoked with different Flag commands. (As jaypro has pointed out, the original Sprite-txt file is part of the GForce package and is titled Moon.txt)
Basically, this sprite movement technique involves using two files with the same name at the same time. The only difference in the file names is their extension, i.e. jpg/mov/avi for the Sprite and txt for the config file. Both files are loaded into the same folder, the Sprite folder. Both files are activated at the same time by calling only the name of the Sprite file. (The extension of the file’s name is not included when calling the Sprite via scripting commands or the Tool Bar.)
Jaypro describes another technique for making sprites move which involves adding the mag(s) function to the Pen command in the Default.txt file. I’ve got an example of this technique which I’ll contribute at a later time.
The Curious Hiccup
In jerhom’s post of September 24, he mentions a “pause” phenomenon during the loading of jpgs. I couldn’t duplicate this “pause” event with jpgs, but I did find a very obvious “hiccup” at the invocation of the first –and only the first – video file. The hiccup is consistent, and its duration varies with each playing of the file. Yes, the” hiccup” is usually more drastic if the first video file is an .avi file rather than a .mov file, which is understandable, but it is always present even with the smaller file. A slight “hiccup” can be seen with the invocation of the first .avi file in the full-length, 8 minute rendering, even though it is preceded by several .mov files.
Please note I’m being very picky here. Most casual observers wouldn’t notice the problem. They’d be too impressed with the performance of GForce.
I am guessing that the cause of the “hiccup” and jerhom’s “pause” are related… something to do with the cache settings. If anyone has any suggestions, I’ll be happy to give them a try and report back. There is also the possibility of a particular .mov codec not being to GForce’s liking. I recall doing some experiments in this regard and finding that GForce does have a preference for a particular codec, but the “hiccup” still occurs if all files are in the .avi format, and it occurs with the invocation of the first .avi file.
My workaround for the “hiccup” phenomenon is to run a short .mov file with the screen blank and black at the very beginning of the script. In this recording I do not use this workaround to demonstrate the phenomenon.
In the full-length, 8 minute rendering, I’ve superimposed a CPU and RAM meter over the screen to see if any clues can be noticed to account for the “hiccup.” The meters show a slight bump in CPU usage with the invocation of the first .mov file, but nothing drastic. When the screen recording program (Camtasia) is not running, i.e. in GForce play mode only, the CPU meter hovers in the low, single digit number (3-5%). When the first video file appears, it will jump to 10-12%, and then return to the lower single digits.
When the recording software is also engaged, the Camtasia recording program pushes the CPU usage into the upper 20’s and lower 30’s. Naturally, CPU usage also increases when the GForce frame rate is moved to the mid-point on the Tool Bar. The “hiccup” is still present and obvious without the simultaneous running of the recording program and with the Tool Bar frame rate set to its lowest value.
What You See Is Not What You Get
The visual effects from GForce are so smooth I didn’t want to post something that wasn’t true to this product’s potential or might somehow detract from the brilliance of its producers. So I want to emphasize that in these renderings, there is an artifact introduced by the recording process itself.
You will notice an “unevenness” or jerkiness to the flow of the WaveShape and its interaction with the FlowField, which is consistent throughout each rendering. This “unevenness” is very obvious if you’ve first seen the GForce playback on your monitor, and it’s likely obvious to those of us familiar with GForce’s smooth operation. I’ve tested this problem and found it to be created by the process of using the screen recording program, e.g. Camtasia. Even though Camtasia is recording in .avi format, which is running at 30 frames per second, there is “unevenness” caused by the recording process itself. In other words, the WaveShapes/FlowFields look much smoother when simply observed on your monitor… even while Camtasia is engaged. It is only after the recording, during playback of the recorded event that the “jerkiness” or “unevenness” is observed. I even went so far as to connect an external format converter and record the output of the computer directly onto DV video tape. The “unevenness” and “jerkiness” disappears when external recording equipment is used. I’ve also varied the frame rate using the GForce ToolBar to see if this has any affect. Each rendering linked at the end of this post has a different frame rate, and yet the same “unevenness” or “jerkiness” appears in all.
There are two versions of the full-length, 8 minute renderings linked below. One file is in .avi format, and it is huge, as uncompressed video tends to be. The second version is in .mov format, and it is still large. I then edited the full-length, 8 minute video into short, .mov segments for easier viewing. I used the H.264 codec for the .mov conversion, which runs at 29 frames per second, to try to minimize any additional “unevenness” caused by the conversion process itself. When I tried to use a .mov codec with 15 frames per second, which makes for a much smaller file, the jerkiness was just too pronounced for a posting on this forum. If you have a fast internet connection, I recommend the full-length versions. Sorry for the large files I’m posting here.
A quick note: In the full-length, 8 minute version which shows the script running alongside the GForce screen ( a frame from which appears above and the rendering of which appears at the end of this post), I am having to advance the script with mouse clicks, which accounts for the “jerkiness” on the script side of the frame. This is not the “jerkiness” and “unevenness” to which I have been referring.
Here are the parameters of the experiment:
A. The GForce screen size is fixed at 504 x 336. This aspect ratio is a derivative of the 640 (720) x 480 DV NTSC standard. I kept the GForce screen small to reduce the size of the video files.
I’m using an Intel® Core™ 2 Quad Processor Q8200, 2.33GHz, 4MB L2 cache, an Intel® DQ45CB Motherboard with Q45 Chipset, 4GB DDR2 800MHz RAM (2.96 Usable ) and a SATA Hard Drive. This is far from the state of the art, but for purposes of this experiment, it suffices.
B. I’m still using GForce Platinum, ver 3.92. I have upgraded to version 4 but have yet to install it. I will compare the results of the same test on the newer platform later. The techniques being demonstrated would be the same for both versions.
C. I use only one FlowField, which helps focus on the movement of the Sprite. I chose jerhom’s Vortex FlowField (without the rnd commands) because it so nicely breaks up the screen area and disposes of the “trails” rather quickly. Keeping the “trails” generated by FlowFields off the moving Sprite exposes the movement on the screen and enhances the effect.
D. The test uses only one WaveShape that stimulates the entire 504 x 336 screen area. I made a slight modification to Andy Cabrera’s Spin Doctor because it provided stimulation of the entire screen area in short, controllable cycles. I used no sound stimulation techniques (mag/fft/BASS) in any of the config files because it is easier to observe and understand the results without this additional element.
E. Only one ColorMap (Yellow Border) was used to demonstrate the influence of Pen values and the results of different Flag masking/blending values.
A quick note about these Flag values: The Default.txt file, at least in my version 3.92, lists one of the Flag values as “ThesholdCopy”, rather than “ThresholdCopy.” I assume this is just a typo.
F. A script was produced to control the timing and variations of all the elements. A copy of the script can be seen in one of the full-length, 8 minute renderings at the end of this post. All random formulas in the WaveShape, FlowField and Sprite-txt files were removed to ensure repeatability.
G. An EPen value of .9 was used in the Default.txt file. A Flag value of 12 was used in the Default.txt file because it does not impose any “masking/blending” effects on the Sprites. I used script commands to impose the different “masking/blending” effects.
H. The same image is used as a source for all files, i.e. both the jpg files and the .mov files come from the same jpg image of a dark brown horse on a white background.
Most of the images were “inverted” using the “~” technique.
What To Look For
You’ll be able to follow the sequence of events in the full-length, 8 minute versions because each file name is superimposed over the image using the GForce StartTextOverlay command. Here’s a list of the events and links to each edited segment in case you want to examine just a particular effect in the full-length renderings:
0:05 First Titles
Screen=504 x 336, WS=Spin Doctor, FF=vortex1-3, CM=Yellow Border, EPen=.9, (Default.txt) Flag=12",
Segments 1 and 2
The first two segments use a jpg file file titled “horse2.jpg”. This file matches the aspect ratio of the GForce screen, i.e. both are 504 x 336, which means there’s no way to make this .jpg image move using the Sprite-txt technique. However, it is possible to get some movement using jaypro’s Pen/mag(s) technique, but an example of this alternate technique is not included here. I’ll post an example of my best effort with this alternate technique later.
0:20 Still Image – Jpg -- horse3.jpg, Selective Blend, Image=504 x 336
http://www.bnh.net/gforce/spritetest7a.mov
0:35 Still Image – jpg -- horse3~.jpg, Alpha Mask, Image=504 x 336 (Inverted)
http://www.bnh.net/gforce/spritetest7b.mov
Segments 3 thru 8.
After two Flag blending/masking variations of the first jpg file, a .mov file (horse1-6) is cycled through different Flag variations. The aspect ratio of this .mov file is 504 x 336, the same as the screen.
The .mov file (horse1-6) shows a “bucking horse” traveling from right to left. In other words, the .mov file already contains the moving image of the horse. There is no Sprite-txt attached to this .mov file. All movement of the horse is the result of the .mov file. However, the interesting effects added by various blending/masking Flags enhance the movement.
The “hiccup”
The first appearance of the .mov file (horse1-6) occurs around 1:00 and demonstrates the “hiccup” mentioned earlier. The “hiccup” always happens at the first introduction of a video file. However, the extent of the “hiccup” varies almost every time I run the program. Sometimes it will be very obvious, and at other times, you will hardly notice it.
The “hiccup”, which is basically a freeze in the action, will not be as apparent in these renderings as in the original playback, for reasons cited earlier.
And the mystery deepens. Even though several .mov files may follow in the course of the script, it is the appearance of the first .mov file that generates the most obvious pause. Subsequent .mov files show no signs of the “hiccup.”
In fact, there will be no more “hiccups” until the last use of the “horse1-6” file. This last file is passed through GForce in the .avi format, which is much larger than a .mov file. I’ve run this script many times and the extent of this second “hiccup” varies, but it always precedes the invocation of the first .avi file.
1:00 Video File, .mov The Hiccup -- horse1-6.mov, Selective Blend, Image=504 x 336 (Inverted)
http://www.bnh.net/gforce/spritetest7c.mov
1:30 Video File – built-in movement -- horse1-6~.mov, Additive Blend, Image=504 x 336 (Inverted)
http://www.bnh.net/gforce/spritetest7d.mov
2:00 Video File – built-in movement -- horse1-6~.mov, Alpha Blend, Image=504 x 336 (Inverted)
http://www.bnh.net/gforce/spritetest7e.mov
2:30 Video File – built-in movement -- horse1-6~.mov, Alpha Mask, Image=504 X 336 (Inverted)
http://www.bnh.net/gforce/spritetest7f.mov
3:00 Video File – built-in movement -- horse1-6~.mov, Threshold Copy, Image=504 x 336 (Inverted)
http://www.bnh.net/gforce/spritetest7g.mov
3:30 Video file, .avi Slight hiccup – built-in movement -- horse1-6~.avi, Alpha Mask, Image=504 x 336 (Inverted)
http://www.bnh.net/gforce/spritetest7h.mov
Segments 8 thru 12 -- Using the Sprite-Txt
A new .mov file, titled “horse1-7,” with an aspect ratio of 304 x 204, follows the exhaustion of the ”horse1-6” file. The “horse1-7.mov” file is smaller than the GForce screen, which remains at 504 x 336.
This .mov file (horse1-7) shows the horse zooming in and out. There is no lateral movement of the horse image built into this second .mov file.
However, there is a Sprite-txt. file attached to this second .mov file, and this Sprite-txt file causes the image of the zooming horse to move from left to right across the screen. In other words, the image of the horse zooms in and out while moving from left to right at the same time. The left-to-right movement is caused by the Sprite-txt file.
4:00 Video file – built-in movement Plus Sprite Txt) -- horse1-7~.mov, Selective Blend, Image = 304 x 204 (Inverted), With Sprite Txt
http://www.bnh.net/gforce/spritetest7i.mov
4:30 Video file – built-in movement Plus Sprite Txt ) -- horse1-7~.mov, Additive Blend, Image=304 x 204(Inverted), With Sprite Txt
http://www.bnh.net/gforce/spritetest7j.mov
5:00 Video file – built-in movement Plus Sprite Txt -- horse1-7~.mov, Alpha Blend, Image=304 x 204 (Inverted), With Sprite Txt
http://www.bnh.net/gforce/spritetest7k.mov
5:30 Video file – built-in movement Plus Sprite Txt -- horse1-7.mov, Alpha Mask, Image=304 x 204, With Sprite Txt
http://www.bnh.net/gforce/spritetest7l.mov
6:00 Video file – built-in movement Plus Sprite Txt -- horse1-7~.mov, Threshold Copy, Image=304 x 204 (Inverted), With Sprite Txt
http://www.bnh.net/gforce/spritetest7m.mov
6:30 Video file – built-in movement Plus Sprite Txt horse1-7~.avi, Alpha Mask, Image=304 x 204 (Inverted), With Sprite Txt
http://www.bnh.net/gforce/spritetest7n.mov
Segments 13 thru 15.
Finally, another .jpg file.
Unlike the first .jpg file, "horse3.jpg" is smaller than the GForce screen. The horse3.jpg file is only 304 x 204 and uses an embedded Sprite-txt file to achieve movement from left to right across the GForce screen. This is the technique which jaypro described in several earlier posts.
7:00 Still Image – jpg, Plus Sprite Txt -- horse2.jpg, Alpha Blend, Image=304x204, With Sprite Txt
http://www.bnh.net/gforce/spritetest7o.mov
7:30 Still Image – jpg, Plus Sprite Txt -- horse2.jpg, Threshold Copy, Image=304 x 204, With Sprite Txt
http://www.bnh.net/gforce/spritetest7p.mov
Notes On Scripting
1. In the script, the superimposed titles –via the StartTextOverlay () command -- occur at the same time as the StartSprite() command. I wanted to see if both of these elements remain in sync throughout the script.
An automatic fade-in/fade-out of approximately 2 seconds is applied to all Sprites, and this timing, to my knowledge, cannot be altered in the StartSprite() command. The duration of the Sprite can be controlled via the StartSprite() command when writing a script, but, to my knowledge, there’s no control of the fade in/fade out values using a script. This is not true for superimposed text. I matched the sprite’s 2-second fade-in/fade-out value in the StartTextOverlay() command, but you will observe noticeable differences in the appearance of the text verses the image. This lag can be easily adjusted in the writing of the script, but for the sake of the test I wanted to keep the evocation of the commands simultaneous.
2. To make sure the sprites were not overlapping, I inserted a KillRunningSprites() command after each sprite call. In other words, if a sprite was called at 0:00 to run for 20 seconds, I added a KillRunningSprites() command at 0:21 to make sure the sprite would not overlap the following sprite, which was scheduled to start at 0:25. Using the KillRunningSprites() command produced a few sudden “pop offs” rather than a smooth fade outs, but they are barely noticeable. I added the KillRunningSprites() command because I had a feeling that if a sprite was delayed -- in keeping with the “hiccup” -- once it appeared it would continue to run for its prescribed duration even though it may be late in starting/appearing. The same would not be true for the superimposed titles.
The full-length, 8 minute Making Sprites Move files can be seen at:
--------------------------------------------------
504 x 336 GForce output using screen capture. CPU and RAM meters included.
AVI Format -- Large file for download only. Best quality.
http://www.bnh.net/gforce/spritetest7.avi
Mov Format , Quick Time – compressed format at 29 frames per second. Less quality.
http://www.bnh.net/gforce/spritetest7.mov
---------------------------------------------------
Screen size is 968 x 336. Shows script running alongside of the GForce screen.
AVI Format -- Large file for download only. Best quality.
http://www.bnh.net/gforce/spritetest1.avi
Mov Format, Quick Time – compressed format at 29 frames per second. Less quality. Includes a side-by-side view of the script commands.
http://www.bnh.net/gforce/spritetest1.mov
---------------------------------------------------
.
