VisualBoyAdvance-M

I have come to notice that "cycle accuracy" is the new HDR/SSAO/whatever. It apparently makes everything perfect. And suddenly makes everything else inadequate. I guess I can relate it to SSAO and HDR, since those things, I can understand.

 

Noticed how everything game graphics wise is judged by shader quality, and so, the amount/quality of SSAO and HDR?

 

Its the same for emulation with "cycle accuracy".

 

It apparently is the best thing since sliced bread, and now anything thats NOT it, (like VBA-M in parts) apparently stinks. It also means now, people hound developers over how they do things (if its NOT "cycle accurate") It happens on this very forum. People complain that stuff is NOT accurate enough OR it should be "cycle accurate". And if nothing happens to make it "cycle accurate", people bitch and moan. And it all started ever since byuu and bsnes marketed that buzzword.

 

Which is what it is: People use that word without either knowing the ramifications of a emulator using that development approach OR, what the hell it even means.

 

So, there should be a ironclad definition of it. This is exactly why I don't say how accurate a product is, it saves the fights and bullshit surrounding it. And frankly, I couldn't care less about being something that could be a mountain of effort for zero gain and that HW preservation BS. Which apparently "cycle accuracy" or more is paramount to.

 

Seriously, most people suck. They blindly put a label on things and ONLY follow stuff that use that label.

 

Fuck, I should say VBA-M is now cycle accurate and see what people say. And then see the people flock to it just because of that buzzword.

 

Lol.

People are stupid >.<.

And THAT is the problem.

 

People blindly use the term like some Messiah, and blindly follow things that apparently fit to "cycle accuracy" based rules. Anything else, they say is not accurate >_>

 

Yes, thats stupidity, right there.

http://forums.ngemu.com/emulation-news-submissions/125871-retrocopy-v0-100b-released.html#post1708746

 

Right now, I feel like bashing that persons face in.

 

They THREATENED any other emulator that does not use cycle accuracy, calling them hacks!

A good deal of what these people say doesn't even apply to a good deal of platforms. They need to understand that not everything runs a CPU derived from z80 or 6502.

 

Also, while the author of this emulator explains the approach taken and insists several times how accurate it is, he doesn't actually describe a scenario where sub-instruction granular interleaving (a real description of what these people mean when they say "cycle accurate") will necessarily generate a different vital emulation state than a instruction granular interleaving. On a single CPU system like Master System w/o any real kind of tight feedback loops between components I don't even know if this is possible. Would be nice if someone would prove that instead of just blindly implementing it this way. I mean, you could implement something at the gate level instead and you could claim how since it's lower level it COULD be more accurate but if you don't come with an example it's pretty moot.

 

By the way, it's also my opinion that it's much easier to do an emulator like this than it is to say, schedule interrupts and what have you. People like this just want praise for nothing. SMS is dead simple to emulate as far as emulators go and he has to be the millionth person to write one. I suppose something is necessary for him to differentiate himself to the people who don't know any better?

 

Unfortunately far fewer people are in emulation for optimization these days, which tends to have much more pragmatic results than improving accuracy where 100% of games worked fine w/o hacks to begin with.

They THREATENED any other emulator that does not use cycle accuracy, calling them hacks!

 

 

Nonono.

 

He said the emulators use little hacks here and there instead of doing some stuff accurately. BIG difference, and it's a normal process done by just about every single emulator in existance. He was not insulting them, just stating what they do.

 

The word hack is even used by the various emu authors too. Read Kega Fusion/ZSNES's history and you'll see that word used more than a few times.

 

he meant no harm by it.

 

FWIW, I think this debate is kind of silly. there's room for all camps, and for that matter there are more than two camps. myself, I don't care about the method used as long as it represents what I can see on the actual console. Emulation is a substitute for me, so I want accurate reproduction of the visuals and audio. I care nothing of how that is obtained.

Exophase:

 

Thanks for your response. It makes me feel better that the dev is using that "cycle accuracy" buzzword for recognition and nothing else [img]<fileStore.core_Emoticons>/emoticons/laugh.png[/img]/emoticons/laugh@2x.png 2x" width="20" height="20" /> It sickens me though that every single emulator author that uses cycle accuracy then has the warrant to badmouth other people who don't use thier approach.

 

Yes, I know VBA's core is a mess, I know it uses DMA hacks, I know of the missing cycle problem. But seriously, I don't think cycle accuracy will fix that. Theres better ways to fix it than simply "Hey letz make it cycle accuratz!!!!1"

 

 

IST

 

He said the emulators use little hacks here and there instead of doing some stuff accurately.

 

...You just opened up a red herring. What do you define a " hack" as? Yes, I am well aware of VBA doing things wrong, but really according to those devs, even some ASM optimizations are classed as hax to them >.>

shrug Depends really. Going through the ZSNES history file, you'll find that back in the day they used a lot of timing hacks because they could not simulate the timing right. So, they created a kludge to get game X working. Nothing wrong with that in the least.

I agree that "hack" is a pretty open term. I don't like using per-game hacks in my emulator. What these consist of are certain pieces of code added to detect certain complex states that the real machine could never detect, usually added because the emulator authors have no idea why something isn't working and kept trying out hackish things until it worked.

 

The reason I don't like these is because it distracts from understanding what the machine is supposed to be doing, which means that you could end up having that bug in other games. You could also very easily end up having that bug in other places in the same game, where your hack no longer catches it. It also makes the code more complex and messier, requires you to have some kind of per-game identification system which is prone to failure with modified versions of that game, and can even make the code slower.

 

It reminds me of some ancient Greek astronomers who were certain that the planets orbited in paths that consisted of circular components. When they observed the planets and found that a simple circular model didn't work they added in all kinds of weird circular fixtures to it to try to compensate, including having the planets move backwards and go in little sub-circular loops at various points. In reality planets move in elliptical orbits, which is a much simpler model. They ended up making things really complicated because they had misconceptions that they were forcing things to work in, but even then things only worked some of the time.

 

Other times, however, it's okay to implement something that's not a faithful representation of the underlying hardware when you do actually know/understand how the hardware works and have a good grasp on why the software would never rely on it, or feel that it's not worth the tradeoff. I think that you have to make careful decisions about this, but you always need to know what's actually going on as much as possible.

Other times, however, it's okay to implement something that's not a faithful representation of the underlying hardware when you do actually know/understand how the hardware works and have a good grasp on why the software would never rely on it, or feel that it's not worth the tradeoff. I think that you have to make careful decisions about this, but you always need to know what's actually going on as much as possible.

 

What concerns me though, is the people that think cycle accuracy is the holy grail and anything and everything must use it.

 

Take that "cycle accurate" SMS emu. The dev just proved itself that it believes cycle accuracy is heaven, any other approach is hell. At least byuu has some common sense when its useless or completely insane to do. Like with those PS2 emus.

Take that "cycle accurate" SMS emu. The dev just proved itself that it believes cycle accuracy is heaven, any other approach is hell. At least byuu has some common sense when its useless or completely insane to do. Like with those PS2 emus.

 

I think you're overreacting. As I said before, he was not insulting the other emulators, and there is room for all approaches.