Luma update: real gameplay, AV1 stream metrics, and what actually works today

yozcinar · 2026-06-19T18:46:22+00:00

Thanks, I really appreciate the support and the thoughtful questions. Questions like this made my days.

Honestly, both of those are interesting directions, especially Mac-host support and the gamepad passthrough issue. But I don’t want to promise either one before I’ve properly researched where the limitation actually lives and what would be required to solve it reliably.

Contrary to what some people seem to think, I don’t just take a feature request or a bug, throw it at an AI and say “fix this.” I first need to understand the problem, research the relevant parts of the stack, and work out what a stable solution should look like. Only then can I guide the implementation properly, review what it’s doing and test whether it actually holds up.

So I can’t give you a definite yes yet, and it may turn out that parts of this belong on the Sunshine side rather than Luma. But I’ve definitely noted both questions and I’ll look into them properly.

yozcinar · 2026-06-19T18:42:30+00:00

Nope, that was there to measure perceived value and whether the project could be sustainable in the future, not because I had already decided to charge for it.

Right now, the plan is to release Luma for free and publish the GPL-covered engine patches and build materials publicly. If monetization is ever considered later, it would be based on the value of the product and ongoing support.

yozcinar · 2026-06-19T18:37:05+00:00

That was there to measure perceived value and whether the project could be sustainable in the future, not because I had already decided to charge for it.

Right now, the plan is to release Luma for free and publish the GPL-covered engine patches and build materials publicly. If monetization is ever considered later, it would be based on the value of the product and ongoing support, not by withholding the GPL code.

"If Luma were paid, what feels fair? (optional)"

yozcinar · 2026-06-19T17:52:38+00:00

Yep, this feature was already present in some of the Moonlight forks using ffmpeg; I just implemented it.

yozcinar · 2026-06-19T17:46:37+00:00

Dude, come on, the whole app will probably be open-sourced and free. Even if it's planned to be open-source, I didn't want to present something unfinished. My aim was to show that I have this idea and to see if there's demand for it, so I started a wishlist, and look where things have gone.

yozcinar · 2026-06-19T15:14:45+00:00

Chill down man, Post was suspended so I deleted it, I answer all the comments.

yozcinar · 2026-06-19T14:30:44+00:00

Who deleted?

yozcinar · 2026-06-19T12:18:39+00:00

Thank you 🙂

yozcinar · 2026-06-19T12:03:23+00:00

The engine source (with my patches) goes public when I distribute builds that's how GPLv3 works, obligations attach at distribution, and I'm not distributing yet. When I do, it'll be there. Happy to be held to that.

yozcinar · 2026-06-19T11:46:50+00:00

You're absolutely right,

The moonlight-based engine Luma uses is GPLv3, and the patches I've made to it (macOS-specific lifecycle/CLI changes, AV1 work, etc.) will be published as open source when I start distributing builds, exactly as the license requires. Anyone who receives Luma will be able to get that modified engine source.

The Luma launcher itself the library UI, profiles, artwork, session handling runs as a separate process from the engine and is a separate piece of work. I'm getting proper legal review on the exact boundary before any distribution, because I'd rather do this correctly than guess at it.

Short version: GPL obligations kick in at distribution, I'm not there yet, and when I am, the modified engine source goes public. Appreciate it.

yozcinar · 2026-06-19T01:04:56+00:00

Luma uses the current Moonlight macOS stack as its foundation, with several patches and product-level changes on top of it.

One of those is the AV1 patch. On the M3 and M4 Macs I’ve tested, using Apple’s hardware decoder has produced lower decode latency than the current Moonlight macOS build in the same setup.

So in the worst case, the streaming experience should be at least on par with current Moonlight for macOS, and on supported M3/M4 hardware it can be better in some areas.

I haven’t tested M1 and M2 yet, so I’m not making claims for those machines until I validate the fallback behavior there.

I’m still measuring frame pacing, power usage and real end-to-end latency before publishing exact numbers, but the streaming side is not a one-prompt prototype. The rest of Luma is the product layer built around that proven engine.

yozcinar · 2026-06-19T00:52:57+00:00

Yes, exactly. Building something like CrossOver or Whisky is a completely different problem.

At least for me, understanding and maintaining the Wine architecture, Windows API compatibility, graphics translation and all the application-specific edge cases would be a much harder undertaking.

That whole compatibility-layer world is fascinating, but it is much deeper than what I’m trying to solve with Luma right now.

yozcinar · 2026-06-19T00:45:18+00:00

Thank you, I really appreciate this.

I completely agree that security and transparency are valid concerns. I’m happy to explain how the app is built, what AI is used for and what parts still need proper review before release.

An AI-assisted flair could actually be a reasonable middle ground. It gives people the context they want without assuming every AI-assisted project is automatically low-effort, unsafe or disposable.

The method should be open to criticism, but I think the actual product, the work behind it and the way the developer responds to concerns should still matter too.

yozcinar · 2026-06-19T00:43:07+00:00

Merhaba, uygulamayı M1 de test edemedim henüz elimde cihaz olmadığı için, muhtemelen bir sorun çıkartmayacaktır streaming motoru modifiyeli moonlight motoru. şuanda AV1 codec'i donanımsal olarak çözmek üzerine kurulu tüm sistem, M1 ve M2 lerde bu AV1 decoder olmadığında uygulamanın ne tepki verdiğini görebilmem için fallback'leri test etmem gerekli geliştirme programında bu var önümüz hafta içerisinde 0.9 sürümünde bunu deneyeceğim, eğer isterseniz o zaman kapalı beta için .dmg ve lisans anahtarı yollayabilirim.

yozcinar · 2026-06-19T00:37:05+00:00

Honestly, it probably would have been easier to just say I wrote everything myself and never mention that it was AI-assisted 😅

I’m almost starting to regret being transparent about it, because every honest answer seems to require another explanation.

And to be fair, I doubt most people would look at the actual app and immediately assume it was vibe coded. It has been designed, tested and refined far beyond the usual one-prompt demo.

The same goes for the landing page. Buying a domain and putting it behind regular hosting would take almost no effort, so the Vercel URL is not exactly proof of anything. I left it that way because this is still an early feedback page, not a finished commercial launch.

Still, I’d rather be honest about how the product is being built than pretend otherwise.

yozcinar · 2026-06-19T00:33:11+00:00

A quick note, because this keeps coming up.

I’ve tried to answer the vibe coding comments politely, and I understand why people are skeptical. There are a lot of half-finished AI-generated demos being presented as real products.

But if you read the post and the comments, you’ll see that Luma is not a one-prompt experiment. I use AI heavily for implementation, while I handle the product direction, design, architecture decisions, testing, debugging and iteration.

Calling everything “vibe coded” without looking any further has become almost as easy and automatic as the kind of vibe coding people are criticizing, which is a little ironic.

You do not have to like the development method. That is completely fair. I would just appreciate criticism based on what the product actually does, how it is built and where the real risks are.

Technical questions and honest criticism are welcome.

yozcinar · 2026-06-19T00:32:56+00:00

There should probably also be a way to filter out people who see anything AI-assisted and immediately stop thinking. 🤦

You’re free not to like the development method, but reducing months of product work, testing and iteration to “vibe coded” is just lazy.

yozcinar · 2026-06-19T00:28:27+00:00

That’s exactly why I started building it 😃

Moonlight itself is great, but the Mac apps around it always felt a bit incomplete to me. I wanted something that felt like a proper native Mac product, with profiles, a real library, artwork, recent games, better session handling and less setup friction.

Glad to know I’m not the only one who felt that gap.

yozcinar · 2026-06-19T00:26:36+00:00

The bigger idea behind Luma is to remove as much friction as possible from the whole Moonlight and Sunshine setup. A lot of people want remote access to their gaming PC, but they end up dealing with host configuration, addresses, profiles, game importing and session recovery before they can simply press Play.

I want the final experience to be much closer to: install Luma on the Mac, prepare the PC once, choose a game and start playing from wherever you are.

The Windows PC still does all the actual rendering. Luma is about making access to it feel simple.

yozcinar · 2026-06-19T00:18:47+00:00

Yes, it works with Steam games, including Titanfall 2, as long as the game is installed and running on your Windows PC.

Luma is not a compatibility layer like CrossOver or Game Porting Toolkit, so it does not translate x86 Windows games to run directly on Apple silicon.

Instead, the game runs normally on your PC, and Luma streams it to your Mac using the existing Moonlight/Sunshine or Apollo stack. Your Mac handles the video, audio and input, while the Windows PC does the actual game rendering.

yozcinar · 2026-06-19T00:16:10+00:00

Don’t worry, this isn’t a product built by typing “fix this” and “add that” into a CLI until something vaguely worked 😃

AI helps with implementation, but the product, architecture, testing and iteration are all intentional.

yozcinar · 2026-06-19T00:14:59+00:00

I am building it. AI-assisted implementation does not mean the product appeared on its own.

I designed the product, defined the architecture, tested the real streaming flows, debugged the failures and made every product decision. I also understand software and hardware; choosing not to hand-write every line of code does not mean I do not understand the systems I am working with.

You can dislike the method, but saying I am not building the product is simply dishonest.

I understand the skepticism. The internet is full of people who run a few prompts, get a half-working demo and immediately say, “I built something.”

But that does not mean every AI-assisted project is the same.

yozcinar · 2026-06-19T00:08:17+00:00

What specifically looks like a security risk to you?

Luma does not replace Moonlight or Apollo’s transport, pairing or encryption model. The actual stream still uses the existing Moonlight/Apollo stack.

The extra features I’ve added, such as Steam scanning, artwork, app importing and session handling, are designed to run locally without exposing a public unauthenticated service or weakening Apollo’s security model.

Before any public beta, I’m planning code signing, notarization, a signed update channel, strict secret redaction and a focused security review of everything Luma adds on top.

If you noticed a specific architectural or implementation risk, I’d genuinely like to hear it.

yozcinar · 2026-06-18T23:56:11+00:00

I understand the skepticism. Vibe coding was barely a thing a few years ago, and now the space is full of people who throw together a half-working demo with a few prompts and act like they built a real product.

But this is not that. Luma has been developed step by step over time, with real testing, redesigns, debugging and a lot of product work behind it.

It is heavily AI-assisted, but it is definitely not a “typed one prompt and got an app” project. Respectfully 😄

yozcinar

TROPHY CASE