The Legend of Zelda - Ocarina of Time

Discuss ROM-compatibility related issues here.
Post Reply
User avatar
Snowstorm64
Posts: 303
Joined: Sun Oct 20, 2013 8:22 pm

The Legend of Zelda - Ocarina of Time

Post by Snowstorm64 » Thu Oct 31, 2013 7:59 am

I think we should start to report all bugs we encounter in every N64 game we are testing. Any contribution are always welcomed.

We start with one of most iconic N64 games, Ocarina of Time!


There is what I have encountered so far:

1) Strange vertical lines in some places (Link's home and Kokiri Shop, maybe there are also other places as well)
Image
Image

2) In one of the earliest scene of OoT, transitions aren't smooth
Image
(I made it slower so you can see it better)
You can see how after the black frames, just for some frames, Zelda and Impa are still there. I don't remember this happening on N64, it shouldn't do that.

Comparison with N64 footage:

Image

3) Crash and debug mode at certain points.

Image

Are there any other bug?

EDIT: I forgot, I'm using the revision 432c8d8157 on git.
Last edited by Snowstorm64 on Fri Nov 15, 2013 6:34 pm, edited 3 times in total.
OS: Debian GNU/Linux Jessie (8.0)
CPU: Intel i7 4770K @ 3.5 GHz
Build: AVX (compiled from git)

User avatar
Sintendo
Posts: 25
Joined: Thu Oct 31, 2013 9:11 am

Re: The Legend of Zelda - Ocarina of Time

Post by Sintendo » Thu Oct 31, 2013 9:13 am

Snowstorm64 wrote:1) Rupees number isn't showed correctly in the savegame
Image
In this savegame I have 11 rupees in my bag, but it says 000.
That's because it's not a rupee count, but a death count. :P

User avatar
MarathonMan
Site Admin
Posts: 691
Joined: Fri Oct 04, 2013 4:49 pm

Re: The Legend of Zelda - Ocarina of Time

Post by MarathonMan » Thu Oct 31, 2013 9:37 am

Snowstorm64 wrote:I think we should start to report all bugs we encounter in every N64 game we are testing. Any contribution are always welcomed.

We start with one of most iconic N64 games, Ocarina of Time!


There is what I have encountered so far:

1) Rupees number isn't showed correctly in the savegame
...
In this savegame I have 11 rupees in my bag, but it says 000.

2) Strange vertical lines in some places (Link's home and Kokiri Shop, maybe there are also other places as well)
...

3) In one of the earliest scene of OoT, transitions aren't smooth
...
(I made it slower so you can see it better)
You can see how after the black frames, just for some frames, Zelda and Impa are still there. I don't remember this happening on N64, it shouldn't do that.

4) Slash effect isn't rendered correctly
...
(GIF is a bit too fast, sorry)
When it happens, I have frame rate drops. (I don't know for fps, but the VI drops to 30 VI/s from usually 35+ VI/s)

Are there any other bug?

EDIT: I forgot, I'm using the revision 432c8d8157 on git.
1) As Sintendo said, IIRC that is a death count.

2) Yes, this is a problem I'm well aware of. :(

3) I was not aware of this; good eye. This, however, might happen on the actual hardware as oftentimes the console was too slow to properly handle parts of the game. That is why it only runs at 17 FPS or something. When Ganon's castle starts sinking into the ground at the end of the game, on a real console it is immediately evident that the console isn't able to keep up, unless you play the game on an iQue or something with better RAM latency.

4) Hmm, haven't seen that one either! Can you produce a save file for this one?

User avatar
Snowstorm64
Posts: 303
Joined: Sun Oct 20, 2013 8:22 pm

Re: The Legend of Zelda - Ocarina of Time

Post by Snowstorm64 » Thu Oct 31, 2013 9:43 am

Sintendo wrote:
Snowstorm64 wrote:1) Rupees number isn't showed correctly in the savegame
Image
In this savegame I have 11 rupees in my bag, but it says 000.
That's because it's not a rupee count, but a death count. :P
Ops, my bad, rupee count was in Majora's mask. My mistake :P
MarathonMan wrote: 4) Hmm, haven't seen that one either! Can you produce a save file for this one?
Well, I'm not sure, it may be a GPU driver issue, but I don't know how that can affect. Is it 100% software renderer or not?

EDIT: There is my savegame: https://mega.co.nz/#!xREyAIAS!KwILtGf3I ... FLw8IOtzqM
Last edited by Snowstorm64 on Thu Oct 31, 2013 11:36 am, edited 1 time in total.
OS: Debian GNU/Linux Jessie (8.0)
CPU: Intel i7 4770K @ 3.5 GHz
Build: AVX (compiled from git)

User avatar
dsx
Posts: 3
Joined: Fri Oct 04, 2013 10:26 pm

Re: The Legend of Zelda - Ocarina of Time

Post by dsx » Thu Oct 31, 2013 10:51 am

was curious about 2)

actual n64
Image

User avatar
ShadowFX
Posts: 86
Joined: Sat Oct 05, 2013 2:08 am
Location: The Netherlands

Re: The Legend of Zelda - Ocarina of Time

Post by ShadowFX » Thu Oct 31, 2013 12:22 pm

I have come across these kind of bugs already while went through all the US games, including these.
Though at the time I thought it wouldn't made sense to report as these were most likely graphical issues that went beyond the current scope. Moreover, the internal graphics plug-in isn't even native to CEN64 but third party, am I correct?

MarathonMan, until what lengths can games be tested at this time?

Also, shouldn't this be under Bugs/Issues?
"Change is inevitable; progress is optional"

OS: Windows 10
Specs: Intel Core i7-7700K @ 4.2GHz, 16GB DDR4-RAM, NVIDIA GeForce GTX 1080 Ti
Main build: AVX (official)

beannaich
Posts: 149
Joined: Mon Oct 21, 2013 2:43 pm

Re: The Legend of Zelda - Ocarina of Time

Post by beannaich » Thu Oct 31, 2013 12:57 pm

Snowstorm64 wrote:3) Slash effect isn't rendered correctly
Image
(GIF is a bit too fast, sorry)
When it happens, I have frame rate drops. (I don't know for fps, but the VI drops to 30 VI/s from usually 35+ VI/s)
This happens in Majora's Mask too, it's also not just a graphical bug. If you slash near a bunch of grass (In Majora's Mask anyway) the grass goes ape shit, and starts swirling around in a vortex before disappearing. Quite strange, if not hilarious to see. Also in Majora's Mask, you can walk through closed doors (The one right after becoming Deku Link comes to mind), and the flower petals you need to use to fly don't respond to anything, so you can't get further than that.

These bugs could all be connected, since they all seem to have something to do with range or proximity. The slash has a GIANT range, the door you can walk through has no collision range, and the flowers similarly have no range. Probably some VR4300 comparison instructions? *shrug*

PS: I think it's undoubtedly a very important fact that the strange lines are evenly spaced (8px) and perfectly straight. Maybe something to do with RDRAM being 9-bits or something?

User avatar
Iconoclast
Posts: 47
Joined: Fri Oct 04, 2013 8:00 pm

Re: The Legend of Zelda - Ocarina of Time

Post by Iconoclast » Thu Oct 31, 2013 6:27 pm

It could be a floating-point comparison bug under COP1 of the VR4300 somewhere, though my gut tells me that if it were anything else major of a CPU instruction bug then graphics glitches would be the least of your worries with that game.

It's also possible MarathonMan might have overstepped some of his optimizations of the RSP vectorizer and the RDP since the time at which they had been implemented.
beannaich wrote: PS: I think it's undoubtedly a very important fact that the strange lines are evenly spaced (8px) and perfectly straight. Maybe something to do with RDRAM being 9-bits or something?
How is RDRAM 9-bit?

If you're referring to addressing segmentation, then the RCP can access DRAM during DMA with up to 24 bits of precision, or 16 MiB, though only 8 of which is usable by the OS.

beannaich
Posts: 149
Joined: Mon Oct 21, 2013 2:43 pm

Re: The Legend of Zelda - Ocarina of Time

Post by beannaich » Thu Oct 31, 2013 7:04 pm

Iconoclast wrote:How is RDRAM 9-bit?
I was under the impression that it was, admittedly I'm no N64 expert. :D

I agree it's probably a small bug, I've been combing through the cen64 source looking for easy to mess up things (Especially with copy/paste). Given that you mentioned floating point, cen64 maps everything to the host FPU, think it could be a problem of something being lost in translation there?

User avatar
Iconoclast
Posts: 47
Joined: Fri Oct 04, 2013 8:00 pm

Re: The Legend of Zelda - Ocarina of Time

Post by Iconoclast » Thu Oct 31, 2013 8:13 pm

Don't know. There is a small history of prior FPU bugs MarathonMan has had to fix.

I was never able to help with those. I am not familiar with the VR4300 FPU, just the elementary MIPS commands and the RSP vector commands which he also had very many bugs in before I helped isolate those out. Past that, I didn't control much CPU stuff with what I wrote.

The graphics issue in question does, however, resemble some of the bugs you can see with the 1964 emulator when you disable the "CP1 Unusable Exceptions" ROM settings control, which virtually enables a FPU hack of sorts. If it was anything more major than that, like a RSP floating-point fractions device in the multipliers, that would be far from the first bug you'd hope to encounter.

User avatar
MarathonMan
Site Admin
Posts: 691
Joined: Fri Oct 04, 2013 4:49 pm

Re: The Legend of Zelda - Ocarina of Time

Post by MarathonMan » Thu Oct 31, 2013 11:49 pm

Iconoclast wrote:It could be a floating-point comparison bug under COP1 of the VR4300 somewhere...
This was my suspicion, exactly, for the longest time... yet I have been unable to find a bug. :(
Iconoclast wrote:How is RDRAM 9-bit?
The RDRAM basically does a "checksum" of all data on every access; this is the reason why although you will find that the N64 has 36Mbit of RDRAM, it is only able to store 32Mbit (32Mbit/8 = 8MiB + 8Mbit hidden checksum) of actual data. In the case of the RDP, when it renders 16-bit graphics, it uses the additional "checksum" bit as an additional alpha value. If you look at emulators that don't emulate the 17th-bit alpha value, you will see that the "N" logo doesn't have its shine when booting Zelda: Ocarina of Time.

User avatar
Iconoclast
Posts: 47
Joined: Fri Oct 04, 2013 8:00 pm

Re: The Legend of Zelda - Ocarina of Time

Post by Iconoclast » Fri Nov 01, 2013 12:52 am

I'm not completely following.

If we're converting megabits to "megabytes", of sorts, do you mean 32 Mb/8 = 4 MiB, or 64 Mb/8 = 8 MiB?
Because 32 Mbit/(8==2*2*2) = 8 [MiB] doesn't seem right.

User avatar
MarathonMan
Site Admin
Posts: 691
Joined: Fri Oct 04, 2013 4:49 pm

Re: The Legend of Zelda - Ocarina of Time

Post by MarathonMan » Fri Nov 01, 2013 1:02 am

Iconoclast wrote:I'm not completely following.

If we're converting megabits to "megabytes", of sorts, do you mean 32 Mb/8 = 4 MiB, or 64 Mb/8 = 8 MiB?
Because 32 Mbit/(8==2*2*2) = 8 [MiB] doesn't seem right.
The N64 actually has 36Mbit (36*1024*1024 bits) physical bits of memory.

However, the user only sees 32MBit (32 * 1024 bits = 4 conventional megabytes or 32 megabits) of RAM.

The reason is: 1/9th of the 36MBit is used as a checksum or "error correcting code" of sorts. RDRAM, or RAM for all sorts for that matter, is based on capacitor charges. Capacitors aren't exactly perfectly reliable over time, so servers or high-performance systems often reserve additional bits to correct or detect errors (see hamming codes for an introductory matter in this subject). However, when graphics are concerned, if a bit flips: the user probably won't notice as the N64 generally renders at least ~30FPS.

User avatar
juef
Posts: 31
Joined: Sun Oct 27, 2013 10:19 pm

Re: The Legend of Zelda - Ocarina of Time

Post by juef » Fri Nov 01, 2013 10:06 am

MarathonMan wrote:36Mbit (36*1024 bits) physical bits of memory.
36 * 1024 * 1024 :)

beannaich
Posts: 149
Joined: Mon Oct 21, 2013 2:43 pm

Re: The Legend of Zelda - Ocarina of Time

Post by beannaich » Fri Nov 01, 2013 12:34 pm

MarathonMan wrote:However, the user only sees 32MBit (32 * 1024 bits = 8 conventional megabytes or 32 megabits) of RAM.
I'm with Iconoclast on this one, 32/8 is definitely not 8.

32 MBit / 8 bits per byte = 4 MiB. Maybe you're getting confused with the total memory available with expansion pak?

User avatar
Iconoclast
Posts: 47
Joined: Fri Oct 04, 2013 8:00 pm

Re: The Legend of Zelda - Ocarina of Time

Post by Iconoclast » Fri Nov 01, 2013 1:14 pm

Yeah, really, 36 isn't even divisible by 8.

So if we're validating beannaich's expression of RDRAM being 9-bit, wouldn't you say 72 Mbit == 9 MiB/"MB", not 36 MBit/8 is 9? :roll:

Sorry, or was the explanation behind the ninth bit somewhere else in the RDP explanation you were giving?

beannaich
Posts: 149
Joined: Mon Oct 21, 2013 2:43 pm

Re: The Legend of Zelda - Ocarina of Time

Post by beannaich » Fri Nov 01, 2013 1:33 pm

Iconoclast wrote:Yeah, really, 36 isn't even divisible by 8.

So if we're validating beannaich's expression of RDRAM being 9-bit, wouldn't you say 72 Mbit == 9 MiB/"MB", not 36 MBit/8 is 9? :roll:

Sorry, or was the explanation behind the ninth bit somewhere else in the RDP explanation you were giving?
36 Mbit / 9 bits per byte = 4 MiB, you normally don't have access to the 9th bit. I think that's what he's getting at.

User avatar
MarathonMan
Site Admin
Posts: 691
Joined: Fri Oct 04, 2013 4:49 pm

Re: The Legend of Zelda - Ocarina of Time

Post by MarathonMan » Fri Nov 01, 2013 3:33 pm

Whoops, yeah. The explanation was correct except for the 8MiB typo. Fixed.
juef wrote:
MarathonMan wrote:36Mbit (36*1024 bits) physical bits of memory.
36 * 1024 * 1024 :)
Also yes, this. :P

Presence
Posts: 51
Joined: Fri Oct 18, 2013 9:27 am

Re: The Legend of Zelda - Ocarina of Time

Post by Presence » Mon Nov 04, 2013 3:15 pm

Ocarina of Time crashes for me if I try to pause close to the entrance to the Deku Tree. The yellow debug line appears in the upper left after a few seconds.

Here's a screenshot of it crashing at about the distance from the Deku Tree where it starts to occur:

Image

Here's a save file right inside the Deku Tree: https://dl.dropboxusercontent.com/u/232 ... d54d6.sram
If I walk out and pause from there it will freeze.
Last edited by Presence on Sat Mar 08, 2014 12:04 am, edited 1 time in total.

User avatar
MarathonMan
Site Admin
Posts: 691
Joined: Fri Oct 04, 2013 4:49 pm

Re: The Legend of Zelda - Ocarina of Time

Post by MarathonMan » Tue Nov 05, 2013 11:55 pm

Presence wrote:Ocarina of Time crashes for me if I try to pause close to the entrance to the Deku Tree. The yellow debug line appears in the upper left after a few seconds.
Great job finding this, I'll test on an actual console. Unfortunately, this bug is particularly difficult to trace but I'll see what I can do. :|

Presence
Posts: 51
Joined: Fri Oct 18, 2013 9:27 am

Re: The Legend of Zelda - Ocarina of Time

Post by Presence » Thu Nov 14, 2013 2:32 pm

I ran into this again. Seems to happen at the bottom of the first stairway towards Death Mountain in Kakariko:

Image

I've ran into these two just randomly, so I'm sure there are more places where this happens.

Save file with access to Kakariko: https://dl.dropboxusercontent.com/u/232 ... d54d6.sram
Last edited by Presence on Sat Mar 08, 2014 12:04 am, edited 1 time in total.

User avatar
MarathonMan
Site Admin
Posts: 691
Joined: Fri Oct 04, 2013 4:49 pm

Re: The Legend of Zelda - Ocarina of Time

Post by MarathonMan » Fri Nov 15, 2013 9:25 am

I've confirmed that the odd corruption during sword slash is due to unimplemented CP1 instructions. This will be fixed in the next push.

Presence, I still need to determine what is causing the unexpected freezes. I have been able to reproduce them on my end. :|

EDIT: Sword slashes looking much better in most recent commit. :D

User avatar
Snowstorm64
Posts: 303
Joined: Sun Oct 20, 2013 8:22 pm

Re: The Legend of Zelda - Ocarina of Time

Post by Snowstorm64 » Fri Nov 15, 2013 6:31 pm

Sweet! 8-)

I'm going to update first post.
OS: Debian GNU/Linux Jessie (8.0)
CPU: Intel i7 4770K @ 3.5 GHz
Build: AVX (compiled from git)

Presence
Posts: 51
Joined: Fri Oct 18, 2013 9:27 am

Re: The Legend of Zelda - Ocarina of Time

Post by Presence » Fri Nov 15, 2013 7:49 pm

MarathonMan wrote:I've confirmed that the odd corruption during sword slash is due to unimplemented CP1 instructions. This will be fixed in the next push.
The commit also fixed the issue with being able to walk through the first door in Majora's Mask. You can now get to the town, but the zeroed health causes issues. I eventually got stuck in a loop in the Great Fairy's fountain where Link would die right after receiving the magic bar and then start back at the beginning of the cutscene (which Link would die again at the end).

User avatar
MarathonMan
Site Admin
Posts: 691
Joined: Fri Oct 04, 2013 4:49 pm

Re: The Legend of Zelda - Ocarina of Time

Post by MarathonMan » Sat Nov 16, 2013 5:18 pm

Supposedly there's a "debug screen" that will pop up if you press the right keys fast enough. The information could be useful, but I can't press the keys fast enough.

When the yellow line appears:

L + R + Z
DPAD UP + C DOWN
C UP + DPAD DOWN
DPAD LEFT + C LEFT
C RIGHT + DPAD RIGHT
A + B + START

In each sequence, you must continue holding the button until the end of the sequence. (So press L, while holding L press R, and holding L + R, press Z), etc.

Anyone have better luck?

User avatar
Jbop
Posts: 2
Joined: Fri Oct 04, 2013 8:05 pm

Re: The Legend of Zelda - Ocarina of Time

Post by Jbop » Sat Nov 16, 2013 6:24 pm

I've gotten both crashes shown in this thread as well, and I've also tried the debug code with no luck. The screen needs to continue to refresh after the crash - does CEN64 do that?

The funny part is that at the framerate CEN64 can pull (at least on my computer), inputting the debug code should be extremely easy :P

P.S. I'm an OoT speedrunner
Last edited by Jbop on Sun Nov 17, 2013 4:59 pm, edited 1 time in total.

User avatar
MarathonMan
Site Admin
Posts: 691
Joined: Fri Oct 04, 2013 4:49 pm

Re: The Legend of Zelda - Ocarina of Time

Post by MarathonMan » Sat Nov 16, 2013 8:08 pm

Yes, CEN64 keeps refreshing the screen after the crash. Glad to know I'm not the only one. :D

User avatar
MarathonMan
Site Admin
Posts: 691
Joined: Fri Oct 04, 2013 4:49 pm

Re: The Legend of Zelda - Ocarina of Time

Post by MarathonMan » Mon Nov 18, 2013 12:34 am

I believe that I have fixed the OoT random crashes; it was a race condition in the game that wasn't being emulated properly.

Pausing outside of the Deku Tree no longer causes a crash, anyways.

User avatar
Snowstorm64
Posts: 303
Joined: Sun Oct 20, 2013 8:22 pm

Re: The Legend of Zelda - Ocarina of Time

Post by Snowstorm64 » Mon Nov 18, 2013 8:34 am

Image
Image
Image

:P
OS: Debian GNU/Linux Jessie (8.0)
CPU: Intel i7 4770K @ 3.5 GHz
Build: AVX (compiled from git)

User avatar
MarathonMan
Site Admin
Posts: 691
Joined: Fri Oct 04, 2013 4:49 pm

Re: The Legend of Zelda - Ocarina of Time

Post by MarathonMan » Mon Nov 18, 2013 1:37 pm

Thanks for that; yeah, it's a race condition in SW that is not seen on actual HW (but is on CEN64 due to the fact that it doesn't simulate the HW in a temporally-correct fashion yet).

I could commit the hacks to get that game to work, but it'll break other games. This kind of thing is not just limited to this game -- I've noticed that, for example, changing the cache access delay can also result in significantly less graphical corruption in some ROMs (DK64), and significantly speed-up other ROMs (2x VI/s on Pokemon Snap! intro, SW Racer intro, etc.). Unfortunately, the timings are ROM-dependent at the time being because I don't correctly simulate all sources of delays yet, and instead have been lumping the timings under only one source.

I'm just going to wait until I implement the data cache and other pieces needed to avoid this issue -- I'd rather do it right then toss around a bunch of per-ROM hacks. I could post the patches for this specific issue (although, as I said, it is a hack).

User avatar
Snowstorm64
Posts: 303
Joined: Sun Oct 20, 2013 8:22 pm

Re: The Legend of Zelda - Ocarina of Time

Post by Snowstorm64 » Mon Nov 18, 2013 2:41 pm

So if you implement more source of delay, could we see speed-up and more graphical stability in all games, right?

How long it takes to implement data cache and other sources? Could also this fix that animation in the OoT's earlier scene?

Do you think this could also fix Super Mario 64? Or does it need missing opcodes?

Sorry for many questions asked! :P
OS: Debian GNU/Linux Jessie (8.0)
CPU: Intel i7 4770K @ 3.5 GHz
Build: AVX (compiled from git)

User avatar
Nacho
Posts: 66
Joined: Thu Nov 07, 2013 9:25 am

Re: The Legend of Zelda - Ocarina of Time

Post by Nacho » Mon Nov 18, 2013 3:34 pm

From the point of view of an non-expert, how can an uninplemented source of delay (unimplemented data cache) could lead to an overall increase in speed. I mean, more things to compute -> more time employed on simulation -> less VI/s.

But nope.

That seems funny.
Testing CEN64 on: Intel Core i5 520M 2.4 GHz. SSE2 SSE3 SSE4.1 SSE4.2 SSSE3, but no AVX. Ubuntu Linux

User avatar
MarathonMan
Site Admin
Posts: 691
Joined: Fri Oct 04, 2013 4:49 pm

Re: The Legend of Zelda - Ocarina of Time

Post by MarathonMan » Mon Nov 18, 2013 3:46 pm

Snowstorm64 wrote:So if you implement more source of delay, could we see speed-up and more graphical stability in all games, right?
Yes.
Snowstorm64 wrote:How long it takes to implement data cache and other sources? Could also this fix that animation in the OoT's earlier scene?

Do you think this could also fix Super Mario 64? Or does it need missing opcodes?
No idea, depends on how many potholes I stumble into and how focused I am. ;) There's also CP0/1 delays, TLB delays, memory-mapped register access delays, etc. Lots of data to collect before it's accurate.
Nacho wrote: I mean, more things to compute -> more time employed on simulation -> less VI/s.
There's actually less to compute. If I can stall and do no work (while waiting on memory), instead of actually executing something, then that's time saved.

beannaich
Posts: 149
Joined: Mon Oct 21, 2013 2:43 pm

Re: The Legend of Zelda - Ocarina of Time

Post by beannaich » Mon Nov 18, 2013 9:19 pm

Nacho wrote:From the point of view of an non-expert, how can an uninplemented source of delay (unimplemented data cache) could lead to an overall increase in speed. I mean, more things to compute -> more time employed on simulation -> less VI/s.

But nope.

That seems funny.

Code: Select all

while (emulating)
{
    if (stall_cycles || --stall_cycles) // stall_cycles is non-zero, and doesn't decrement to zero
        continue; // don't emulate the system

    emulate_system(); // update the virtual console
}
While that isn't technically accurate, it should give you a clearer insight into what happens when stalls are implemented, and how that results in speed-ups. For a detailed explanation: The components on an N64 run at a specific frequency (93.75 MHz for the VR4300). Currently in CEN64, each cycle (1 period of the 93.75 MHz clock, of which there are 93,750,000/Second) executes an instruction. This means that it is theoretically running with perfect throughput (1 cycle per instruction, 5 instruction simultaneous execution). NOW, if stalls were implemented, some of those cycles would instead be doing nothing.

tldr; CEN64 is currently effectively overclocked, adding stalls would fix that.

User avatar
MarathonMan
Site Admin
Posts: 691
Joined: Fri Oct 04, 2013 4:49 pm

Re: The Legend of Zelda - Ocarina of Time

Post by MarathonMan » Mon Nov 18, 2013 11:02 pm

Data caches are ~90% implemented.

Just a few lingering regressions and it should be good to go!

EDIT: ... and done! :D Pushing binary releases in a few minutes.

User avatar
The Extremist
Posts: 29
Joined: Sun Nov 03, 2013 6:11 pm
Location: Canadian Prairie

Re: The Legend of Zelda - Ocarina of Time

Post by The Extremist » Tue Nov 19, 2013 3:00 am

^ MarathonMan is a glowing beacon of efficency! :D

User avatar
Snowstorm64
Posts: 303
Joined: Sun Oct 20, 2013 8:22 pm

Re: The Legend of Zelda - Ocarina of Time

Post by Snowstorm64 » Tue Nov 19, 2013 10:21 am

I tried some games with latest revision (with data cache):

OoT: Debug screen still happens
Paper Mario: segfault (previous: hangs at main screen)
Iggy's reckin balls: segfault (previous: playable, hang at end level)
Mario Party 2: segfault when closing
Banjo-Tooie: segfault (previous: black screen)
Bomberman 64: segfault (previous: black screen)

And some other games didn't see that much change. Maybe it's just my impression, but overall games seem be a bit faster, but graphics are less stable.

It will be a long, entertaining journey ;)
OS: Debian GNU/Linux Jessie (8.0)
CPU: Intel i7 4770K @ 3.5 GHz
Build: AVX (compiled from git)

User avatar
MarathonMan
Site Admin
Posts: 691
Joined: Fri Oct 04, 2013 4:49 pm

Re: The Legend of Zelda - Ocarina of Time

Post by MarathonMan » Tue Nov 19, 2013 12:25 pm

Snowstorm64 wrote:Mario Party 2: segfault when closing
Unrelated issue. This is due to my inproper use of signal handlers. :P
Snowstorm64 wrote:OoT: Debug screen still happens
As it should! Timings still aren't implemented. I'm working on stabilizing them.
Snowstorm64 wrote:I tried some games with latest revision (with data cache):
Paper Mario: segfault (previous: hangs at main screen)
Iggy's reckin balls: segfault (previous: playable, hang at end level)
Banjo-Tooie: segfault (previous: black screen)
Bomberman 64: segfault (previous: black screen)
I noticed these sometimes occurring too, just haven't been able to nail down 'why' yet. :cry:

User avatar
MarathonMan
Site Admin
Posts: 691
Joined: Fri Oct 04, 2013 4:49 pm

Re: The Legend of Zelda - Ocarina of Time

Post by MarathonMan » Sat Dec 21, 2013 2:17 pm

The freezing issues that occured mid-ROM (i.e, in OoT) should now be fixed.

I got SPLiT's Nacho PD to run a few passes without any crashes, which has historically not been possible.

User avatar
Snowstorm64
Posts: 303
Joined: Sun Oct 20, 2013 8:22 pm

Re: The Legend of Zelda - Ocarina of Time

Post by Snowstorm64 » Sat Dec 21, 2013 3:50 pm

With latest commit, OoT doesn't crash anymore, and those games, that made CEN64 segfaulting, have return at their previous status :)
OS: Debian GNU/Linux Jessie (8.0)
CPU: Intel i7 4770K @ 3.5 GHz
Build: AVX (compiled from git)

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest