LLE Graphics Plugin

[ShadowPrince]

That doesn't make sense. More accuracte emulation causing more glitches than HLE makes no sense at all.

You're better listen to a guy who made a working N64 emulator.If it does make sense to him,than you can be sure,that it's the way.

For me, doesn't make sense to hear somebody making claims about full speed low level n64 emulator on 1Ghz machine.
This is comes from the people, who can't even make Mortal Kombat run full speed on such machine.
Even if he is good at MAME,i'm sorry,he doesn't know much about N64 emus.From the same "MAME" guy i heard that 1964 is fully HLE,so you see now what kind of N64 emulation experts they are.
The damn sources is available,how hard is to look and check it,before you make a ridiculous claim ?

Reznor,you've been told several times,that lle is already made,but it's so slow,that it cant compete with others, much more advanced and efficient methods.Try to understand it for 10s time ! LLE means SLOWER always , but it doesn't means BETTER.

 

[grand master]

That doesn't make sense. More accuracte emulation causing more glitches than HLE makes no sense at all.

Man give the man some respect i mean he is an emu author he knows what he is talking about.

If you know more then write your own emulator. Just give him the respect he deserves ok?

 

[grand master]

Wow shadow Prince replied 1 second b4 me! check out the times!

All i can say is RIGHT on man. Im sick of this bullsh*t.

This is comes from the people, who can't even make Mortal Kombat run full speed on such machine.

Hey man that hardware is like 11 years old ok? it has 2d sprites and everything! You will need to buy a computer in the year 2011!! I mean why is that unreasonable?? It makes sense to me?

I bet they will now claim that it is so powerful! so my question is is it more powerful than a ghz computer?? absolutley not! Iknow they will use there usual bullcrap to make up a story on how powerful the hardware was (yeah like 11 years ago) and how todays computers still cant handle it.

 

[Reznor007]

Wow shadow Prince replied 1 second b4 me! check out the times!

All i can say is RIGHT on man. Im sick of this bullsh*t.



Hey man that hardware is like 11 years old ok? it has 2d sprites and everything! You will need to buy a computer in the year 2011!! I mean why is that unreasonable?? It makes sense to me?

I bet they will now claim that it is so powerful! so my question is is it more powerful than a ghz computer?? absolutley not! Iknow they will use there usual bullcrap to make up a story on how powerful the hardware was (yeah like 11 years ago) and how todays computers still cant handle it.

MK2 was a [email protected]+ADSP2105@10MHz. The sound is the biggest speed hit. It was composed of 4 channels of MPEG-like sound data processed by the ADSP chip.

And if you want to get into years regarding emulation speed(which is totally wrong), N64 was finalized in 1995, MK2 was from 1993....surely 2 years won't make a difference. And remember that the Saturn came out before N64, yet emulating Saturn full speed is MUCH harder than N64.

 

[Reznor007]

You're better listen to a guy who made a working N64 emulator.If it does make sense to him,than you can be sure,that it's the way.

For me, doesn't make sense to hear somebody making claims about full speed low level n64 emulator on 1Ghz machine.
This is comes from the people, who can't even make Mortal Kombat run full speed on such machine.
Even if he is good at MAME,i'm sorry,he doesn't know much about N64 emus.From the same "MAME" guy i heard that 1964 is fully HLE,so you see now what kind of N64 emulation experts they are.
The damn sources is available,how hard is to look and check it,before you make a ridiculous claim ?

Reznor,you've been told several times,that lle is already made,but it's so slow,that it cant compete with others, much more advanced and efficient methods.Try to understand it for 10s time ! LLE means SLOWER always , but it doesn't means BETTER.

The dev that said that is a professional programmer and has worked on N64. I would trust him.

LLE slower yes, better? Hell yes. Do you think ZSNES would have near the compatibility it does if they HLE'd ANYTHING in there?

PS, MK should run ok on a 800MHz system.

 

[Slougi]

You cannot compare SNES and N64 developement/emulation. For snes, almost everything was afk done using assembly and custom libs, whereas for the N64 that is not true, and is thus much easier to HLE. If I understand correctly, HLE for snes would require that each game (or game family by a company) be emulated separately.

 

[Cyberman]

REZ you are comparing apples and oranges.

two totally different systems. With emulation you do what works. For SNES and ZNES it's handled with an interpretor (65816) and lots of careful work. Because of the size of ROM space the games are pretty packed (See star ocean with compressed graphic data). I think Tales of Phanatasia hit the biggest SNES size at 6Megs (not bits either).

Each system is a different animal and behaves differently LLE will always work but is a step to get somewhere. The N64 Emu's of today are a hybride breed that do both, for graphics they ignore handling each instruction, simply because it's faster and it is easier to do. That's reality if it works, I don't see a better or worse scenario.

I suspect the same thing will happen with Game Cube emulation, since Nintendo put a lot of special opcodes in it's power PC processor.

Cyb

 

[Reznor007]

Yes, you do what works, but in the case of SNES, nearly every game you can find(out of thousands) work fine. Only a handful have issues, most of which are caused by custom chips, extremely tiny timing issues, and things like that. On N64 there are only a few hundred games, and some that don't boot at all, and nearly every game has some kind glitch(ranging from an extremely tiny thing, to bad sound, etc).

I'm not trying to badmouth any N64 emu authors or anything like that, I'm just saying that rather than continue on with HLE methods, go back and do a LLE emulator. If people complain that it's slow, just use the pre-existing fast emulator until they can get a computer that will run the LLE version.

As for Gamecube, I doubt it will be done for a while. Even then it will be extremely slow. No one has even emulated early PowerPC chips, let alone a 750CX series model(at 100Mhz, let alone 485MHz).

 

[tooie]

let see snes is 3.58 MHz 16-bit CPU, pc need
Recommended System for 65536 (16-bit) color mode :
- Fast Pentium processor (P166 or higher)

from (emuhelp)

n64 64-bit MIPS RISC 93.75MHz CPU and
64bit 62.5MHz custom MIPS ASIC vector processor
lets say 150MHz (other then likely more if you caculate for the SIMD instructions)

n64 is about 42 times faster ..
so 166 * 42 = 6972 ..

so for lle of comparison we need about 7 ghz pc .. gee that is going to be fun to wait for a pc to run that fast just so we can just focus on low level

 

[Tagrineth]

let see snes is 3.58 MHz 16-bit CPU, pc need
Recommended System for 65536 (16-bit) color mode :
- Fast Pentium processor (P166 or higher)

from (emuhelp)

n64 64-bit MIPS RISC 93.75MHz CPU and
64bit 62.5MHz custom MIPS ASIC vector processor
lets say 150MHz (other then likely more if you caculate for the SIMD instructions)

n64 is about 42 times faster ..
so 166 * 42 = 6972 ..

so for lle of comparison we need about 7 ghz pc .. gee that is going to be fun to wait for a pc to run that fast just so we can just focus on low level

Bit skewed, eh?

First off, SNES also had a much more efficient processor than N64. The 65816 does a decent amount more in 3.58 million cycles than the r4300i does in the same cycles... (note: This is in terms of overall architecture, and takes into account the fact that the poor r4300i is idling about half the time)

Second, just about every last tidbit morsel of SNES emu code has to be LLE - with very, VERY few exceptions in the graphics segment. Now, N64 LLE has a few big-time gotchas, don't get me wrong - for example, lots of redundancy in the display list, LLE 3D is unbelievably slow on x86 processors - but N64 can easily get away with a good amount of HLE, especially in the rasterisation (big relief).

Third, SNES and N64 are... well, reversed, architecture-wise. SNES has a severely slow CPU which can't keep up with the rest of the system, while N64 has a stunningly fast CPU which the system can't keep fed half the time.

Now, yes, N64 'LLE' would take a lot of horsepower, but not 7GHz. I'd guesstimate most simpler games could probably be just about pulled off today on a 3.06GHz P4... but that does still assume hardware rasterisation. The most demanding games would probably go up to 5GHz but I doubt all but 1-2 games would need more than that.

HOWEVER - if you were to LLE the entire N64 architecture, including raster... your estimation is WAY low. Try in the 15GHz range for *playable* frame rates. :holiday:



Edit: One more thing, re: CPU/RCP interaction - if you're comparing process power (which you obviously are), you can't include the RCP. It is NOT part of the CPU. Also keep in mind that at least a decent amount of the RCP's SIMD can be done with SSE and probably also 3DNow!. If you want to count the RCP in with the r4300i, you have to account for SNES's deliciously efficient graphics processor, and its WAY-effing-ahead-of-its-time sound processor (which N64 can also get away with HLE'ing most of the time!) - again, SNES's SPC700 sound chip has to be LLE... and in this case it HAS to be 100% LLE. Can't do it any other way. Turning sound off alone brings SNES's system reqs down 66MHz...

 

[Reznor007]

Software bilinear filtering is slow on x86, but LLE 3d is not necessarily slow. You can have LLE with hardware rasterization. That is what Playstation emulators use. There has also been talk of using hardware rasterization for Namco System22(and others) in MAME.

Full LLE N64 emulation with hardware rasterization would probably take 2GHz for the most demanding game(not counting render-to-texture stuff). Icarus(the DC emu) is only estimated to need 8GHz for full emulation. Even NFL Blitz arcade, with software rendering(yeah, software Voodoo2), and interpreter mode CPU would only((!)) need 15GHz.

 

[Slougi]

Full LLE N64 emulation with hardware rasterization would probably take 2GHz for the most demanding game

ROFLMAO

/me falls of chair



I kinda doubt that

 

[grand master]

I give up!
no point talking to someone who knows nothing.
Let that be a lesson kids! Stay in school.

 

[RJARRRPCGP]

Bit skewed, eh?

First off, SNES also had a much more efficient processor than N64. The 65816 does a decent amount more in 3.58 million cycles than the r4300i does in the same cycles... (note: This is in terms of overall architecture, and takes into account the fact that the poor r4300i is idling about half the time)

Second, just about every last tidbit morsel of SNES emu code has to be LLE - with very, VERY few exceptions in the graphics segment. Now, N64 LLE has a few big-time gotchas, don't get me wrong - for example, lots of redundancy in the display list, LLE 3D is unbelievably slow on x86 processors - but N64 can easily get away with a good amount of HLE, especially in the rasterisation (big relief).

Third, SNES and N64 are... well, reversed, architecture-wise. SNES has a severely slow CPU which can't keep up with the rest of the system, while N64 has a stunningly fast CPU which the system can't keep fed half the time.

Now, yes, N64 'LLE' would take a lot of horsepower, but not 7GHz. I'd guesstimate most simpler games could probably be just about pulled off today on a 3.06GHz P4... but that does still assume hardware rasterisation. The most demanding games would probably go up to 5GHz but I doubt all but 1-2 games would need more than that.

HOWEVER - if you were to LLE the entire N64 architecture, including raster... your estimation is WAY low. Try in the 15GHz range for *playable* frame rates. :holiday:



Edit: One more thing, re: CPU/RCP interaction - if you're comparing process power (which you obviously are), you can't include the RCP. It is NOT part of the CPU. Also keep in mind that at least a decent amount of the RCP's SIMD can be done with SSE and probably also 3DNow!. If you want to count the RCP in with the r4300i, you have to account for SNES's deliciously efficient graphics processor, and its WAY-effing-ahead-of-its-time sound processor (which N64 can also get away with HLE'ing most of the time!) - again, SNES's SPC700 sound chip has to be LLE... and in this case it HAS to be 100% LLE. Can't do it any other way. Turning sound off alone brings SNES's system reqs down 66MHz...

15 Ghz!!! That processor is likely to require the following:

24V Vcore

1000 watt power supply.

 

[Hacktarux]

Software bilinear filtering is slow on x86, but LLE 3d is not necessarily slow. You can have LLE with hardware rasterization. That is what Playstation emulators use. There has also been talk of using hardware rasterization for Namco System22(and others) in MAME.

Full LLE N64 emulation with hardware rasterization would probably take 2GHz for the most demanding game(not counting render-to-texture stuff). Icarus(the DC emu) is only estimated to need 8GHz for full emulation. Even NFL Blitz arcade, with software rendering(yeah, software Voodoo2), and interpreter mode CPU would only((!)) need 15GHz.

I'll make it simple:
psx->less powerfull than n64
icarus->uses some hle afaik (not sure tho)

you want to remove gfx glitches in n64 games ? i think the best solution is a software rasterization (doesn't matter i u hle it or not)... but of course it'll still look like a screen shot session...

 

[Tagrineth]

Software bilinear filtering is slow on x86, but LLE 3d is not necessarily slow. You can have LLE with hardware rasterization. That is what Playstation emulators use. There has also been talk of using hardware rasterization for Namco System22(and others) in MAME.

Full LLE N64 emulation with hardware rasterization would probably take 2GHz for the most demanding game(not counting render-to-texture stuff). Icarus(the DC emu) is only estimated to need 8GHz for full emulation. Even NFL Blitz arcade, with software rendering(yeah, software Voodoo2), and interpreter mode CPU would only((!)) need 15GHz.

Which is basically a repeat of what I said.

LLE N64 emulation with hardware raster would take more than 2GHz though. Keep in mind the N64 display lists are really, really overcomplicated (which is why they aren't processed fully yet) and would take a LOT more muscle than that to run.

Dreamcast emulators would have to do *more* work for raster alone than N64 (not counting faster CPU, etc.)... DC runs at full 640x480, progressive (buy the VGA adaptor if you don't believe me!), with *proper* bilinear as default and trilinear in some games... trilinear is performance hell in x86 ASM. Keep in mind that on N64, not all surfaces are filtered, and that N64's bilinear uses only THREE samples.

Also Dreamcast uses a 200MHz SH-4 CPU, which is a good deal harder to emulate than N64's 94MHz r4300i...

But of course, that 8GHz figure is probably more like just CPU/sound with graphics mostly HLE.

 

[The Khan Artist]

Let me shove this thread in a different direction...

What about the Power970? When it hits the market, as the Power970, G5, whatever, would it be a viable platform for N64 LLE?

 

[Tagrineth]

Let me shove this thread in a different direction...

What about the Power970? When it hits the market, as the Power970, G5, whatever, would it be a viable platform for N64 LLE?

Dunno. Depends on the clock speed, IPC, and how efficient the PowerPC architecture is at severely redundant calculation and memory access.

 

[tooie]

Let me shove this thread in a different direction...

What about the Power970? When it hits the market, as the Power970, G5, whatever, would it be a viable platform for N64 LLE?

how does it go for fixed point SIMD instruction set ?

things like MMX and MMX2 help dramaticly with rsp optimization.

where SSE is useless cause it is floating point ..

 

[The Khan Artist]

AFAIK AltiVec is supposed to totally kick the butt off of MMX and SSE.

how does it go for fixed point SIMD instruction set ?

things like MMX and MMX2 help dramaticly with rsp optimization.

where SSE is useless cause it is floating point ..