> What's the advantage of this approach vs cycle-accurate emulation? (I'd guess it can go faster, due to compiler optimization?)

I don't think anyone is doing it this way because they chose to do it this way. All the AI decomp/recomp projects I've seen recently have done it this way. It just seems an easy way to have an AI brute force "port" something.

▲

Retr0id 3 hours ago | parent [-]

This only works for something noninteractive that always executes the same code (unless I'm misunderstanding the LLM's description of what it did)

▲

bananaboy 3 hours ago | parent [-]

Ah yeah true, no I don't think you're misunderstanding. Actually sorry I misspoke - what I've seen in the game re/decomp projects is that the binary gets turned into a direct C implementation of the instruction stream, and it's basically a sort of emulation with CPU/memory state and emulation of whatever hardware it might need to talk to.

	▲	_the_inflator 2 hours ago \| parent [-]
		I agree on this description. It looks like a wrapper for an app alias demo, not a generalization for all app following the hardware possibilities at the time. On the other hand, at least these folks build and create and I prefer wrapper demos instead of a perfect emulator that will never finish. Nevertheless, on the feature side of these wrappers I really miss a fast-forward option. If you go pseudo-emulation, then at least come up with some convenience features. Maybe this is the irony: the ff button is perfectly legit, I used mine many times with the 486DX3-100 and Pentium 133. Back then it was called turbo button.