-
Notifications
You must be signed in to change notification settings - Fork 3
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
Investigate multi-cog vs dedicated PPU video generation approach #20
Comments
@konimaru I'm definitely interested in discussing what you discuss in this thread if you have the time: http://forums.parallax.com/discussion/126874 |
Ah, that one. I felt a bit odd replying to myself :) Anyway, what are you after? |
Thanks! I guess first off, what's the final "verdict" you reached on fully deterministic and synced waitvid timing? I see you go through quite a few iterations of solutions, and in your final version you freeze the video hardware before changing vscl. Does that have to be done for every change of vscl (for example changing for vertical blanking lines and HSync) or just initially? What's the final stream of consciousness explanation for the issues people have classically had with achieving fully deterministic timings? Is it still fundamentally rooted in what Linus Akesson discusses here? |
Let me ponder this for a while. This is really old stuff and these days I simply use it. |
@konimaru Haha understood, no problem! I'm working on getting the general structure of this refactor together right now, so no rush! |
@konimaru I've managed to implement a cog sync method (based on your and Linus's legwork) that's at least as good as it needs to be. I'm not going down the rabbit hole of WHOP methodology at this stage, and likely won't in the future, as the resolutions I'm working with don't require that kind of time-shaving and code obfuscation. I'm still interested in the odd behavior exhibited by the video generation hardware. As far as this issue goes, I've chosen to go with a multi-cog approach over one requiring a dedicated PPU. My graphics demands simply aren't high enough to warrant a PPU, and at this point I've managed to wrap my head around the multi-cog approach enough to implement it. |
This paradigm ended up being chosen as the way forward, as "my graphics demands simply aren't high enough to warrant a PPU" turned out to be an outright lie. |
Current driver has to render faster than it can load the next tile/color at high tile dimensions, and adding the sprite rendering feature will only exacerbate this. The benefits of spreading the rendering of each line over multiple cogs vs having a dedicated PPU with screen buffer need to be investigated.
The text was updated successfully, but these errors were encountered: