|
Notes |
|
|
(0014145)
|
|
DJ Mike
|
2024-10-24 00:16
(Last edited: 2024-10-24 00:18) |
|
I've tried this myself in WinUAE. I can reproduce the problem reliably if Cycle Exact is off, but as soon as I set it to Full, the problem stops.
Tried with 68000 + OCS + KS1.3 setup, 68000 + ECS + KS2.0, and 68060 + AGA + KS3.1.
Will continue to investigate if I can think of anything though...
Would be helpful to know if any real hardware exhibits this problem.
|
|
|
|
(0014146)
|
|
Hexaae
|
|
2024-10-24 00:32
|
|
I use WinUAE 060, with JIT cache 8MB, KS3.1, OS3.9bb2...
But I run the game as follows to degrade it:
whdload slave WizNLiz.slave PRELOAD NOCACHE EXECUTESTARTUP="" EXECUTEPOSTDISK="uae-configuration cachesize 0 cpu_speed real cycle_exact true"
... and I can still reproduce the random buggy frame in split mode demo. |
|
|
|
|
|
This could just be a WinUAE bug though, so I still want to know if any real hardware does it. |
|
|
|
(0014148)
|
|
Hexaae
|
|
2024-10-24 00:59
|
|
Uh! Just found a perfect degrade option for WinUAE which solves the issue:
uae-configuration cachesize 0 cpu_speed real cpu_memory_cycle_exact true cpu_throttle -900 gfx_filter_autoscale integer_auto
Cpu throttle to -90% and cpu memory cycle exact workaround the gfx glitch!
Could be some CPU speed dependent routine? |
|
|
|
|
I've tested and my real Blizzard 1260 seems to reproduce this exactly the same, so it is not just an emulator issue. Although it's interesting that Cycle Exact fixes WinUAE in my case.
I'm currently focusing my attention on the copperlists the game uses to update the screen in two player mode, as there is a lot that happens with the bitplane buffers there. |
|
|
|
|
|
Would you mind giving the attached slave a try please? |
|
|
|
(0014154)
|
|
Hexaae
|
|
2024-10-24 14:47
|
|
|
Fixed! I can't reproduce it anymore! |
|
|
|
|
|
Thanks for testing. :-) Now released to website. |
|
WizNLiz.slave (2,504) 2024-10-24 13:41
