Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

migeel.sk

Post reply on HN
Print view View original

21–30 of 42 posts

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

#21

Post by gwervc »

pjmlp wrote: post #13
TillE wrote: 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.

WinRT is one of the biggest fail of Microsoft in the last decades. Instead of pushing for a multiplatform .NET implementation with a portable UI (Silverlight OOB was just that), or even running on most Windows versions, we got framework over framework (WinRT, UWP, WinUI) that are only compatible with the last version of Windows and don't bring value over WPF.

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

#22

Post by pjmlp »

gwervc wrote: post #21
pjmlp wrote: post #13

Earlier quoted context omitted.

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.

WinRT is one of the biggest fail of Microsoft in the last decades. Instead of pushing for a multiplatform .NET implementation with a portable UI (Silverlight OOB was just that), or even running on most Windows versions, we got framework over framework (WinRT, UWP, WinUI) that are only compatible with the last version of Windows and don't bring value over WPF.

Speaking as someone that bought into it, WinRT was kind of the .NET idea before they went with a Java clone (Ext-VOS), they didn't fail only on features, they failed on how it was managed.

From the forced rewrites across Windows 8, 8.1 and 10, as the platform was maturing, the deprecation of C++/CX, replaced by less capable C++/WinRT (now in maintainance, while they are having fun in Rust/WinRT), deprecation of .NET Native without parity in Native AOT, no designer, and plenty of other broken stuff.

It was for this that WinDev kind of sabotaged Longhorn efforts, thanks very much.

Meanwhile Google shows what happens when everyone pushes into the same direction, even if it takes some growing pains (with lots of cash) to get there.

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

#24

Post by orthoxerox »

delta_p_delta_x wrote: post #8

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.

You don't want these optimisations to be on by default.

Trimming can cause bugs when your program or one of its libraries relies on reflection and Native AOT is good for startup time (FaaS), but tiered JIT will likely outperform it in long-running applications.

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

#25

Post by pjmlp »

mobiuscog wrote: post #17
delta_p_delta_x wrote: post #8

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.

Side note, one of the first commercial games written in .NET used OpenGL, released in 2004 long before XNA.

It was a RTS game and quite cool, Arena Wars.

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

#28

Post by SirMaster »

orthoxerox wrote: post #24
delta_p_delta_x wrote: post #8

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.

You don't want these optimisations to be on by default. Trimming can cause bugs when your program or one of its libraries relies on reflection and Native AOT is good for startup time (FaaS), but tiered JIT will likely outperform it in long-running applications.

No, but I learned from this that self-contained builds can be compressed. Why isn't that an option in the publish gui of vs 2022?

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

#29

Post by delta_p_delta_x »

orthoxerox wrote: post #24
delta_p_delta_x wrote: post #8

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.

You don't want these optimisations to be on by default. Trimming can cause bugs when your program or one of its libraries relies on reflection and Native AOT is good for startup time (FaaS), but tiered JIT will likely outperform it in long-running applications.

> when your program or one of its libraries relies on reflection

Fair enough; perhaps it'd be worthwhile to throw a compiler error if both reflection and trimming were attempted.

> Native AOT is good for startup time (FaaS), but tiered JIT will likely outperform it in long-running applications

This is intriguing; could you elaborate on the latter? Would tiered JIT perhaps have more runtime information which would be more useful when optimising frequently-accessed code paths or tight loops?

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

#30

Post by mlhpdx »

flohofwoe wrote: post #15
nwellinghoff wrote: post #11

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.

I’m using some of these techniques to minimize the size of my executables for use with a AWS Lambda and on embedded Linux projects.
Post reply on HN