- --
Viewing Issue Advanced Details
ID | Category [?] | Severity [?] | Reproducibility | Date Submitted | Last Update |
---|---|---|---|---|---|
04249 | Crash/Freeze | Critical (emulation) | Always | Feb 14, 2011, 15:16 | Feb 28, 2011, 14:23 |
Tester | Saku00 | View Status | Public | Platform | MAMEUI |
Assigned To | aaron | Resolution | Fixed | OS | Windows Vista/7 (32-bit) |
Status [?] | Resolved | Driver | |||
Version | 0.141u2 | Fixed in Version | 0.141u3 | Build | Normal |
Fixed in Git Commit | Github Pull Request # | ||||
Summary | 04249: Several saturn.c sets: Black screen after system checking | ||||
Description |
Black screen after checking screen but the game don't freeze because config menu or F2/F3 buttons works perfectly. Had to be fixed per-game in stvinit.c known to be affected: rsgun - fixed cotton2 - fixed grdforce - fixed maruchan - fixed othellos - fixed |
||||
Steps To Reproduce | |||||
Additional Information | stv.c merged into saturn.c in 0.142u2 | ||||
Github Commit | |||||
Flags | |||||
Regression Version | 0.141u2 | ||||
Affected Sets / Systems | Several saturn.c sets | ||||
Attached Files
|
|||||
Relationships
Notes
7
No.07195
Haze Senior Tester
Feb 15, 2011, 00:17
|
hap> I call 'hack' on your fix. Reducing the interleave (which is what you're doing by reducing the period of 'perfect sync') should not FIX anything. It should just make it faster. This IMHO points at a more serious problem which you're just hiding by doing so. |
---|---|
No.07196
Tafoid Administrator
Feb 15, 2011, 00:22
edited on: Feb 15, 2011, 00:23 |
Yeah. I had researched it and it looks more to do with the emu/timer changes (r11464/r11472) rather than attotime bulk changes that happened. |
No.07197
hap Developer
Feb 15, 2011, 01:27
|
Yes I know what the change does, I made timeslices smaller which increases the interleave frequency, should make it more accurate (and slower on old PCs, not faster) I couldn't find the underlying issue, I suppose it's either a bug in core timer changes, or actually a bug _fix_ in it. |
No.07199
Haze Senior Tester
Feb 15, 2011, 12:59
|
ah true, I though you'd changed the other param (the length of time it was boosted for) either way, I'm a little miffed as to why the behavior has *changed* unless there was an underlying bug in the system before. It's a little unnerving that refactoring changes to the timer system have measurable effects on the behavior when we're dealing with attoseconds in the first place. |
No.07209
hap Developer
Feb 16, 2011, 16:29
|
setting it to resolved |
No.07253
hap Developer
Feb 22, 2011, 16:43
|
temporary reopening |
No.07270
hap Developer
Feb 28, 2011, 14:23
|
underlying issue was fixed in u3 |