ProffieOS v6.3 BETA testing

That’s a problem with the prop, not the display code though.

I’m on it.

2 Likes

All of your most recent fixes are working perfectly. I tried color zoom using on the fly color change, edit mode color list, and edit mode adjust color hue. All work as expected and use the same control. Preon edits are working great. And the dial controls are working much more fluidly now.

1 Like

ProffieOS 6.1 zips are up with all the fixes we’ve made so far.
Still lots of things to test!

5 Likes

This fix is now in 6.1 along with everything above if someone can test in my prop. I also fixed Rotate for Track Player, it was skipping first track when it looped around.

4 Likes

Working on this here:
https://crucible.hubbe.net/t/blaster-make-autofire-count-bullets

1 Like

I’ll try and test tomorrow. Had a bad work week after the live video, and haven’t had a chance to test.

1 Like

This worked, by the way. Thank you! Simply changed COMSCANDEC, to COMSCANINC on line 41 as you suggested and it flipped it just like I needed.
Now, if I can only find my L cable for my Saber, I can help test the other stuff as well.

Still wondering about this.
Sometimes I find the image needs to be the inverse to display correctly, but others are as-is.

Wait. Are you flipping 180 AND mirroring? Which of the pairs to you change?

Maybe we should just have a new #define OLED_MIRRORED
But of course then we’d have 4 orientations:

  1. normal
  2. mirrored
  3. flipped 180
  4. flipped 180 mirrored

The reason for the inversion is BMP. BMP has a color map, and it chooses which color is black and which one is white somewhat arbitrarily. I have some code that tries to deal with this, but it’s commented out because it didn’t seem to work very well.

Oops, my last comment should have said line 841, not 41. And yes, I needed the image to “Un-mirror” I guess? I have a HUD in my scope with the actual OLED image shining up at the reflective but see-through film. So un-fixed, it was upside down and backwards in the HUD. The change made to the code seemed to have fixed that.

A follow up request would be to have the bullet counter disappear after a short pause and then have the recticle animation pop back on the screen, until the trigger gets pulled again. Not part of the beta testing, so no worries.

This is going off topic sorry. But someday we can clarify some of that stuff, maybe in the Wiki.
Like that BMP inversion thing, how pbm animations play once through without looping whereas bmp files loop, etc…

Maybe we could allow an animation to override the set ProffieOS_X_ImageDuration if it’s longer so it completes one full “loop” and not get cut off before it’s done.
I’ll append my to-do list.
Moving on for now.

@MTMiller I submitted an edit for #define OLED_MIRRORED. So with that and the already existing OLED_FLIP_180, any of the 4 orientations listed above can be set.

1 Like

The format is irrelevant.
If you make an image that is N frames high, it will loop.
If you concatenate frames image files, they will not loop.

1 Like

Not sure this is OS6 specific, as it may have existed before, but I’m only finding it now.
Regarding BUTTON_CLIP_DETECT.

Not using Clip in /out this is not noticed.
However, I found that when having a BUTTON_CLIP_DETECT latched, at boot, the first press of Mode Select button registers as having a modifier Left (which is the shared button 32). Then the subsequent presses are not modified. It doesn’t matter if it’s a press, click, held…the first instance of that button always has the mod, then doesn’t from then on.

Really not a huge deal, but it does prevent blaster functions like cycling modes, or any other things using that button from working unless another button is pressed first.

06:05:34.336 -> Welcome to ProffieOS, Brian! Type 'help' for more info.
06:05:38.801 -> EVENT: Down-Pressed#1 mods Left ON millis=8266
06:05:38.801 -> EVENT: Down-Pressed mods Left ON millis=8266
06:05:38.910 -> EVENT: Down-Released#1 mods DownLeft ON millis=8385
06:05:38.910 -> EVENT: Down-Released mods DownLeft ON millis=8385
06:05:38.910 -> EVENT: Down-Shortclick#1 mods Left ON millis=8385
06:05:38.910 -> EVENT: Down-Shortclick mods Left ON millis=8385
06:05:39.295 -> EVENT: Down-SavedShortclick#1 mods Left ON millis=8769
06:05:39.295 -> unit = 0 vol = 0.50, Playing testblaster/full.wav
06:05:39.295 -> channels: 1 rate: 44100 bits: 16
06:05:41.022 -> EVENT: Down-Pressed#1 ON millis=10473
06:05:41.022 -> EVENT: Down-Pressed ON millis=10473
06:05:41.092 -> EVENT: Down-Released#1 ON millis=10571
06:05:41.092 -> EVENT: Down-Released ON millis=10571
06:05:41.092 -> EVENT: Down-Shortclick#1 ON millis=10571
06:05:41.128 -> EVENT: Down-Shortclick ON millis=10571
06:05:41.512 -> EVENT: Down-SavedShortclick#1 ON millis=10974

A workaround is to add a case with the modifier in the prop for all things MODE button, like this:

    case EVENTID(BUTTON_MODE_SELECT, EVENT_FIRST_SAVED_CLICK_SHORT, MODE_ON):
    case EVENTID(BUTTON_MODE_SELECT, EVENT_FIRST_SAVED_CLICK_SHORT, MODE_ON | BUTTON_CLIP_DETECT):

but maybe there’s a root cause? Otherwise, either the workaround, or just press a button once when first booting the blaster?

This is just how the event system works at present.
Held buttons registers as a “mode” until some event claims it by returning true. At that point the mode is cleared, even if the button is still held.

First of all: That might not make much sense for latching buttons, since they are always “held”. However, I can see two ways of changing it:

  1. latching buttons are never added to the “mode” set.
  2. latching buttons are never cleared from the mode set until released.

Not sure which is better.

However, if the prop handles the PRESS/RELEASE or LATCH_ON/LATCH_OFF events for the latching button and returns true for those handlers, then it should never become a mode, and none of the above should matter. This is in fact how the blade detect button works. Now, since the blaster seems to handle these events, I suspect that the problem lies in the SaberBlasterProp. Basically, the blade detect takes a few milliseconds to register, and the LATCH_ON event happens before that. The SaberBlasterProp probably needs special code for the CLIP_DETECT button. Most likely, the easiest solution is to always send those events to the blaster code.

The twist scrolling is much smoother now Fernando, in the menus. Less flip glitches, lots smoother. Trying to test more stuff tonight at work. I’m working from 8PM to 4AM, its a boring assignment, so I’ll have my saber with me to pass the time.

3 Likes

Thanks for that reply.

I tested 2 and 5 fairly extensively tonight, and had no issues. I need to re-flash for one button to test one button features. I’ll try today after I get out of work and take a nap. PS, no zoom sound.
17 hour shift…

Thanks, I’ll take a peek at the sound.