﻿<?xml version="1.0" encoding="utf-8"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0">
  <channel>
    <title>Celso Jr</title>
    <link>https://celsojr.com</link>
    <description>Recent posts on Celso Jr's blog</description>
    <generator>Blazor WASM</generator>
    <language>en-us</language>
    <copyright>(c) 2022-current Celso Jr</copyright>
    <lastBuildDate>Thu, 02 Apr 2026 00:00:00 +0400</lastBuildDate>
    <atom:link href="https://celsojr.com/rss.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Pixel Perfect — Part 3: PNG Writer</title>
      <link>https://celsojr.com/post/pixel-perfect-part-3-png-writer</link>
      <guid>https://celsojr.com/post/16</guid>
      <pubDate>Thu, 02 Apr 2026 00:00:00 +0400</pubDate>
      <description>Part 1 rendered pixels. Part 2 organized them. Now Part 3 makes them real. This post builds a PNG writer from scratch—IHDR, IDAT, IEND, CRC32—using nothing but C# and the spec. No libraries, no shortcuts, just bytes becoming an image.</description>
    </item>
    <item>
      <title>Pixel Perfect — Part 2: OOP Render</title>
      <link>https://celsojr.com/post/pixel-perfect-part-2-oop-render</link>
      <guid>https://celsojr.com/post/15</guid>
      <pubDate>Wed, 01 Apr 2026 00:00:00 +0400</pubDate>
      <description>Encapsulation keeps data hidden. Inheritance reuses logic. Polymorphism lets objects behave differently. This post builds an OOP scene with IRenderable, Shape, and Renderer—then shows how it all collapses to raw loops when it's time to render.</description>
    </item>
    <item>
      <title>Pixel Perfect — Part 1: Imperative Render</title>
      <link>https://celsojr.com/post/pixel-perfect-part-1-imperative-render</link>
      <guid>https://celsojr.com/post/14</guid>
      <pubDate>Tue, 31 Mar 2026 00:00:00 +0400</pubDate>
      <description>C# gives you for, if, and byte[]. That's all you need to render a frame. This post strips away the abstractions and stares directly at the imperative loop that fills pixels—because sometimes the fastest path is the simplest one.</description>
    </item>
    <item>
      <title>PartitionWith in C#</title>
      <link>https://celsojr.com/post/partition-with-in-csharp</link>
      <guid>https://celsojr.com/post/13</guid>
      <pubDate>Fri, 13 Mar 2026 14:00:00 +0400</pubDate>
      <description>F# gives you partitionWith out of the box. In C#, you can keep the same semantics with a tiny helper that preserves intent and keeps the call site clean.</description>
    </item>
    <item>
      <title>Memory Regions - Virtual Memory</title>
      <link>https://celsojr.com/post/memory-regions-virtual-memory</link>
      <guid>https://celsojr.com/post/12</guid>
      <pubDate>Fri, 01 Aug 2025 12:00:00 +0400</pubDate>
      <description>Learn how virtual memory powers modern games and engines—streaming massive textures, improving stability, and simulating memory beyond RAM using paging, swap files, and on-demand loading.</description>
    </item>
    <item>
      <title>Memory Regions - Registers</title>
      <link>https://celsojr.com/post/memory-regions-registers</link>
      <guid>https://celsojr.com/post/11</guid>
      <pubDate>Wed, 16 Jul 2025 12:00:00 +0400</pubDate>
      <description>What makes CPU registers so fast? This post explains their role, how they differ from cache, and why modern runtimes and compilers use them for top performance—with real C and assembly insights.</description>
    </item>
    <item>
      <title>Memory Regions - Cache</title>
      <link>https://celsojr.com/post/memory-regions-cache</link>
      <guid>https://celsojr.com/post/10</guid>
      <pubDate>Wed, 25 Jun 2025 12:00:00 +0400</pubDate>
      <description>Cache is fast, temporary memory that speeds up access to data by storing what's used most—making systems feel snappy.</description>
    </item>
    <item>
      <title>Memory Regions - Code Segment</title>
      <link>https://celsojr.com/post/memory-regions-code-segment</link>
      <guid>https://celsojr.com/post/9</guid>
      <pubDate>Sun, 23 Feb 2025 12:00:00 +0400</pubDate>
      <description>The code segment, or .text segment, is a read-only region of memory that contains the compiled machine code of a program.</description>
    </item>
    <item>
      <title>Memory Regions - Static</title>
      <link>https://celsojr.com/post/memory-regions-static</link>
      <guid>https://celsojr.com/post/8</guid>
      <pubDate>Sat, 22 Feb 2025 12:00:00 +0400</pubDate>
      <description>Static memory, like a public notice board, stores global and static variables for a program's lifetime. It's efficient but can risk memory leaks and bugs.</description>
    </item>
    <item>
      <title>Memory Regions - Heap</title>
      <link>https://celsojr.com/post/memory-regions-heap</link>
      <guid>https://celsojr.com/post/7</guid>
      <pubDate>Fri, 21 Feb 2025 12:00:00 +0400</pubDate>
      <description>The heap offers flexible memory but lacks automatic cleanup. It's larger yet slower than the stack, and mismanagement can lead to leaks and performance issues.</description>
    </item>
    <item>
      <title>Memory Regions - Stack</title>
      <link>https://celsojr.com/post/memory-regions-stack</link>
      <guid>https://celsojr.com/post/6</guid>
      <pubDate>Thu, 20 Feb 2025 12:00:00 +0400</pubDate>
      <description>Stack memory operates in a Last In, First Out (LIFO) manner, making allocation and deallocation fast and automatic, but it has a limited size and can cause stack overflow if exceeded.</description>
    </item>
    <item>
      <title>Memory Regions</title>
      <link>https://celsojr.com/post/memory-regions</link>
      <guid>https://celsojr.com/post/5</guid>
      <pubDate>Wed, 19 Feb 2025 12:00:00 +0400</pubDate>
      <description>Memory management is crucial in programming, affecting performance and stability. This series explores key memory regions—stack, heap, static/global memory, code segment, cache, and registers—to help developers optimize allocation and avoid common pitfalls.</description>
    </item>
    <item>
      <title>Closures - Part 2: Performance implications</title>
      <link>https://celsojr.com/post/closures-performance-implications</link>
      <guid>https://celsojr.com/post/4</guid>
      <pubDate>Thu, 25 Apr 2024 12:00:00 +0400</pubDate>
      <description>If you're coding in a resource-saving mission-critical way and want to avoid the default closure capture for any reason, consider reading further.</description>
    </item>
    <item>
      <title>Closures - Part 1: Lifting the hood</title>
      <link>https://celsojr.com/post/closures-lifting-the-hood</link>
      <guid>https://celsojr.com/post/3</guid>
      <pubDate>Wed, 24 Apr 2024 12:00:00 +0400</pubDate>
      <description>Closure is not something new. In fact, closures has been around for several years. Pretty much all programming languages have closures.</description>
    </item>
    <item>
      <title>Avoiding Boxing</title>
      <link>https://celsojr.com/post/avoiding-boxing</link>
      <guid>https://celsojr.com/post/2</guid>
      <pubDate>Wed, 13 Dec 2023 12:00:00 +0400</pubDate>
      <description>Boxing involves allocating memory on the heap for the boxed object. In scenarios where memory usage is critical, minimizing unnecessary boxing helps in keeping memory consumption under control.</description>
    </item>
    <item>
      <title>Hello world</title>
      <link>https://celsojr.com/post/hello-world</link>
      <guid>https://celsojr.com/post/1</guid>
      <pubDate>Mon, 25 Apr 2022 12:00:00 +0400</pubDate>
      <description>Coming back with my blog/site after a short break. Life changes, things change, the only thing that never change is my appetite for technology.</description>
    </item>
  </channel>
</rss>