<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Code Generation on Martiiin's site</title><link>https://martiiin.net/blog/code-generation/</link><description>Recent content in Code Generation on Martiiin's site</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Tue, 09 Jun 2026 12:00:00 +0000</lastBuildDate><atom:link href="https://martiiin.net/blog/code-generation/index.xml" rel="self" type="application/rss+xml"/><item><title>Reflecting SPIR-V to generate C# code</title><link>https://martiiin.net/reflecting-spir-v-to-generate-c%23-code/</link><pubDate>Tue, 09 Jun 2026 12:00:00 +0000</pubDate><guid>https://martiiin.net/reflecting-spir-v-to-generate-c%23-code/</guid><description>&lt;p&gt;This is a post about my experience reflecting SPIR-V shader code to generate C# code!&lt;/p&gt;
&lt;h3 id="problem"&gt;Problem:&lt;/h3&gt;
&lt;p&gt;anyone who has worked with shader programming probably knows about the headache of memory layout, and how updating a datatype in the shader doesnt update the corresponding datatype in your engine code.
this usually doesnt throw an error, so you can forget about it, continue working, and everything seems fine until something unrelated breaks and you have no idea why, only to find out the memory layout was wrong the whole time.&lt;/p&gt;</description></item></channel></rss>