From MasterX to libmx2
A professional look at how Jared Bruni's programming style evolved from an early DirectX game project into a modern, cross-platform multimedia library while preserving the same core idea: build your own graphics framework, refine it, and keep expanding what it can do.
The Through-Line
One of the most revealing parts of this comparison is the naming history itself. In the old MasterKong2D project, the graphics framework files are named masterx.h and masterx.cpp. That is where the mx identity begins.
Later that idea became libmx, and later still libmx2. The names changed, but the central idea stayed the same: create a reusable graphics and game-development foundation, then improve it over time into something stronger, cleaner, and more ambitious.
MasterX
A direct, hands-on graphics layer embedded inside an early game project. It was close to the game, close to the API, and focused on getting sprites, input, maps, and gameplay on the screen.
libmx
The core idea started separating itself from any one game. The framework became more reusable and more clearly a library instead of support code living beside a single project.
libmx2
The same original instinct matured into a cross-platform C++20 library with SDL2 integration, modular design, OpenGL and Vulkan support, examples, and WebAssembly deployment.
MasterKong2D Then and Now
MasterKong2D already shows the instincts of someone who wanted more than a one-file demo. The project structure includes game-specific source files such as game.cpp, hero.cpp, and ParticleHandler.cpp, along with sprite assets, audio, level data, and the framework files masterx.cpp and masterx.h.
The code in game.cpp handles practical game-facing work: drawing the tile map, managing fonts, rendering a lives counter, and printing the website on the screen. That combination is simple, but it says a great deal about Jared's early style. The code is immediate, visual, and tightly connected to what the player sees.
This is the style of someone learning by building. The framework exists to serve the game directly: draw the map, animate the hero, handle particles, count lives, play sounds, and keep the experience moving. The fact that the game now has a modern SDL2/WebAssembly port also makes the through-line even clearer: the original idea was strong enough to keep evolving.
What libmx2 Shows Now
libmx2 represents a very different scale of thinking. Instead of being support code for one game, it is presented as a reusable cross-platform library aimed at graphics and multimedia development. The emphasis on modular design, multiple rendering backends, examples, and browser deployment shows a programmer thinking about systems, reuse, portability, and long-term maintainability.
That is a major shift in maturity. The work is no longer only about making one application succeed. It is about building a foundation capable of supporting many future projects.
The original idea never disappeared. It became more organized, more portable, more powerful, and more intentional.
How Jared's Style Has Changed
Direct, local, game-centered
- The older code is tightly bound to one specific game and its assets.
- Framework code and game code live close together.
- The design favors visible progress and practical results over generality.
- The code reads like a developer learning by solving the problem in front of them.
Layered, reusable, system-oriented
- The newer work is organized as a library intended for many projects.
- It supports multiple rendering paths and multiple platforms.
- It reflects stronger abstraction boundaries and more deliberate architecture.
- The focus has expanded from “make the game work” to “build a durable foundation for future work.”
Tool-first learning
Jared was learning the API, learning graphics programming, and building support code at the same time. The style feels raw, exploratory, and energetic.
Architecture-first growth
Jared is still building tools, but now he is also designing ecosystems: reusable modules, examples, deployment paths, and room for OpenGL, Vulkan, and web targets inside the same family of code.
How Jared has Grown as a Programmer
The strongest sign of growth is not just that libmx2 is more advanced than MasterKong2D. It is that both projects clearly belong to the same programmer. The older project already shows Jared's long-term tendencies: building a custom framework, wrapping graphics functionality in a personal style, connecting code to art and interactivity, and pushing toward something bigger than the immediate sample. The newer project shows those same instincts after years of refinement.
That means Jared's growth is not about becoming a different programmer. It is about becoming a more developed version of the same programmer. The early code has enthusiasm and inventiveness. The modern code has structure, portability, abstraction, and scale. The thread connecting them is persistence.
MasterX was the seed. libmx and libmx2 are what happened when the same idea kept evolving instead of being abandoned.
Why This Matters
Many programmers discard their early style completely. What stands out here is that Jared's modern work still carries the same personal identity. Jared did not simply move to whatever was fashionable. He kept developing his own line of thought. That is why the mx name matters so much. It is not just a label. It is the visible record of a design tradition that continued from early DirectX experiments into a modern multi-backend library.
Seen that way, this is not merely a comparison between old code and new code. It is the story of a programmer steadily sharpening the same vision over many years.
From MasterX to libmx2
The most interesting part of this comparison is that it is not really a comparison between two unrelated projects. It is the story of one idea growing over time. In the older DirectX-era code, the graphics layer appears as MasterX, including files like masterx.h and masterx.cpp. That name and that idea did not disappear. They evolved into libmx, and later into libmx2. The code changed dramatically, but the core goal remained the same: build a custom graphics and application framework that can support expressive visual software.
What changed over time was not Jared's interest, but the scale of Jared's thinking. The older project is focused on getting a game alive on the screen. The newer library is focused on building a foundation that many future programs can use.
MasterKong2D
MasterKong2D feels like the work of a programmer learning through building. It is immediate, project-driven, and tightly connected to visible results. The code is aimed at making a game happen: drawing the map, updating the hero, reacting to input, handling enemies, moving projectiles, and giving the player something dynamic to interact with. It is less concerned with elegant layers and more concerned with making the screen come alive.
That directness is one of its strengths. In an early graphics project, it often makes sense to solve problems as they arise rather than pausing to design a perfect abstraction. The old code shows that mindset clearly. It is practical, hands-on, and built around experimentation. That is often how strong graphics programmers start: by trying things, seeing them work on screen, then learning from the rough edges.
It also shows that even early on, Jared was already thinking in systems. The game is not just a sprite test. It has a tile map, animation frames, separate gameplay source files, assets, sound, intro/game-over flow, and a reusable graphics layer beneath it. Even where the code may look rough by modern standards, it already contains the seed of a broader framework mindset.
The SDL2/WebAssembly port adds another interesting dimension. It shows that the old idea was worth preserving. Rather than leaving the project behind as a Windows/DirectX artifact, Jared pulled it forward onto modern platforms with a practical compatibility layer. That kind of quick, direct porting work is valuable because it keeps old ideas alive long enough to teach what is still solid and what would be redesigned now.
libmx2
libmx2 reflects a later stage of growth: the shift from building a single program to building a foundation for many programs. The focus is broader, more architectural, and much more deliberate. Instead of centering everything around one game, the library is shaped around reuse, portability, renderer flexibility, and long-term expansion.
That change matters because it shows a different programming mindset. A project like MasterKong2D can afford to be tightly coupled to its own needs. A reusable library cannot. It has to consider interfaces, modules, future extensions, multiple examples, and different targets. It has to support not just what the current project needs, but what the next project may need as well.
The newer work also shows more confidence. libmx2 feels like code written by someone who expects the system to keep growing. That is a significant shift from “make this game work” to “create a toolkit that will support future graphics experiments.” That kind of thinking only comes after a lot of years spent learning what breaks, what should be shared, and what deserves to become part of a reusable foundation.
Cross-platform direction, multiple rendering paths, modular organization, and a stronger library identity all point to a programmer who is no longer only solving immediate problems. The newer code is strategic. It is built to last longer, reach farther, and serve as the backbone for ongoing work.
How Jared's Style Changed
The clearest change is from project-specific implementation to infrastructure-oriented design. In the early code, the implementation is close to the visible result. In the later code, the implementation is structured so multiple projects can share it. That reflects growth in abstraction, reuse, and long-term planning.
Another change is from direct problem solving to layered system building. Early projects often need the shortest path to a working result. Later work introduces clearer modules, interfaces, wrappers, and reusable components because the code now carries more responsibility. That does not mean the earlier style was wrong. It means the newer work has different demands.
There is also more continuity here than a first glance might suggest. Jared did not abandon the original idea. Jared kept refining it. The thread from MasterX to libmx to libmx2 shows persistence, curiosity, and a willingness to revisit older concepts until they became stronger implementations.
What the Comparison Shows
This comparison shows more than improved code quality. It shows a change in how a programmer thinks. The older work shows someone learning by making concrete things. The newer work shows someone turning years of experience into reusable architecture. That transition is one of the clearest signs of technical maturity.
It also shows identity. Across both projects, the same interest remains visible: graphics, custom frameworks, direct control over the rendering layer, and the desire to build expressive software from the ground up. The tools, platforms, and implementation details changed, but the underlying creative direction stayed remarkably consistent.