I think that’s what we want.
However, we just need to add something to pnmwindshieldwiper that let’s us specify the value on the command line instead of changing it in the code.
Once that’s done with can make a makefile variable for it. Then you could just do:
make HEIGHT=73
I’m out of gas.
Tried to understand how to get 2nd argv, but HEIGHT=73 is all one string… trying to get makefile to be interactive and just ask for width and height. Failing miserably tonight.
Something with ‘atoi’ is close as I get.
I was happy doing the changes I did before all this height stuff 
I got the data filename to be input in the config like a prop file, so pov.h doesn’t need to be edited.
More on that later.
Sorry guys, I signed of way before you. It was already 3AM in Germany, when I couldn’t follow any more!
The thing is, with the height variable only in the Makefile, it was already a smaller version of the original. So maybe the 144 in windshield wiper is not as relevant?
I will post the smaller preview image later.
Good job! Looking forward to it
EDIT shouldn’t have tried to get fancy on the syntax.
from pnmwindshieldwiper
int main(int argc, char** argv) {
read_pnm(stdin, &image);
// output.resize(800*10, 144*10);
if (argc !=2) {
output.resize(800*10, 144*10);
} else {
int height = atoi(argv[1]);
output.resize(800*10, height *10);
}
from Makefile
......| ./pnmwindshieldwiper $(HEIGHT)| pnmscale -reduce 10 |.....
Is working. The height is adjusted to the input value. yay!
Well done, good sir!
And now the width too.
So basically you input the image size if it’s smaller than 800x144 if you want it to retain the smaller size and not get scaled up.
At least I think that’s what we’re going for here.
Here are the images created by only adding the height variable to the Makefile.
Source Image
Original (800x144)
72 height version (400x72)
That is why i thought maybe the windshield height is irrelevant? Or maybe this just leads to scaling there.
The *data.h-files are also roughly twice as small, which suggests it might be okay?
Should the user be able to input the width? I mean a 144 height image has a defined width of the 800 which describes the arc of the blade, doesn’t it? When we scale down the height, shouldn’t the width scale accordingly?
I might be understanding something not entirely though.
I’ll be honest and not sure at the moment - it’s alllll blurring together lol.
That said, I have a working set of everything, including the user-interactive script that asks for width and height if the source is smaller than 800x144.
It also checks for number of .pngs in the directory and quits before freaking out if there’s any amount <>1.
It also makes any spaces in the filename into underscores.
Here’s the current stuff:
Just edited it to download the Star Wars logo if no .pngs exist when run .
See, NOW it’s fun again, because things are working 
.
Ahhh…the magic of the 4am hour.
How did you get the 400 width here?
And is the white center coming through? This is the full color data file?
It just worked. This is with my changes to the Makefile only to make the height as a variable. The full color works because it is only 2 colors I guess and the white is visible (picture above somewhere).
I had to update the pov.h file to the height as mentioned before, to stop it from freezing, but other than that I did not think about checking windshieldwiper.cc.
updated pov.h how?
There was the 144 hard coded at the bottom. This is where I put into pov_height = 72 and used it where 144 was before. But only in that file.
My guess is that something goes wrong when during one of the steps it goes out if bounds of the 72.
Well we don’t have to do any of that apparently, and it turns out after ALL that overnight work (educational as it may have been)
NOTHING except the Makefile needs to change for it to scale width AND height.
All that it needs is a HEIGHT variable and it just works 
.
This for example, sets a custom resolution based on height, and adds the base name and new height onto the output filename of whatever png you throw in the folder.
OUTPUT ?= $(wildcard *.png)
HEIGHT ?= 69
ALL: image.h image_pgm.h preview.png
# Full-Color images
image.h: pnmtorle pnmwindshieldwiper *.png
pngtopnm *.png | ./pnmwindshieldwiper | pnmscale -height $(HEIGHT) | ./pnmtorle > $(basename $(OUTPUT))_$(HEIGHT)_FC_POV_data.h
#Single-Color images
image_pgm.h: pgmtorle pnmwindshieldwiper *.png
pngtopnm *.png | ./pnmwindshieldwiper | pnmscale -height $(HEIGHT) | ./pgmtorle > $(basename $(OUTPUT))_$(HEIGHT)_SC_POV_data.h
preview.png: pnmwindshieldwiper *.png
pngtopnm $(basename $(OUTPUT)).png | ./pnmwindshieldwiper | pnmscale -height $(HEIGHT) | pnmtopng > $(basename $(OUTPUT))_$(HEIGHT)_preview.png
pnmtorle: pnmtorle.cc
g++ -O2 pnmtorle.cc -o pnmtorle -g -lm
pgmtorle: pgmtorle.cc
g++ -O2 pgmtorle.cc -o pgmtorle -g -lm
pnmwindshieldwiper: pnmwindshieldwiper.cc
g++ -O2 pnmwindshieldwiper.cc -o pnmwindshieldwiper -g -lm
This is what I was talking about.
oh and @profezzorn is the -g flag really needed for the g++ lines? That’s what’s causing my .dSYM files.
I have yet to figure out why the tool files themselves are having hex versions generated.
Yes. And after much ado figuring out that Pastebin was making tabs into 4 spaces and giving me endless *missing separator errors… That’s what I last tested with on a barebones download of OS6.5 and wrote the post above.
But we still need a variable in the pov.h or at least in the define option you were talking about?
I think we wanted to safe that in the *data.h file for easy access in the pov.h so we wouldn’t need to change that all the time.