What is the difference between ... (a few things)

ProffieOS
1

I apologize in advance because I feel this is going to be a long one. @profezzorn , if you only feel like replying to one a day (or even less/more days), it’s fine. I am not going anywhere and I would like to learn so I can create (hopefully) some fun prop files.

I have a few “What is the difference” questions:

  1. The first one is about error reporting.
    I assume these all send some “text” to the serial monitor? Do some send errors to OLED?
    I also assume that ln is for “line new” or “next line” but what is the difference between print("some_text\n") & println("some_text"), I am thinking flash memory usage ? Or when do I choose one over the other ?
    I believe that some of them will only show/hide the “text” depending on wether #define DISABLE_DIAGNOSTIC_COMMANDS and/or #define ENABLE_DEBUG is defined or not, but which one for which define ?
Serial.println("Dual Push Detected");
PVLOG_NORMAL.print("Maximum Volume \n");
PVLOG_NORMAL << "** Entering ProffieOS Menu System\n";
PVLOG_DEBUG << "** STOPPING timer.\n";
PVLOG_VERBOSE << "The Force will be with you...always.\n";
PVLOG_STATUS << "Blade Detected\n";
STDOUT << "Turning off " << location << "\n";
STDOUT.print("Minimum Volume \n");
STDOUT.println(battery_monitor.battery_percent())
STDERR << "Unknown variable source: " << variable_source << "\n";

Are there other error reporting ways that I should/could know about?

  1. Some error messages in @NoSloppy 's props start with "**", "***", "****", "*****" Do the different multiple of “*” mean something ?

That is it for errors reporting, but the following have been brewing in my mind for some time.

  1. What is the difference between these:
hybrid_font.PlayPolyphonic(&SFX_sound_name);
hybrid_font.PlayPolyphonic(SFX_sound_name);
//but no "&" before SFX, I can't find where I saw it anymore, but I know it was in official ProffieOS files, or did I dream it? What is "&" for ?
hybrid_font.PlayCommon(&SFX_sound_name); // this one I only noticed today as I was writing 1) above.

  1. Event & Event2 most props have all of the “action” happening in Event2. I only found 2 that have something in Event (SaberBlasterProp from dual_prop.h & micom.h - of course multi_prop.h as well, since it was based on SaberBlasterProp). I was under the impression that the bulk of the “action” would be under Event, Event2 would be for the “exception”, I guess it is just the opposite?

  2. Last one is about effect location. I understand that location is whether or not the effect will show on the blade(s), but what are the different values that location can have and what does those values mean ?

As always, thank you for reading so far & thank you for you time and dedication.

2
    • None of these print anything to the OLED. Only calls in common/error.h do that.
    • Generally speaking print / println the Arduino api for printing things, it’s well supported in all arduino code, but usually requires many lines of code to print something.
    • println() is just print, with an newline printed afterwards. The actual effect of print(“foo\n”) and println(“foo”) is the same. println(“foo”) saves one byte. For non-constant strings, picking the right one makes the code shorter.
    • SOME_OUTPUT << THING_YOU_WANT_TO_PRINT << “\n” is ProffieOS style, and it’s also similar to how you normally print things in C++ (Although it’s not based on cout, so it’s not exactly the same.) Using << this way generally ends up calling print eventually, the only advantage is that it’s simple to put multiple things to print on one line, like: PVLOG_NORMAL << "Milliseconds: " << millis_ << " some_variable=" << some_variable << "\n";
    • PVLOG_STATUS/NORMAL/DEBUG/VERBOSE correspond to different debug levels. You can use PVLOG_DEBUG_LEVEL to control how much information proffieOS will print out. You can also change this define for some section of the code if you want to debug that code more. ENABLE_DEBUG and DISABLE_DIAGNOSTIC_COMMANDS have no effect on PVLOG_DEBUG_LEVEL. The default debug level is 300. You can see the actual limits here: ProffieOS/common/stdout.h at ed595f7a419388277e54eea942d78c9c424e58c9 · profezzorn/ProffieOS · GitHub
    • If you use ENABLE_SERIAL, it will get output that used STDOUT, but not anything that uses STDERR. STDERR are meant for async messages, STDOUT is meant for messages which are in respons to a command.

  2. no

  3. hybrid_font.PlayPolyphonic(SFX_sound_name); This is not valid code. PlayCommon is used for sounds that share a filename in monophonic and polyphonic fonts. PlayCommon will decide how to play it based on whether the rest of the font seems to be monophonic or polyphonic.

  4. Event is meant for sound. Event2 is meant for other actions. By making sure that the sound is started before the action, the action can use the length of the sound to determine what kind of effect to play, and for how long.

  5. The intent was to have some piece of code determine the location where the event happened. Particularly for a clash this would be where on the blade the clash occurred. (0=at the hilt, 1=tip of blade) However, this has never come to fruition, and since most people use “reactive” effects nowadays which ignores the location, it is not likely to ever happen. In OS8 location was extended to specify which blade something happened on, which turns out to be more useful. (If you have more than one actual blade.) In particular, it allows you to turn on and off blades individually, as seen in Phantom Meanace.

1 Like
3

This is just for me so I can see more easily messages that come from my prop as opposed to standard system messages. When there’s a lot of printouts things can get lost so that helps.

1 Like
4

What you’ve seen is this with and without the ampersand. Like


If (SFX_sound_name) {
hybrid_font.PlayPolyphonic(&SFX_sound_name);
}
``
The if checks if the pointer is nullptr or not (meaning whether such sound exists) 
The second instance with an ampersand means get the specific address of the sound and play it with PlayPolyphonic().
1 Like
5

Ok, I only have one word: WAW! I am in total admiration of your knowledge.
That made me speechless, which is a rare occurrence.
It took me “a minute” to compose my thoughts.
You guys are so great. I know I have more questions but it will take me more than “a minute” to put them in written words and even longer to fully “digest” all that information. Now it’s bed time so I speak me tomorrow.

Have a great end of day & a good night.

6

Just one before I sleep: what is “cout” ?

7

std::cout is for “character out” and is the c++stdlib’s response to printing characters to (almost always) the console.

A quick google search for that should give you a wealth of hits :slight_smile:

1 Like
8

Look up “Taking memory address of variable” for C++.

Basically, it creates a pointer from a variable which points to the variable’s memory.

References are cooler since they can’t be null and mean the & isn’t needed, but you can’t null them which is sometimes desirable, which I assume is why profezzorn is using pointers here.

9

References are pointers, but hidden.
That doesn’t make them cooler, it makes the code harder to read.
They have their uses, but in general I prefer const references and pointers for just about everything else.

10

Yes, but they’re non-nullable (without trying), and with a bit of help from an LSP to indicate mutability (I personally have my stuff setup so that variables are italicized when they’re passed to a function which can mutate them, pointer or reference), they’re much more convenient in my opinion.

A matter of taste I suppose, but when they can be used I prefer them.

It’s never not clear when a reference is in use when I’m programming, so I feel the idea of them being “hidden” and harder to read a bit disingenuous.

11

If everywhere that C++ code is displayed worked like that, I might change my mind.

… maybe

12

Everywhere C++ is displayed that I handle it works like that :crazy_face: