Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Request: GroovyMISTER output path #130

Open
star69rem opened this issue Jan 5, 2024 · 5 comments
Open

Request: GroovyMISTER output path #130

star69rem opened this issue Jan 5, 2024 · 5 comments

Comments

@star69rem
Copy link

https://github.com/psakhis/Groovy_MiSTer

The lack of front buffer rendering has always been an albatross around contemporary PC software's neck. GroovyMister allows you to use a Mister device as a GPU for a PC. There is an interface for the PC to send raw pixel data over the network to the Mister device.

You can get ~3ms of end to end latency with emulators/games because there's no vsync lag and no back/front buffer swapping. It would be awesome if Super Model could be updated to send the raw native resolution Model 3 pixel data to a Mister over the network for CRT output of the games at their native resolution with basically no lag. I think it would be pretty sexy.

More info:
http://forum.arcadecontrols.com/index.php/topic,168163.0.html
https://www.youtube.com/watch?v=PpUSyN1Wt6Q

@toxieainc
Copy link
Contributor

Just to help me understand: As Supermodel renders via GL, could there be even any noticable benefit? Cause from my understanding, there could only be a lag benefit if the emulator/game draws everything in software and then sends that over.

@star69rem
Copy link
Author

There are multiple benefits. The first one is compatibility. Anyone with a setup like this won't be able to use Super Model unless someone adds support for it. In terms of lag you should be able to get vsync off responsiveness since this solution doesn't even need a swap chain anymore. It's basically like having front buffer rendering.

@star69rem
Copy link
Author

image

Seems like a benefit to me.

@dukeeeey
Copy link
Collaborator

For fullscreen mode in windows it generally renders in exclusive mode, which is something you don't have direct control over with the opengl API. So there won't or shouldn't be any lag introduced by the compositor. It just sort of happens behind the scenes. You call swapbuffers, which blocks until vblank happens. The only possible benefit I could see is if u wanted to emulate the tilegen chip with a CRT, you could reduce the lag to less than a frame. Basically whatever the network latency was + transmission time accounting for the bytes/s. But honestly I don't think anyone would ever notice any difference. But you'd have to rewrite the emulator somewhat to make that happen, because the final image is a sandwich of the 3d and 2d. You'd have to split them and send them separately I think to really take advantage.

@star69rem
Copy link
Author

star69rem commented Jan 15, 2024

shows a screenshot of a conversation from Discord where someone literally did notice

"I don't think anyone will notice."

People are going to notice if they can run Super Model at all.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants