Pure Batch Colored Bouncing ball animation

[jeb]

Dave, I have use the code above, (select all and copied to a new file named BALLS.BAT), and have tried it with both of the exact option sets you provided too, neither of them displays animations as above!

Here's the output from the first of your examples

I'm using Win7, to get it working I open it in a git bash or cygwin window.
These windows supports the vt100 escape sequences, the only problem for me, was that the "cls" command doesn't work in cygwin.
But this can be solved by using the "Clear Screen" "\e[2J" escape sequence instead of cls.

Code: Select all

<nul set /p "=!esc![2J!screen!"

In cygwin, I'm not able to stop the cmd process itself, I have to kill it with the task manager

[IcarusLives]

What you are asking absolutely makes sense - in fact, I was working on an alternate plotting strategy that can support your idea. However, bouncing off properly can be a bit tricky, because you have to figure out if you are changing X direction, Y direction, or both. And if both objects are moving, then it wont be very realistic if one object moves its full frame distance, and then the other bounces off that end location. In reality both objects should probably meet somewhere in the middle. For any type of realism, you also need to worry about angle of deflection and momentum transfer.

Yes I've considered this issue myself, but currently have no work around.. I'm new/extremely interested in pure batch animation... Idk why I love it so much. Nerorobin is one member here who I look up to a lot for this reason.

So the idea is to plot more like I did with SNAKE.BAT, where you have an array of strings with fixed length that represents the pixels of a horizontal line. The array index represents the Y position, and the position within the string represents the X position. Plotting a pixel (or contiguous horizontal line of pixels) involves replacing pixels in the middle of the line with the new pixel values.

SNAKE is monochrome, so it simply uses one character for each pixel.

This makes perfect sense. I truly didn't consider having !screen! as an array, because I figured the old "1 variable is the entire display" would be the fastest method. But it seems Jeb has something neat ahead!

But we want color, so each pixel is represented by Esc[{ColorValue}m{Pixel}, where {ColorValue} is one or more semicolon delimited numbers, depending on whether we are using 4, 8, or 24 bit color, and {Pixel} is the character used for that pixel. The important thing is each {ColorValue} must have a constant width. Thankfully, the VT100 escape sequence engine treats 009 the same as 9. So each number in the {ColorValue} must be left zero padded to a constant width (either width 2 or 3, depending on your color palette).

It is easy to modify the plot routine to use substring operations to set pixels in the middle of the string.

I didn't realize VT100 engine read numbers that way. I am trying to understand what you mean by this. Do you mean that 009 represents 0;0;9? But for the sake of the delimited ; we can store the value as 009? I apologize for my lack of intuition..

At the start of the program, CLS is followed by ESC7 to establish the home (top left corner) of the screen.

Jeb has an excellent solution!

But this can be solved by using the "Clear Screen" "\e[2J" escape sequence instead of cls.

Code: Select all

<nul set /p "=!esc![2J!screen!"

[dbenham]

... Thankfully, the VT100 escape sequence engine treats 009 the same as 9. So each number in the {ColorValue} must be left zero padded to a constant width (either width 2 or 3, depending on your color palette).

I didn't realize VT100 engine read numbers that way. I am trying to understand what you mean by this. Do you mean that 009 represents 0;0;9? But for the sake of the delimited ; we can store the value as 009? I apologize for my lack of intuition..

No, I was worried that 009 might be interpreted as octal, similar to the SET /A command. But it is interpreted as a normal base 10 number. This is important, because it enables constant width numbers for values from 0 to 256. If the color values are not constant, then the PLOT macro has no way to tell where a pixel begins and ends.


Dave Benham

[IcarusLives]

... Thankfully, the VT100 escape sequence engine treats 009 the same as 9. So each number in the {ColorValue} must be left zero padded to a constant width (either width 2 or 3, depending on your color palette).

I didn't realize VT100 engine read numbers that way. I am trying to understand what you mean by this. Do you mean that 009 represents 0;0;9? But for the sake of the delimited ; we can store the value as 009? I apologize for my lack of intuition..

No, I was worried that 009 might be interpreted as octal, similar to the SET /A command. But it is interpreted as a normal base 10 number. This is important, because it enables constant width numbers for values from 0 to 256. If the color values are not constant, then the PLOT macro has no way to tell where a pixel begins and ends.


Dave Benham

Oh okay I think I understand now.

So plotting in color would be for example...

Code: Select all

009;004;021m

and this is because if the padded 0s are there, we can easily find the x and y because of how much space will be in between??

[dbenham]

Yep, with Esc[38;2; tacked on in front to signal 24 bit foreground color (it would be a very dark color)