GoldenEye 007 Nintendo 64 Community, GoldenEye X, Nintendo 64 Games Discussion

[radorn]

well, I'd say that if rare decided to use 32bit operations instead of 64bit, then there's probably a reason. Rare is (or was) known for studying the hardware thoroughly in order to achieve the best results possible, and they had the know-how and resources for it, so yeah, they probably did the right thing

The N64 had some serious bottlenecks. The executable code in a 64bit instructions also take twice as much room as 32bit ones, and also take longer to travel along the buses. If you can do something efficiently in 32 bit, going for 64 is probably not advisable when you have limited resources (bandwidth and storage, for example).

[Trevor]

It makes me wounder what the point is for having 64bit then...

I wounder why the busses take longer to transmit 64 bit (surely Nintendo would have made them the correct width)

some hardware mods would be nice...

Trev
_________________

[Trevor]

OK, err, so what IS the best output for the N64, NTSC has a faster refresh rate yet PAL has a few more lines. Isn't the graphics of GoldenEye 640x480 (which wouldn't make much difference with the number of lines then?)

Also, how can the US and UK games be optomised differently?

Sorry for asking dificult questions, Im just trying to get my head round it.

Trev
_________________

[acceptable67]

I remember playing this on my 52"... I had no resolution errors, worked really good... till the lamp burned out and the T.V. took a shi*
_________________

Rare wrote:

Perfect Dark Forever.

[radorn]

http://www.xente.mundo-r.com/radorn/n64_img.zip

some N64 pics taken with Action Replay.
They come from the game's framebuffer, so they represent the actual resolution of the games.
Normally consoles from generations between the N64 and NES have half resolution than the TV system used, since they use two analog tv lines for each of the digital image's lines. so no, no 640x480. There are exceptions, like turok2 hirez mode, which also causes some flicker.

[Trevor]

ok, not 640x480 but I just 'knew' GoldenEye had the highest res (it always looked better than the rest and its what I measured a games quality on) Im surprised that Perfect Dark is less.

Trev
_________________

[radorn]

well, these PD pics are taken in low res mode because the AR trainer that allows communication with the PC to take these screens prevents detection and use of the expansion pak, so I could only take screens in the limited CS mode for people without EP.
the logo animation screenshot is high res thoug, but seems like only the top half of the screen made it to my PC... wonder why.

[fantsu]

Is there a list somewhere, where you can see all the "hi-res" games for N64?

Many later games had this option when you had the expansion pak.
I think C&C64 had hi-res option that gave you 640x480, at least it looked like that when I had it. And games before the expansion pak support had these "letterbox" resolutions, like World Driver Championship.

[zoinkity]

RAUR IW ILL EAT BRIANS & CHEWS TEH BUBBLEGUM!!!

Okay, here's how it works. This:

Quote:

64bit CPU (although it runs in 32bit mode most of the time, believe it or not)

is inaccurate to misleading.

Here's what's going on.
The N64 is probably set in 64bit mode the entire time, with the exception of maybe some cheap jerk who homebrews something.
Individual opcodes are 32bits long. However, two ops are processed at a time. Hence the interesting "delay slot" following branches, since that gets processed the same time you branch or jump.

If you sift through the opcode list, you'll see a fair number either don't work or work differently in 32bit mode. You can also return the mode, though without the docs in my hand I can't tell you exactly how. Still, you'll notice that all the ops work perfectly fine in both GE and PD.

What you're all griping about is 64bit memory access, which is for the most part inconvienient. That said, I can name two games off the top of my head that use it: Robotech: Crystal Dreams and Wonder Project J2.
Why, and why is it slower?
It works like this. It is insignificantly slower dumping data into or out of memory. However, lets do a more complex operation, like integer division. Int. division burns cycles as it is, but when you're dealing with double the data you burn more cycles. That means this: if you attempt to access the variable, the processor waits until the data is ready. So in other words, you sit around and do nothing, burning daylight.
The fastest mult/div operations are simple bitshifts. However, they work on only 32bits at a time, so it is inconvenient to use them.

Also, why the heck do you need long longs anyway? When do you need to handle that large of a number? That's reason #1 why they aren't commonly used.

+_+

As for floating point numbers, that's all handled through a subprocessor and has no impact on the argument. Long story short, you can set either 32 or 64bit float mode arbitrarily on COP1. WPJ2 does this stupidly and obsessively. The advantage is in 32bit mode you have double the registers to work with, but 64bit allows more freedom in your mathmatics.
_________________
(\_/) Beware
(O.o) ze
(> <) Hoppentruppen!