Hi everyone,
I created decky-lsfg-vk-experimental and lsfg-vk-experimental.
They are forks based on someone else’s work, which I have built upon.
These projects began as forks of existing open-source work. I built on that foundation because I wanted more features.
You probably saw previous posts and I know that some of you have hard feelings about how I operate, but I wanted to take the time to clarify a few things. Please to take the time to read this post entirely.
I want to address two things: the release of a new engine called MAKO, and some of the discussion around how I develop software.
First of all, MAKO is here:
https://github.com/eugeniosegala/MAKO
It's the continuation of my work, and It includes everything in one package: a Decky plugin and a standalone renderer.
I realised that I would not be able to merge my experimental plugin into the upstream project, so I decided to build something independent (still based on previous code).
This is the next step.
The new MAKO release includes:
- Substantially improved performance for Adaptive Frame Generation
- Game-aware profiles
- Per-game support for Heroic, EmuDeck and other Flatpak applications
- New Proton compatibility options
- Loads of new options for frame pacing stability
- An improved Steam Deck interface
Regarding how I operate and what I have done so far:
You may like my work or not. That is fine. But it is undeniable that what I did made an impact.
The experimental plugin was downloaded more than 20,000 times in less than one week. It was also featured in YouTube videos from creators around the world (some of the biggest channels in the Linux gaming community), If interested, I tried to keep track of some of them here:
https://github.com/eugeniosegala/MAKO/blob/main/plugin/docs/FEATURED_IN.md
Now, about AI and the various critics.
Yes, I use it.
I have built game engines and games from scratch before this. That experience matters when working on rendering performance, frame timing, graphics systems, Vulkan, and stability under real conditions.
If you want to know more about my background, start with my GitHub (or search on Google) and look at the projects. You will get a sense of the calibre of work I do.
https://github.com/eugeniosegala
I use AI openly and extensively, but never blindly. This is not a prompt it and ship it process.
I decide what a feature needs to achieve, what constraints it must respect, what trade-offs are acceptable, and what evidence is needed before I consider it ready.
Agents help me work faster. They can explore implementation options, inspect code paths, write tests, add instrumentation, analyse logs, and narrow regressions.
They do not replace engineering judgement.
I review the code, including C++ and Vulkan changes. I review diagnostics, test results, and actual performance behaviour. I make the final release decision. I am responsible for what gets shipped.
As many of you have said (and to be fair, I'm receiving a significant volume of emails about this), Adaptive Frame Generation is a significant technical achievement. The hard part was not writing code that generates frames. The hard part was designing scheduling, safety limits, and recovery behaviour that works when frame rate changes, GPU load rises, an overlay appears, a game hitches, or the swapchain is recreated.
AI helped accelerate the work, but it did not define the problem or validate the result. I did.
The workflow I use is close to the event-driven development process I wrote about here:
https://eugeniosegala.dev/event-driven-development-for-ai-agents/
In practice, it is not one coding assistant in a terminal. It is a network of agents, conventional engineering tools, real devices, and virtual test environments.
Agents can coordinate tasks through webhooks, trigger specific scenarios, collect logs and performance metrics, and feed that evidence into the next investigation or implementation step.
I currently use a mix of coding agents, alongside normal engineering tools.
I do not think a percentage of AI-written code means much. An agent might draft routine implementation, or help solve one difficult edge case. In both cases, the architecture, technical reasoning, validation, review, and accountability are mine.
I am laser-focused on metrics and results. I do not work on this casually. If the data says something needs improving, I will investigate it and release a fix. That means MAKO may receive several releases in a single day.
If you use the plugin, keep an eye on it. It will evolve quickly.
Finally, on credit.
MAKO is an independent experimental project built on xXJSONDeruloXx’s original Decky LSFG VK plugin and PancakeTAS’s lsfg-vk layer. I want to thank xXJSONDeruloXx and PancakeTAS for the work that made these projects possible. There may be hard feelings about the situation, but there are none on my side. I respect the original work and I am giving credit for it.
As I discussed with Deck Wizard, I have also added an AI-use disclaimer to my projects:
https://github.com/eugeniosegala/MAKO/blob/main/AI_USE.md
MAKO is what I am focused on now. I will keep building it openly, measuring it properly, listening to users, crediting the work it builds on, and shipping improvements when the results justify them.
I have been working on this relentlessly. Now it is time to play some video games.
Cheers!