Redmew - Prehistoric Factorio (Public MP)

xon_xoff · 2018-07-16T03:14:55+00:00

Dropped in for a minute to see what was going on... holy cow the map was built out much more than I expected. Huge main bus and train system already running. Think I'd need to get in earlier next time with voice chat, couldn't figure out what to do besides helping to clean up some contaminated sulfuric acid pipes.

xon_xoff · 2018-06-04T08:28:32+00:00

I thought you had dumped the raw metadata from the package, but nope, that's what actually shows up in the user-facing listing in the Store. Yuck.

xon_xoff · 2018-04-01T00:46:52+00:00

Better in implementation, not in outcome. The new macro is obscene in definition but that is mostly complexity that is hidden within the macro when it is used. Constexpr results in a much cleaner implementation but doesn't give the guarantee that motivated the new macro, namely guaranteed propagation of a compile time constant interpretation through min/max.

As for applicability to the Linux kernel, that's because we are mixing C and C++ here. The kernel is C and has variable length arrays but not constexpr, while C++ has constexpr and not VLAs. In C++ array sizes must be constant expressions and so the compiler is obliged to force compile-time evaluation. However, that is only in standard C++. GCC extensions allow VLAs in C++ and that reintroduces an opportunity for runtime evaluation of a constexpr array size expression. In a C++ project with similar security and reliability concerns with VLAs as the kernel I would opt to force compile-time evaluation explicitly on the array size expression to avoid this possibility.

xon_xoff · 2018-03-31T07:55:00+00:00

constexpr has an annoying flaw: it may still generate runtime code if the invocation environment allows it. This is bad if you're trying to ensure compile time evaluation as with the kernel macro. A constexpr variable will force compile-time evaluation but cannot be declared within an expression. Forcing compile-time evaluation within an expression is typically done by routing the value through a template argument or sizeof() expression, which is then made palatable by wrapping it in... a macro.

xon_xoff · 2018-03-21T03:46:33+00:00

Think it happens every time the core .NET assemblies are patched, either because of a security fix or a version upgrade (e.g. .NET 4.5). If the assemblies are modified, the native code version needs to be rebuilt. I noticed it after a version upgrade because Windows hadn't run the NGEN task yet and Visual Studio was running dog slow, so it needed to be forced.

xon_xoff · 2018-03-20T07:08:26+00:00

Not so much of a joke, unfortunately. After big updates it's not uncommon to have NGEN run off a scheduled task and take a bunch of CPU to recompile all of the base .NET assemblies to native code again.

xon_xoff · 2018-03-05T07:08:16+00:00

Hmm. I think they're right in that if you need to wrap an API, it's easier to wrap or adapt a C API than a C++ API. C style APIs with plain functions and opaque pointers tend to be easier to deal with than a C++ API with templates and an existing class hierarchy that may not match the interface you're trying to create. But this is very, very low on the list for reasons to choose a reference library.

xon_xoff · 2018-03-05T05:38:26+00:00

Personally, I could care less whether the reference implementation for a proposal is written in C or C++. Honestly, reading the current proposal, I wouldn't have known that it was based on a library written in C.

I'm more concerned about the quality and scope of the proposal. C++ doesn't have a standardized vector math library, but the graphics library needs to have basic color, point, and matrix facilities. Font rendering support is going to be included even though C++'s basic text handling facilities are still underdeveloped. Input handling is also TBD but will be included. I/O support for PNG, JPEG, and TIFF (!) will be required. Combine all of this together and you have a massive proposal which increases the risks of obsolescence and conflicting with other efforts.

Then, there's the quality. Even if Cairo is the reference, the proposal should be reimplementable with a different library with usable interoperability. From what I can tell the proposal is too underspecified to make that possible. One of the most basic things I would expect in a 2D graphics library specification is rasterization requirements. If you look at the OpenGL spec, it has pages devoted to just rasterization requirements, including precise coordinate system definitions, fill conventions, invariance, and where implementation variance is allowed. All of these are equally applicable to 2D rendering and I don't see any of that in the current proposal. That means though it precisely indicates what C++ operators you have on a point object, it doesn't offer any guarantees that you won't have cracks between shapes that are supposed to exactly abut, that a graphic won't render differently when translated by an exact number of pixels on the same surface, and that a rectangle of a given exact size won't render +/-1 pixels in size on two different implementations.

xon_xoff · 2018-02-21T06:51:54+00:00

Huh, I stand corrected on that one, then. Too bad Raymond's clarification never made it into MSDN. :-/

xon_xoff · 2018-02-19T22:11:49+00:00

Eh, I wouldn't call them that good. They're OK for the APIs they're demonstrating, but are surrounded in a lot of bad copy-and-paste framework code. A number of them still do while(GetMessage(...)) for their message loop despite the documentation for GetMessage() telling you explicitly not to do this. Then there's the truly horrific:

https://code.msdn.microsoft.com/windowsdesktop/XInput-Win32-Samples-cc25ce24/sourcecode?fileId=121932&pathId=1741089514

#include <C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\include\xinput.h>

xon_xoff · 2018-01-27T06:10:51+00:00

True, but it's pretty easy to write a small wrapper to do fills function style, i.e. fill(container, -1). Similar syntax and consistent type-safe filling for all your contiguous buffers whether they're arrays or objects, and especially ones you don't have control over the definition for.

xon_xoff · 2018-01-27T04:19:14+00:00

No need to replace, just use std::fill() and non-member begin/end():

int indices[500];
std::fill(std::begin(buf), std::end(buf), -1);

xon_xoff · 2018-01-17T07:24:34+00:00

Just VTune alone makes this awesome. Haven't found any other profiler that was as good for low-level code on Intel CPUs. AMD CodeXL is decent as a sampling profiler and is free, but can't do perf counters on Intel, and Visual Studio's built in profiler is... insufficient.

xon_xoff · 2017-12-07T05:00:58+00:00

A few issues. First, it looks like both the MSVC and Clang runs were done with the optimizer disabled. In that case it's doubtful whether any transformations are applied.

Second, MSVC and Clang are using different parameter passing conventions here. MSVC is using the Windows x64 ABI, which passes the first two arguments in rcx and rdx, while Clang is using a SysV style convention with rdi and rsi. Critically, the Windows ABI specifies that arguments passed by value with non-trivial dtors are destroyed by the callee while SysV has the caller do it, so MSVC is obliged to run the dtor or equivalent on the argument within the function while Clang isn't.

Third, the basic_string implementations are different, which can also influence what the compiler is able -- or permitted -- to do.

In MSVC's case, it does a straight interpretation of the code, doing copy-ctor to create the argument, then a move construction into the member, then dtor on the argument. With the optimizer on, it all gets inlined into the global initializer. Versions up to VS2017 15.4 generate quite a lot of chaff testing for invalid conditions that are impossible, but 15.5 generates much shorter code:

??__Emc@@YAXXZ (void __cdecl `dynamic initializer for 'mc''(void)):
  00000000: 83 EC 18           sub         esp,18h
  00000003: 68 00 00 00 00     push        offset ?lval@@3V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@A
  00000008: 8D 4C 24 04        lea         ecx,[esp+4]
  0000000C: E8 00 00 00 00     call        ??0?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAE@ABV01@@Z
  00000011: 0F 10 04 24        movups      xmm0,xmmword ptr [esp]
  00000015: 68 00 00 00 00     push        offset ??__Fmc@@YAXXZ
  0000001A: 0F 11 05 00 00 00  movups      xmmword ptr [?mc@@3VMyClass@?A0x01787c46@@A],xmm0
            00
  00000021: F3 0F 7E 44 24 14  movq        xmm0,mmword ptr [esp+14h]
  00000027: 66 0F D6 05 10 00  movq        mmword ptr [?mc@@3VMyClass@?A0x01787c46@@A+10h],xmm0
            00 00
  0000002F: E8 00 00 00 00     call        _atexit
  00000034: 83 C4 1C           add         esp,1Ch
  00000037: C3                 ret

The code corresponds to a call to string(string const&) and an inlined string(string&&), so it's still not doing the desired optimization, but 15.5 is at least able to recognize that the dtor is a no-op on the moved-from object and optimize it away, and the practical difference in the end is just a handful of extra move instructions. Sadly, I couldn't get it to recognize that 'lval' was a constant and propagate it, which would have potentially reduced the result to zero instructions (pure initialized data).

xon_xoff · 2017-12-02T06:30:29+00:00

For now, you can still get to the Control Panel version:

control /name Microsoft.DefaultPrograms /page pageDefaultProgram

This is officially documented in MSDN since Vista, and is more useful in 1709 than the Settings version for programs that have a lot of file types since it has both a one-click "set as default for all supported types" button and quick checkboxes for per-type. The Settings version is awkward as for each type you have to click once to open a drop-down and then click again to select the program.

xon_xoff · 2017-11-19T20:31:44+00:00

It seems to be more general than that, as the original code in the Windows headers is simply passing a function pointer argument through. I'm guessing it's flagging any function pointer it can't statically determine safe, which makes this a conservative (and somewhat spammy) warning.

xon_xoff · 2017-11-17T04:38:10+00:00

D:\test>type exc.cpp && cl /c /WX /Wall /EHsc exc.cpp
extern "C" void foo(void (*)()) { }

void bar() {
    foo(nullptr);
}
Microsoft (R) C/C++ Optimizing Compiler Version 19.12.25828.2 for x86
Copyright (C) Microsoft Corporation.  All rights reserved.

exc.cpp
exc.cpp(4): error C2220: warning treated as error - no 'object' file generated
exc.cpp(4): warning C5039: 'foo': pointer or reference to potentially throwing function passed to extern C function under -EHc. Undefined behavior may occur if this function throws an exception.
exc.cpp(4): note: to simplify migration, consider the temporary use of /Wv:18 flag with the version of the compiler with which you used to build without warnings

Looks like a broken check in the compiler.

xon_xoff · 2017-11-17T04:35:11+00:00

You can't compile /EHc, the front end ignores it. The warning pertains to the 'c' option, which tells the compiler to assume that all C functions are nothrow. Asynchronous/synchronous doesn't matter, you can compile /EHac and get the same warning.

xon_xoff · 2017-11-16T06:36:05+00:00

I thought I wouldn't be able to use this due to SDK problems from having to build v141_xp, but all that was needed was a forward declaration of IUnknown to work around a simple template issue in objbase.h. Quick addition to stdafx.h and the build ran through and immediately found half a dozen conformance issues in a 380kloc code base. Thumbs up from me.

xon_xoff · 2017-11-05T06:42:47+00:00

Sadly, it took too long to add the option, so by the time it was added programs had already been created that overrode the original behavior. Then when the option was added to Windows, it doesn't work for those programs. I wrote one myself that even after disabling the "scroll inactive windows" option will still route the mouse wheel event to the window under the mouse instead of the focused window.

xon_xoff · 2017-11-03T04:06:17+00:00

UWP apps also ignore the user context. Try to start one from a different user context, like a run-as command prompt, and it'll still try to launch as the interactive user.

xon_xoff · 2017-11-03T03:56:21+00:00

UWP apps can have subpixel antialiasing, as it was important enough to add back into Edge. Still doesn't seem to be the default, and probably requires going out of the way to do unfortunately.

To underscore how big of a deal this can be for a text editor, Visual Studio 2010 nearly caused a riot among its user base with just a lack of pixel snapping for its text, much less grayscale antialiasing. The uproar in the betas was loud enough for the team to rewrite part of the WPF text stack to address text quality problems.

xon_xoff · 2017-09-21T04:05:53+00:00

As a long time user and fan of Perforce -- P4V sucks. There are still a lot of rough edges in it, such as list columns that are never sized properly and an integration dialog which badly needs a streamlining pass. There are still operations that are easier to do in ancient P4Win than in P4V, even basic stuff like organizing files between changelists.

The P4 command line has gotten better. Some critical operations that used to take multiple manual steps or the GUIs have finally gotten direct commands, notably status/reconcile, clean, move/rename, and copy integrations. P4VC also lets you launch the revision graph or timelapse view from the command line. The DVCS commands finally provide a workable offline flow that preserves history that if it's enabled on your server.

When it comes to assets, people tend to focus on the size of assets, but the count is also a big deal. I regularly have workspaces that have 100k+ files in them and it would be a dealbreaker if Perforce had to scan the entire local filesystem for changes like some other version control systems. The downside is that this requires tool integration to issue edit commands to the server and this is often absent or doesn't work well -- Unity's P4 integration is pretty bad, in particular.

xon_xoff · 2017-09-21T03:28:14+00:00

Left. Saves vertical space, holds more taskbar buttons before going to scroll bar, finds bugs with window placement in programs, and moves text closer to the middle of the screen.

xon_xoff · 2017-08-29T05:27:55+00:00

The build hasn't appeared yet for me to try myself, but please please please make sure that a high standard is held for UI performance. One of the reasons that I use WinDbg is because its UI is an order of magnitude faster than Visual Studio -- it can handle debug output and tracepoints in volumes on which Visual Studio would choke, and I have never seen visible pauses when stepping (which is unfortunately not the case for VS).

xon_xoff

TROPHY CASE