Baking does lots of stuff - light maps, visibility queries, SH probes, etc.

This built system runs on top of a very simple distributed processing system - you just tell the system "run this linux command somewhere" and it just does it. No incredibuild here.

They use ubershaders with #defines for each feature.

They wrote their own GUI shader editor for artists. Programmers would "export" feature flags and settings, and an artist could play around with them. They hooked it up to Maya.

4/10

Trump’s #TransBan #Defines Everyone as #Female — But That’s Not the Problem.

The #president’s #executiveorder is an attempt to #rollback #decades of #progress. #LGBTQ+ #advocates intend to #fightback

https://www.rollingstone.com/politics/politics-news/trump-trans-ban-executive-order-1235243876/#utm_campaign=syndication

"But but .. main.h will contain the #defines for all the named pins"

then use _ and no spaces @_@ it's not that hard.

https://stackoverflow.com/questions/71175568/can-i-define-gpio-pin-in-header-file-stm32

@phil_stevens No OTA, just direct USB to the MD motherboard. There doesn't seem to be any serial anything. I could use a simple test program that is least likely to need trickier configurations, but the SDK is full of Tools settings, and it's not clear to me how these interact with the code's own #defines.

@josch do note that the iso646.h header isn't for adding this functionality. you can add it using simple \#defines if you wanted to, but the iso646 header contains much more than that.

It's fast! And has very few errors. We like to go through each register one by one, add the typedefs and #defines, then the setter/getter functions, and finally the arduino ino 'sketch' to actually test and verify. However, with three files - header, cpp, and ino - canvas can get really confused about which file we're editing and what it's called.

INTERFACE spits out an .H file with the resource IDs and an .RSH file with the OBJECT and OBSPEC data all helpfully in arrays of C structs. the only problem is the output is for Pure C’s TOS lib and not MiNTlib so I need to include a file that converts the #defines first.

But it means I should be able to whip up a loader that places the OBJECTs in my window’s OBJTREE, converts INTERFACE’s character grid coordinates to pixel grid coordinates, and places the container G_BOX where I want it

@Doomed_Daniel By the way, my favorite variant of X macros is to use a separate .inl file that's parameterized and configured by a bracketed set of #defines by the includers. It often lets you get away with much cleaner syntax.

After a little bit of fiddling around this morning, I've realised that the classes aren't in the order they come in the external files. In fact, I have no idea how they're ordered. I assume it's something to do with dependencies, but I can't see it.

Like I said, it probably makes no difference - it's just a load of #defines. But I'd like to make it character-perfect at some point.

I have other things to do today, but if I get a chance this evening I'll try using #ctran to compile something.

@stuartmarks amusingly a few posts before this in my feed was complaints about namespace pollution from the Xlib.h header having #defines for things like “Status” and “None” due to decisions made nearly 40 years ago, when X was just a fun experiment, not core system API.

Have I ever mentioned how much I *hate* the C preprocessor? It poisons everything built on top of it, you make modern code with namespaces and such and it gets broken by the pre-namespace #defines in your thirty year old OS header files. You're building skyscrapers on sand. A significant portion of why I want to jump to Rust or Go is just to get away from the C preprocessor by itself

@madcoder

In the olden daze, a null pointer in C actually was a zero, and it pointed to address zero, and guess what was there? Zeros.

So, a null string pointer pointed to a null string or zero int. And it worked.

And then ANSI C came along, and NULL was no longer a zero pointer to zeroes, and whoa! Stuff broke.

I spent a lot of time reworking the toolchains back then to wrap all of the C library functions via the preprocessor.

Then, I wrote frontends for the libc functions that had the null pointer problem.

Then, I made the build system use my frontend library which trapped the bad code.

So, strcpy() became safe_strcpy() and if a null pointer came in, I would fix it on the fly, and also log the calling code so it could be fixed later.

Oh, I had a common header file that almost all of the code #included so that made it easier. I just changed that common header file to include all of the #defines I needed from another header file, and like magic, all of the source code C calls to strcpy() (example), magically became calls to safe_strcpy(), and then the rest was linker magic because I controlled the build system so I could make it use my frontend wrapper library.

I've also removed a huge number of preprocessor #defines and moved the constants that they created directly into code, which feels really weird in the abstract, but was the right call in this specific case.

I love "this is usually wrong, *but*..." moves.

There were a huge number of "#define FOO_PID 0x1234" defines, each of which were used once, defining the hardware ID burned into specific device models. Maintaining the list in 2 places was a pain, and it made automated tooling harder.