Project

General

Profile

Emulator Issues #10373

Ed, Edd, n Eddy: The Mis-Edventures gets stuck on loading screen after menu

Added by Techjar about 3 years ago. Updated 8 days ago.

Status:
Fix pending
Priority:
High
Assignee:
-
% Done:

0%

Operating system:
N/A
Issue type:
Bug
Milestone:
Current
Regression:
Yes
Relates to usability:
No
Relates to performance:
No
Easy:
No
Relates to maintainability:
No
Regression start:
Fixed in:

Description

Game Name?

Ed, Edd, n Eddy: The Mis-Edventures

Game ID? (right click the game in the game list, properties, info tab)

GE9E5D

MD5 Hash? (right click the game in the game list, properties, info tab, MD5 Hash: Compute)

31256eb96d1caa1f28e7e4579b4f4ce9

What's the problem? Describe what went wrong.

Attempted to get in-game and it hangs on the loading screen. Emulation is still running, but loading does not progress.

What steps will reproduce the problem?

Simply start a new game or load a saved game.

Which versions of Dolphin did you test on? Does using an older version of Dolphin solve your issue? If yes, which versions of Dolphin used to work?

I bisected, any build before 5.0-2431 works. 5.0-2431 is when it stopped working, and that build messed with disc read timings, which makes it highly suspect.

What are your PC specifications? (CPU, GPU, Operating System, more)

Windows 10
Intel Core i7-7700K @ 4.5GHz
NVIDIA GeForce GTX 1080
32GB of RAM

Is there any other relevant information? (e.g. logs, screenshots,
configuration files)

FastDiscSpeed does not help and never worked anyways. Interestingly I see a report on the wiki of it working on 5.0-4598, but the issue persists on and past that build as well in my testing. Perhaps it's loading too quickly, because I can get it to successfully load if I set the CPU Clock Override all the way down to 6%. I wonder if this is some sort of anti-piracy method in the game, to prevent the use of flash drive loading on a console.
Here's a screenshot of where it gets stuck: https://qimg.techjargaming.com/i/yMabHa49.png

GE9E5D_log.txt (196 KB) GE9E5D_log.txt Ed, Edd, n Eddy: The Mis-Edventures log file. stoo, 05/05/2018 08:42 PM

History

#1 Updated by JMC4789 about 3 years ago

Yeah, it looks like the game is crashing now.

#2 Updated by JMC4789 almost 3 years ago

  • Status changed from New to Accepted
  • Priority changed from Normal to High
  • Milestone set to Current
  • Regression changed from No to Yes

#3 Updated by kolano over 2 years ago

Have never played in enough to determine, but there was also an older crash issue with this title on the wiki...
"After completion of the third scam there is an error that causes a crash in which you cannot move on to the fourth scam."

#4 Updated by kolano over 2 years ago

Reported as also effecting Scooby-Doo! Night of 100 Frights, refer:
https://forums.dolphin-emu.org/Thread-gc-scooby-doo-night-of-100-frights?pid=468139#pid468139

#5 Updated by kolano over 2 years ago

Though Scooby-Doo! Night of 100 Frights is apparently working at least through 5.0-4607, so if this started in 5.0-2431 the Scooby-Doo! crash may be a different issue.

#6 Updated by JMC4789 over 2 years ago

I thought they originally both broke the first time on the same version?

#7 Updated by JMC4789 over 2 years ago

I think I just bought Scooby Doo in my last pile of shovelware so maybe I can actually report back.

#8 Updated by stoo about 2 years ago

Scooby Doo Night of 100 Frights is 100% working in latest build. I've tested EU, US v1.00 and US v1.01. The reported crash seems likely to have been user error, and unrelated to this issue.

Ed, Edd, n Eddy: The Mis-Edventures still freezes at the loading screen at around 25% load progress in all builds after 5.0-2431.

Log file attached.

#9 Updated by danileon95 5 months ago

Just chiming in to inform that this issue is still present :(

#10 Updated by danileon95 5 months ago

And yeah, a workaround is to set CPU override to like 6% for the loading, and then disable it.

#11 Updated by JMC4789 5 months ago

This might be dcache issues...

#12 Updated by mysteryman141 5 months ago

I fixed this issue on my machine by deleting every trace of the emulator from my computer and reinstalling it. Including registry entries.

#13 Updated by hthh 11 days ago

I think I've found the root cause of this... it looks like a timing issue.

The game uses asynchronous I/O with double buffering to read from the DVD and upload the data ARAM:

void __fastcall read_complete_callback2_80121BC0(int currrent_chunk_size)
{
  void *current_chunk; // r30
  int aram_destination; // r31
  arq_manager *v4; // r3
  arq_manager *v5; // r0
  arq_request *arq_request; // r3
  unsigned int next_read_size; // r31
  int file_offset; // [sp+8h] [-18h]

  DCFlushRange(buffer2_803D352C, 0x8000);
  current_chunk = buffer2_803D352C;
  aram_destination = aram_base_803D3530 + aram_bytes_copied_803D628C;
  if ( !arq_request_manager_803D3968 )
  {
    v4 = (arq_manager *)new_800D643C(0x382Cu);
    v5 = v4;
    if ( v4 )
      v5 = init_arq_manager_801188C0(v4);
    arq_request_manager_803D3968 = v5;
  }
  arq_request = allocate_arq_request_8011A178(arq_request_manager_803D3968, 0);
  if ( !arq_request )
    while ( 1 ) { }
  ARQPostRequest_80155944(
    arq_request,
    arq_request,
    0,
    1,
    current_chunk,
    aram_destination,
    currrent_chunk_size,
    arq_complete_callback_80121E08);
  file_offset = 0;
  tell_8010393C(&current_file_803D6290, &file_offset);
  next_read_size = ((file_length_803D6294 + 31) & 0xFFFFFFE0) - file_offset;
  if ( chunk_size_803D9710 < next_read_size )
    next_read_size = chunk_size_803D9710;
  if ( next_read_size )
  {
    sub_80102D2C(&dword_8038AAEC, current_file_803D6290);
    read_from_dvd_async_8010368C(
      &current_file_803D6290,
      buffer1_803D3528,
      next_read_size,
      // identical to this function but with buffer1 and buffer2 swapped
      read_complete_callback1_80121BC0);
  }
}

Each time a chunk is uploaded to ARAM it counts up the number of bytes written until the whole file has been uploaded, then sets a global flag indicating this asynchronous file load is complete:

void __fastcall arq_complete_callback_80121E08(arq_request *req)
{
  arq_request *self; // r31
  arq_manager *allocation; // r3
  arq_manager *manager; // r0

  aram_bytes_copied_803D628C += req->dword18;
  if ( aram_bytes_copied_803D628C == file_length_803D6294 )
    aram_upload_complete_803D6298 = 1;
  self = req->self;
  if ( !arq_request_manager_803D3968 )
  {
    allocation = (arq_manager *)new_800D643C(0x382Cu);
    manager = allocation;
    if ( allocation )
      manager = init_arq_manager_801188C0(allocation);
    arq_request_manager_803D3968 = manager;
  }
  self->owner_id = 0;
}

However (without the 6% CPU override hack) "aram_upload_complete_803D6298" never gets set, causing the load to hang. Looking in the debugger, I see that "arq_complete_callback_80121E08" is called the correct number of times. It should add 0x8000 bytes every time, except for the final chunk, which is 0x1160 bytes, but under the debugger it appears to add 0x1160 instead of the second-last value as well.

This is partially explained by "allocate_arq_request_8011A178" returning the same structure every time, because of the 0 argument passed in both "read_complete_callback" functions:

arq_request *__fastcall allocate_arq_request(arq_manager *manager, int owner_id)
{
  arq_manager *v2; // r6
  int i;

  for (i = 0; i < 20; i++)
  {
    if ( manager->requests[i].owner_id == 0 )
    {
      manager->requests[i].owner_id = owner_id;
      return &manager->requests[i];
    }
  }
  return 0;
}

Because of this, I believe the hang will occur if the final 0x1160 byte DVD read completes before the prior 0x8000 byte ARAM upload completes. Unfortunately, I have no idea if DVD reads are too fast or ARAM upload is too slow, so I haven't tried to fix it.

#14 Updated by hthh 10 days ago

I took a closer look at the current (5.0-12245) emulated timings:

  • First, the 0x8000 byte ARAM DMA begins
  • 4us later (1914 ticks), the 0x1160 byte DVD read begins
  • 433us later (210227 ticks), the DVD read completes
  • 81us later (39763 ticks), the ARAM DMA ends

The ARAM DMA duration is 518us (251904 ticks), and the disc read duration is 432us (210227 ticks).

So, at the moment, we're off by a minimum of 81us. It'd work if this disc read were ~20% slower, or this ARAM DMA were ~15% faster (or they met in the middle somehow), but it's not immediately clear what's happening that causes a deviation from the prior hardware measurements. (Could multiple DMAs at the same time cause contention or something?)

I think current ARAM DMA timing is from around 2014 (http://dolp.in/pr1012), and DVD timing is from around 2017 (http://dolp.in/pr4829 - which led to this issue).

#15 Updated by JosJuice 10 days ago

My hunch is that the startup latency for reading data out of the DVD controller's cache hasn't been measured in much detail. (I'm assuming that the read in question is cached, since less than 1 ms is very fast.) Right now the startup latency for this is set to the same constant as the startup latency of every other command, including simple ones like "report status". This is just a guess from my side, so I'm not sure that something is wrong with it, but I think it would be a good place to start looking.

(I should probably do so myself at some point, but I haven't been succeeded in bothering to make hardware tests at any point yet...)

#16 Updated by JosJuice 8 days ago

  • Status changed from Accepted to Fix pending

Also available in: Atom PDF