/vr/ - Retro Games

>>4801665
Is the N64 version the same as the PC version? Because I remember playing the hell out of the PC version at my cousin's.

>>4801665
Holy crap this looks bad!

>>4801670
Not quite. Factor 5 took the PC version and overhauled the controls, combat, and made a bunch of tweaks to the level design. They also completely replaced the lighting system and added a fancy new particle system. The problem with Infernal Machine N64 is that Lucasarts fucked them over and reallocated most of the team to work on Battle for Naboo instead, even though Infernal Machine was their passion project.

What this means is that Infernal Machine N64 was largely developed by one person who could kinda code and kinda animate and kinda fix bugs -- and as a result is one of the buggiest games on the N64. It crashes unacceptably often on real hardware, and is full of little glitches. But if you look past that, it's a really solid game that is dramatically more fun than the PC version, and it earned decent 8/10 reviews from UK publications that got their hands on the PAL version which never got officially released. (Although it leaked a few years back as part of the THQ liquidation.)

>>4801670
https://www.youtube.com/watch?v=q9UfIFRYDb0

Sorry, what you are saying is that they made a version for emulator which has way less bugs and more polygons?
Is that what I'm gathering?

>>4801695
It has taken 18 years for someone to reverse engineer the graphics microcode used by Indiana Jones and Star Wars Episode 1: Battle for Naboo. This means that you can (reasonably) accurately emulate these games without an extremely slow software renderer.

>>4801698
That's very impressive indeed.
I don't think I'll be able to run it though. It looks foreign to me.

>>4801673
Looks like MGS Snake.

>>4801665
I like how he slings the rifle over his shoulder when you unequip it.

>>4801698
they are both on pc anyway

i played indiana jones on my flashcart, it was ok seemed like a tombraider knock off but i like tombraider a bit better

>>4801678
The PC version is "dramatically" more fun in my opinion, as a fan and owner of both.

>>4801713
>they are both on pc anyway
The PC version of Indiana Jones is terrible, though. It has basically the worst Tomb Raider knock-off controls ever conceived.

>>4801720
What makes the PC version better in your opinion? It has tank controls and a clunky inventory system. Mechanically, I can't imagine wanting to play the PC version.

>>4801734
get gud
>>4801735
do your eyes work?

>>4801738
You didn't answer the question, anon. The N64 version has better controls, better level design, better graphics, and the only real downside is that it's a bit buggier due to being rushed/understaffed. It's not like the PC version runs great nowdays, either.

who cares, emperors tomb is far better

>>4801748
>emperors tomb is far better
They're pretty darn different. Infernal Machine was by the Fate of Atlantis team and is basically that game's ideas translated into a third person action adventure title. Emperor's Tomb was by The Collective, and it kinda plays like Buffy the Vampire Slayer, their previous game, except you play as Indiana Jones. Personally Infernal Machine is a lot better, but I think it really comes down to what you want from an Indiana Jones game.

>>4801745
N64 has better graphics and level design, among other things.

>>4801754
>Infernal Machine was by the Fate of Atlantis team
I know that game is regard as point-and-click essential, but it had the most brain-melting story I've ever come across (the U-boot scene, in particular).
So that gets me worried about trying the title at hand.

>>4801775
It's Indiana Jones vs Russians and they're searching for interdimensional beings and... Yea, it's the source material, loosely, for Crystal Skull.

>N64 emulation

Not even once

>>4801919
>grammar
Not even once

>>4801919
>A blurry vomit
>B blurry vomit

>>4801937
Extreme spectrum

>>4801949
B is still objectively sharper and properly displayed. 5th gen 3D's gonna look like blurry vomit anyway.

>>4801919
3-point bilinear filtering was a gigantic mistake/performance cheat that had severe negative consequences for N64 image quality, particularly text filtering. It has kneecapped attempts to create widescreen hacks for N64.

>>4802014
>3-point bilinear filtering was a gigantic mistake/performance cheat that had severe negative consequences for N64 image quality, particularly text filtering
Are you actually trying to say that when Nintendo designed the N64 they should have said to themselves "Gee, we really should make this motherfucker emulator friendly, huh" ?

>>4801919
Both pics are the same

So what's the deal with the microcode? Emulator authors are implementing the microcode itself?

Can't they write something that emulates the system that ran the microcode? Isn't microcode basically like shader code anyway?

Why has N64 emulation gone down this path?

>>4802027
Look near the top edge of the staircase.

>>4802028
>Emulator authors are implementing the microcode itself?
No, they are basically working out what the microcode does and then simulating it.
>Can't they write something that emulates the system that ran the microcode?
That's low level emulation (LLE) and you generally need a monster PC for it to work properly.
>Isn't microcode basically like shader code anyway?
Yes. Think of it as the absolute first generation of vertex shader code.
>Why has N64 emulation gone down this path?
LLE too slow. HLE for N64 is famously garbage and worked even worse with the more technically advanced games, so this is an attempt to fix HLE moving forward slowly.

>>4801713

>they are both on pc anyway

naboo is actually on pc, why I never knew this?

>>4802032
It seems there are some low level emulators out there like https://github.com/libretro/parallel-n64 .

Reading this,
http://gliden64.blogspot.com.au/2014/11/a-word-for-hle.html , it sounds like the author of Glide64 thinks enhanced lighting and increased resolution are good things so why bother with LLE. So that's why they are sticking with the HLE model even if they have to spend months implementing single games.

>>4802031
Ohhh, I see it now. This just shows what an advanced piece of hardware the N64 was.

>>4802051
That's just the most visual difference. If your eyes aren't shit-tier you can tell that all other textures look blurrier on the left, particularly the grass.

>>4801665
>that Ocarina of Time shit in the top right

>you'll die of old and n64 emulators will still look bad and run like shit

isn't easier breaking in nintendo hq and stealing the developer tools and documents at this point?

>>4802063
Documentation isn't really a problem anymore, except for these esoteric third party microcodes. If documentation was a problem, then LLE emulation wouldn't exist for N64, and yet it does.

HLE emulation sucks for the most part on N64 because developers are too lazy to translate N64 GPU features to PC GPU features.

Out of all of the consoles released, except the Saturn probably, N64 is the most challenging in this regard. N64's GPU had an extremely large range of features for its time (including programmable vertex shader) and yet it didn't comply with any mainstream 3D API.

Consoles older than N64 like PS1 have less sophisticated GPUs so it's not an issue, while consoles newer than N64 like Dreamcast and PS2 actually have some compliance with PC compatible APIs like DirectX / OpenGL.

>>4802023
>"Gee, we really should make this motherfucker emulator friendly, huh" ?
The N64 hardware completely fucks font rendering. They should have noticed that instead of cutting even more corners so they could sell the system for 199USD.
>>4802051
>Ohhh, I see it now. This just shows what an advanced piece of hardware the N64 was.
It's not advanced. It's doing 3 samples instead of 4, which is stupid and wrongheaded and cheap.
>>4802058
It was incredibly forward thinking, and essentially the precursor to the UIs you see in heaps of modern games. A lot of modern console games use the D-Pad for hot selection. The N64 was a wellspring of design innovation. Turok 2 for the N64 introduced weapon wheels, for instance.
>HLE emulation sucks for the most part on N64 because developers are too lazy to translate N64 GPU features to PC GPU features.
That isn't true at all. It's not laziness. It's API limitations, largely. GLideN64 is way ahead of its legacy peers in most regards because it makes use of more advanced GL features. Its accurate depth emulation mode is pretty good, for instance, and has no performance impact on modern hardware.
>>4802049
>It seems there are some low level emulators out there like https://github.com/libretro/parallel-n64..
Parallel is an interesting attempt that kinda stagnated. It has some glaring problems such as abysmally shit performance that becomes more abysmally shit as you increase the resolution. Pretty much all the games are hardcoded to render at 320x240 instead of their real resolution because even a top-end GPU can't handle high resolution N64 games using compute rendering. Accurately emulating the nitty gritty of N64 rasterization is obscenely expensive and necessary to handle some rather nasty quirks that pop up in more naive solutions.

The other benefit of GLideN64 and its techniques -- which do have limitations -- is that they are very fast.

>>4802049
Why do you think Dolphin's developers chose to HLE every single audio ucode? Because an HLE microcode implementation is a lot faster. Paradoxically, N64 audio isn't expensive enough to justify HLE, but there are in fact HLE implementations of all the N64 audio ucodes, including Indiana Jones/Naboo. The audio ucodes were HLEd years ago. Audio is far, far simpler than graphics.

Stuff like this is why I come her. Thank you.

>>4802063
>>4802076

I am assuming the problems with LLE will eventually be overcome. It is a matter of emulating the DSP accurately with modern shader code.

>>4802108
>The N64 hardware completely fucks font rendering. They should have noticed that instead of cutting even more corners so they could sell the system for 199USD.
Except it doesn't fuck font rendering on N64 real hardware. It just fucks PC GPUs that try to render fonts the way that N64 is trying to render them because it does it differently.

>It's not advanced. It's doing 3 samples instead of 4, which is stupid and wrongheaded and cheap.
IIRC the N64 hardware does do 4 samples but only for trilinear filtering. Bilinear is 3 samples. The difference I believe was due to a hardware bug that they couldn't fix in time for production, not because they were cheap. At that time most PC cards weren't even capable of filtering. Or if they were, they were slow as fuck at it, like the S3 Virge.

>That isn't true at all. It's not laziness. It's API limitations, largely.
The API limitations *are* why it requires hard work to translate it over. Hard work that most developers haven't done despite N64 emulation existing for literally 20 years.

https://youtu.be/130Id_HKRxM

Never forget

>>4802142
Wrong. The N64's bilinear filter fucks up text. It makes widescreen hacks largely untenable on real hardware and 100% accurate renderers. Multiple aspects of the N64's design are a complete shitshow of cost-cutting and dubious priorities.

>>4802154
Bizarre as fuck episode that backfired horribly. They seemingly assumed they could play like retards and nobody would notice because they assumed IM was some kind of shovelware, when in fact it's a cult classic and is basically the TLOU of N64 games in terms of technology.

>>4802173
>It makes widescreen hacks largely untenable on real hardware and 100% accurate renderers
Then they are shitty hacks. Plenty of N64 games have real widescreen modes and the fonts aren't fucked up there.

> Multiple aspects of the N64's design are a complete shitshow of cost-cutting and dubious priorities.
Nah, the only part of the N64 design which was shit (cartridges aside) was Nintendo gimping the RAM (which to be honest they've done to every single one of their consoles, but N64 got it the worst). Everything else was good.

"Why didn't Nintendo make the N64 compatible with a future API specification for PC graphic cards that didn't exist yet" is not a goddamn design flaw.

>>4802189
>Plenty of N64 games have real widescreen modes and the fonts aren't fucked up there.
Untrue. It's one reason why image quality degrades so much when using animorphic widescreen in N64 games.

The N64 architecture is a travesty. There's a reason so few games can hold a stable 30fps, much less 60fps. The fill rate limitations were crippling, and like a whopping three games solved that particular problem.

>>4802207
>It's one reason why image quality degrades so much when using animorphic widescreen in N64 games.
Looks fine to me. Video's off S-Video connection on the real console. There's no degradation here. You DO realize anamorphic doesn't actually increase resolution right?

>The N64 architecture is a travesty. There's a reason so few games can hold a stable 30fps, much less 60fps
That had more to do with the bad developers getting trashed by the difficult hardware, and the good developers, like Rare, being overly ambitious with their game design.

>The fill rate limitations were crippling, and like a whopping three games solved that particular problem.
Fill rate is linked to RAM though, it's about how many pixels get filled *into* the RAM. Literally the problem on N64 is that the GPU is serving up shitloads of pixels and the RAM isn't fast enough to take them in so the GPU has to keep waiting for it.

It's a simple but big problem, but the solution would have been equally simple. Just Nintendo putting in better RAM. No re-designs required. Just better RAM, that's all it needed.

The games that "solved" the issue. Guess what they do? Don't use a z-buffer, which in those days was the biggest enemy of RAM speed.

>>4802231
>Looks fine to me. Video's off S-Video connection on the real console. There's no degradation here. You DO realize anamorphic doesn't actually increase resolution right?
It may look fine to you, but it doesn't look fine at all. Also, what has resolution got to do with anything?

Three-point bilinear is bad. Period. It essentially "eats" edges, creating a characteristic look that worsens with an increased horizontal viewport.

>>4802231
>That had more to do with the bad developers getting trashed by the difficult hardware, and the good developers, like Rare, being overly ambitious with their game design.
Factor 5 were literally the best engineers in the industry, and they couldn't prevent framerate dips. Meanwhile, they managed a locked 60fps with the best graphics on the system when the Gamecube came along.
>Fill rate is linked to RAM though, it's about how many pixels get filled *into* the RAM. Literally the problem on N64 is that the GPU is serving up shitloads of pixels and the RAM isn't fast enough to take them in so the GPU has to keep waiting for it.
There's also the fact most N64 games are performing coverage checks for every single pixel as part of their AA solution which eats 1/3 of the fill rate.
>The games that "solved" the issue. Guess what they do? Don't use a z-buffer, which in those days was the biggest enemy of RAM speed.
It's more nuanced than not using the z-buffer. The way they render scenes is completely different, and if more games had used it -- Nintendo were lazy about finishing the reference microcode and teaching developers how to use it -- N64 game performance would have been dramatically better across the board.
http://ultra64.ca/files/documentation/online-manuals/functions_reference_manual_2.0i/ucode/gspZ-Sort.html

>>4801745
>It's not like the PC version runs great nowadays, either.
What's wrong with it?

>>4803330
It should work on 64-bit Windows. Make sure to set your display resolution to 1024x768 or lower first.

AFAIK the main problem with the game is that it ran in the N64's seldom-used 640x480 mode which was not properly emulated due to lack of adequate documentation on how it works.

>>4802108
>The N64 hardware completely fucks font rendering. They should have noticed that instead of cutting even more corners so they could sell the system for 199USD.

Both the N64 and Saturn suffered badly from trying to have hardware designs that couldn't be implemented properly at the price they were selling them for.

>>4802108
>Pretty much all the games are hardcoded to render at 320x240 instead of their real resolution

Wait, isn't that the native resolution of N64 games anyway?

>>4803330
The PC version was riddled with technical issues on modern hardware/operating systems until fairly recently, when an unofficial patch was created. Someone should probably post this on the PC Gaming Wiki. https://www.frictionalgames.com/forum/thread-24981.html

>>4803340
>AFAIK the main problem with the game is that it ran in the N64's seldom-used 640x480 mode which was not properly emulated due to lack of adequate documentation on how it works.
Nothing like that. It actually runs at 400x440 or thereabouts.The game is fussy about timing, MMU emulation, and some other stuff.

>>4803367
Seems like it was mostly a matter of replacing the original 16-bit installer program and some patches to correct timing issues caused by the game running too fast on newer CPUs. There may have also been some compatibility problems with newer versions of DirectX.

>>4803367
>The game is fussy about timing, MMU emulation, and some other stuff.
Some of that might have been avoided if the game had been coded a bit more cleanly and wasn't so buggy.

>>4803272
>Nintendo were lazy about finishing the reference microcode and teaching developers how to use it -- N64 game performance would have been dramatically better across the board.

Nintendo always had shitty documentation and offered little help to devs ever since the NES.

Wow! I can finally play a game that costs $20USD on ebay!

>>4801919
lol

>>4801919
>not just turning the filters off entirely for the best image quality

I'll never understand why the filter is there to begin with...is it to get better performance? With it off it has the crisp textures of the PSX, but with none of the stuttering.

>>4803007
>It may look fine to you, but it doesn't look fine at all.
So what's actually wrong with it? You haven't described the issue.

>Three-point bilinear is bad. Period. It essentially "eats" edges
No it doesn't. What eats edges is the unorthodox way the N64's filtering unit works with its texture mapping coordinate system. If the console did 4 point filtering (which I'm pretty sure it does for trilinear anyway) you would get the same problem because that texture mapping system is NOT directly pc card compatible.

>>4803272
>Factor 5 were literally the best engineers in the industry
Nah, they were no better than Rare. According to a post I saw a while ago from a Criterion Games programmer, he said they were notorious for overhyping the technical aspects of their games.

While they were good, think about how they overhyped their audio driver for N64 as the best thing ever, and yet Battle for Naboo sounds like plinky plonky MIDI, compared to say the older Jet Force Gemini by Rare which actually sounds orchestral and almost CD quality.

>Meanwhile, they managed a locked 60fps with the best graphics on the system when the Gamecube came along.
Gamecube hardware was built around Rogue Leader in the same way that N64 hardware was built around Mario 64. Seriously, look it up. You'd hope their games would run well on that platform then.

But your point is also stupid. What PS1/Saturn games are there which are free-form (not rail) 3D shooters which look and play smoother than RS1 / Naboo? The real reason they slow down anyway is because Factor 5 targeted resolutions higher than 240p, due to over-ambition like I stated above.

>There's also the fact most N64 games are performing coverage checks ... which eats 1/3 of the fill rate.
The reason it eats into the fill rate is because those coverage values have to be read / written from RAM all the goddamn time. The RAM is the choke point again. It's always the choke point on N64, because everything else is literally perfect.

>>4803817
>With it off it has the crisp textures of the PSX

>>4803839
Jesus Perfect Dark is so good
I love the 64

>>4803839
> You haven't described the issue.
that anon explained the issue but you're either blind or dumb. im going with dumb based on the rest of your gigantic SHITPOST:

>>4803839
> Nah, they were no better than Rare
kek. u = not knowing that factor 5 was a top middleware producer for dozens of different developers.. hilarious. made my day.

> overhyped their audio driver for N64
so, you're making up shit now? yea it was overhyped by nobody. all n64 music was garbage. it was all MIDI based and some musicians and programmers put an incredibly low amount of time into making soundbanks that did not sound like shit. don't blame the software, blame the fucking hacks calling themselves programmers and musicians.

>The RAM is the choke point again. It's always the choke point on N64
KEK. ram is a choke point in every system, genius. please, tell us more of your wonderful, made up bullshit facts you've dug out of your misinformed asshole.

>>4802028
microcode can be written per game basis. they can be quite different per game depending on what the programmers want the n64's gpu or audio cpu to achieve.

>>4802032
>Yes. Think of it as the absolute first generation of vertex shader code.
except it's nothing like it at all and far more complex.

>>4803850
Tiny texture cache is a real bitch.

>>4803272
>Nintendo were lazy about finishing the reference microcode and teaching developers how to use it

not quite. nintendo had poorly documented the microcode manuals from DAY 1. to add insult to injury, nintendo kept certain specifications completely top secret within nintendo so they had the competitive edge over their third-party developers. nintendo didn't even bother sharing their secrets about coding for it until years later and then only with a select few third party developers they trusted.

moral of the story: nintendo have always been cunts to third party devs.

>>4803927
>that anon explained the issue
Nope, all he said was the font and image quality was fucked up in widescreen mode. Looks all good in these webms though.

>factor 5 was a top middleware producer for dozens of different developers
The only middleware they sold was voice compression technology which was admittedly good, but they were not better than Rare at anything else. Arguably worse, even.

>yea it was overhyped by nobody. all n64 music was garbage. it was all MIDI based
Except Factor 5 *literally* hyped up the quality of their audio driver as the best possible one for N64. Yet it sounds far FAR inferior to what Rare were doing. Just take a listen to this.

https://www.youtube.com/watch?v=8GQe5Jye7ik

Then listen to what Rare were pulling off.

https://www.youtube.com/watch?v=VPjIlXKu1fU

It sounds like a whole fucking different console, Factor 5's effort was so inferior. Jet Force Gemini sounds pretty much as good as Metal of Honor on PS1, despite the latter being backed up by CD data.

> ram is a choke point in every system
No it isn't. And it wasn't a bottleneck for the other two consoles in that generation. PS1 was uniformly considered to be bottlenecked by its CPU, and Saturn was bottlenecked by its VDP1 graphics chip.

>made up bullshit facts you've dug out of your misinformed asshole
Except it's obvious dumbshit. The N64's CPU is 3 times faster than PS1. The GPU also has a much higher fill rate than PS1.

The GPU's fill rate ITSELF isn't affected by z-buffer being on or off. Don't believe me? Check it out right here:

>One-cycle mode fills a fairly high-quality pixel. You can generate pixels that are perspectively corrected, bilinear filtered, modulate/decal textured, transparent, and Z-buffered, at one-cycle-per-pixel peak bandwidth.

http://n64devkit.square7.ch/pro-man/pro12/12-01.htm

Vs PS1 which was 33 MPixel/s in 1-cycle mode with its much lower of pixel processing.

So what was holding N64 back was entirely on the RAM.

>>4803936
meanwhile at rare

>>4803961
>> ram is a choke point in every system
> No it isn't.
then..
> So what was holding N64 back was entirely on the RAM.

typical american retardation.

>>4803975
What the fuck are you on about? It's not a choke point in every system, that's true, but it is a choke point for N64. How is anything that was said inconsistent you dumb yuro fuck?

>>4803404
>Some of that might have been avoided if the game had been coded a bit more cleanly and wasn't so buggy.
It was largely coded by one person, apparently. Lucasarts diverted team members to work on Battle for Naboo because they wanted a Star Wars tie-in game for Christmas.

>>4803817
Why the hell would you play a game with point sampled textures?
>>4803839
>>So what's actually wrong with it? You haven't described the issue.
Perfect Dark is already an extremely fuzzy game. Expanding the viewpoint has a negative impact on texrects because the bilinear filtering doesn't handle stretching well. This is lessened if the game renders in a widescreen resolution (such as perfect Dark's high resolution, which is 640x240 in NTSC and 480 by something or other in PAL). If you take a 320x240 game and attempt to widen the viewports, bad things begin to happen, and it's entirely the fault of the N64's bilinear technique.
>Except Factor 5 *literally* hyped up the quality of their audio driver as the best possible one for N64. Yet it sounds far FAR inferior to what Rare were doing.
Factor 5's MusyX audio system is fantastic. You're basically just saying, "I like British composers more than German composers imitating the works of John Williams." Several N64 games use MusyX, including Resident Evil 2 N64. The point of MusyX wasn't so much to make better quality music. It was to reduce the CPU overheads of music.
>>4803961
>The only middleware they sold was voice compression technology which was admittedly good, but they were not better than Rare at anything else. Arguably worse, even.
The rendering techniques in Rogue Squadron/Naboo/Indiana Jones are light years beyond what Rare were doing in terms of draw distance, performance, and visual complexity. The particle system they wrote for Naboo/Indy is a triumph of engineering. There's nothing else like it in any other 5th gen game.

>>4804154
>Perfect Dark is already an extremely fuzzy game. Expanding the viewpoint has a negative impact on texrects because the bilinear filtering doesn't handle stretching well.
Except that isn't happening and it isn't. Considering this is being shit out of an N64 without RGB into a webm, with stretched non-square pixels, not in high-res mode, this looks remarkably clear >>4802231

Your argument, the "muh bilinear filtering doesn't anamorphic stretch well" (directed at 3 or 4 point bilinear i can't even tell anymore) doesn't hold up to scrutiny at all.

There's only one significant disadvantage to 3 point bilinear filtering and you haven't even named it (instead you've named the font rendering which has nothing to do with 3 point). And that's 3 point filtering creates weird diamond shaped artifacts in textures when you look closely (though these can be avoided if the developer pre-filters the texture).

>Factor 5's MusyX audio system is fantastic. You're basically just saying, "I like British composers more than German composers imitating the works of John Williams."
No, I'm not saying that at all. I'm saying that MusyX sounds like tinny MIDI, while the audio in Rare games on N64 actually have richer sound production.

>Several N64 games use MusyX, including Resident Evil 2 N64
I'm pretty sure RE2 is the only one that uses the whole audio driver outside of Factor 5's own games. Shit like Pokemon Stadium only used the voice decompression. RE2 on N64 also sounds pretty tinny despite allegedly using superior music samples to PS1, I think the only genuine improvement is the Dolby Surround support (which Rare and even Nintendo in MM also managed in their audio engines).

>The point of MusyX wasn't so much to make better quality music. It was to reduce the CPU overheads of music.
GPU overheads actually, since the N64's GPU processes sound. Too bad it sounds like a General MIDI module from 1993. I don't doubt the efficiency though.

>>4804154
>The rendering techniques in Rogue Squadron/Naboo/Indiana Jones are light years beyond what Rare were doing in terms of draw distance, performance, and visual complexity.
Nah, I'd put it squarely at Rare quality visuals, technically speaking. Less detail than Rare games but at a higher resolution with a comparable framerate. They were not wizard coders.

Battle for Naboo uses Spyro-like gouraud shading stage LOD, while Conker uses the superior mipmap technique. Further, Naboo uses few directional light sources, leaning instead heavily on computationally simple lightmaps, while Conker uses up to 4 simultaneous light sources.

As for texturing, Conker can display a wide variety of textures in any one scene with multitexturing blending different types over each other to produce unique texel combinations, while Naboo just tiles the same goddamn texture over and over. Conker also has a sophisticated shadowing system which correctly projects onto walls depending on angles, while Naboo just uses a simple heightmap based one. Granted, Naboo is showing larger draw distances than Conker and more 3D models on screen, being a arcade-style flight sim, but on balance it's hardly showing a technical edge. They matched Rare but they didn't go beyond.

>The particle system they wrote for Naboo/Indy is a triumph of engineering. There's nothing else like it in any other 5th gen game.
You really need to stop drinking the Factor 5 kool aid. They look good but are nothing mindblowing compared to Conker, which has particles which are direction dependent rather than the mostly ambient 'snow' particle effects in Naboo/Indy.

>>4804189
>No, I'm not saying that at all. I'm saying that MusyX sounds like tinny MIDI, while the audio in Rare games on N64 actually have richer sound production.
MusyX is literally a sequencing/playback system. It has jack shit to do with actual audio sample quality.
>There's only one significant disadvantage to 3 point bilinear filtering and you haven't even named it (instead you've named the font rendering which has nothing to do with 3 point).
It has everything to do with 3-point. A fair number of N64 developers rendered text as texrects with 3-point bilinear applied to them. These misbehave when widescreen is forced on a real hardware. It has caused severe problems for people trying to create widescreen hacks that work on real hardware. The problem was discovered fairly recently.
>I'm pretty sure RE2 is the only one that uses the whole audio driver outside of Factor 5's own games. Shit like Pokemon Stadium only used the voice decompression.
The speech codec is MORT. MusyX is different.
>GPU overheads actually, since the N64's GPU processes sound.
It's both. Some N64 games use the CPU to process audio, most use the RSP. MusyX uses both, depending on developer preference.

>>4803976
>you dumb yuro fuck
>yuro
Wow, anon, good job proving you're not retarded.

>>4804218
>It has jack shit to do with actual audio sample quality.
It places severe limits on sample quality. How do you think they got those CPU usage savings? As I said, I'm sure it's efficient but it just doesn't sound good.

>These misbehave when widescreen is forced on a real hardware
I guarantee you that they would misbehave whether they were 3 or 4 point. These widescreen hacks are probably fucking with texture coordinate constants that the texture filtering unit relies on.

>The problem was discovered fairly recently.
How about a link showing these issues then?

>The speech codec is MORT. MusyX is different.
Whatever, it's module in the Factor 5 audio driver package.

>It's both. Some N64 games use the CPU to process audio, most use the RSP. MusyX uses both, depending on developer preference
True, but it mostly relies on GPU since a vector unit is faster at audio processing than a CPU. Some games will just adjust the workload ratio between the two as required.

>>4804214
>They look good but are nothing mindblowing compared to Conker, which has particles which are direction dependent rather than the mostly ambient 'snow' particle effects in Naboo/Indy.
How many particles did Conker have onscreen at once? Indiana Jones uses its particle system for water spray, smoke, rubble, snow, and Naboo uses it for rain. The sheer number of particles being sprayed onscreen at once is literally the same shit Naughty Dog later got their dick sucked for implementing in the Uncharted games. Offloading particle processing to the vector co-processors.

>>4804227
m8 even OoT got close, and did similar shit when it was raining and storming. And Nintendo didn't give a fuck about pushing their hardware.

Also it's much easier to do ambient particles than dynamic ones, which is why Sony showed off the power of the PS2 using the fireworks game Fantavision.

>>4804214
>Battle for Naboo uses Spyro-like gouraud shading stage LOD, while Conker uses the superior mipmap technique.
Battle for Naboo has an extremely sophisticated terrain generation system that runs almost entirely on the RSP, and minimizes CPU<>RAM access. There are reasons why they chose the rendering techniques they did.
>Further, Naboo uses few directional light sources, leaning instead heavily on computationally simple lightmaps, while Conker uses up to 4 simultaneous light sources.
Battle for Naboo has different priorities for its lighting system. In particular, every single blaster bolt and explosion creates its own light source. The lights aren't really proper point lights, so they can effectively create an unlimited number of them. The game is built around huge battlefields, not intimate scenes with elaborate lighting. Indiana Jones goes in that direction, with Indy's gun creating muzzle flash and his lighter nicely lighting scenes and heaps of light sources around the levels.

Factor 5 steered clear of a number of techniques used by Rare games because they required z-buffer usage or heavy framebuffer usage. You'll notice that Factor 5 games basically never use framebuffer effects. That's because using the FB involved reading and writing from ram, which was poison for performance. They tried to handle as much as possible on the RSP itself.
>Conker also has a sophisticated shadowing system which correctly projects onto walls depending on angles, while Naboo just uses a simple heightmap based one.
This is what I mean. While Conker's shadow is fantastic, it's a framebuffer effect. Every single frame, the RAM is being R/Wed to update the FB version of Conker based on a lower LoD model. Indiana Jones runs at 400x440. Conker runs at like 280x200 or something like that. Very few devs could attain decent framerates at resolutions like that.

>>4804249
>Battle for Naboo has an extremely sophisticated terrain generation system that runs almost entirely on the RSP, and minimizes CPU<>RAM access
Wow dude, if Factor 5's work was so incredibly amazing, then how come PS1 which doesn't even have a programmable vector unit, could have heightmap terrain of comparable quality to Naboo?

https://www.youtube.com/watch?v=j986HhbzIwg

>Battle for Naboo has different priorities for its lighting system. In particular, every single blaster bolt and explosion creates its own light source
lmao, no it doesn't. All the blaster bolt and explosions do is trigger lightmaps in the terrain polygons. Well done Factor 5! You pulled off what Quake did in 1996 and called it "nearly unlimited light sources". Dude, this was just that overhype bullshit that other developers like Criterion were laughing at Factor 5 for.

>Factor 5 steered clear of a number of techniques used by Rare games because they required z-buffer usage or heavy framebuffer usage
All getting rid of z-buffer did for Factor 5 is free up enough memory bandwidth so they could use higher resolutions than 240p at reasonable framerates, while Rare stuck to z-buffered 240p.

>Conker runs at like 280x200 or something like that. Very few devs could attain decent framerates at resolutions like that.
Look I do agree that what Factor 5 pulled off was impressive. Due to the high resolution Factor 5's games are easily the sharpest 3D games on the N64. But they didn't have their cake and eat it also. The were not so sufficiently better than Rare that they could pull off equally good graphics, at a higher resolution, with a better framerate or anything like that. It's just higher-res, with more shit on screen, but moderately lesser overall detail.

>>4804238
>m8 even OoT got close
CLOSE? CLOSE? OoT has maybe 30 particles onscreen all moving in the same direction. Indiana Jones has more particles than I can count and they're all moving independently.
See here. (17:00)
https://youtu.be/q9UfIFRYDb0?t=16m58s

>>4804257
Looks good through sheer numbers but my mind isn't blown. There's no interesting physics on those particles, which makes them not unlike the ones in OoT. The particles in Conker by contrast behave in visually arresting ways.

>>4804256
>Wow dude, if Factor 5's work was so incredibly amazing, then how come PS1 which doesn't even have a programmable vector unit, could have heightmap terrain of comparable quality to Naboo?
Firstly, I think you need to play Naboo again. Terracon's terrain quality isn't anywhere near as good as Naboo's. Secondly, I think you misunderstand the problem. They came up with that solution because the N64's terrain rendering performance was dogshit. If they wanted to have huge, detailed, textured landscapes, they need to get creative. Otherwise the performance was in the toilet. The PS1 didn't have crippling latency problems.
>All the blaster bolt and explosions do is trigger lightmaps in the terrain polygons.
I think you're getting lightmaps confused with something else. What most N64 games do is actually vertex painting. For instance, the dynamic lighting system used in the Turok series is pretty nice and directionally affects entities, but they're not real point lights. It looks like dynamic lighting, but it isn't in the traditional sense.

Like, look at Conker. It's using a similar technique, but it has a limit to how many lights it can render per scene.

>>4804263
What do you mean by physics?

>>4804265
>They came up with that solution because the N64's terrain rendering performance was dogshit
But it shouldn’t be. IIRC PS1 has a 3 element vector unit (something like 36 bit, 12 bit elements times 3) running at 33 MHz, while N64 has an 8 element vector unit (128 bit, 16 bit elements times 8) running at 62.5 MHz. You can actually program the N64 vector unit for whatever program you want too, which makes it more efficient. Of course it also has to partially process audio, and does way more sophisticated triangle setup for perspective correct textures, etc.

Factor 5 eliminated some of the memory bandwidth chokepoint by using the z-buffer. All things considered, what they accomplished was not really any more impressive than what those literally who developers of Terracon managed on what was much more limited hardware.

>The PS1 didn't have crippling latency problems.
You use the word latency like a buzzword, free of understanding. The N64’s vector unit is not so badly effected by the memory bandwidth limitations as the CPU and pixel pipeline are because it hardly ever has to write out to RAM. It either writes to its own data cache, or sends the vector data straight into the rasterizer at the top of the pixel pipeline via a dedicated bus.

>I think you're getting lightmaps confused with something else
No, lightmaps are a computationally cheap but inaccurate way of getting lighting without gouraud interpolation. It’s why when you shoot a laser in Naboo, it lights up a disproportionately large block of the terrain instead of a finer and more accurate amount of it.

>What most N64 games do is actually vertex painting. For instance, the dynamic lighting system used in the Turok series is pretty nice and directionally affects entities, but they're not real point lights
By vertex painting, I assume you mean vertex lighting. But no, vertex lighting actually require real point lights, though some games only use one global light point, like Naboo.

>>4804290
Like wind variation or even collision

>>4804297
>By vertex painting, I assume you mean vertex lighting.
No, I mean literally painting vertexes with colours to mimic lighting them. It looks like per-vertex lighting, but it isn't. The reason why Turok 2/3's dynamic lighting went unimplement is because the lights in question aren't actually lights. Rogue Squadron puzzled the people reverse engineering it because there is no lighting in the microcode at all. It's all fake.
>But it shouldn’t be. IIRC PS1 has a 3 element vector unit (something like 36 bit, 12 bit elements times 3) running at 33 MHz, while N64 has an 8 element vector unit (128 bit, 16 bit elements times 8) running at 62.5 MHz. You can actually program the N64 vector unit for whatever program you want too, which makes it more efficient.
The problem is that any attempts to access the RAM when you're rendering what is essentially an open world fucks you in the ass. So you have to figure out how to render complex terrain without accessing the CPU and with as little RAM access as possible. That's why they had to write the entire terrain system in microcode for the RSP. Nobody else did that.

>>4804321
>No, I mean literally painting vertexes with colours to mimic lighting them
That will either be vertex lighting (lighting interpolated between the three vertices based on direction) or lightmaps (light intensity on the whole polygon based on simple distance or even just manually trigger). There’s no in-between. It’s either one or the other in these old games (pixel shaded lighting wasn’t a thing yet), though there are a ton of different vertex lighting algorithms which accounts for variation.

>The reason why Turok 2/3's dynamic lighting went unimplement is because the lights in question aren't actually lights.
No. They actually use vertex lighting, but the algorithm used in the microcode wasn’t known.

>Rogue Squadron puzzled the people reverse engineering it because there is no lighting in the microcode at all. It's all fake.
Because it mostly is. The Factor 5 games predominantly use lightmaps instead of vertex lighting, though they do use some vertex lighting. Pretty sure just one global vertex light source for the sun or whatever.

>That's why they had to write the entire terrain system in microcode for the RSP. Nobody else did that.
Everybody had to do that. Putting RAM aside, the CPU is terrible at terrain generation compared to RSP. At best you can say that Factor 5 generated a more sophisticated terrain than other developers due to more efficiency, but their techniques were not really a revolutionary use of hardware.
>The reason why Turok 2/3's dynamic lighting went unimplement is because the lights in question aren't actually lights.

>>4804321 #
>No, I mean literally painting vertexes with colours to mimic lighting them
That will either be vertex lighting (lighting interpolated between the three vertices based on direction) or lightmaps (light intensity on the whole polygon based on simple distance or even just manually trigger). There’s no in-between. It’s either one or the other in these old games (pixel shaded lighting wasn’t a thing yet), though there are a ton of different vertex lighting algorithms which accounts for variation.

>The reason why Turok 2/3's dynamic lighting went unimplement is because the lights in question aren't actually lights.
No. They actually use vertex lighting, but the algorithm used in the microcode wasn’t known.

>Rogue Squadron puzzled the people reverse engineering it because there is no lighting in the microcode at all. It's all fake.
Because it mostly is. The Factor 5 games predominantly use lightmaps instead of vertex lighting, though they do use some vertex lighting. Pretty sure just one global vertex light source for the sun or whatever.

>That's why they had to write the entire terrain system in microcode for the RSP. Nobody else did that.
Everybody had to do that. Putting RAM aside, the CPU is terrible at terrain generation compared to RSP. At best you can say that Factor 5 generated a more sophisticated terrain than other developers due to more efficiency, but their techniques were not really a revolutionary use of hardware.

Well, having looked into it, it does seem that the Turok 2 lighting method isn't directional but based on distance.

http://gliden64.blogspot.com.au/2017/06/acclaim-custom-lighting.html

However, it's still vertex lighting, since the calculation is per-vertex and interpolated, rather than fixed across the whole polygon like it seems to be with the laser blasts in Naboo (or at least it seems that way because it looks pretty bad). So you could say that Turok 2 is vertex lighting that uses the kind of maths used to trigger dynamic lightmaps.

Games like Conker and Majora's Mask use actual directional vertex lighting though.

It's a pity Lucasarts sent this out to die because it's a quality game that deserved to be more played.