Go Back   Project64 Forums > General Discussion > Open Discussion

Reply
 
Thread Tools Display Modes
  #1111  
Old 14th January 2015, 04:54 AM
RPGMaster's Avatar
RPGMaster RPGMaster is offline
Alpha Tester
Project Supporter
Super Moderator
 
Join Date: Dec 2013
Posts: 2,008
Default

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

Your code is
Code:
	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.
Code:
	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).
Reply With Quote
  #1112  
Old 14th January 2015, 03:14 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,236
Default

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.

Quote:
Originally Posted by RPGMaster View Post
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.

Last edited by HatCat; 14th January 2015 at 03:18 PM.
Reply With Quote
  #1113  
Old 14th January 2015, 03:43 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,236
Default

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?
Reply With Quote
  #1114  
Old 14th January 2015, 07:49 PM
RPGMaster's Avatar
RPGMaster RPGMaster is offline
Alpha Tester
Project Supporter
Super Moderator
 
Join Date: Dec 2013
Posts: 2,008
Default

Quote:
Originally Posted by HatCat View Post
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.
Quote:
Originally Posted by HatCat View Post
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.
Quote:
Originally Posted by HatCat View Post
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++.

Quote:
Originally Posted by HatCat View Post
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.
Reply With Quote
  #1115  
Old 14th January 2015, 08:19 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,236
Default

Quote:
Originally Posted by RPGMaster View Post
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.

Quote:
Originally Posted by RPGMaster View Post
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.
Reply With Quote
  #1116  
Old 14th January 2015, 09:21 PM
RPGMaster's Avatar
RPGMaster RPGMaster is offline
Alpha Tester
Project Supporter
Super Moderator
 
Join Date: Dec 2013
Posts: 2,008
Default

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.

Last edited by RPGMaster; 14th January 2015 at 09:57 PM.
Reply With Quote
  #1117  
Old 14th January 2015, 10:14 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,236
Default

Quote:
Originally Posted by RPGMaster View Post
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.

Quote:
Originally Posted by RPGMaster View Post
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!

Quote:
Originally Posted by RPGMaster View Post
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.
Reply With Quote
  #1118  
Old 14th January 2015, 10:35 PM
RPGMaster's Avatar
RPGMaster RPGMaster is offline
Alpha Tester
Project Supporter
Super Moderator
 
Join Date: Dec 2013
Posts: 2,008
Default

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 .

Last edited by RPGMaster; 14th January 2015 at 10:50 PM.
Reply With Quote
  #1119  
Old 14th January 2015, 11:32 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,236
Default

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.

Quote:
I never considered the advantage in splitting it to conveniently test older versions.
You are going to wish that you did.

Quote:
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.
Reply With Quote
  #1120  
Old 15th January 2015, 12:35 AM
V1del V1del is offline
Project Supporter
Senior Member
 
Join Date: Feb 2012
Posts: 442
Default

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
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 05:09 PM.


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