Time for a little update, even though I haven't implemented any of the stuff on my previous todo-list
The repo and the zip file were updated.
One day I realized the simplest thing: why not run cmdgfx with start "" /B
? This starts a separate process in the same window, leaving the batch script to run uninterrupted while the graphics is rendered. It is certainly not without its problems doing things this way, but it does increase FPS radically in many cases.
Here is plasma3.bat:
Not only does this script run at a much higher frame rate than plasma2.bat (which does not use the start /B technique), but it can even load/draw a complex 3d model such as hulk.obj over the plasma and still retain a very high framerate!
So, what are the problems/things to think about with this method?
1. First of all, since start /B runs cmdgfx in the background and returns immediately, you will not be able to get the errorlevel from the program. This means that you cannot check for keys and mouse input this way. There are a few ways to deal with this:
1.1 Right after calling cmdgfx with start /B, call "cmdwiz getch noWait", and get the errorlevel. Remember not to use the k flag in the previous call to cmdgfx
1.2 For even more speed, you can use Aacini's "Getkey.exe /N" instead. Unfortunately it doesn't use the same errorlevel output as cmdwiz, but for "basic" standard keys the codes are the same.
1.3 It is also possible to specify the new flag 'o' in the start /B call to cmdgfx. This will save the errorlevel to a file called EL.dat. You can then get the input in the script using something like: set /p KEY=<EL.dat 2>nul . This is the fastest of all these methods since no extra external program needs to be called, but it is unfortunately not reliable. Several cmdgfx might execute simultaneously and overwrite EL.dat, which means key presses might get lost. If maximum speed is needed and input is not needed at the moment, this can still be used. As an example, "bezier-col-hires-nowait.bat" uses this (you may have to press Escape a few times to quit)
1.4 To get both input AND the possiblity to synch better, a slightly cryptic call to cmdgfx_gdi is needed, see (2).
2. One problem with the start /B method is that things now sometimes runs *too fast*! The old 'W' flag was unfortunately rather useless since it measured only the time from the beginning of starting cmdgfx to the end. I changed this so that the W flag now writes a file called CGXMS.dat with the current tick count on each frame, and the wait value is then re-read on the next frame, which means the entire processing is regarded in the wait, providing a much smoother result. This way we can ensure both smooth animation and that it doesn't run too fast on faster machines.
So, to use this, this is needed (after the start /B call with cmdgfx):
cmdgfx_gdi "" kf0:0,0,0,0W10
This means: "" use no operations, report key (k), don't actually write any output (by specifying a screen with width and height of 0), and wait a MAXIMUM of 10 ms (counting from the last time the tick count was saved to file), and finally write the current tick count to file.
One more thing to note: pretty much all scripts get a higher speed using this "start /B" technique, EXCEPT the ones that need to use the non-gdi version of cmdgfx, because the effect builds the current screen output based on the previous one (like fire.bat and rotate-expr.bat). This seems to be because of my old nemesis Windows API WriteConsoleOutput, which is just soo slow when the output has many colors that the frame rate is not noticeably improved by running cmdgfx concurrently).
Many of the old scripts were updated to run with start /B, some with synching (W), some not. For some comparisons, run 3dmaze.bat then 3dmaze-noWait.bat, or bezier-col-hires.bat compared to bezier-col-hires-noWait.bat. Other new scripts are hulk.bat (spinning quite nicely in 1280x680 resolution), loader.bat, curve.bat, plasma2.bat, plasma3.bat
Final important note: Start /B can be dangerous! Even more so if combining with the /High or /realtime switches. I have managed to freeze my computer using this, forcing a reboot. In general, only use this technique as a final optimization step (if extra speed is needed) when everything else is functioning in the script, not during development.