[ 3 / biz / cgl / ck / diy / fa / ic / jp / lit / sci / vr / vt ] [ index / top / reports ] [ become a patron ] [ status ]
2023-11: Warosu is now out of extended maintenance.

/vr/ - Retro Games


View post   

File: 41 KB, 980x490, landscape-1465570966-n64-console-bare.jpg [View same] [iqdb] [saucenao] [google]
3994902 No.3994902 [Reply] [Original]

Why is N64 emulation STILL lagging behind?

>> No.3994908

Limited sales and interest to/from 3rd world shitholes like Europe, South America, and china.

>> No.3994916

>>3994902
>Why is N64 emulation STILL lagging behind?
general incompetence

i bet the author of mednafen could get this shit sorted out in 6 months tops, 2 months minimum

>> No.3994921 [DELETED] 

>>3994916

I'm just thankful for Saturn and PSX emulation.

>> No.3994923

>>3994921
amen

>> No.3994926

>>3994921
>saturn emulation
I thought that was still absolute shit too

>> No.3994935 [DELETED] 

>>3994926

Nope. mednafen gets better with every release. Tons of games are playable, quite a few manifest no glitches of any kind.

>> No.3994938

>>3994926
>I thought that was still absolute shit too
you must have been listening to that guy who hates SSF because it forces him to use virtual drive software

give him a few minutes, he'll show up

>> No.3994939

>>3994926
Of all the gens, 5th seems kinda unfinished. Only PS1 (and maybe) 3DO seems quite good

>> No.3994941 [DELETED] 

>>3994938

I'd hate an emulator for pulling that bullshit too. Fuck the Japs.

>> No.3994943

>>3994938
>needing to read 3+ guides and search for a virtual drive software that works
>good

>> No.3994946
File: 2.75 MB, 376x376, 1476682016236.gif [View same] [iqdb] [saucenao] [google]
3994946

>>3994941

>> No.3994947

The answer is very simple. Consoles older than the N64 used extremely dumb (I don't mean that disparagingly btw, just a description of how they work), simplistic renderers with barely any features. PS1 is a great example. That makes them very easy to emulate in software, and even in hardware to some extent.

Consoles newer than N64 use sophisticated renderers that are DirectX or OpenGL compliant (Dreamcast and PS2 are good examples). This makes them easy to emulate in hardware.

The N64, however, is the only console ever made that uses a sophisticated renderer that isn't compliant with any API used on PC because the hardware predates them. Its GPU does things in a different way than any PC GPU. To add to the challenge, it has a very sophisticated vertex shading programmability feature for its day which is poorly understood. Lastly, the components in the console are more tightly syncronized than your average machine since they are threaded to share one piece of RAM. Modern computers are all about parallelization while N64 low-level emulation demands extreme single-threaded performance. Finally, the console can do weird things like the CPU can directly interfere with GPU-reserved memory (e.g. framebuffer, etc) which can cause unpredictable behavior for emulators.

>> No.3994951 [DELETED] 

>>3994946

mmmmmm...Right up the fishy ol' stinker.

>> No.3994953

>>3994947
So how come things like the Jag and Saturn don't have much good emulation?

>> No.3994959 [DELETED] 

>>3994947

>The answer is very simple.

What did he mean by this?

>> No.3994960 [DELETED] 

>>3994953

Saturn emulation improves every month my dude.

>> No.3994963

>>3994953
Lack of interest until recently.

>> No.3994992

>>3994902
because Mario, Zelda, Pokemon, and Rare games already work, and nobody gives a shit about the rest.

>> No.3994997

>>3994926
>I thought that was still absolute shit too

There's no working Saturn emulator for Android, so yeah, it is still absolute shit.

>>3994943
I've been using the same virtual drive software for a decade and it is working perfect.

and you don't need a guide to run SSF, not anymore than for every other emulator.

>> No.3994998
File: 1003 KB, 250x251, 1408875776190.gif [View same] [iqdb] [saucenao] [google]
3994998

>>3994992
Than why is the N64 the second most popular retro console now days?

>> No.3995001

>>3994963
never an excuse

>>3994953
saturn is a legitimately complicated system on a hardware level.

>> No.3995004

>>3994947
>Consoles newer than N64 use sophisticated renderers that are DirectX or OpenGL compliant (Dreamcast and PS2 are good examples).

No, they are awful examples, they use noncompliant floating points that cause glitches in the emulation of many games (Border Down was one, I think), and they also use custom video hardware that might be distinctly similar to DX or OGL but internally they work in a completely different way. Dreamcast uses tile based deferred rendering and 32bit Z-buffer just from the top of my head (pretty much all emulators suffer from z-sort issues, like broken shadows in normal games, or hidden projectiles in Ikaruga), while the PSX2 has something like 128 internal cores in the gpu that work in tandom with 2048 bit RDRAM, as well as two vector units to do the math.

They are just more popular consoles with tons of great exclusives, so people put more effort into emulating them.

for the N64 you have something like 10 good exclusives, half of which got ports in other consoles.

>> No.3995007

>>3995001
>saturn is a legitimately complicated system on a hardware level.

No, it just has a lot of shit inside, and implementing all of that on a basic level already takes a fucking year.

Note that almost no games actually push the hardware, so basic implementation already gets you 70% of the library running with no or minor glitches.

>> No.3995015

>>3995004
>they use noncompliant floating points
It can be a problem but not a huge one.

>they also use custom video hardware that might be distinctly similar to DX or OGL but internally they work in a completely different way
Irrelevent. If they respond to DX or GL commands and the output of those commands are compliant (which they are) it doesn't matter how those results were achieved.

>Dreamcast uses tile based deferred rendering and 32bit Z-buffer
There were several tile based deferring rendering cards on PC which were DX compliant (Kyro is the most recent example). Furthermore, Nvidia Maxwell and Pascal now use a form of deferred rendering. Anyway, the above point stands. It doesn't matter how the result was achieved (every brand of card works slightly differently anyway) as long as the result is compliant.

Also 32-bit Z-buffer is standard now, even if it wasn't back then.

Even the N64's bilinear filter isn't DX or GL compliant (as in, the inputs and outputs are different) and that's only the smallest inconsistency. Totally different kettle of fish to the likes of Dreamcast.

>> No.3995104

>>3994902
because people focus on emulators for consoles with tons of good games, sadly N64 doesn't have this feature

>> No.3995195

>>3995015
>It can be a problem but not a huge one.
Yeah, it only breaks games, and needs completely custom math to fix. Oh wait...

>If they respond to DX or GL commands
They don't.

>and the output of those commands are compliant
They aren't.

>Furthermore, Nvidia Maxwell and Pascal now use a form of deferred rendering.
On a silicon level that a normal programmer cannot touch, making it completely irrelevant.

>Also 32-bit Z-buffer is standard now, even if it wasn't back then.
With DX10, yes, but it uses different bit depth iirc. Yeah you can write your own compute shader code to get around that but... this is more difficult, and then you are subject to whatever dodgy support videocard hardware has for that (Intel, AMD, Nvidia all handle shit differently, in hardware and in drivers, and OGL is a patchy piece of shit of a standard on top of all that).

>Totally different kettle of fish to the likes of Dreamcast.

If anything, the N64 is closer to modern hardware with its primitive shaders than the Dreamcast, which uses an internal rasterization that is completely different than what modern hardware does (and in many ways, much more advanced, hence why it could trade blows with the PS2 with a hundredth of the fillrate).

>> No.3995275

>>3995195
>Yeah, it only breaks games
There are very few situations where more precision would break a game. Those particular routines can be trapped and down in software. It's trivial. Just like how early DirectX 9 shader code was either compiled in 16-bit, 24-bit or 32-bit precision and they all worked on both Nvidia and ATi hardware despite the latter preferring 24-bit and the former preferring 16-bit and 32-bit.

>They don't.
Yes they do. Dreamcast's GPU (PowerVR2) is completely DX 6 certified. Same with the its PC variant. PS2's GPU is OpenGL certified.

That's not to say, however, that both consoles GPUs don't have propriety DX or GL extensions. These are the only things that would present challenges to emulation.

>They don't.
But they are. For any given DX / GL input their output has to meet the specification. And it does.

>On a silicon level that a normal programmer cannot touch
And it's exactly the same with Dreamcast's tile deferring rendering or any other GPU hardware for that matter. The inner workings of the rasterizer is completely off limits - you can only issue commands to it.

>the N64 is closer to modern hardware with its primitive shaders than the Dreamcast
No. It's completely wrong. N64 hardware is only more similar to modern hardware in the overall pixel fill technique it uses (immediate mode rendering as opposed to Dreamcast's tile based deferred rendering).

However, the rasterization unit, texture unit, texture filtering unit, blending unit, color combining unit, etc on the N64 are not DX / GL compliant because their inputs and outputs do not meet the specifications.

A minor example: the texture filtering unit on the N64 uses the non-compliant 3-sample bilinear instead of 4-sample. Also the filtering unit uses non-compliant texture alignment parameters for the filtering of texels on the border of pixels. Which is why N64 emulators usually show lots of texture seams.

>> No.3995297 [DELETED] 

>>3995275
*Meant to say texels bordering between textures

>> No.3995303

>>3995275
*meant to say texels on the borders of textures

>> No.3995316

>>3995275
>Those particular routines can be trapped and down in software. It's trivial.
>per-game hacks
>trivial

Stopped reading there. This is exactly why N64 emulation has made zero progress in the past ten years.

>> No.3995331

>>3995275
Only thing I would add is that PS2 indeed had an OpenGL implementation that was used in some games. Back in the day I had the Japanese paper describing it, but I don´'t have it anymore

>> No.3995353

>>3995316
We're talking about HLE of course. My explainations of it shouldn't be interpreted as support for HLE. Good HLE can be really good though. But no, just because a routine has to be done in software doesn't mean it's a "per-game hack. A lot of general HLE is done in software anyway.

>> No.3995381

>>3995275
>Dreamcast's GPU (PowerVR2) is completely DX 6 certified. Same with the its PC variant. PS2's GPU is OpenGL certified.

DX and GL are just a bunch of standards on paper. A GPU may meet them on paper, but internally work completely different. You can't just offload the gpu emulation, it has been done before and the result was a broken mess with z-sorting issues, fucked up stencils, broken framebuffer effects.

Console GPUs are programmed directly to the metal and this allows the coders to do way more with them than what DX and GL would allow, and you cannot emulate that sort of stuff by simply offloading everything.

>For any given DX / GL input their output has to meet the specification. And it does.

They may have other inputs, which do not, and provide greater freedom for the programmers for various reasons. Or, they may TECHNICALLY meet the specification, but not in reality. For example, multitexturing on Dreamcast can be done, but it isn't done in hardware, but by drawing multiple alpha blended textured polygons on each other, manually.

>The inner workings of the rasterizer is completely off limits - you can only issue commands to it.

You can issue commands that get around the consoles limitations in creative ways. With a console being on the market for 3-8 years, this happens a lot.

>> No.3995385

>>3995331
Having an OpenGL implementation does not mean that the hardware is OpenGL compliant, nor does it mean that all it does is what OpenGL does.

>> No.3995407

>>3994992
GoldenEye is still garbage in emulators.

>> No.3995409

>>3995381
>but internally work completely different
Nvidia and AMD GPUs internally work completely differently, and it means jack shit.

>You can't just offload the gpu emulation, it has been done before and the result was a broken mess with z-sorting issues, fucked up stencils, broken framebuffer effects
I think you're getting LLE and HLE mixed up...the whole point of HLE isn't to emulate the hardware but its output by using equivalent API commands.

>Console GPUs are programmed directly to the metal
This is a misnomer and does not mean what you think it means.

>this allows the coders to do way more with them than what DX and GL would allow
Because some console GPUs have extensions on top of DX and GL. I'll re-emphasize the key phrase here: "on top of".

>They may have other inputs, which do not, and provide greater freedom for the programmers for various reasons
The extra inputs would be extensions. However, to meet the DX / GL specification they have to also have inputs which comply with them. However, because console hardware is economically produced, they don't have super-wide pipes where the hardware is replicated wholly for say DX and wholly for extensions. By that I mean, no console GPU has anything like a texture filtering unit which is DX compliant and then a second one which follows its own rules. No, it's got the one filtering unit which is compliant and maybe some extra extensions on top of that.

>multitexturing on Dreamcast can be done, but it isn't done in hardware, but by drawing multiple alpha blended textured polygons on each other,
As said time and time again. It doesn't matter how the console achieves the output for any given input. The only important thing is that for any given input, the output is DX / GL compliant.

It might matter for LLE (implementation-wise only), but it doesn't matter for HLE.

All HLE cares about is shitting out framebuffers that look like the framebuffers the real console shits out when reading game data.

>> No.3995564

>>3994902
Probably because no one cares to really work on it, since it doesn't really have any games worth playing in 2017?

>> No.3995578

>>3994902
just get a real one

>> No.3995579
File: 193 KB, 500x387, goemon2.png [View same] [iqdb] [saucenao] [google]
3995579

>>3995564
You wish.

>> No.3995676

>>3995564

>>3994998

>> No.3995704

>>3995385
While technically true, just come on. If the implementation isn't similar to what developers had in their PC's, why would they bother porting the graphics API?
Also, in that time frame, you REALLY didn't need all OGL features (pallete textures, slow immediate mode and such).
If I can issue my vertex, object... commands the same way I did in the PC, and my final framebuffer is similar to what would my GeForce 2 would spit with a decent performance, I'm ok with it.

>> No.3995954

>>3995409
>Nvidia and AMD GPUs internally work completely differently, and it means jack shit.
Because you have hundreds of mbytes worth of drivers to make them "work" for you in every game, more or less.

>the whole point of HLE isn't to emulate the hardware but its output by using equivalent API commands.
Which doesn't mean fuck all when the game doesn't use DX/GL calls, but instead manipulates reading lists in vram, or the framebuffer contents, entirely manually in software.

>This is a misnomer and does not mean what you think it means.
It means they send draw commands directly into the VRAM command list for the gpu to execute them at a time it is set up to do it. Meanwhile with DX / GL you do glBufferData(GL_ARRAY_BUFFER, sizeof(g_vertex_buffer_data), g_vertex_buffer_data, GL_STATIC_DRAW); which calls OpenGL to draw a triangle, which calls the device driver to draw a triangle, which then puts the draw command into the vram.

>I'll re-emphasize the key phrase here: "on top of".
In an ideal world yes, but due to millions of different restrictions (including: time, money, transistor budget, etc), it's more like the other way around: the gpu works in some specific way, which is extended in software for it to be DX/GL compliant to a degree depending on implementation.

Consoles don't just run DX/GL and leave it at that. Well you can, but then your performance is at the mercy of that specific interpretation (which most likely comes from a devkit). This is why they could HLE most N64 games fine, because they used the same implementation. But different games could use different code, or even fully custom code, and do things for which you have no DX or GL equivalents, because they use something unorthodox or something extremely hardware specific, to do an interesting effect or to achieve higher performance.

HLE won't get you accurate emulation, unless you write so many extensions for the hardwares peculiarities that it ends up being an LLE implementation.

>> No.3995969

>>3995704
>If the implementation isn't similar to what developers had in their PC's, why would they bother porting the graphics API?

Because that is their job, retard.

>If I can issue my vertex, object... commands the same way I did in the PC, and my final framebuffer is similar to what would my GeForce 2 would spit with a decent performance, I'm ok with it.

Yeah, but Japanese programmer Osakawa Hiroshima might be bothered that that API only gets him 42fps with constant framedrops, and he may end up converting the GL commands to direct hardware calls, so they can reach the target 60fps in their dreamcast touhou game.

>> No.3996017

>>3995954
>Because you have hundreds of mbytes worth of drivers to make them "work" for you
Drivers are just the software interface that links the hardware to the software. You can't do heavy duty stuff with it, like implement hardware feature in software, unless you want to put a real drain on the CPU. The fact is, even though Nvidia and AMD have different ways of getting there, they've produced little DX engines. DX in, DX out.

>Which doesn't mean fuck all when the game doesn't use DX/GL calls, but instead manipulates reading lists in vram, or the framebuffer contents, entirely manually in software.
Then that becomes a matter of CPU interpretation, not GPU. You're conflating the issues here. GPUs, even console GPUs, aren't truly programmable like CPUs are. And even the efforts to standardize their programmability (Vulkan for instance) requires conformity to yet another set of compliance rules.

>It means they send draw commands directly into the VRAM command list for the gpu
As above, that's the CPU's work. You can do it on N64 because the CPU has direct access to "VRAM".

>the gpu works in some specific way, which is extended in software for it to be DX/GL compliant
You cannot achieve compliance to another APU in software (without enormous CPU overhead that is) unless the hardware is already 99% compliant. That's why MiniGL drivers were possible for 3dfx cards - the Voodoo cards were already designed according to a similar paradigm so there was some overlap between Glide and OpenGL.

>Consoles don't just run DX/GL and leave it at that.
Most of what they do is DX/GL, or the slightly extended version of them provided by the console manufacture. The optimization you are talking about is CPU (and hence memory management) related.

>This is why they could HLE most N64 games fine
The reason N64 games could be HLE'd fine to a certain extent (particularly in the early days) is because there was some overlap between N64's way of doing things and Glide. Up to a point.

>> No.3996061

I'm sure if the emu scene wasn't such cheap bastards and raised $100k or whatever in a kickstarter someone could talented could make the BSNES of N64 emulators in a year's time.

>> No.3996084

>>3994902
It will be over soon. Or at least, some guys are trying it with CEN64. Not sure if it will come as far as BSNES/Higan but even at this point the emulation has become slightly better than it used to be several years ago.

>> No.3996232

>>3994902

What exactly isn't good enough about existing emulation? I use the 'tendo64' one for the android and it works great for smash bros, mario kart 64, ocarina of time, etc.

>> No.3996329

>>3995969
You know when you call other people retard for no reason you are a underaged prick,
Go fuck yourself with a BBC and die of fucking aids you shit piece of fuck

>> No.3996629

Is SGI's technology still poorly documented?

>> No.3996664

>>3994908
>3rd world shitholes
>like europe
>>>/pol/

>> No.3996676

>>3996084
>>3996084
it'll all be over soon
>an heros

>> No.3996680

>>3994902
Because only normies care about N64 and they're too busy getting laid and smoking weed to work on emulators.

>> No.3996690 [DELETED] 

>>3996676

Pretty much. Cen64 is a bit of a joke at this point. They're running into the same problems everyone older and wiser said they would.

>> No.3996724

>>3996680
>>3995202
Really made me think.

>> No.3996746

What is the best N64 emulator then?

>> No.3996767

Can't catch lightning in a bottle, my dudes

>> No.3996770

>>3996746
Project64 due to lack of competition.

Mugen for non-Windows.

>> No.3997176
File: 666 KB, 1280x1024, this is you.jpg [View same] [iqdb] [saucenao] [google]
3997176

>>3995004

>> No.3997182

>>3994902
Real reason is because most people who make emulators are from poor countries, the whole reason they want an emulator is because they can't afford to buy the physical hardware. The n64 was not popular in these poor countries due to the high price of carts, so there is much less interest to make an emulator for them as a result since they don't even know what they are missing out on. Notice how anyone who shits on the N64 are all ESL faggots?

>> No.3997186

>>3997182
Would there not be MORE incentive to make an emulator for expensive platforms?
Your logic seems kinda backwards.

>> No.3997486

>>3996676
>heros
Huh?
>Cen64 is a bit of a joke at this point. They're running into the same problems everyone older and wiser said they would.
What problems exactly? And how has it become "a bit of a joke"?

>> No.3997675

>>3994902
There is no public documentation on the n64 hardware.
Plenty of people are interested, but without those docs it's very difficult.
N64 emulation is fine though, but you'd need a 5 or 6ghz intel cpu to run the correct plugins like angrylion etc at fullspeed.
>>3994926
It's been extremely good for over a decade.
>>3994943
You wouldn't survive in the wild.
>>3994953
Pull your head out.
>>3994997
>Android
lol

>> No.3997793

>>3994916
I bet he couldn't, because he hasn't.

>> No.3997815

why doesnt paper mario work at all

>> No.3997842

>>3997675
>There is no public documentation on the n64 hardware
Everything is documented other than how RSP microcodes work

>> No.3997870

>>3994902
Umm all emulation is a laggy pos mess, buy an everdrive already you casuals

>> No.3997872 [DELETED] 

>>3997486

>What problems exactly? And how has it become "a bit of a joke"?

They're having difficulty getting it to perform on even high-end consumer hardware (and that's *with* drastic shit like no sound subsystem). Multithreading has completely stalled. Hell, the project itself is at a dead stop. They simply can't come up with a coherent multi-core paradigm that isn't the same or worse performance wise than single core. All this shit was predicted by people "in the know" regarding LLE emulation, because they've been eyeing a workable route to robust N64 emulation themselves over the years.

Marathonman taking long, unexpected hiatuses and only doing sporadic heavy lifting with the code has essentially killed all forward momentum from contributors.

>> No.3997873 [DELETED] 

>>3997842

Microcode documentation is a huge fucking deal, though. The best games (virtually all Rare offerings) use that shit extensively.

>> No.3998240

>>3994902
seems to me like Dolphin has you covered for the most important non-Rare games.

If you crave Perfect Dark, you could always play Rare Replay, or even TimeSplitters

>> No.3998267

>>3997873
>The best games (virtually all Rare offerings) use that shit extensively.
IIRC most custom microcode were just modifications of Nintendo-provided microcode.

Conker's microcode is just Nintendo's F3DEX microcode (an improved version of Fast3D) with custom lighting improvements. World Driver Championship's microcode is just Nintendo's Z-Sort microcode with some custom improvements.

I think Factor 5 were the only company that actually wrote microcode fully from scratch.

>> No.3998318

>>3995004
>PSX2

>> No.3998335

>>3995381
>a broken mess with z-sorting issues, fucked up stencils, broken framebuffer effects.
Neon Genesis Evangelion?

>> No.3998409

What are microcodes? Are they like opcodes or something? But what I don't get is how there's so much mystery surrounding them. Can't people just discover them by brute force?

>> No.3998417

>>3998409
In the RSP's case it's basically assembly used to construct DSP-like functions. The instruction set is based on MIPS but heavily modified. I think it already has been brute forced in LLE implementations.

>> No.3998480

>>3994908
>Implying america isn't the biggest 3rd world shithole on the planet.

>> No.3998523

>>3998318
oh, should I put up a trigger warning there for you special snowflakes?

>> No.3998535
File: 28 KB, 260x226, Neon Genesis Evangelion.jpg [View same] [iqdb] [saucenao] [google]
3998535

>>3998335
That game emulates like shit.

>> No.3998672

When will banjo tooie finally be playable with random freezing?

>> No.4000775

recently my everdrive 64 started playing games a little faster than they naturally are. is anyone familiar with this problem?

>> No.4001023

>>4000775
Are you playing PAL roms on a NTSC N64?

>> No.4001071

>>4001023
nope, PAL roms on a PAL n64. I started noticing just a week ago when Mario Kart seemed a little off and then confirmed it via comparing snowboard kids running on original cartridge and on a rom using the same console. i dont even know if it's permanent.

>> No.4001135

>>3994992
Perfect dark emulation is still buggy

>> No.4001195

>>3995407
And GoldenEye is fucking shit

>> No.4001196

>>3997182
Not a ESL,and shit on the N64 all the time. Worst console Nintendo has ever made. The only fans of it are tards,kids who grew up with it and die-hard Nintendo fanboys.

>> No.4001263

>>4001196
Disregard that. I suck cocks

>> No.4001408

>>3994902
I can play Perfect Dark flawlessly on 1964 so I dont care for anything else.