Moving some stuff to various PS2-components will hopefully yield a very good performance!
The GS itself has quite some capability and moving some executions onto it, would yield a lot of CPU-cycles to be free'd up and less interrupts to "disturb" the emulation.
The same would apply to moving stuff to the VUs, the FPU, and rather TLB-Tricks to set up the Hardware, instead of continous "transfers"... The last thing would not spare RAM, but would decrease latencies caused by interrupts and these are one of the most crucial things, which affect/limit emulation.
I suppose by Macros you mean "ahead of time" compilation/translation from a (pre-)compiler/toolchain... Not a "just in time" translation of those during runtime!
(I am quite certain even without looking at it, because you do those Emulator-ports since a while and know that this would cost extra-resources.)
About the unsupported opcodes... I suppose the most efficient way would be either a micro-code on the VU, or an SIMD-Instruction to "bind" at least some "same executions" on multiple registers and addresses together! Maybe even a combination of both!
The GS itself has quite some capability and moving some executions onto it, would yield a lot of CPU-cycles to be free'd up and less interrupts to "disturb" the emulation.
The same would apply to moving stuff to the VUs, the FPU, and rather TLB-Tricks to set up the Hardware, instead of continous "transfers"... The last thing would not spare RAM, but would decrease latencies caused by interrupts and these are one of the most crucial things, which affect/limit emulation.
But why doesn't it apply to everything else? Weird... Why is Mario's ass not becoming 2 triangles, lol? Really weird...For sure that vertices are glitching.
Even ON LINES?!? Oh dear... That's reeeaaally weird!Tested that by just drawing lines instead textured triangles. Same problems happens on interpreter and dynarec.
Interesting! THX for the reply and info/input!I've had to disable daedalus software clipping also because it discarded to many polygons. It may be something related to projection matrix.
Even though this reply wasn't for me, THX for the informative reply!Current support for c++ is kind buggy. Maybe newer toolchain can fix some problems.
Not many changes were required to get dynarec to work. Some of them:
- ins, ext opcodes are missing on EE, I've used macros as quick solution
- stack pointer alignment must be multiply of 16
- proper cache instruction arguments
- commenting out missing FPU opcodes to use interpreter functions instead
- forbidding using register k0 as it get trashed by interrupts
- fix some unaligment memory access errors
Thanks.
I suppose by Macros you mean "ahead of time" compilation/translation from a (pre-)compiler/toolchain... Not a "just in time" translation of those during runtime!
(I am quite certain even without looking at it, because you do those Emulator-ports since a while and know that this would cost extra-resources.)
About the unsupported opcodes... I suppose the most efficient way would be either a micro-code on the VU, or an SIMD-Instruction to "bind" at least some "same executions" on multiple registers and addresses together! Maybe even a combination of both!