Zelda - OOT - how ?

[112]

if its emulated then why is there a break in sound when you pause the game. this is obviously a glitch, but it shows that not everything is the same, once properly into the game itself and not on the title screen. Im talking about the jap GC version if that makes a difference.

112

[Valken]

[Port or emulation it was certainly no simple recompile... and the arcitectures of the 64 and GC aren't *that* similar IMO.

It's possible that some kind of middleground method was used where Nintendo have in their possesion a set of libraries that facilitate the running of N64 games on the machine if recompiled.

If this were true it could be *kinda* considered as an emulation of sorts.

[rgraves]

Actually, it probably was a fairly simply recompile. With access to all of the original source code, and the fact that the GC and N64 APIs are not a million miles apart by all accounts, it was probably fairly easy for them.

[Valken]

Actually, it probably was a fairly simply recompile. With access to all of the original source code, and the fact that the GC and N64 APIs are not a million miles apart by all accounts, it was probably fairly easy for them.

Well, in terms of experience all I know about is developing for the XBox so I can't possibly comment in any detail but I'd be interested to know why you think that...

[Papercut]

I reckon its emulated with 'high level' optimisations, which could be considered a partial port. If it had been a complete port there would be no excuse for the low frame rate.

It seems to load the whole game in memory before you begin playing. Perhaps it just streams (or caches) audio tracks off the disk, which would explain why it asks for the disk when you switch areas.

It also appears to save the game state, the save files are rather large. The emulation layer seems to intervene when you save and do the job itself.

The underlying hardware is very different, a port would have been difficult to do. The N64 version was no doubt full of nasty low level hardware hacks to ring as much performance as possible out of the N64.

Also, compare GCN OOT to playing the N64 version under UltraHLE, they're very similar. UltraHLE does not emulate the underlying hardware fully, it reimplements high level i/o functions instead for speed.

I hope its emulation anyway, if it is then maybe we can expect to see more N64 games bundled with GCN updates. F Zero X with track editor, mmm...

[Saurian]

I hope its emulation anyway, if it is then maybe we can expect to see more N64 games bundled with GCN updates. F Zero X with track editor, mmm...

Dont say things like this - I go all weak!

[weresheep]

How would changing the framerate from at times a headache inducing 20 odd FPS to a smooth 60FPS alter the gameplay or balance?

Well I don't have access to the source code so I can't say for sure. But you are talking about changing timing and that can have a massive affect on things. But the real point I was making was OOT is considered to be a masterpiece. Why alter it now for a freebie port which is simply trying to get people to pre-order the real money maker, Zelda: TWW.

Whilst part of me likes the idea of getting more N64 games onto the GC as freebies, I would really rather Nintendo concentrate of more original stuff. Mind you, I am not complaining about getting OOT and master quest with WW.

-weresheep

[Tom Salter]

Well I don't have access to the source code so I can't say for sure. But you are talking about changing timing and that can have a massive affect on things.

I'm pretty sure that Nintendo aren't stupid and have used frame based animation for this game So running it at 60fps will not have any effect on this at all.

[Staplehead]

I dunno about all these port/conversion whatever thingies, but on my PAL version I get the pause screen sound glitch. I've opened the disk tray coming back from Kakariko Village and back onto Hyrule field and I haven't been ordered to close the tray.

Staplehead.

[weresheep]

I'm pretty sure that Nintendo aren't stupid and have used frame based animation for this game So running it at 60fps will not have any effect on this at all.

Well I don't write games for a living, but the software I do write is very sensitive to timing. I would be suprised to find that mearly running the code on faster hardware results in faster graphics with no other side effects. I could be wrong though.

But anyway, as I asked before, why would you want to change anything in OOT?

If I was Nintendo, I'd be pretty happy with it and leave it alone.

-weresheep

[Brats]

Isn't the frame rate in the GC version oh so slightly better than the original anyway? So the timing has changed a little bit.

One thing that makes me believe it is a port is the fact that the PAL version only comes in 60hz flavours. If it was under emulation, surely it would be as easy to emulate the 50hz PAL original as it would the 60hz version. I guess they ported across the 60hz version and didn't want to spend additional time porting the 50hz version for what is essentially a freebie.

The fact that it was a freebie though intimates to me that the porting was a fairly easy process though, so hopefully we'll see some more updates .

[Blondie]

The fact that it was a freebie though intimates to me that the porting was a fairly easy process though, so hopefully we'll see some more updates.

Yes please. I'd love F-Zero X with track editor I still play this baby today...

Anyways whilst you lot are wibbling wistfully about TWW I'm happily immersed in OOT. I hated Zelda on the SNES - sure it was pretty but as I said, Mr Twitch Gamer is me - so I overlooked OOT completely at the time.

I'm glad I did. Its lovely, full of charm and with my nice big telly and sound system I'm much better placed to enjoy it than I was on my little portable all those years ago

[Valken]

I'm pretty sure that Nintendo aren't stupid and have used frame based animation for this game So running it at 60fps will not have any effect on this at all.

Well I don't write games for a living, but the software I do write is very sensitive to timing. I would be suprised to find that mearly running the code on faster hardware results in faster graphics with no other side effects. I could be wrong though.

But anyway, as I asked before, why would you want to change anything in OOT?

If I was Nintendo, I'd be pretty happy with it and leave it alone.

-weresheep

In computer graphics the best way to keep animation constant is to move objects based upon a fraction of the current frame rate... otherwise a faster frame rate will result in an increase in game speed. Take PC FPS for example... whether you've got Quake 3 running at 60fps or 160fps your character moves at exactly the same speed through the world.

The best example I could find on the web is at http://www.gametutorials.com/Tutoria...OpenGL_Pg1.htm. It's not how I do it personally but it's explained pretty well through the source code.

[rgraves]

It's a cast-iron port. JPickford over in RllMuk is currently developing a title on the GC (as well as PS2 & XBox) and he had this to say on this very topic:

The GC hardware can do everything the N64 does + a lot more. The API is very similar. It's not that difficult for Nintendo to port the game over (assuming no major changes are made).

No need for an emulator, the game is recompiled for the GC.

The N64 had limitations like texture sizes being very small. And the fact it really wasn't all that fast (less than 2000 polygons per frame at 60Hz). Those things are not going to cause any problem on a GC which can handle large textures and up to 250,000 polygons per frame.

Animal Crossing (ported from N64) even managed to load ALL its textures into the GC's memory on boot up and never access the disk again ( you can even remove it and boot in another cube apparently). So the N64's small textures came in handy.

Zelda is written very cleanly only using calls to the API. You can tell this by how well it ran on the PC N64 "emulators". Those emulators were true emulators when it came to the CPU but they didn't emulate the graphics at all, they simply patched every graphical call to an equivelant on the PC.

Having access to the original C source meant Nintendo didn't need to emulate the N64 CPU they simply recompiled all the logic to the GC processor and patched all the graphical calls to the GC equivelants. Very easy.

The NES stuff is definately emulated rather than ported. Those games were written in assembler not C which is much trickier to port and heavily machine specific. Also emulation means they wouldn't even need the original source code (possibly lost in some cases) they could simply get the code from any original cart of the game in question.

And on the subject of framerate:

...I'm guessing that the N64 was written to run no faster than 30fps and that means all the animation and cut scene stuff is timed for that framerate. I'm guessing that on the GC the game runs at that speed pretty much all the time (not slowing down as much as on the N64) but its locked to run no faster, even though the hardware is capable of much more. Re-doing all the animation would have been a big job and not worth the time and effort for a freebie.

[Tom Salter]

In computer graphics the best way to keep animation constant is to move objects based upon a fraction of the current frame rate... otherwise a faster frame rate will result in an increase in game speed. Take PC FPS for example... whether you've got Quake 3 running at 60fps or 160fps your character moves at exactly the same speed through the world.

Exactly. One game that sticks in my mind is the original Grand Theft Auto on the PC. Because it was frame based animation, with today's PC's playing that is a joke (although they did put an option to limit the frame rate in).

And if a game/application is very sensitive to the speed it runs at, it's very bad coding IMO

And I'm not bothered if it's emulation or just a port, Miyamoto has said that it was easy to do, lets just hope they do some more freebies like this