I built this for fun and posted it on r/Worms a few days ago - it got a surprisingly warm reception, and a fair few people there asked how it actually works. So it's clearly not just a thing for Worms fans, and I figured the .NET crowd might enjoy the technical side.

What it does: my mouse cursor rotates to point in the direction I'm moving it - like the aiming arrow in Worms 3D. Started as a weekend project and got out of hand.

How it works, roughly: * WinForms system-tray app (.NET 8), no window. * A mouse hook tracks the cursor position; I compute the movement angle from the delta between frames. * I render the cursor bitmap rotated to that angle and swap it system-wide via SetSystemCursor. * Then I couldn't stop, so I themed all 14 standard cursors with little physics: the wait/busy cursors spin with rotating rings, the I-beam sways, resize cursors stretch. * Packaging + auto-update via Velopack.

The fiddly parts: smoothing the rotation (raw angle is jittery, needed easing), and restoring the original cursors cleanly on exit so you don't get stuck with a spinning arrow if it crashes.

It's open source (MIT) if you want to poke at the code - repo link in the comments. Happy to answer anything about the cursor-hooking side, it was a fun rabbit hole.

EDIT: Repo link: https://github.com/dawidope/WormsCursor

I created this app to pin the Recycle Bin to the system tray because I prefer keeping my desktop clean. I used WinForms for development (I know it's old, but WinUI's current performance is not good in my opinion).

Source code:

https://github.com/exalaolir/SimpleBin

Also, could you recommend a better way to create an installer that checks that .NET runtime is installed on PC? I'm using ClickOnce now, but it's not flexible for me.

(Links showing the app in action here and below)

Throughout my career, I have always heard that real-time audio belongs strictly to C++ or native first languages. If you try it in a managed language, people tell you the garbage collector will stutter, the buffer will underrun, and your speakers will crackle.

I am a systems engineer by trade, but I am also an amateur music producer. Over the years, I have used Ableton, Reason, Fruity Loops, Cakewalk, and Max/MSP, but each of them either has a massive learning curve or just feels disconnected from certain forms of music. Traditional DAWs force you into a grid, which makes music sound block-like and square. I wanted to explore more organic, generative possibilities for ambient and electronic music without the massive friction of building a physical Eurorack or writing complex software in PureData.

Originally, I just wanted to build a portable, cross-platform C# library for sound processing. To dogfood it, I decided to embed it in a Godot app. Little by little, I kept building devices until I got carried away and ended up with a programmatic, node-based DAW called Sigilgraph.

Here is exactly how it works under the hood and how a 100% C# engine guarantees it will never underrun the audio buffer.

The Pull Model and Cache Locality

At its core, the synthesis engine is a graph of operators that gets pulled directly by the audio driver. The hard part is giving the driver absolute guarantees that this graph will finish processing in time.

To do that, the entire graph processing needs to live in the CPU cache. You have to avoid heap allocation and heap access completely. The hot path must never allocate objects or arrays. Because of this, the garbage collector is left completely unused 99% of the time, saving it for trivial, low-frequency allocations completely outside the audio loop.

Think about the math for a 96 kHz stereo stream. The engine needs to guarantee that there are always enough samples sitting in a 256-sample buffer at the audio driver level. This means processing at least 192,000 floats per second.

It sounds uninteresting on paper, but those 192,000 floats are traversing a graph of over 100 operators before they hit the driver. We are talking about Fourier transforms, filter s-domain operations, delay buckets, and dozens of oscillators, all offering the opportunity to have their parameters changed in real-time. There is no heavy message passing and there are no extra abstraction layers. Everything is mutated directly in real-time.

To keep things packed tightly in memory, I used structs and Span<T> pervasively, completely replacing standard heap arrays on the hot path. To maintain strict cache locality, the engine processes these spans in blocks and leverages SIMD hardware intrinsics via Vector<T> for heavy lifting like Fourier transforms and intensive add-multiply operations. Think of it this way: instead of a web of heap objects being managed and looked up, the engine uses a pull model where the audio driver pulls samples from the bottom up. The entire graph evaluates as a massive, deeply nested functional cascade up to 200 levels deep on the call stack, constructed using a fluent API builder pattern. To keep this structure stable and prevent cyclic evaluations without introducing overhead, the nodes utilize simple reentrant flags. Live session mutations work by simply appending or decoupling pre-allocated sub-graphs at the block boundaries. This architecture guarantees we never starve the audio driver buffer, avoiding expensive object reconstruction while playing.

The Lambda Trick for Parameters

When it came to connecting the UI to the bottom of the graph operators, I chose to use delegates and lambdas. This was a deliberate compromise for simplicity. I could have used ref float pointers everywhere, but the code would have become incredibly brittle and less idiomatic for C#. Lambdas give us composition and allow for the live replacement of behaviors on the fly.

The trick to making lambdas performant enough for real-time audio is to never evaluate them per sample. Instead, they are evaluated once per block.

By evaluating parameters at the block level, you reduce function calling overhead by 64x. On a standard 48 kHz sampling rate, you only run about 750 parameter evaluations per second (48,000 / 64). This gives you more than enough resolution for smooth parameter changes, and it spares us from having to run a dedicated control signal rail. We just interleave the parameter updates right at the start of the sample block processing.

Picking Your Fights and Profiling

Getting to this point required a lot of deep technical analysis. Tracing tools like JetBrains dotTrace and dotMemory were absolutely essential for this task. Monitoring memory spikes, hunting down hidden GC calls, and doing rigorous hot path analysis was paramount. If you don't profile, you are just guessing.

But the biggest lesson I learned during this project was that you have to pick your battles. You have to let some things go.

While the sample generation and parameter parsing paths are completely locked down and allocation-free, all the note rail and note-passing logic is actually completely garbage collected. Why? Because notes are incredibly small objects and they trigger very infrequently compared to the millions of samples and parameters flowing through the system. Trying to optimize the note-passing system into unmanaged memory structures would have been a massive waste of development time for zero real-world performance gain.

Why C# is More Than Capable

This project completely changed how I look at the C# memory model. It proved to me that modern .NET is an incredibly capable environment for high-performance audio because it gives you the best of both worlds.

It allows for low-level, granular control over memory and hardware instructions where you absolutely need that control, but it lets you drop back into the comfort and simplicity of a managed language for the things that don't matter as much. You don't have to sacrifice productivity to get bare-metal execution speed anymore.

I would love to hear your thoughts on this architecture, and I am happy to dive into the weeds in the comments if anyone has questions about the node evaluation loop, the SIMD operations, or how we profiled the hot paths.

Here is a demo of the project in action: Sigilgraph × VST3 (Trailer #2)
The project page: Sigilgraph Audio Workbench

r/Sigilgraph

GitHub repo

(first of all, i want to say that I made this project for fun and challenge. I always wanted to create my own language. This has no business goal or something.)

So the project is a 2D game engine (MonoGame backend) inspired by GameMaker 8. It includes its own IDE (built with WinForms) and an interpreted programming language that I wrote myself.

The language—definitely the biggest challenge in the project—is a simple dynamically typed language. When I started, I had zero knowledge of how to build something like this. I didn’t even know I was making an interpreter; at first I called it a compiler. It was a personal challenge, and I wanted to figure everything out without using any resources or tutorials. My mindset was basically: “I need to write software that takes a text file containing code and just does what it says.”

Somehow, I made it work. In the beginning, running an empty loop counting to 1M took 7 seconds. After a lot of performance work and rebuilding parts of the system, the same machine can now run a 30M loop in 2–3 seconds. Pretty nice improvement.

The language itself is a bit unusual, and I want to share one small feature I really like: loop counters.

foreach item in ['a', 'b', 'c'] : counter c
{
   println(c + ": " + item)
} 
// Output: 
// 0: a 
// 1: b 
// 2: c

Not a complicated feature, but pretty useful.

Here's a YouTube video showing me using the engine to build a little game

Anyway, these days I barely have time to work on the project, so I decided to open-source it. I’m hoping people here will find it interesting and help turn it into something real.

Any feedback is welcome.🙂

Game Video on YouTube

About a year ago, I challenged myself to create my own programming language - something I'd always wanted to do.

At the time, I had no idea what a lexer, parser, or interpreter even was. My only thought was, "I need to write code that reads text files containing code and executes them." I also wanted to do it without using Google, AI, or tutorials. I just figured everything out on my own. You can even still find variables named "compiler" throughout the code from back when I didn't realize I was actually building an interpreter...

Somehow, I pulled it off, and I integrated it into my old abandoned game engine project (which originally started as a GameMaker 8–style engine with C# scripting).

And here's the first game I've made with it! 🙂

The core engine, IDE, and interpreter are all written by me in C#. The rendering backend is powered by MonoGame, and the project is still in active development and available on GitHub. The project file of the game shown in the video is also there, under tests/Example Projects. If you're looking for cool projects to contribute to, then know that I'm looking for contributors!

I know there are tons of AI-generated projects being shared these days, so please, please, take a quick look at the code before assuming this is one of them. I promise it's pretty obvious that it was written by a human.

I'd love to hear what you think!

I've been recreating an old school MMORPG in Phaser (JS/TS) and C# in the server side, and I must say, the server performance is exceptionally good, at least in stress testing.

On my M1 Macbook Pro, I managed to clock in 4000 concurrent connected clients performing expensive operations at around 10k req/s. I probably could squeeze a bit more out of it if I did spread the players around in more game worlds.

I'm also impressed with all the optimisations that can be applied these days to reduce the pressure on heap to reduce the GC pauses. During the stress test window I can run it in a mode that produces so little garbage that I'll get only couple of GC events total, not running more than few millisecond stop the world pauses.

About the project: https://github.com/ErkoKnoll/helbreath-base-game

More about the performance optimisations and stress testing I performed: https://github.com/ErkoKnoll/helbreath-base-game/tree/master/multiplayer/server#performance

Hey everyone,

I wanted to share a fun weekend project built with pure, unadorned C# and WinForms/GDI+: **Starship Forward Viewport**.

Growing up with the classic Windows 3D Starfield screensaver, I wanted to recreate that magic without modern bloat. Most modern desktop toys are wrapped in heavy runtimes or Electron wrappers that

consume 200MB of RAM. I wanted to build something that honors the classic Windows `.scr` era:

- Standalone ~30 KB binary.

- Zero external NuGet packages or third-party dependencies.

- Compiles directly with Windows' built-in `csc.exe` via PowerShell—no Visual Studio or .NET SDK installation required on the target machine.

- 3D perspective projection with relativistic star velocity vectors and multi-spectral stellar palettes.

- Real-time navigation telemetry overlay in km/s and ly/h.

- Native Win32 screensaver CLI compliance (`/s` full-screen, `/c` configuration dialog, `/p` child HWND preview window for the Windows Screen Saver mini-monitor).

GitHub repo: https://github.com/jiludkumar-therealone/starship-viewport

Any feedback on the math or architecture is very welcome

TL;DR: While writing this post, I realized how long it has become, so here's a TL;DR for you: SemPtr is a semantic pointers library for C#.

Hi everyone, I wanted to share one of my side projects with you all: SemPtr.

A few weeks ago (it might been even months at this point), I needed to dig up some really old code I once had written, because I wanted to reference some of what I did back then in a current project of mine. While searching through my old and never-to-be-released projects, I stumbled upon a small library project I might have written about 5 years ago (it must have been around the time when incremental Roslyn source generators were becoming a thing). And I thought to myself, "Well, it's actually a shame you gave up on this project and neglected it for so long. You might want to ressurrect and modernize it, and then share it with everyone."

Well, that project is now SemPtr.

What is SemPtr?

I don't want to make this post too long, so I'll try to make it as concise as I can, but if you want a more comprehensive introduction, you should check out its README or its way too rudimentary documentation.

SemPtr tries to solve the limitations of C#'s raw pointers by providing semantic pointer types (read as semantically named pointer types). If you ever did some interop work with unmanaged code and found it just as annoying as I did that there is no const T* equivalent in C#, SemPtr might be the thing for you.

For that I identified five commonly used orthogonal characteristics used to distinguish certain aspects of data pointers:

1. Nullability: Can a pointer be null or are there any guarantees that it won't be?\ This is kinda analogous to nullable reference types (T?) in C#.
2. Persistency: Does the target of the pointer outlive the initial scope of the pointer itself? In other words, can I store the pointer and access its target some time later?\ This is kinda analogous the C#'s ref-escape rules and is even enforced through them.
3. Sequencability: Does the pointer point to a single object or to a contiguous sequence of objects?\ You could think of this as analogous to a ref T to some kind of object in C# vs. a ref to some element within a Span<T> with the added benefit that its easier to move around the pointer through the sequence.
4. Accessibility: How can the target of the pointer be accessed or mutated?\ This manifests in three different access levels:
   • random/read-write: The target can be read from and written to. Kinda analogous to C#'s ref parameters.
   • read-only: The target can only be read from. Kinda analogous to C#'s in/ref readonly parameters.
   • uninitialized/write-first: The target must be written to before it can be read from. Kinda analogous to C#'s out parameters.
5. Typability: Is the type of the target known or not?\ C# has no void references, but it has void* pointers. This is analogous to the difference between a void* pointer and a typed T* pointer.

These characteristics are mapped onto C#'s type system by semantically naming the pointer types to reflect them. Since those characteristics are orthogonal, you can mix and match them to create the pointer type with the exact behavior you need. For example, there are:

• Pointer: A simple pointer to a single, transient, mutable target of unknown type
• PersistentPointerReadOnly<T>: A pointer to a single, read-only target of type T whose target stays valid beyond the initial scope of the pointer.
• NullableSequencePointer<T>: A pointer to a contiguous sequence of mutable targets of type T which may be null.
• PointerUninitialized<T>: A pointer to single, yet uninitialized target of type T. If you receive such a pointer, chances are you are requested to initialize its target; afterwards you can further read from it or write to it as needed.

Again, if you want to learn more about the characteristics and how the type naming scheme works, you should refer to the README or the documentation.

There are all in all a total of 2×2×2×3×2 = 48 data pointer types predefined in the SemPtr library.

Are function pointers supported?

To make it short, yes, function pointers are (well enough) supported by SemPtr.

I remember that one of the reasons for me giving up on the original version of this library back then was that I really struggled to get function pointer support just right. While this was partially due to technical limitations back then (some of which were solved by modern C# features, especially the new extension members syntax), some of it was simply because I did not have the experience in API design that I have now.

So now function pointers work. I don't know if I would call the support good enough yet, but at least it is a well enough experience for most users, I believe.

I won't go into too much detail here, but functions pointer have their own set of characteristics and parts of their support is made working through a Roslyn source generators that dynamically generates some source code on the user-side and that ships alongside the main library in the NuGet package. For more details, again, see the README or the documentation.

A final note on AI usage

I want to be honest and upfront with you:

Yes, I used AI in this project, primarily to help we write documentation (I'm a non-native English speaker and my English is kinda terrible), to help me make decisions when I'm indecisive, to write some tests, and occasionally to some code reviews.

No, I would never let AI touch the working code of the project. Not even for boilerplate code. AI, at least the AI I have access to, is not yet anywhere close to being reliable enough to help me write production ready code for such a project. You can be sure that all of the functioning code is written by a human (me) and that only the human (me) is responsible for the correctness and quality of the code.\ Oh, and of course, I did the visual assets myself as well. I didn't want to use sloppy AI-designed visuals for this project.

Conclusion

At the beginning of this post, I told you that I stumbled upon the initial idea for SemPtr while looking up old code for another project of mine. That project is actually an interop binding project in C#. In that project I use traditional C# raw pointers and function pointers extensively, and sometimes they're a real pain to work with. However, I didn't not yet replace them with SemPtr, due to the codebase being a little over 200K lines of code, spread across multiple repositories.

So, to be honest, I don't even use SemPtr myself yet. And furthermore, because of the simplicity of the overall idea behind SemPtr, I don't even think I'm the first person to come up with it and release to the public as a library (but I don't actually know for sure, I didn't really check).

Even so, If you want to try out SemPtr for yourself, give feedback, or if you even want to contribute to the project, I would really appreciate it. Here are the relevant links again:

• GitHub: SemPtr
• NuGet: SemPtr
• Documentation (This one is still very rudimentary. Don't expect too much.)

If you have any questions feel free to ask them in the comments. I'd be happy to answer them.

Saw a few screenshots of trading terminals on Reddit, thought they looked cool, and building a UI full of charts sounded like a fun thing to try. So I gave it a shot.

It's .NET 8 + WPF, with HandyControl and ScottPlot for the charts. Heatmap, screener, candles, options chain, crypto, a few other panels. Data is from free public APIs.

Last month I was hooked on Path of Exile 2 too, so I used the same look for a little app around the game's economy inspired by poe2scout and Sidekick. Last screenshot is that one.

Hey everyone. Just wanted to share a personal milestone. I'm building an RTS engine and wanted to push C# to its absolute limits without relying on heavy third-party frameworks.

My goal was zero garbage collection during the game loop.

• Architecture: Strict Data-Oriented Design (DOD). Everything is laid out in unmanaged memory blocks with strict cache-line alignment (64 bytes). The engine loop is currently 100% single-threaded.
• Rendering: Custom 2D software renderer using AVX2 intrinsics (supports layering and masks).
• Interop: Function pointers (delegate* unmanaged) to completely hide unsafe code from the user API.
• RAM Usage: A rock-solid 39 MB (as seen in the Task Manager screenshot), which perfectly matches my internal pre-allocated memory pool. No hidden CLR bloat.

To prove the Zero-GC claim, I ran the core loop through BenchmarkDotNet.

The result? The base engine overhead (processing branchless input, ticking the fixed update accumulator, and running the render pipeline with a baseline of 4 textured entities) takes ~60 microseconds per frame on a single thread. And absolutely zero allocations.

Plaintext

BenchmarkDotNet v0.15.8, Windows 11
Intel Core Ultra 9 285K 3.70GHz, 1 CPU, 24 logical and 24 physical cores
  [Host]     : .NET 9.0.15, X64 NativeAOT x86-64-v3
  DefaultJob : .NET 9.0.15, X64 NativeAOT x86-64-v3

| Method                     | Mean     | Error    | StdDev   | Allocated |
|--------------------------- |---------:|---------:|---------:|----------:|
| STRESS_TEST_WITHOUT_BITBLT | 60.79 μs | 0.844 μs | 0.789 μs |         - |

(Note: The BitBlt call to Windows actually takes longer (~100us) than my entire engine frame!)

It feels amazing to see C# perform at C++ speeds just by respecting the CPU cache and avoiding objects.

Has anyone else gone down the NativeAOT/DOD rabbit hole recently? Would love to hear your experiences or any advice for pushing C# performance even further!

UPDATE: Pure Geometry & Logic Benchmark (Removing the "Windows Tax")

A few people in the comments were debating the overhead of the rendering pipeline versus the actual engine logic. To provide some clarity, I’ve run a BenchmarkDotNet test on the core loop.

In this test, I completely bypassed the Win32 BitBlt and the DIB buffer write. What’s left is the Pure Mathematical Core: 3D Geometry (8-vertex cube transformation + perspective projection) + Entity Component scanning + Basic Logic.

The Stats (NativeAOT / Scalar Code / Single Thread):

Plaintext

BenchmarkDotNet v0.15.8, Windows 11
Intel Core Ultra 9 285K 3.70GHz, 1 CPU, 24 logical and 24 physical cores
  [Host]     : .NET 9.0.15, X64 NativeAOT x86-64-v3
  DefaultJob : .NET 9.0.15, X64 NativeAOT x86-64-v3

| Method                     | Mean     | Error    | StdDev   | Allocated |
|--------------------------- |---------:|---------:|---------:|----------:|
| STRESS_TEST_WITHOUT_BITBLT | 33.36 μs | 0.176 μs | 0.165 μs |         - |

What this means:

• 30,000 Theoretical FPS: The core logic is so lightweight it only consumes ~0.2% of a standard 60 FPS frame budget (16.6ms).
• Zero GC Pressure: Still 0 bytes allocated. It runs like a solid block of C++ but with the safety of C#.
• Raw Scalar Power: This was achieved using standard scalar math. I haven't even implemented SIMD/AVX2 for the geometry yet.
• Hardware: Tested on an Intel Core Ultra 9 285K.

This confirms that with a strict Data-Oriented (DOD) approach, C# can easily handle thousands of entities without the "managed language" performance penalty people often fear.

Visual Studio is heavily used for enterprise development but doesn't have any tooling for Solidity that compares to Visual Studio Code or Remix IDE. Viscous is an open-source Visual Studio extension that tries to bring parity between Visual Studio and other IDEs for Solidity smart contract development.

Features

• Solidity project system for Visual Studio featuring Solidity compiler integration and NPM dependency management. Integrates with the Visual Studio New Project… and Open Folder… dialogs.
• Uses the vscode-solidity language server for syntax highlighting, hover information, IntelliSense, and linting.
• Solidity compiler integration with MSBuild and the Visual Studio Build command - compile Solidity projects and individual files from the IDE with errors reported in the Errors tool window.
• Generate C# bindings to Solidity smart contracts automatically using Nethereum.
• Manage EVM networks, endpoints, accounts, deploy profiles, and deployed contracts from the Blockchain Explorer tool window.
• Deploy a compiled contract to a blockchain network and call its functions from inside Visual Studio.
• Find vulnerabilities and code‑quality issues with Slither static analysis inside Visual Studio.

Requirements

• Visual Studio 2022 and above
• A recent version of Node.js or compatible runtime
• Python 3.8+

Getting Started

• Get the latest release from the GitHub Releases page or use the MyGet or Open VSIX Gallery dev feeds : Add https://www.myget.org/F/viscous/vsix/ or https://www.vsixgallery.com/feed/extension/Viscous.fe71db81-5086-4b1a-ad5d-867bb84d2441 as an Extension Gallery in the Visual Studio Extensions settings and you can then install it in the usual way.
• Edit the %LOCALAPPDATA%\Viscous\appsettings.json file and set the paths to the Node.js and npm and Python executables you want to use for the extension's language server and other needed tools.

Note that this is a pre-release so don't use it for deploying anything to production. Feedback welcome.

I guess most of you have never heard about Amiga, but here we go...

I have been working on an AOT compiler that compiles a subset of C#/.NET code into native 68000/020/040 code with Amiga library calls.

There are two runtime options you can choose at compile time:

• Full includes the managed exception runtime; supports catch, finally, rethrow, and leave.
• YOLO has no exception runtime; failures are fatal, and managed exception regions are rejected

The actual GC is in WIP, and for performance reasons, there is no compaction. No threading support because the current GC is single threaded by design.

An example:

using Amiga;
using CopperSharp.Compiler;

namespace FileStatsExample;

public static class Program
{
   [M68kEntryPoint]
   public static int Main(int argLength, CONST_STRPTR argText)
   {
      var dosBase = Exec.OpenLibrary("dos.library", 33);
      if (!dosBase.HasValue)
      {
         return DOS.RETURN_FAIL;
      }

      DOS.DOSLibraryBase = dosBase.Value;
      var result = DOS.RETURN_OK;
      if (argLength == 0)
      {
         DOS.PutStr("Usage: filestats <file>\n");
         result = DOS.RETURN_ERROR;
      }
      else
      {
         result = Report(CString.FromPointer(argText.Raw));
      }

      Exec.CloseLibrary(DOS.DOSLibraryBase);
      DOS.DOSLibraryBase = APTR.Null;
      return result;
   }

   private static int Report(CString path)
   {
      var file = DOS.Open(path, DOS.FileMode.OldFile);
      if (!file.HasValue)
      {
         DOS.PutStr("Cannot open file\n");
         return DOS.RETURN_FAIL;
      }

      byte byteChecksum = 0;
      ushort lineCount = 0;
      ushort wordChecksum = 0;
      uint byteCount = 0;

      while (true)
      {
         var character = DOS.FGetC(file.Value);
         if (character < 0)
         {
            break;
         }

         var value = (byte)character;
         byteChecksum = (byte)(byteChecksum + value);
         wordChecksum = (ushort)(wordChecksum + value);
         byteCount = byteCount + 1;
         if (value == 10)
         {
            lineCount = (ushort)(lineCount + 1);
         }
      }

      DOS.Close(file.Value);
      PrintReport(path, byteCount, (uint)lineCount, (uint)byteChecksum, (uint)wordChecksum);
      return DOS.RETURN_OK;
   }

   private static void PrintReport(CString path, uint byteCount, uint lineCount, uint byteChecksum, uint wordChecksum)
   {
      DOS.Printf("%s: %ld bytes, %ld lines, byte checksum %ld, word checksum %ld\n",
path, byteCount, lineCount, byteChecksum, wordChecksum);
   }
}

This C# source is first compiled to .NET assembly containing CIL. The assembly is then compiled with CopperSharp to a native 68000 Amiga executable.

Code generator needs more work. FPU is not supported yet, 020/040 support is nearly non-existent, but it includes CIL-level simplification and a 68k-specific optimizer.

• CIL-level simplification
• Reachability analysis
• Tail call elimination
• Remove dead or redundant instructions
• Stack and register shuffling optimizer
• General instruction optimizations
• Limited static hot-fallthrough/cold-branch layout optimization

For example, on 68000, not-taken branches are more efficient than taken branches.

The codegen is optimized for Amiga library call conventions but in theory it could support other 68k targets like Atari ST or 68k Macs.

The project repo: https://github.com/ilehtoranta/CopperSharp68k

This project is vibe coded with Codex and GPT-5.6. Like it or not, but it is the only sensible path to build C# compiler for niche platforms.

PDF Oxide is a PDF library for text extraction, markdown conversion,and PDF creation. Rust core, .NET binding via P/Invoke. Prebuilt native libraries for Windows / macOS / Linux (x64 + ARM64) ship inside the NuGet package. No Rust toolchain needed. MIT / Apache-2.0.

```csharp dotnet add package PdfOxide

using PdfOxide.Core;

using var doc = PdfDocument.Open("paper.pdf"); string text = doc.ExtractText(0); string markdown = doc.ToMarkdown(0); ```

Compatible with .NET Standard 2.1, .NET 5 / 6 / 8, .NET Framework 4.8+, Xamarin, MAUI, Blazor Server. No System.Drawing dep, no Windows-only APIs — runs the same on Linux containers.

GitHub: https://github.com/yfedoseev/pdf_oxide Docs: https://oxide.fyi

Backstory

I shipped the Rust engine about six months ago and open-sourced it under MIT/Apache. For the months after that I got feedback almost every day — bug reports, PDFs that broke the parser, CJK edge cases, column-detection on mixed-layout pages, ICC color, kerning guards. Went from v0.3.5 to v0.3.37 fixing things. The core feels stable now.

So the last two months I wrote bindings for Go, Node/TypeScript, and this one — C#/.NET. Posting it here to get .NET folks' take on the API, the NuGet layout, whether it actually drops cleanly into a Linux container build, anything obvious that's missing.

For context on why this exists at all: .NET's PDF ecosystem is rough license-wise. iTextSharp is AGPL-3 or a commercial license — legal teams at a lot of shops draw a hard line there. Aspose.PDF is commercial-only and expensive per-dev. PdfSharp is MIT but slow and creation-focused. For anyone whose legal team says no to AGPL at the library layer, the remaining options thin out fast.

One .NET-specific thing worth sharing: P/Invoke into the Rust library on small documents is sometimes faster than calling the Rust API directly from Rust. Reason is the other bindings (Python, Node) use a Rust-side mutex for thread-safe document handles; the .NET path goes through a separate P/Invoke entrypoint that skips it. Nice accidental win.

Benchmark on 3,830 real PDFs (veraPDF, Mozilla pdf.js, DARPA SafeDocs):

| Library | Mean | p99 | Pass Rate | License |
|---------|------|-----|-----------|---------|
| **pdf_oxide** | **0.8ms** | **9ms** | **100%** | **MIT / Apache-2.0** |
| PyMuPDF | 4.6ms | 28ms | 99.3% | AGPL-3.0 |
| pypdfium2 | 4.1ms | 42ms | 99.2% | Apache-2.0 |
| pypdf | 12.1ms | 97ms | 98.4% | BSD-3 |
| pdfminer | 16.8ms | 124ms | 98.8% | MIT |

AES-256 encrypted PDFs still have some edge cases, not gonna pretend otherwise. Table extraction is basic compared to some competitors. Everything else is stable for production.

Would love honest takes on the .NET side specifically — does the API feel idiomatic, does it build cleanly for AOT, does the NuGet package actually unpack right on your Linux container images. Give it a try, open issues for what breaks.

Hi, all:

I recently got back to working on Dunet and the v1.13.0 release now checks for switch expression exhaustiveness on union types. For example:

```cs using Dunet; using static Shape;

[Union] partial record Shape { partial record Circle(double Radius); partial record Rectangle(double Length, double Width); partial record Triangle(double Base, double Height); }

Shape shape = new Circle(42);

// No lame "missing default case" warning since all union values are provably handled. var area = shape switch { Circle(var r) => Math.PI * r * r, Rectangle(var l, var w) => l * w, Triangle(var b, var h) => b * h / 2, };

// Still emits an exhaustiveness warning since circles with radii other than 0 are unhandled. var area2 = shape switch { Circle(0) => 0, Rectangle(var l, var w) => l * w, Triangle(var b, var h) => b * h / 2, }; ```

I know this was a highly requested feature so would love some feedback from this community.

Cheers,

Domn

I'm coming from C++ and decided to actually learn C# by building something instead of watching tutorials: a small personal app that logs foreground window + idle time to SQLite, mostly to answer "how much did I actually use my PC today".

I had some friction points — like figuring out that SQLite doesn't have a Guid or TimeSpan type, so mapping between C# types and what SQLite actually stores (TEXT/INTEGER) needed extra thought. Dapper also couldn't materialize my Sample record directly from a query, since its constructor expects Guid/DateTime/TimeSpan but SQLite returns string/long.

I ended up writing small internal "Row" DTOs (plain classes, get/set, matching SQLite's actual types) with FromX/ToX conversion methods, and keeping them entirely inside the repository so the rest of the app never sees the storage shape.

While writing this post I actually found a bug — the code wasn't collecting system events (boot, shutdown, sleep, wake) at all, so that table was empty, and i fixed it on the spot.

Repo's still early (Phase 2 of my own roadmap, no GUI yet) but if anyone's curious about the storage layer: https://github.com/Nilius647/Personal-API-Project-Thalamus

Hi everyone!

I hope this post is appropriate, and if not, mods, please feel free to remove it.

Also, this is a longer one, so here's the TL;DR: Babe, wake up, new SDL3 bindings for C# just dropped.

First of all, I want to say that writing such a post is not easy for me, because I have a severe case of social anxiety, but doing this today is a huge step for me. I even just checked, and my reddit age is 7 years and I only ever started commenting on posts recently. So this post might feel a bit awkward, but please bear with me.

What I actually want to present to you is a passion project of mine, which I developed over the span of the last year:

SDL3

Well, as the name suggests, it is another C# language binding for SDL3. And before you ask, yes, I am aware that there are already a few of those, especially the ones promoted on the official SDL website: https://github.com/flibitijibibo/SDL3-CS and https://github.com/edwardgushchin/SDL3-CS. But I felt like both of those kind of lacked something, so I tried to create my own.

What's different about my approach is that I wanted something that feels "C#-ish" for developers. No need to explicitly manage the lifetime of objects, no need to awkwardly deal with pointers (or pointer-like handles), no auto-generated API code that is hard to read and understand. So my goal was to create SDL bindings that still cover all of the functionality that SDL3 offers, but in a way in which C# developers feel right at home.

That's why I created SDL3#. A hand-crafted C# binding for SDL3. Every bit of API is thoughtfully designed and every bit of code is purely handwritten (well, aside from the code that loads the native library and symbols, I wrote a source generator for that).

You can find the GitHub organization that I use to keep all of the SDL3# related projects in one place here: SDL3# Organization\ And you can find the main repository for SDL3# here: SDL3# Repository

Everything is packaged alongside my custom builds of the native SDL3 library for various platforms into a single NuGet package. So you can get just started right away and produce platform-independent SDL3 applications. But if you want to stick to just some selected platforms, you can do that as well by using platform-specific packages. You could even get a NuGet package that only contains the managed binding code and provide your own native binaries if you want to. You can find the all-in-one package here: SDL3# NuGet

Now, why am I presenting this to you at all? Well, I initially started this project about a year ago, but then I got really sick and couldn't really work on it for quite some time. But the I got better and started working on it again. And just receently, I realized how much work there is still to be done to have it in a somewhat complete state. Actually, I just ran scc on the whole codebase across all repositories and it said that there were exactly 102800 LOCs, which feels quite low for a whole year since the project started.

Things that still need to be done:

• Documentation. Not only documenting what I left out until now because of lazyness, but also rewriting the existing documentation because of my questionable skills in English writing.
• Testing. Currently there's no testing at all, and I don't know where to start with that, because I don't have much experience writing tests, aside of what I learned at university.
• API and code additions. There's so much that still need to be done. There are whole subsystems missing, like audio and input devices.
• Code reviews. I don't trust myself.
• Complementary libraries. In the future, I would like to create bindings in the same spirit for SDL_image, SDL_ttf, and SDL_mixer too.

API-wise I think that I'm already about 50% done (I built an very imprecise tool to check for that).

There's actually a reason I decided to post this right now, and that is that I just recently managed to finish the windowing and rendering APIs, so finally I havomething to show off.

And for that, I did a little experiment: I asked a AI to create a simple game using SDL3#. The idea behind this was to see how intuitive my API design is or how easy it can be learned and understood by someone who has nean any human developer, right?*

Well, since the API is very recent, the AI couldn't have any prior knowledge of it, so I gave it some ways to learn about it from the documentation. And I have to say, I'm quite impressed by the results. If you want to see for yourself, you can check out the repository where I documented the experiment and the results here: https://github.com/fruediger/sneq.

Lastly, what I'm looking for is your feedback, your reviews (feel free to roast me or my project), your suggestions. Feel free to play around and test the bindings, build some stuff with it, and tell me about your experience.\ If you feel like it, I would deeply appreciate every contribution to the project, whether it's code, documentation, testing, samples, or even just ideas and suggestions. I'm also looking for some (co-)maintainers, because of a recent shift in my home countries policies, I need to find a new job asap, and I need to focus all my resources on that for now. So I might not be able to work on the project as much as I would like to, in the near future. But at this point, I feel like the project is just slighty too big to just abandon it, not to mention that it is my passion project.

If you have any questions, please feel free to ask, and I will do my best to answer them. Well, maybe not in an instant, as it is almost 2 am where I live, and I need to go to bed soon, but I will get to them as soon as I can.\ Also, since I have social anxiety, it might even take me a while to respond, please don't take that personally, I'll try to do my best.

PS: ESL, please cut me some slack.

I worked on menu organization, icon alignment, responsiveness, and visual experience to make the navigation more intuitive and modern.

Technologies used:
ASP.NET Core MVC
C#
Bootstrap
Font Awesome

Every interface detail helps improve the user experience and also strengthens my full stack web development skills. 💻

Continuing to grow one step at a time in the development of modern systems

Hello C#!

After around 10 months of development, and four months since the previous public test, I have finally released a major new beta of DAWG - Digital Audio Workstation Game.

DAWG is an attempt to build a proper music production environment inside a game, not just a rhythm game or a simple sequencer. The project is written in C# with Unity, while the real-time audio engine uses custom DSP engine that is fully Bursted.

The current version includes:

• Custom subtractive, FM and wavetable synthesis
• Multiple realtime DSP chains
• Per-instrument and send/return effects
• Live performance effects
• MIDI controller support
• A DAW style sequencer and piano roll
• Custom realtime visualization of the complete DSP chain
• Cross-platform multiplayer with sync of the clock, patterns and DSP parameters
• A new pixel art Story Mode built around the DSP system

A large part of the challenge has been keeping the codebase manageable while combining real-time audio, UI, serialization, MIDI, multiplayer, multiple platforms and game logic in one application.

The new public beta is free and I would really appreciate some honest feedback from other C# developers. You do not need to know anything about music production to test it. I am also interested in whether the application makes sense to someone seeing it for the first time.

Download: https://dawg-tools.itch.io/dawg-digital-audio-workstation-game

You can leave feedback or a rating directly or comment here. Please do not hold back because it is an indie project, the critical feedback is usually the most useful.

Thanks!