Pixel-Accurate N64 Software Video Plugin

[HatCat]

That looks like a neat trick there with the switch expression shifting; I would probably have done the same thing as what you did to enforce a static-indexed jump table in the optimized code generation.

You know I used to always do shift-masks like this:
rs = (inst >> 21) & 31;
rt = (inst >> 16) & 31;
rd = (inst >> 11) & 31;

...but now I more commonly do it this way:
rs = (inst & 0x03E00000) >> 21;
rt = (inst & 0x001F0000) >> 16;
rd = (inst & 0x0000FFFF) >> 11;

...since doing the AND-mask first, before the shift, in special cases promotes the possibility of a memory-indexed move, on the right boundary such that no and instruction is generated. Example: Hopefully rd = (inst & 0x0000F800) >> 11 compiles to the same thing as rd = (inst & 0x0000FFFF) >> 11 does, where no AND instruction is actually generated. This optimization works on VS2013 but not VS2010.

Though, the code you excerpted looks more like a debugging feature in Project64...wouldn't it make more sense to optimize the emulation thread stuff for performance? I can understand optimizing the debugging/features code for smallness in size though; the rest of your program doesn't suffer when you make performance-irrelevant code smaller.

[RPGMaster]

Well ya, my main priority was to reduce code bloat first and read through everything. Also, the code I posted was part of the recompiler's code. I'm pretty sure it's functions like MoveConstToX86reg that write the converted machine code. The name of the function that contained the example I posted is called void Compile_LB . After I'm done reducing the total size, I'm going to profile again to see where the performance bottlenecks are.

You brought up a good point though. I actually came to that conclusion yesterday that I should focus more on the performance intensive part. My main issue was, idk what parts need the most optimizing. I only recently learned I could use the built in profiler to see what's hogging the cpu. Most of the cpu goes to graphics which i unfortunately can't do anything about as long as I'm using closed source plugins like Jabo's. Idk if I'd want to use Glide even though it is more accurate than Jabo's. I still may look into it anyway. One reason why I wanted to try these micro optimizations on the recompiler is that I thought maybe during parts of a game that heavily use the recompiler, it would make a difference.

So for now I'll keep reading code and seeing what other changes I can make. I'm also looking into adding features, like on the fly settings changes. I already added the rsp plugin selection . All Zilmar did was write a macro that disables that option if MSVC was set to RELEASE_EXTERNAL, so I commented that out.

[HatCat]

lolwut

So if it's an "external" release, to the public? Then don't let anybody else change the RSP plugin. If it's internal, in the development zone, then allow changing it.

As far as graphics goes, you know this plugin is actually not so slow when you're in some elementary parts of some games. In fact it's almost as fast as the Basic CFB plugin zilmar wrote. I was able to make a plain GDI, non-hardware-accelerated version of zilmar's graphics plugin that was still like a whole 200 VI/s faster than his for ROMs like Absolute Crap 2, but I couldn't pull the same thing off with this plugin of angrylion's since it emulates extra line-synching properties of the video interface that zilmar's CFB plugin doesn't. I don't have a chance at making it as fast as his DLL while I'm emulating those, but it's still like 300-400 VI/s when the RDP isn't being executed anyway so who cares, good enough.

Even if you enable my frame skip option, only update the screen every 20 frame buffers, in RDP-heavy games you'll notice like 0 to 0.1 VI/s speed-up. That's how totally INSIGNIFICANT optimization of the VI filtering is, to the grand scale of performance of this plugin. It's all about those texturing and triangle RDP commands.

[RPGMaster]

Lol I didn't get why he removed the rsp plugin selection thing either.

Since I'm mostly concerned with performance, I should start working on improving an open source graphics plugin. My issue with rice was that not only is it inaccurate, but I can't even compile it! I'll still try and see if I can improve the emulator core. I want to learn more about interpreters and recompilers.

I'm seriously considering checking out Glide's source. I hope it isn't too complex for me. I'm really impressed at the amount of quality code you've been writing in a short amount of time. It takes me forever to fix things... What ends up happening is I improve 1 thing, but break something else lol..

[HatCat]

I guess HLE makes it somewhat easier to contribute to the performance/directness of a C-level algorithm for a system of which, you're not an expert. You probably don't want to put most of your time into this open-source graphics plugin I am maintaining in this thread, because it's LLE and involves an understanding of the hardware system. With HLE, it's possible to know nothing about N64 graphics, but improve the high-level algorithms.

It's pretty hard to optimize LLE for performance...well in a way it can be easier than HLE, but I mean, it's just distracting to know that you have such systematic limitations, the standard concepts of a computer system...like the fetch-decode-execute cycle modeled best by an interpreter.

I'm not a gamer though, nor do I particularly enjoy video games. I like computer science, so I like LLE. I understand it more than I understand HLE graphics plugins. When you look at Glide64 source, tell me if you think you can follow along with it. To me, it's just more C++.

Sure was pretty easy and smooth to tweak some small HLE code in Hacktarux's RSP build for Mupen64 though.

Originally Posted by RPGMaster

It takes me forever to fix things... What ends up happening is I improve 1 thing, but break something else lol..

No that happens to me too. You're not the only one with that problem.

Sometimes I fix 1 thing and break another.
That hasn't happened yet with any commits of this particular plugin project I'm hosting here, but it's been a tendency of the past. I wouldn't at all be surprised if I keep doing it sometime in the future. Keeping ourselves organized and structured with micro-step commits can be a drag on our patience sometimes.

Sometimes it's just a matter of what type of project you're used to working on...I think there are 2 major kinds: home-brew stuff you created on your own, and other peoples' code you have yet to learn and master the entire system in your repertoire.

As for how quickly it takes me to fix regressions, maybe cause I use a VCS and you don't? I'm usually pretty lazy. The idea of copy/pasting old Git trees' files and compiling them, and having to isolate which part of the commit (if it was huge as shit) introduced the bug, just makes me wanna watch some annoying filler episode of Naruto or something and blow the whole day away. I'm a slacker.

[RPGMaster]

Aww man . Didn't know Glide was C++ ._. What I like to do is read through code and try to spot things that I could easily improve (no matter how insignificant it is). When I looked at angrylion's code, I could not find much I could change, other than the ternary operation stuff. Pretty much the only thing I did with your gfx source was use winapi for file i/o instead of stdio. So if I were to make a gui for your plugin, how many options would I need to implement?

I don't play games much either, but I sometimes I enjoy taking a break form programming and tv shows / anime and get hooked for a few days. These past few days I've been no lifing programming, emulator testing, and casual gameplay.

For regression, I should look into using Git and keeping even more exe files.

Now I'm currently interested in gfx plugin programming, emulator core, and rsp. For rsp, I'd like to see if I can improve the recompiler.

[HatCat]

Don't use Git repositories to store EXE files though. I think there might be a Git downloads feature or something, but really you should probably just release stable EXE's to the community or something. That way you not only have the option of testing between different EXE's to find where you introduced a bug, but telling one of your thousands of testers to gtfo make you a sammich and find the breaking exe version for you.

Originally Posted by RPGMaster

Aww man . Didn't know Glide was C++ ._.

I ban "C++" as a badword on my IRC channel.
Anyone who says it gets auto-kicked by bots (and banned if mentioned enough times).

While I'm on the subject, one of the other badwords I banned is:
richardstallmaneatssomethingfromhisfoot.avi


Then again if Bjarne Stoustrupe had named it ++C, instead of C++, then I probably wouldn't have banned it. Who cares, though; it's still overflow. And vector should not be a built-in type in C++; it should be a type that I can define myself in C.

Originally Posted by RPGMaster

So if I were to make a gui for your plugin, how many options would I need to implement?

Idk. I guess I was thinking about someday having a future-extensible GUI, for when new options get added...maybe a pseudo-AVI recorder that dumps BMP screenshots for every frame drawn to the screen, some of those RDP dither/render mode pattern controls that FireWSP talked about, a microcode selector option in the future if I decide to play with microcode HLE (-1 for LLE, 0 for RSP SW Mario64, 1 for F3DEX, some other checkbox for try to auto-detect? idk), just, things that people would want to configure about graphics plugin in general.

Probably a separate tab for OpenGL transformations, texture replacement (not hi-res texture loading exactly)? Features are very very easy to implement in this plugin compared to making it run at full speed.

[RPGMaster]

Lol I haven't looked at Glide's source yet, but after giving it some thought, I'm hyped! Even if it's in C++, perhaps I can convert it to C, like you did with angrylion's plugin. I hope I can actually compile it or I'm going to rage.

That pseudo AVI recorder sounds like a neat idea though. You can count on me for implementing at least some of these features! Now I'm extra motivated to learn winapi, D3d, and opengl.

[oddMLan]

What's wrong with C++?
The Dolphin emulator uses it as main programming language.

[RPGMaster]

Well, it looks like I won't start editing glide yet. For one, i haven't fixed the plugin spec issue. Also Idk which version of Glide is the best, and does Glide still use a wrapper? For now I want to focus on improving the emulator core if possible and adding neat features.

Originally Posted by oddMLan

What's wrong with C++?
The Dolphin emulator uses it as main programming language.

I don't like the style and the fact that it adds code bloat. I much rather prefer procedural programming over object oriented. I'm not surprised Dolphin is made in C++. That explains why I don't like it . Lol more like it still has a lot of work that needs to be done.