Live data from Hacker News

Building a self-contained game in C# under 2 kilobytes

migeel.sk

11–20 of 42 posts

Re: Building a self-contained game in C# under 2 kilobytes

#12
post #6

I love the low level .NET stuff Michael Strehovsky makes. Microsoft has built a feature-rich and easy-to-use environment, but it makes .NET developers think there is only one way to use it: create csproj and call dotnet build. But underneath the covers, there is an extremely powerful compiler (Roslyn) and build-system (msbuild). Combine that with the flexibility of C# and you can develop pretty much anything.

We know the other ways, in fact stuff like NGEN have been a CLI set of commands since the early days.

However .NET (alongside Java), has a culture of great tooling, we only do stones and sticks programming when there is no way around it.

Re: Building a self-contained game in C# under 2 kilobytes

#13
post #5

This is really cool, but it's funny to use C# primarily as an awkward substitute for C as you call Win32. For most practical purposes, the default .NET 8 AOT is great if you really need native code.

Windows Forms is basically this, a better MFC version, and even if it was only for faster startup times, NGEN has been there since day 1.

The biggest issue has been WinDev, that contrary to Google's culture in ChromeOS and Android, they will kill any attempt to touch their precious COM and C++ tools, thus the way the Longhorn project went down, only to see its ideas redone in COM, and WinRT coming to existence.

Re: Building a self-contained game in C# under 2 kilobytes

#14
post #6

I love the low level .NET stuff Michael Strehovsky makes. Microsoft has built a feature-rich and easy-to-use environment, but it makes .NET developers think there is only one way to use it: create csproj and call dotnet build. But underneath the covers, there is an extremely powerful compiler (Roslyn) and build-system (msbuild). Combine that with the flexibility of C# and you can develop pretty much anything.

Don't forget the Win32 API which allows to create a window and run an event loop with a handful of simple function calls (even in C# apparently). Then compare that to the APIs that came after (like UWP and WinUI) and shudder in horror.

Re: Building a self-contained game in C# under 2 kilobytes

#15

Very cool. What are the practical implications for this? Would it ever be wise to deploy these techniques for a commercial program? Is the end result more memory efficient during execution?

A small binary size is at least useful when running code in web browsers via WASM. Granted, 2 KByte would be way below diminishing returns, but even a couple of hundred KBytes is rare with high level languages like C# which usually require a big runtime.

Even "we care about binary size at all" would be a major step forward for most "professional" applications.

Re: Building a self-contained game in C# under 2 kilobytes

#16
post #5

This is really cool, but it's funny to use C# primarily as an awkward substitute for C as you call Win32. For most practical purposes, the default .NET 8 AOT is great if you really need native code.

Heh, I thought exactly the same seeing the code: "This looks almost exactly like C talking to Win32, except slightly more awkward" :)

Re: Building a self-contained game in C# under 2 kilobytes

#17

It is pretty impressive that even without third-party tools, the binary went from 64 MB to ~1 MB. IMO future versions of .NET should add more of such optimisation flags as default in a Release build.

It would be really interesting to see how small it could stay whilst adding in support for OpenGL.

Re: Building a self-contained game in C# under 2 kilobytes

#18

"Win32 is the only stable ABI on Linux" ;)

"This will produce a single EXE file that is whopping 64 MB in size. [...] You might say “still better than Electron” and call it good, but let’s see if we can do better."

Re: Building a self-contained game in C# under 2 kilobytes

#20

It is pretty impressive that even without third-party tools, the binary went from 64 MB to ~1 MB. IMO future versions of .NET should add more of such optimisation flags as default in a Release build.

Agreed, it feels like there's still low-hanging fruit there.
Post reply on HN