cycle-accuracy vs feature rich - lets duke it out
- Thread starter gendoikari4
- Start date
ScottJC
At your service, dood!
Give it up, nobody agrees with you and the more you go on the more you sound like a whining child. For all your sarcasm this thread is going absolutely nowhere. Now if you didn't post in the manner that you do I wouldn't have responded this way, this is no debate - this is more like "If I don't get my own way, i'll scream"
Doomulation
?????????????????????????
Dude, you have no idea what you're talking about. I wrote some code in C++ before, and believe me, it was slow. So I rewrote it in assembly, and hey, I got at least a 1000% speedup. So what was the problem? Bottlenecked code! So the point is, you CAN optimize A LOT if you just know HOW. I am NOT talking about hacks here.Ballard said:
They still deserve money for a game well made for OUR sake - that is the reason games are being made. A game is game and a game for pay for and that is it.
byuu_
New member
The page you linked to is regarding SNES emulation.
The SNES is a two-pipeline CPU without cache running at a nomimal "2.68mhz". There are not different variants of the CPUs with different architectures like the x86, there is only two or three minor revisions to fix bugs. With a library of over 3000 games, there are quite a few that just barely work right on real hardware, and some that have glitches even then. To recreate these faithfully, I chose to break the emulation down as low as possible. First, cycle-accuracy isn't enough to get things perfectly right. You also need to support memory read/write hold delays. Second, it's very useful for figuring out timing for more complex things once you have the simpler layers timed perfectly. For example, the cycle-accurate core was mandatory for understanding the SNES CPU's DMA bus synchronization delay. I also needed this to figure out quirks in the NMI and IRQ interrupt triggers by testing perfectly accurate timing tests on the real hardware vs emulation. And these findings make real differences in many games. Sure, I could probably drop the cycle accuracy now that I know how these things work, but why bother? x86 CPUs capable of emulating a 2.68mhz processor in this manner at full speed cost $80 with the motherboard included.
Now, the N64 is a very different beast. Multiple pipelines, (probably) cache, 100(?)mhz, etc -- I don't know much about the N64 so I might be wrong on a couple of these points. But anyway, it's a much, much faster CPU with a lot more complexity. It's less likely that a game is going to require razor sharp accuracy to work on the N64 than for the SNES. Likewise for the SNES to the NES. The same for NES to Atari 2600. The slower the processor, the more lower level emulation matters.
Doomulation said:
I know C++ is slower, and I'm not ordering anybody to do anything, nor am I even implying that PJ64 is lousy. Obviously this piece of hardware is challenging to emulate accurately and get "perfect" results accross the board. I'm glad byuu weighed in. I respect his work in trying to proliferate accuracy in leu of speed and he admitted that the Nintendo 64 is a far more advanced piece of hardware, thusly the methods of coding the emulation might be too cumbersome to mimic the way he did with the SNES. So I will drop the comparison and stop mentioning it.
Maybe there is a good compromise. Most of my PJ games work great... no complaints, but a few of them have noticable graphic glitches and I figure that a more accurate emulation would fix the texture issues (one that comes to mind is the water glitches in Gex), but generally I'm very impressed with the overall product of PJ64.
I'm not whining. This is a thread on cycle-accuracy vs. features.
Perhaps we should eventually aim for both!
Doomulation
?????????????????????????
It is a matter of writing efficient code, as it is. The assembly code was still experimental and actually not complete. If you truly need speed, you can convert some heavy used code into assembly to optimize as much as possible.Ballard said:
And perhaps, you should also concider, that if doing cycle-accurate emulation, with all its complexities, it might introduce more bugs, if not less, and the problem in Gex might not be fixed anyway. Also know that the video plugins has a lot to do as well, and many video plugins causes a lot of these problems. And although I do not know for sure, I believe the water in gex is a video plugin known issue.
Doomulation said:
Yeah. I'm currently trying to compile a PC-Engine (TG-16) emulator that runs at normal speed on modern x86 platforms. Most of the current ones either are glitchy as hell or run so fast they are unplayable on newer computers. That is an example where a C++, cycle-accurate version would be ideal. I mean, most of the PC Engine emus haven't been updated since 99 or 2000. Sad.
byuu_ said:
I agree with you byuu_ 100%. This level of accuracy is need when you are compensating for bugs that work because the real hardware does something you would not expect. As is evedinet is need for some of the snes games.
I believe it is not the speed of the CPU that matters most it is how the games are written. These days I would say 99% of the code is writen in C/C++ with some optimizations in asm. In this case it will not need that level of details. Where as the slower machines would have had people more likely writing a lot more in asm to try to get more speed and do things that a good compiler would never do. There are a lot of in accuracies in n64 and I would be happy to look at those when I go to fixing a specific bug, and as we get better compatibility and move closer to 100% that is when those things need to start being looked at.
this level of accuracy is something far off and most likely never done. Mostly cause it is not likely ever needed. There would be a lot better things to get correct first like how many cycles an op really takes, at the moment we just take a view that all ops take the same amount of time and that is X, and set able by the user.
At the end of the day it is the experience that counts, If there is bugs that make the game not look perfect then there are things to be done there to make it work perfect. There are features to add as well to make the actual overall use ability better, even if you had 100% accuracy but no could use the thing, it would be meaningless
any way those are my thoughts
byuu_
New member
Sorry, I had to cut my previous reply short as I was running late for work.
Anyway, my point is that I believe the SNES is old enough, and simple enough, to emulate as accurately as possible. I believe it's possible to match hardware 1:1 in regards to everything excluding timing crystal fluctuations between the ~21mhz and ~24mhz clocks, and even that can be simulated to an extent. This includes bus conflicts, bus hold delays for memory reads/writes, clock synchronization for DMA, the two-stage pipeline for interrupt triggering (in fact, the pipeline need not even be emulated to match hardware with a little trickery), and syncing the various components (really just S-CPU, S-PPU[1,2], S-SMP and S-SDP) for the smallest possible clock stepping of each component. In fact, almost all of that is already done.
Some of these things really affect games, eg Marko's Magic Football requires hackery or proper support of the two-stage CPU pipeline. Some of it doesn't visibly affect anything at all, such as DMA bus synchronization. There are no bus conflicts on a single-process PC emulator (no parallelism to cause it), so it's irrelevant for emulation. However, it could slightly throw off timing if lots of DMAs were done in a row, so I choose to support it because I can.
x86 assembler could easily result in massive speed increases, as could better optimized c++ code, but I prefer to write my code as a reference rather than a speed hack.
Which of these three are clearer to you?
1) screen[y * screen_width + x] = pixel;
2) screen[(y << 9) + x] = pixel;
3) mov eax,dword [y] : shl eax,9 : add eax,dword [x] : mov [edi+eax],word [pixel]
I'd rather use the first, when the host system is fast enough to handle it. I could care less about catering to people using ten year old computers to run modern software.
And back to N64 emulation. I would definitely prefer a totally accurate N64 emulator if it were possible. I really don't believe even with the most intensive x86 assembler optimizations that you can pull off a low-level cycle-accurate N64 emulator at full framerate on any modern PC. And I mean all of the components. The video renderer drawing dot by dot in real-time, the sound rendering one sample at a time, etc. -- not just the CPU.
For the purposes of preservation, obviously the dead-on accurate approach is preferred, but when it isn't possible on the target hardware, anything (dynarec+HLE) is better than nothing.
And again, the differences are already minimal in SNES emulation, I'd make an educated guess that they are virtually non-existant on the N64. And by the time you get up to the complexity of something like the PS3 and Xbox 360 processors, I'd bet a lot of money that we will never see perfectly accurate CPU emulators for these processors, as it would be a good 20-40 years or more before it were even possible to do with any semblance of performance. And it would require someone of extrodinary intellect to handle emulating these 40+ pipelined processors accurately. I won't say it's impossible, but damn close.
In closing, I disagree that PJ64, or any N64 emulator, should use a cycle-accurate CPU core. It isn't worth the effort for the minimal gain. I'd even bet it wouldn't fix a single game that a perfectly accurate interpretive opcode-based CPU core wouldn't run.
Thanks for taking interest in my cause though, Ballard. I really do think the older consoles (TG16, Genesis, etc) really could use more accurate emulators, and awareness and discussion of the matter is always a good thing.
Anyway, my point is that I believe the SNES is old enough, and simple enough, to emulate as accurately as possible. I believe it's possible to match hardware 1:1 in regards to everything excluding timing crystal fluctuations between the ~21mhz and ~24mhz clocks, and even that can be simulated to an extent. This includes bus conflicts, bus hold delays for memory reads/writes, clock synchronization for DMA, the two-stage pipeline for interrupt triggering (in fact, the pipeline need not even be emulated to match hardware with a little trickery), and syncing the various components (really just S-CPU, S-PPU[1,2], S-SMP and S-SDP) for the smallest possible clock stepping of each component. In fact, almost all of that is already done.
Some of these things really affect games, eg Marko's Magic Football requires hackery or proper support of the two-stage CPU pipeline. Some of it doesn't visibly affect anything at all, such as DMA bus synchronization. There are no bus conflicts on a single-process PC emulator (no parallelism to cause it), so it's irrelevant for emulation. However, it could slightly throw off timing if lots of DMAs were done in a row, so I choose to support it because I can.
x86 assembler could easily result in massive speed increases, as could better optimized c++ code, but I prefer to write my code as a reference rather than a speed hack.
Which of these three are clearer to you?
1) screen[y * screen_width + x] = pixel;
2) screen[(y << 9) + x] = pixel;
3) mov eax,dword [y] : shl eax,9 : add eax,dword [x] : mov [edi+eax],word [pixel]
I'd rather use the first, when the host system is fast enough to handle it. I could care less about catering to people using ten year old computers to run modern software.
And back to N64 emulation. I would definitely prefer a totally accurate N64 emulator if it were possible. I really don't believe even with the most intensive x86 assembler optimizations that you can pull off a low-level cycle-accurate N64 emulator at full framerate on any modern PC. And I mean all of the components. The video renderer drawing dot by dot in real-time, the sound rendering one sample at a time, etc. -- not just the CPU.
For the purposes of preservation, obviously the dead-on accurate approach is preferred, but when it isn't possible on the target hardware, anything (dynarec+HLE) is better than nothing.
And again, the differences are already minimal in SNES emulation, I'd make an educated guess that they are virtually non-existant on the N64. And by the time you get up to the complexity of something like the PS3 and Xbox 360 processors, I'd bet a lot of money that we will never see perfectly accurate CPU emulators for these processors, as it would be a good 20-40 years or more before it were even possible to do with any semblance of performance. And it would require someone of extrodinary intellect to handle emulating these 40+ pipelined processors accurately. I won't say it's impossible, but damn close.
In closing, I disagree that PJ64, or any N64 emulator, should use a cycle-accurate CPU core. It isn't worth the effort for the minimal gain. I'd even bet it wouldn't fix a single game that a perfectly accurate interpretive opcode-based CPU core wouldn't run.
Thanks for taking interest in my cause though, Ballard. I really do think the older consoles (TG16, Genesis, etc) really could use more accurate emulators, and awareness and discussion of the matter is always a good thing.
byuu_
New member
Oh wow, that is bad, heh. ZSNES does that with its SPC700 emulation as a speed hack. Heh, imagine, divides taking the same amount of time to complete as right shifts. Imagine trying to profile code inside of that emulator
But, if it works, it works. It's a good point though that perfect accuracy isn't as important if that doesn't cause horrible failure.
I disagree. Emulation should be about emulating the hardware, and not the games. By just trying to get the commercial games playing, it sends a bad message that emulation is all about playing games for nothing. Of course, I realize my opinion is in the minority so I tend to not bug others about it. Preserving the games is important too, just less so than preserving the hardware to run them. Preserving the games perfectly doesn't preserve the hardware, but preserving the hardware does preserve the games.
Ultimately, choice is good. That's why there's ZSNES and bsnes. Polar opposite approaches, ultimately reaching the same goal.
You make a good point. I believe both are factors. CPU speed is definitely important when we're talking about infinitesimal sync misses.
Think about interleaving a line of binary.
From 3mhz to 4 -> 123 -> 1223
From 3mhz to 16 -> 123 -> 1111122222233333
From 3mhz to 100 -> ... you get the idea
Which is more noticeably different? Now consider the difference a sync miss.
I'd like to chime in here
/nick Ballard
Well, one reason it's important for the SNES is because you can end up with different results when you have such low-clocked processors. Let's say you ask the CPU to poll an APU register. On a real system, it's possible the APU could be in the middle of executing an instruction that changes the value on that APU port. The CPU would then read the new value. Without properly interleaving bus cycles and hold delays ?(eg properly emulating the processor parallelism), you'd end up reading the old value. This causes a miss, and you end up having the CPU run a loop again while waiting to see the new value. You get enough of these misses in timing critical games, and you start seeing tiny glitches. Small crackles in sound (listen to Earthworm Jim 2 in ZSNES and then SNEeSe or bsnes), small glitches in the video, little things like that which most people won't notice or care about.
When your processors are running 30-50x faster, like the N64, these misses become much less important.
/nick byuu
zilmar said:
I'll quote you in a previous post where you said: "There would be a lot better things to get correct first like how many cycles an op really takes, at the moment we just take a view that all ops take the same amount of time and that is X, and set able by the user."
Would figuring that out and being able to properly emulate that in code, in a broad sense be "cycle-accuracy"?
Last edited:
byuu_
New member
Definitely not.
Read this: http://byuu.cinnamonpirate.com/sdp/?page=cpu/cpu_methods
Then look at this diagram: http://byuu.cinnamonpirate.com/sdp/images/cpu_methods.png
byuu_ said:
I agree, but I wouldn't mind the games acting the same way they do on the real hardware and there are those that do not. If the roms are dumped well, it's not the games themselves that hold the problem obviously, it's the hardware emulation that isn't operating the instructions properly. Maybe cycle-accuracy in and of itself isn't the paramount concern, but maybe other methods of streamlining the code so it's both playable and properly exectutes the game instructions. Even though I didn't start the thread, but I believe comments I made in another thread spawned it's existance, I take responsibility for dragging you into this. But your commentary on the issue has at least helped my point that accuracy DOES matter when you said...
"Emulation should be about emulating the hardware, and not the games. By just trying to get the commercial games playing, it sends a bad message that emulation is all about playing games for nothing. Of course, I realize my opinion is in the minority so I tend to not bug others about it. Preserving the games is important too, just less so than preserving the hardware to run them. Preserving the games perfectly doesn't preserve the hardware, but preserving the hardware does preserve the games.
Ultimately, choice is good. That's why there's ZSNES and bsnes. Polar opposite approaches, ultimately reaching the same goal."
If the thing is playable on a reasonably modern PC/Mac, then that is the main concern with the gamers. I never meant to insult anyone calling gamers "freeloaders", but none of us can claim total righteousness when it comes to romfiles. The games are property of someone else and regardless of them being commercially on the market or not, there are laws. This issue is about the hardware and how it functions physically and virtually. If the PJ64 runs the games so close to the original I don't notic the difference then that's ideal. If it's not perfectly cycle-accurate, so be it. If the thing is too slow to play on modern PCs, but perfectly 1:1 matches the hardware, it ONLY serves the purpose of a documentation. If it is to be distributed and have intentions on accomodating the user, then you have to make it WORK just like the original. It's a paradoxial ideal to make something in a virtual state, requireing outlandish system requirements, and claim it to be 1:1, but it won't PLAY like the original on a nominal machine.
So I regress and realize that the best that can be done now, is to address bug concerns as it relates to drivers and code routines, and go with the gamer in mind. But the GOAL is accuracy, no matter how achievable it is now. Somebody will be smart enough to do it, especially when faster and better hardware is available to actually play it with.
And again, most of the TG-16 emus are poor and old and need serious revamping and perhaps byuu's approach would be far more appropriate for that, than PJ64.
You can almost equate it to drumming. I am a drummer, btw. I can record a really fast beat and it sounds fine at speed, but slow it down to half speed or slower and you'll notice little, minute time errors and misplaced beats. Now, play the same beat VERY SLOW AND PRECISE. Speed it up in a editor program (keeping the pitch consistant of course :matrix
to the original tempo. It sounds almost exactly the same to the untrained ear. Kinda the same thing. The N64 is so much faster, that little errors and mistimings here and there won't cause big issues.So away from that analogy, I'll just say that I appreciate the work of the PJ devs and maybe I'll learn something in my quest to make Alien Crush and Bonk's Adventure decently emulated and playable.
ScottJC
At your service, dood!
Pfft, it seems more than likely Byuu IS Ballard. They both have the same post count, they were both registered at the same time (may 2006) and both post after each other within only minutes. He's basically arguing with himself and he expects us to believe this crap.
Its like me posting "Heres some information" then following it five minutes later with "I agree".
Its like me posting "Heres some information" then following it five minutes later with "I agree".