ZeWaka

BRINTNESS

Fast integer lightness calculations from RGB — by Andrew Somers

brintness is an integer brightness/lightness/darkness calculation

This is part of an experiment in estimating a perceived brightness while remaining in integer math and using bitshifts to maximize performance (avoiding all subtraction, division, and square-root calculations).

The Issue

The traditional means to determine the perceived lightness or brightness for a given color value is to first normalize R, G, and B from 0-255 to 0.0-1.0, linearize the values via exponent or more exotic methods (we assume colors are in a gamma encoded color space, such as sRGB), and then after linearizing, creating a linear luminance value by applying coefficients to each of the R, G, B values, adding them, and then finally applying an exponent or more exotic math to find a predicted lightness value.

This downloads standalone MSVC compiler, linker & other tools, also headers/libraries from Windows SDK into portable folder, without installing Visual Studio. Has bare minimum components - no UWP/Store/WindowsRT stuff, just files & tools for native desktop app development.

Run py.exe portable-msvc.py and it will download output into msvc folder. By default it will download latest available MSVC & Windows SDK - currently v14.40.33807 and v10.0.26100.0.

You can list available versions with py.exe portable-msvc.py --show-versions and then pass versions you want with --msvc-version and --sdk-version arguments.

To use cl.exe/link.exe first run setup_TARGET.bat - after that PATH/INCLUDE/LIB env variables will be updated to use all the tools as usual. You can also use clang-cl.exe with these includes & libraries.

To use clang-cl.exe without running setup.bat, pass extra /winsysroot msvc argument (msvc is folder name where output is stored).

Linux Desktop Issues

This is basically my manifesto of why Linux sucks and I keep using Windows as a desktop OS. This is both as a developer platform and end-user targeting.

Look: I would love to be able to use Linux as a daily driver. KDE is amazing and they clearly put far more effort into the desktop experience/UI than Windows (just the volume mixer alone). There are simply far too many underlying and infrastructural problems to the Linux desktop that none of KDE's great UI changes can make up for. I want Linux fanboys, developers, etc... to stop sticking their damn head in the sand about these issues and admit that Linux is still decades behind in some basic infrastructure. This shit can't get fixed if people refuse to admit it's broken in the first place, which some people are far too happy to do.

Desktop App Experience & Developer Tools

Windows has far better desktop apps than Linux, and thanks to WSL, I have all the CLI apps of Linux too. While I do believe KDE Plasma is a much better desk

Where's The Luv?

An Examination of the CIELAB and CIELUV colorspaces.

It is exciting to see so many new color features for the CSS Color Module. There are nevertheless a couple items that resulted in a "raised eyebrow response". This Gist is mainly going to focus on one: the use of the LAB version of LCh instead of LUV LCh, which may be better suited for the task but appears to have been dismissed as if irrellevant.

I DISAGREE. Luv is in common use and very relevant, and LuvLCh or one of the several LuvLCh variants has distinct advantages over LabLCh for use cases such as choosing color for web content for displays.

Myth Destruction

Use ubuntu (or debian works too for this guide) because i dont know the other distros lmao
Run sudo dpkg --add-architecture i386 to enable 32 bits package lists
Run sudo apt update to make sure package lists are updated
Run sudo apt install libstdc++6:i386 to get the dependencies for BYOND
Find the download link for BYOND's linux version from http://www.byond.com/download/, looks like http://www.byond.com/download/build/513/513.1536_byond_linux.zip

Atmospherics

1. Preamble

Figure 1.1: My avatar on github, the /tg/station forums, and BYOND

Hi friends! My name is Dunc. As some background, I have been contributing to /tg/ atmos in various ways since 2015. I was tutored by Aranclanos and eventually followed in his footsteps in writing several major refactors of the atmos system. I am a maintainer for the /tg/ codebase and any atmos issues or PRs are my concern. Most importantly, however, is the fact that as of the time of writing I am the only person who understands each component of the current atmos system. That fact is by far the most important reason for the existence of this document; it is my responsibility to share what I know.

Atmospherics is a very complicated and intimidating system of SS13, and as such very few contributors have ever made changes to it. Even fewer is the number of contributors who have made changes to the more fundamental aspects of atmos, such as Environmental Atmos or

	# dm_full_file_patch.py <byondcore.dll> [bytes to offset strings by]
	# By default, this will create absolute paths, which work perfectly fine in Tracy no matter where it is.
	# However, if you want to trim file paths to only what is necessary, you can specify a number of bytes to offset.
	# For example, if your tgstation is inside C:/Users/Mothblocks/tgstation/, you will want to cut it by 30 (the length of that text).
	# This is useful if you want to send screenshots or upload the Tracy profile without giving away potential PII like your username.

	import shutil
	import sys

	pattern = [

	# TODO: replace :token, :user, and :repo
	curl -H "Authorization: token :token" \
	-H 'Accept: application/vnd.github.everest-preview+json' \
	"https://api.github.com/repos/:user/:repo/dispatches" \
	-d '{"event_type": "awesomeness", "client_payload": {"foo": "bar"}}'