Rich Talbot-Watkins

I've thought for a while that a great feature for an emulator would be an intelligent (of sorts) disassembler built-in, much in the vein of the thing you once wrote...

I can imagine just the incremental complexity of tracking more stuff would start to become significant (particularly more complex stuff like tracking where bytes come from which ultimately end up...

Also consider that paging messes things up a bit; the addresses used would have to be the flattened ones so they could all coexist. There are other disassemblies too, e.g....

I think it's certainly feasible (I thought about it lots when I was starting out on a C++ implementation of jsbeeb - never have been that happy with JS! -...

Not that there's any reason why all this stuff _couldn't_ be tracked of course. But then you have the multiple universes of distinct disassemblies, and I figured that the model...

I don't think I'd bother keeping it TBH. If it's more useful to see the entire screen then that's what it should do. Sometimes a million configurable options just needlessly...

That said, this isn't obviously easy to fix, because it's an inevitable consequence of clearing the texture at the start, instead of blanking scanlines as they're rasterised. This gave a...

If I set the render driver hint to `direct3d11` or `direct3d12`, the terrible performance is gone, but it still doesn't look as smooth as it should. I guess the next...

Confirmed: `gpu` gives me the same terrible performance as I was seeing by default. To try to quantify "terrible" a bit better, a rapid resize of the window takes about...

@thatcosmonaut Yeah I understand that on a window resize, it's necessary to wait for the gpu fence, and then resize the swap chain, and create new back buffers. However this...