The point of a makefile is to re-do only the things that needs to be re-done.
Not that it matters much when out computers can churn out hundreds of these per second, but still. If you’re not going to use it as a makefile, then why use a makefile at all? If you don’t care about the makefileness, then use a script.
In fact, I recommend that you just take the commands from the makefile and copy them into the script. That way we won’t need to contort the makefile into something weird. Instead, the makefile can be the makefile and the script can be the script.
PS: I think you’re over-complicating the script.
The point is for it to be simple, not idiot-proof.
Not all 3 are the same unit:
Height = Pixel amount of the blade
Length = cm or inch of the blade, so different unit for the same thing in Height
Offset = cm or inch of hilt+arm, so basically from the bottom of the blade to the center point / fulcrum of your circle that you swing (e.g. elbow to emitter).
I think it was a misunderstanding we had very early that length was hilt and offset was arm.
The user has to be aware of what each value means. Readme?
400 sounds reasonable. 264 KRs are the V1 strips right? We could argue that it would be okay to let the image scale up there, but I get it, it is no easy task to find limitations.
Minimum height must be able to draw a picture. Not sure what image we can do with a 10pixel blade. Maybe a stubby is not so Bad.
Anyways the user should be made aware of the area of values he may input.
Again I believe this is rooted in our early misunderstanding that Height = Blade, Length = Hilt, Offset = Arm, when in fact
HEIGHT is BLADE size in pixels.
LENGTH is BLADE size in cm/inch
OFFSET is bottom of the blade to your joint that does the swinging (the rest of the radius of the circle that is not the blade)
Of course you might argue you can use the defaults of 36"blade and 18" to your elbow. But what it does it assumes you are placing the 72 pixels then into a 36" blade and that you will always swing around a point that is 18" away from the bottom of the blade.
Not all people swing the same (wrist, elbow, shoulder), have the same blade length or arm size.
What the other values do is enabling you to swing naturally to achieve the image and not guessing how to swing to generate it.
That does not necessarily mean a height only is bad, it speeds things up for sure and enables one to manipulate those base values when the user found his sweet spot.
That would be convenient to calculate the default based on the previous input of pixel height.
If it can be both, wouldn’t that save questions later? “Why was my image so bad”.
Could you add a script, that would do the renaming afterwards? So the makefile stays the consistent? In my opinion I like that it creates this and makes it handy to use, but I am new to Make files and am not sure what best practices there are.
I believe that is not so weird.
I tried to put 30px into a 10(cm) blade which is in turn only 1/11th of a circle.
Those inputs where far from reality, so the image is the same. Not sure though if sarcasm or not
I was trying different extremes of inputs.
Imagine what I can do with 999, 1, 99 (well this would probably be a blue line)
Thank you.
Yeah, I’d rather not run a separate script manually to rename, but I suppose I can figure how to have this one wait until Makefile jobs finish, then do renaming/moving. Feels like more work than needed though? Works like this currently, is that bad?
Is leaving Makefile alone the goal now? If there’s different end-goals as far as data file placement and naming etc… let’s unify, and be all on the same page.
I was thinking this project:
a. improves usability, and yields better results.
b. data files direct to /styles folder makes sense.
c. Naming files with info is not a bad thing.
d. it’s working well in my testing.
So please let me know if anything’s in the wrong direction here, and feel free to grab the reins if I’m off track. @profezzorn what exactly is the preference for Makefile. Can’t be edited as such above? It seems like a clean workflow.
i like the more fluid workflow (r, registering input without enter for choosing an option)
custom options
How many pixels are in your blade? (min 5, ENTER for default 144) 04
! Minimum length is 5, try again
How many pixels are in your blade? (min 5, ENTER for default 144) 400
Are you sure there's that many pixels?? (y/n)
How many pixels are in your blade? (min 5, ENTER for default 144) 133
How long is your blade? (min 5, ENTER for default ($ calc_len goes here)
How long is your arm?
I would change alert message for question 1 to
“! Minimum amount of pixels is X, try again”
personally I would recommend doing X = 30, but open to debate
okay, now I know why, you didn’t write that code yet.
Math should be round($height * 100 / 144) → length in cm. if you further devide by 2.54 (before rounding) you have your inches. But rounding to the next full inch is more of a delta than rounding to the next cm, so we would be more exact to use the metric system.
Cool, updated the minimum message and added calc_len math.
Default should be calculated for How long is your blade? (min 5, ENTER for default $calc_len)
Updated the file in the dropbox, you can test your math
But I thought unit type doesn’t matter, so what is length in terms of then? Because it’s inches right now.
It doesn’t matter as far as you use the same for length and offset.
Still for calculating purposes where you want to calculate pixel per unit with round, the smaller base unit should be more precise.
Think for example you can put 1pixel per cm. That means you can round to translate that really well even with round.
Now you can put 2.5 pixels per inch. But because we don’t have half pixels you would have only options for 3 5 8 10 13 15 and so on.
Making something idiot-proof means putting in a bunch of extra limits that you, I and most people will have no use for. Sure, it may save some people from shooting themselves in the foot, but it may also prevent someone from doing something they actually want to do, and it can be very difficult to know how people will want to use your script in advance.
IMHO, providing reasonable defaults is super-helpful. But preventing people from putting in bad values is simply more work than it’s worth, and may end up preventing real use cases.
Obvoiusly all this depends on how much extra work it is to make something idiot-proof. If it’s really easy, then go for it. But if it takes a bunch of extra work, then I wouldn’t do it, and if it takes a LOT of extra work, then I may even ask you to take it out in the PR review, because I’m going to be responsible for maintaining it.
That’s just a matter of adding an mv command after the “make” invocation in your script.
It doesn’t need to be a separate script, just some commands after the make invocation.
make doesn’t exit until everything is done (or fails)
No. There are simply two options:
Use the makefile, but make sure that the makefile can be used on it’s own and follow all the rules of making makefiles.
don’t use the makefile.
As I’ve stated on numerous occasions: It’s not enough for the code to work, it must also make sense. Writing a makefile rule that creates a file other than a rule would be like having a meatball recipe that makes pound cake; it doesn’t make sense.
In collaboration with @NoSloppy I added the code for calc_len.
I also added a question about inch or cm, which has an effect on the calc_len and default offset.
Added a little bit of visibility to what choices were made. I also saw that the updated text for pixels (min 30) was not the same as in the code and the initial question for it, so I updated that too.
On the QA note:
I found a bug, when there was a preview Image present, the list contained the main image name twice. Deleting works like a charm.
Something in the updated code of the other files stopped make from finishing.
When the calculated default is below the minimum value, “ENTER” still counts as valid input.
Removed ./ path when listing “too many .png files”.
Used measurement unit for the subsequent question. (How many inches is the blade)
All the file moving/renaming happens within the script. This allowed for some useful printouts in the end. “File’s done! Find it here:” sort of thing.
Max blade length check added, based on measurement unit.
While cool, removed keypress-only-does-enter for consistency (values need Enter)
OK, Now… in light of this wisdom:
trying to prevent minimums and too short lengths etc… has reached the “Too much work” point. I vote we SIMPLIFY, remove all the minimums.
The top section getting the source file is good.
Leaving checks for >3 digits values is fine, and max blade lengths, but we should let the script do it’s purpose and done.
If a bad value is entered and the image comes out wonky, that’ll be the indicator something was done wrong.
More so the reason I feel the Height Only calculation is enough, but I digress.
Adding this is the straw breaking the camel’s back. It would require moving the math to earlier in the height input section, pre-calculating if it’s going to be too low, for BOTH cases, making the user re-enter and explaining why… just too much. See my SIMPLIFY above.
Are you sure?
If there’s only 1 .png file and the name contains preview,
it says “Source file name can not contain ‘preview’.”
If the original and preview are both in there, then you get
“OOPS! Too many .png image files found!”
and it lists all files matching *.png. There are no repeats.
Please beat this up and see if anything doesn’t work. I think I got everything:
You guys have put in so much time and effort in making this work and for that I thank you.
But… I am curious.
Could we use this to create a looped animation?
Not sure if this would be possible but could be essentially a series of png’s that would display after every swing back and forth giving the illusion of a moving picture.
Currently, I don’t think so.
It translates one image into a windshieldwiper style warped version (put it on a 90° part of a circle) of itself and translates that into coordinates and color info.
As far as I witnessed, it is only possible to have one such a file.
The issue I see is, how would you be able to see that.
If I swing the blade once, my eye can’t see the image I just created. Only a long exposure image with a camera makes it actually visible. Someone also said video, but I haven’t tried this.
Also it is important to note, that the way you are holding the saber is important to achieve the correct image (my guess so the coordinates/color info thingy is in the correct order) for me that is that the flat side of the soundboard with the usb on it is facing towards myself.
So my guess is, that it could be hard to achieve repeatedly.
Would be a cool idea though, but way out of my league
There are several problems to overcome in order to make animations this way.
speed. Currently it takes a 1-5 seconds to do a single image. With faster LEDs, this could be speeded up a lot, but even if you could get it fast enough, waving the saber back and forth 10 times per second just isn’t possible for a human.
storage. The current method stores everything in flash. It’s already difficult to fit one image into the flash memory. We could make something that loads POV data from disk, but it’s not clear how much the extra time (~0.5ms per angle) would affect the result.
Position. Even if we solved both of the above problems, making sure that the picture shows up in the same place as the previous picture is nearly impossible unless you mount your lightsaber to something stable. So unless you’re general grevious, I just don’t think it’s possible.
i understand that it was pushing the limits a bit but wanted to know if it was possible. (the idea that was in my head was cool though)
you are right though as waving the lightsaber at that speed would probably cause an accident or injury or worse! (break the lightsaber)
Hi @profezzorn,
I tried to use an 8bit image for the first time and got an compiling error:
F:\Saber\Software\ProffieOS5.9\ProffieOS\styles\pov.h:127:13: error: #if with no expression
127 | #if POV_8BIT
| ^
exit status 1
Had a look and changed it to #ifdef POV_8BIT which worked.
But the blade froze with that particular image again.
Has lots of colors and the RGB image.h has 1500 lines, 8bit has 850 lines.
Any ideas, if that is too much to handle?
Question, when we use 144px per meter for our default calculations, should the default Height not better be 133 instead of 144, or the default length 39 instead of 36 inches?
