New LLE RSP Plugin (accurate, fast but untested?)

[RPGMaster]

Idk why I didn't paste the whole thing before, but here's what I mean.

Your code is

	return (FILE *)(HANDLE)CreateFileA(
        filename,
        (mode[0] == 'r') ? GENERIC_READ : GENERIC_WRITE,
        (mode[0] == 'r') ? FILE_SHARE_READ : FILE_SHARE_WRITE,
        NULL,
        CREATE_ALWAYS,
#if 0
        FILE_FLAG_WRITE_THROUGH | FILE_FLAG_OVERLAPPED | FILE_FLAG_NO_BUFFERING,
#else
        FILE_FLAG_WRITE_THROUGH,
#endif
        NULL
    );

Here's mine.

	return (FILE *)(HANDLE)CreateFileA(
	filename,
	(mode[0] == 'r') ? GENERIC_READ : GENERIC_WRITE,
	(mode[0] == 'r') ? FILE_SHARE_READ : FILE_SHARE_WRITE,
	NULL,
	(mode[0] == 'r') ? OPEN_EXISTING : CREATE_ALWAYS,
#if 0
	FILE_FLAG_WRITE_THROUGH | FILE_FLAG_OVERLAPPED | FILE_FLAG_NO_BUFFERING,
#else
	(mode[0] == 'r') ? FILE_ATTRIBUTE_NORMAL : FILE_FLAG_WRITE_THROUGH,
#endif
	NULL
	);

Iirc, the problem seemed to be CREATE_ALWAYS. I honestly didn't look too deeply into FILE_ATTRIBUTE_NORMAL or FILE_FLAG_WRITE_THROUGH, but I don't think write_through should be used when you're just reading data from a file. Up to you though.

According to msdn, the description for FILE_FLAG_WRITE_THROUGH is "Write operations will not go through any intermediate cache, they will go directly to disk."

For FILE_ATTRIBUTE_NORMAL, the description is "The file does not have other attributes set. This attribute is valid only if used alone."

Just to make sure, I quickly tried your version of my_fopen again, and I can verify that the settings never get loaded (always LLE gfx & LLE audio + the other 2 options are disabled).

[HatCat]

I don't understand the change, and that isn't the entire code.

That's just the WIN32 part of the function. It uses fopen on Linux/GNU which will be my primary operating system for testing this plugin. Helped me mend a lot of things actually.

Originally Posted by RPGMaster

Just to make sure, I quickly tried your version of my_fopen again, and I can verify that the settings never get loaded (always LLE gfx & LLE audio + the other 2 options are disabled).

That's not a bug with my_fopen. It always uses LLE gfx & LLE audio simply because I never rewrote the config interface to be CRT-DLL-free, so just removed it atm. Also, HLE has nothing to do with testing what is the RSP's fault, so there's no immediate cause for concern. Rather look into installing the Rsp #1.2 specs used by pj64 2.1 to integrate the RSP settings that way at some point.

[HatCat]

I'm more interested in what you're going to do in the future of that project64 repository on GitHub.

Right now your pull request is time-consuming--both for you and for zilmar. It would save a lot of time for the both of you if you found a way to segment your PRs. Another thing I don't get is, why create a second account on the same day as your pull request? Why not just send it under your original? Do you not want your affiliation with this exact emulator to be known?

[RPGMaster]

Originally Posted by HatCat

I don't understand the change, and that isn't the entire code.

That's just the WIN32 part of the function. It uses fopen on Linux/GNU which will be my primary operating system for testing this plugin. Helped me mend a lot of things actually.

That's not a bug with my_fopen. It always uses LLE gfx & LLE audio simply because I never rewrote the config interface to be CRT-DLL-free, so just removed it atm. Also, HLE has nothing to do with testing what is the RSP's fault, so there's no immediate cause for concern. Rather look into installing the Rsp #1.2 specs used by pj64 2.1 to integrate the RSP settings that way at some point.

There's no point in update_conf (for WIN32) if it doesn't really do anything but set all the values of conf[] to 0. It is unable to read the binary file "rsp_conf.bin", due to using CREATE_ALWAYS instead of OPEN_EXISTING. Just wanted to point that out. If you'd rather just switch to rsp #1.2, then that's fine. I personally prefer being able to use on multiple emulators.

Originally Posted by HatCat

I'm more interested in what you're going to do in the future of that project64 repository on GitHub.

Depends on what he wants & accepts. Idk what I can do outside of changes to RSP. I haven't gotten around to learning enough about the RDP or emulator core ;/ . Sadly I've been trying to move onto something else, but I'm pretty much stuck with working on the RSP, since I can't really successfully do anything else on my own (emulator core, audio, or gfx). I'm more interested in 64bit development now, but dunno if I'd want to use m64p. So not really sure what to do.

Originally Posted by HatCat

Right now your pull request is time-consuming--both for you and for zilmar. It would save a lot of time for the both of you if you found a way to segment your PRs.

Idk how to use github all that well. Didn't know that any commits you do after a pull request, automatically get included too. The first 2 commits weren't bad imo, aside from the typo that I have no clue how it got there. Then there's the issue with MSVC screwing up the format, so now I'll just edit with notepad++.

Originally Posted by HatCat

Another thing I don't get is, why create a second account on the same day as your pull request? Why not just send it under your original? Do you not want your affiliation with this exact emulator to be known?

Just me being silly . At this point, I'm mostly just concerned with other devs. I figured some devs would automatically recognize who I am anyway.

[HatCat]

Originally Posted by RPGMaster

Idk how to use github all that well. Didn't know that any commits you do after a pull request, automatically get included too. The first 2 commits weren't bad imo, aside from the typo that I have no clue how it got there.

Your "first 2 commits" were too big and change too many things simultaneously.

Your first commit:
https://github.com/LegendOfDragoon/p...a12f2ecc6769d8

Changed WAY too many files, WAY too much code in every file.
Just that one single commit, never mind the other three, should have covered at least one pull request on its own. How can you expect zilmar to test ALL of those changes easily for enough games to convince himself that nothing broke?

It should not be "Optimized a few instructions". It should be "optimized VXOR in this way", "optimized VAND in that way", "did this to improve VNOR"...more descriptive, less vague, more organized and more commits. That commit should have been divided into many sub-commits, changing as little code as possible per each one, and finally made into at least one stable pull request. You have to put yourself in zilmar's position: If someone sent you a pull request to your own emulator project, changing/adding/deleting thousands of lines of code into one single PR, how can you just take their word for it? You need to practice organization, if you want to live a healthy open-source life without regrets.

Your second commit:
https://github.com/LegendOfDragoon/p...56afea2c825e52

Better than the first one. It's an improvement in feeling easy about the stability of the changes, but it's still bad for essentially the same reasons.

I very much suggest revising/restarting that PR in a more organized fashion. It doesn't have to be through your actual AIO account I guess, but it needs to be organized if you're trying to help people.

Originally Posted by RPGMaster

It is unable to read the binary file "rsp_conf.bin", due to using CREATE_ALWAYS instead of OPEN_EXISTING.

Never had any problems with it. If you're observing it's not working, it's because of what I just said: I removed the config system entirely. I don't care...use fopen then, not my/your CreateFile, same issue.

Not worried about config, it can be implemented later. pj-specific Rsp #1.2 specs is just one of the methods.

[RPGMaster]

I meant first 2 as in chronological order .

https://github.com/LegendOfDragoon/p...b024bcc7ea9c7c

https://github.com/LegendOfDragoon/p...4770ff8acea425

I know the 3rd and 4th were sloppy and that the titles & descriptions weren't perfect. I didn't even mean to pull request all commits ;/ . All changes I've pushed so far (excluding optimizations), is simply matching recompiler to interpreter. Anyone familiar enough with the RSP could easily eyeball it and see why my changes to SW, LW, LH, and SDV are valid (I basically fixed human errors). Same with VMOV and VMRG. Even the accumulator analysis, he could just look at his interpreter to see what accumulator(s) each instruction writes to. Most of my changes shouldn't take more than a few minutes each to confirm. I understand the optimize commit one will take a bit of time to validate. I know that SQV will also take a bit, since he has to confirm that the shuffling I did is correct. And to think I actually toned it down more than I originally planned .

I haven't even attempted to introduce changes to his interpreter algorithms.

The reason I did VNXOR, VNAND, and VNOR at the same time was simply because I felt that they were similar enough to compare with VXOR, VAND, and VOR, the main thing he has to do is confirm the changes I made to mmx.c and x86.c. I won't repeat the same mistakes.

Is there a way for me to choose which commits to submit in a pull request? Otherwise, I'll generally just wait until it gets accepted, before pushing new commits. I don't plan on doing too many drastic changes in the near future.

About the config. I was just saying that using OPEN_EXISTING, makes file i/o work for me, while "CREATE_ALWAYS" doesn't work. I just felt that it's a simple change, so might as well.

[HatCat]

Originally Posted by RPGMaster

I meant first 2 as in chronological order .

https://github.com/LegendOfDragoon/p...b024bcc7ea9c7c

https://github.com/LegendOfDragoon/p...4770ff8acea425

I had the inverse ordering in my memory. You were right.

GitHub history starts bottom-top; PR commits kinda go the other way. I never remember that stuff.

Originally Posted by RPGMaster

I know the 3rd and 4th were sloppy and that the titles & descriptions weren't perfect. I didn't even mean to pull request all commits ;/ .

This is your perfect opportunity to start over from scratch (not toss your notes/saved source on optimizations of course). A lot of open-source with making shit done perfectly is changing things again and again and again endlessly until it's perfect (key word being endlessly); you should re-do your pull request and wait patiently for zilmar to accept a very small progress. Spend your time being thorough, not eccentric and change-happy.

But the 1st and 2nd weren't too bad yeah ... not saying they were perfect, but way, WAY smaller commits (so easier to finish reading at the very least if nothing else). Still, you can never divide into too many steps!

Originally Posted by RPGMaster

The reason I did VNXOR, VNAND, and VNOR at the same time was simply because I felt that they were similar enough to compare with VXOR, VAND, and VOR, the main thing he has to do is confirm the changes I made to mmx.c and x86.c. I won't repeat the same mistakes.

You can never divide into too many steps.

Look, let's assume your VNXOR, VNOR changes are all as stable, non-breaking changes as changing "Hello world" to "Hello, world!\n"--an obviously non-breaking commit that changes nothing but English text strings. Still, the more you divide your commits, the more power you give both yourself and the repository owner--to debug issues or memory usage changes or whatever you would say pull X commit number/date/time from the Internet to my disk and compile it. You CANNOT do this is you changed VNXOR, VNAND, VNOR all at once in a single commit...you can't debug memory usage changes/issues/speed compare/etc. with them individually using Git if you don't have all 3 of those opcode changes organized to their own commit. So get organized!

That's about the gist of my bitching. I hope I'm done confusing everyone in this thread who was looking for RSP update information.

[RPGMaster]

So I take it, there's no way to select which commits to submit to pull request?

Is there a way to remove commits from history? Otherwise it'll just become a bigger mess to undo and redo commits, especially if I can't select which commits to submit to a pull request.

I never considered the advantage in splitting it to conveniently test older versions. I just grouped stuff together since I already thoroughly checked .

[HatCat]

I dunno; ask zilmar. I didn't create the thread about pull requests; he did. So you should reply to his thread if you'd like to participate.

If he has any willingness to accept a pull request from you, he'll be willing to answer your questions about how to use Git. Personally I don't know jack shit past `git clone`, `git commit -m`, some others + how to use a GUI and the website and that's it.

All I know is ecsv from Mupen64Plus modified his pull request to my RSP repository, before I agreed to accept it. So if he did it...I'm sure there is a way; I just don't know what it is. I only go off the elemental commands / re-clone and start over with a new PR if I have to.

I never considered the advantage in splitting it to conveniently test older versions.

You are going to wish that you did.

I just grouped stuff together since I already thoroughly checked

Not good enough. Making other people thoroughly check just like you did is unnecessary--simplify your commits.

[V1del]

You can branch out your changes, for every change that belongs to a specific subgroup you create a new branch. Pull requests follow the branches so this helps to keep things tidy. Now you are just committing everything to master and so the pull request piles up the commit because it thinks it's something related. You can make a branch "improve-VNOR" and a branch "improve-VXOR", ... and submit pull requests for each seperate branch. Once a branch gets merged you can sync that back into your master, all without affecting other WIP branches. If the changes you do are not conflicting with each other you can always merge even from a relatively old branch. And you can then also easily resync with master once a PR has been accepted and can delete your own branch.

As for readjusting an existing PR, I'd suppose you'd have to rollback the history and make smaller commits manually, but I don't really know either