Go Back   Project64 Forums > General Discussion > Open Discussion

Reply
 
Thread Tools Display Modes
  #1  
Old 20th May 2011, 07:00 PM
ExtremeDude2's Avatar
ExtremeDude2 ExtremeDude2 is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Apr 2010
Location: USA
Posts: 2,997
Default Software Render vs. LLE. vs. Cycle Accuracy

Anyone care to explain the difference between these to me?
__________________
Quote:
Originally Posted by dsx! View Post
are you american or something
Reply With Quote
  #2  
Old 20th May 2011, 07:45 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,256
Default

"Software" is also a short term used to refer to a rendering device for graphics (like DirectX, OpenGL, GLIDE). Jabo's Direct3D8 1.7 includes an option to use software or RGB reference rasterization, Rice's Video Plugin switches to use "reference rasterization" if the video technology is not good enough for Direct3D/OpenGL, and Glide64 just has an option to use point-sampled texture filtering (which is what software RGB uses) instead of ever using bi-linear filtering (the smooth textures you see with 99% of graphics emulation settings for the graphics plugins in N64 emulators).

Software rendering seems to always be the slowest rendering engine more than among DirectX, OpenGL, and GLIDE. Again, it uses point-sampled texture filtering (which you can force using Glide64), which looks like this:


Where you can see a "pixilated" appearance to all the 3-D texture mapping.

It's more sharp than the blurred, overly smooth 3-D texturing many N64 graphics plugins display in games, but it's also a lot more sharp and "pixilated" than the actual filtering results on the N64 machine.
Reply With Quote
  #3  
Old 20th May 2011, 08:03 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,256
Default LLE. vs. Cycle Accuracy

The other two I don't have to think so much about to explain the difference between them.

Cycle accuracy refers to the timing accuracy of the memory instruction cycles. Different machine instructions on processing hardware use a different number of cycles (I'm guessing it's that Fetch-Decode-Execute "FDE" cycle I learned about in my Java programming class when I was 16, or maybe "cycle" refers to something more fundamental of a unit.) before they have been completed.

Because you are emulating instructions on hardware the execution is not actually happening on, timing of the instructions becomes difficult since emulating the instructions is not as fast as directly executing them on hardware that supports them (MIPS instructions on the N64 hardware being re-compiled/write-translated or interpreted/read-translated as x86 instructions on the common PC).

---

LLE means "low-level emulation", as opposed to HLE (or "high-level emulation").

I'm not 100% sure, but I'm sure the interpreter method in emulation is a low-level method for emulation, while the re-compiler style of emulation is high-level.

The graphics (as well as the audio "ucodes" used in various games, 'u' being a half-assed symbol used to half-assedly reference the symbol for the "micro" unit) microcode data is mostly HLE'd by graphics plugins today. The standard gfx microcode objects to be used in games were organized in Nintendo official developer kit material, so there is documentation about emulating those specific devices in plugins. LLE graphics emulation, is where you don't focus on the entirety of those object entities--so much as the exact microcode data in the game and specifically emulating those individual pieces (which is nowhere near as fast for speed in emulation as generalizing the emulation based on known or presumed object data).

And it applies to more than just emulation and programming (high-level language programming, shit like C/Java or "The quick brown rainbow jumped over the lazy-ass dog." compiling to machine instructions," and low-level language programming, directly or slightly indirectly coding the machine instructions explicitly yourself). The terms "high-level" and "low-level" are simple concepts to understand. The more you generalize while analyzing how to play something like a game, doesn't have to be a card game or chess or whatever, the faster you play the game by generalizing using "high-level" thinking.
Reply With Quote
  #4  
Old 20th May 2011, 08:03 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,256
Default

Too bad I couldn't shorten any of that without ignoring the thread. Oh well.
Reply With Quote
  #5  
Old 20th May 2011, 08:09 PM
Jabo's Avatar
Jabo Jabo is offline
Core Team
Alpha Tester
Project Supporter
Project64 Team
 
Join Date: Aug 2005
Posts: 183
Default

We'll probably never get to cycle accuracy across the board, the display processor is too complicated to do things like cycle accurate rendering... I can't imagine doing a pixel/scanline renderer... not to mention trying to estimate simultaneous execution of the 3 chips. There is so many things to be worked out to get to that point where that is possible.

I'm working on a new software renderer which hopefully will look better and perform better... so far it does but there is more work to do... anyway hopefully that will see light this summer, in terms of getting accurate emulation that's probably our best bet. I'll see if i can post some screenshots when I start working on it again.
__________________
Project64 Developer
HP Laptop, Intel P7540 with GMA4500, Windows 7

Last edited by Jabo; 20th May 2011 at 08:11 PM.
Reply With Quote
  #6  
Old 20th May 2011, 08:46 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,256
Default

Current rendering in software looks sexy. Curious how the modifications come out.

I'm not sure how to observe cyclical accuracy anyway. What would be the output difference if there was a systematic design of cyclical accuracy across the RDP while playing a game. I just haven't thought about it that much, and I guess it would be easier and more fun of a task after eliminating the needing to touch other things. Working on something that formal most likely raises an immense question of the purpose of an emulator XD.
Reply With Quote
  #7  
Old 20th May 2011, 11:09 PM
squall_leonhart's Avatar
squall_leonhart squall_leonhart is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Mar 2007
Location: Sydney, Australia
Posts: 2,916
Default

Quote:
Originally Posted by Iconoclast View Post
The other two I don't have to think so much about to explain the difference between them.

Cycle accuracy refers to the timing accuracy of the memory instruction cycles. Different machine instructions on processing hardware use a different number of cycles (I'm guessing it's that Fetch-Decode-Execute "FDE" cycle I learned about in my Java programming class when I was 16, or maybe "cycle" refers to something more fundamental of a unit.) before they have been completed.

Because you are emulating instructions on hardware the execution is not actually happening on, timing of the instructions becomes difficult since emulating the instructions is not as fast as directly executing them on hardware that supports them (MIPS instructions on the N64 hardware being re-compiled/write-translated or interpreted/read-translated as x86 instructions on the common PC).

---

LLE means "low-level emulation", as opposed to HLE (or "high-level emulation").

I'm not 100% sure, but I'm sure the interpreter method in emulation is a low-level method for emulation, while the re-compiler style of emulation is high-level.

The graphics (as well as the audio "ucodes" used in various games, 'u' being a half-assed symbol used to half-assedly reference the symbol for the "micro" unit) microcode data is mostly HLE'd by graphics plugins today. The standard gfx microcode objects to be used in games were organized in Nintendo official developer kit material, so there is documentation about emulating those specific devices in plugins. LLE graphics emulation, is where you don't focus on the entirety of those object entities--so much as the exact microcode data in the game and specifically emulating those individual pieces (which is nowhere near as fast for speed in emulation as generalizing the emulation based on known or presumed object data).

And it applies to more than just emulation and programming (high-level language programming, shit like C/Java or "The quick brown rainbow jumped over the lazy-ass dog." compiling to machine instructions," and low-level language programming, directly or slightly indirectly coding the machine instructions explicitly yourself). The terms "high-level" and "low-level" are simple concepts to understand. The more you generalize while analyzing how to play something like a game, doesn't have to be a card game or chess or whatever, the faster you play the game by generalizing using "high-level" thinking.
you can have low level recompilers.

the simplest description is LLE emulates the hardware including flaws, whilst HLE emulates the game using hacks.

Cycle accuracy is additional to LLE, and some games might require it.
__________________

CPU:Intel Xeon x5690 @ 4.2Ghz, Mainboard:Asus Rampage III Extreme, Memory:48GB Corsair Vengeance LP 1600
Video:EVGA Geforce GTX 1080 Founders Edition, NVidia Geforce GTX 1060 Founders Edition
Monitor:ROG PG279Q, BenQ BL2211, Sound:Creative XFI Titanium Fatal1ty Pro
SDD:Crucial MX300 275, Crucial MX300 525, Crucial MX300 1000
HDD:500GB Spinpoint F3, 1TB WD Black, 2TB WD Red, 1TB WD Black
Case:NZXT Phantom 820, PSU:Seasonic X-850, OS:Windows 7 SP1
Reply With Quote
  #8  
Old 21st May 2011, 12:16 AM
ExtremeDude2's Avatar
ExtremeDude2 ExtremeDude2 is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Apr 2010
Location: USA
Posts: 2,997
Default

Quote:
Originally Posted by Jabo View Post
We'll probably never get to cycle accuracy across the board, the display processor is too complicated to do things like cycle accurate rendering... I can't imagine doing a pixel/scanline renderer... not to mention trying to estimate simultaneous execution of the 3 chips. There is so many things to be worked out to get to that point where that is possible.

I'm working on a new software renderer which hopefully will look better and perform better... so far it does but there is more work to do... anyway hopefully that will see light this summer, in terms of getting accurate emulation that's probably our best bet. I'll see if i can post some screenshots when I start working on it again.
Hacktarux is trying:
http://www.emutalk.net/threads/52511...ad-of-accuracy
__________________
Quote:
Originally Posted by dsx! View Post
are you american or something
Reply With Quote
  #9  
Old 21st May 2011, 12:19 AM
ExtremeDude2's Avatar
ExtremeDude2 ExtremeDude2 is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Apr 2010
Location: USA
Posts: 2,997
Default

Thanks for the info Iconoclast when I asked on the Dolphin forums I got...well criticized.
__________________
Quote:
Originally Posted by dsx! View Post
are you american or something
Reply With Quote
  #10  
Old 21st May 2011, 12:39 AM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,256
Default

Quote:
Originally Posted by squall_leonhart View Post
you can have low level recompilers.

the simplest description is LLE emulates the hardware including flaws, whilst HLE emulates the game using hacks.

Cycle accuracy is additional to LLE, and some games might require it.
Oh that makes sense; I'm sure it's possible. One thing I'm not at all familiar with is the difference between static re-compilation (which the emulator Corn used) and dynamic re-compilation (which is much more common)...not sure if that might have something to do with the point at hand here.

That's basically true though. LLE is emulation on the lowest level, down to even flaws in the original design of the system. HLE doesn't go much below the surface and might introduce some features covering those flaws, which is inaccurate or sometimes even done through hacks.

So yeah, that explanation makes sense as well. I was more geared at defining the concepts of high and low levels (whether with respect to emulation, programming, rhetorical analysis, whatever) than the direct result of HLE and LLE specifically, but I'd say the amount of time it takes to understand that explanation is much less than the amount of time it takes to read the amount of text I put into mine.

The last part I didn't know about at all...again the question of cyclical accuracy I don't know anything about how or why it's observed. That makes sense though...I am sure that the timing is a much more critical factor for certain games. I've read about it so much, yet it's a concept I know relatively less of.

Quote:
Originally Posted by ryancollins View Post
Yeah, he's definitely one of the people making the fun live on. I am rather jealous that I have not proceeded quickly into time enough to be able to participate in something like this.

The mupen group really seems to be its own isle. AFAIK it's the only multi-OS N64 emulator, it's lived on through the development of mostly just le h4x (with contributions by many others, though pj64, 1964, nemu, etc. all had more than one person primarily working on them), somehow a bunch of other things that have led it to stand out.

Quote:
Originally Posted by ryancollins View Post
Thanks for the info Iconoclast when I asked on the Dolphin forums I got...well criticized.
I've seen way more naive questions than that.

I mean, sure, the three things are totally different units of areas to think about, but what would be everyone's definition of "difference"? I presumed maybe you'd have the patience to read through an explanation of the three of them. Teaching is the process of learning after all.
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT. The time now is 11:55 AM.


Powered by vBulletin® Version 3.7.3
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.