Go Back   Project64 Forums > General Discussion > Open Discussion

Reply
 
Thread Tools Display Modes
  #631  
Old 18th December 2013, 01:02 AM
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 was using
Code:
#ifdef _MSC_VER
instead of WIN32 in pr4, but that is all in the past.

Nowadays, in the current pr6, I didn't really bother weighing the pros and cons of a conversion to ifdef WIN32, because I decided I would just use the multi-OS `system` call for echoing RSP messages. (This also helped to eliminate USER32 dll dependency.)

Maybe this isn't as accurate a choice as adding in per-OS code like using Win32 MessageBox for tracing messages for Windows only, but I was really concentrated more on just the simplicity and purity of the ANSI C for focusing on the RSP core. I am not an APIs/GUIs expert (let alone a Win32 functions expert) and actually hate, with a passion, working with projects that consist of lots of API bloat. I am a logical/mathematical thinker. I like simplicity.

Indeed, call me allergic or whatever, but I think it's reasonable. RSP error messages are arranged in a way that I make sure you WON'T see them, so whether it's an ancient ANSI console shell or a Windows GUI showing the error message, I see no special difference it makes, if my plugin is void of reachable errors.
Reply With Quote
  #632  
Old 18th December 2013, 01:13 AM
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

Now, I probably don't need to specify this for most people on a Microsoft Windows emulator forum such as this, but the Linux fork of this plugin for Mupen64Plus maintained faithfully by ecsv has gotten its share of major updates after I did the pr5 release.

It should be a huge percentage faster (We're talking in the 20-40% range.) than the previous builds where SSE2 was not fully generated.

The new configuration structure was also successfully synced by the Linux fork, with maybe some slight difference.
It was based on the raw text specs by Garteal in the CFG file here, except the ideal solution was for them to use the pre-existing Mupen64 core resources to handle the config UI on Linux.
Reply With Quote
  #633  
Old 18th December 2013, 01:22 AM
Bastard's Avatar
Bastard Bastard is offline
Junior Member
 
Join Date: Dec 2013
Posts: 4
Thumbs up

That's OK, I did it just to satisfy my personal taste and nothing else.
The message delivering stuff it's not important at all, anyway. My comments weren't for criticizing your approach, just for clarifying that little 'RSP error' misinterpretation. Keep up the good work!
Reply With Quote
  #634  
Old 18th December 2013, 01:32 AM
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

Thank you. Although in all honesty I'm not sure what work there is left to be done.

Call me crazy, but, I think I've pretty much perfected the interpreter CPU. (Though I would say the dynamic SSE MinGW code gen should improve with future GCC releases.) I started working on this emulator probably Feb/Mar 2012, and almost every day of my life ever since I've been coming up with new ways to accelerate the speed of the emulator as a whole, despite all the 15-25 tedious times I've totally rewritten every single file from scratch.

If you couldn't tell, I probably just have way too much time on my hands. I need to get a "real" occupation I guess, but I'm glad I was at least able to sacrifice it for the result achieved anyway.

I honestly think it's as fast as it can get. (I never said I KNOW that! I'm welcome to criticization.)
Reply With Quote
  #635  
Old 15th February 2014, 03:04 AM
kode54's Avatar
kode54 kode54 is offline
Project Supporter
Junior Member
 
Join Date: Mar 2013
Posts: 14
Default Ooga booga!

Thanks for this project, and thanks to the lord of mud for pointing it out to me, since I've been kind of out of touch with the whole N64 emulation scene.

I've stripped out all the recompilers from LazyUSF, JoshW's fork of 64th Note, which is a N64 USF sound file player based on Project64 1.4 source code. Then I replaced the RSP CPU with yours, and it works perfectly.

My next task is to isolate all the state structures and variables, including your vector general purpose and accumulator registers, and the status register pointers, into a single state structure, so it may be included in other programs as a static or dynamic library. Just a bunch of variable reorganization, adding the state parameter to 50 million functions, adding the state reference -> to all the variables contained within, and adding init/load/play/shutdown functions.

Load is fairly easy, just break out the part of the existing load function, so it accepts a pointer to a reserved chunk from a single MINIUSF/USFLIB/USF file, and the caller passes them all in in the correct order.

Play is slightly more challenging, as it requires modifying the audio DMA callback function to accumulate samples into the caller's buffer, as well as an extra buffer to catch sample data beyond what the caller requested and save it for the next call. At least I assume the emulation loop can safely be exited and re-entered to request more samples.

Your marvelous work makes this whole idea a lot easier for me. I can finally toss out the original piece of junk I was using, which had the potential to crash on random files, and relied on exception handling hacks to rewrite and settle crash bugs in the recompiler output.

Now I need to debate whether it would even be worth lifting MarathonMan's VR4300 for the main processor side of the playback. It would be bothersome to adapt the save states to it, since the genius behind USF, hcs64, decided that USF files should forego lengthy setup code and instead bootstrap using Project64 save states, and it just wasn't a concern that anyone would ever need to process the files with any other emulator.
Reply With Quote
  #636  
Old 16th February 2014, 12:41 AM
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

There is always indeed that concern that the emulation of the RSP has accuracy limited partly by what's done on the host's side. If you use Project64's model, it's doomed to be inaccurate at some point or another, unfortunately. However, the lack of cycle-accuracy in Project64, as far as I could see, has only ever affected graphics tasks in LLE for a few games. The incorrect handling of SP_SEMAPHORE_REG in prior builds of Project64 does affect audio tasks on the RSP more than anything else, but not in any way that I could distinguish externally.

All of that, coupled with the general unreliability of RSP recompilation. If zilmar would have engineered the interpreter better in a more readable and less hazard-prone way, there would have been no need to use--let alone make--a recompiler for the RSP, either in Project64 or in 64th Note. Because of the narrowed gap between speed for both methods with my interpreter plugin, recompilers here have become even more pointless, and 64th Note is typically used to just convert to MP3s or something anyway.

If you do truly want an accurate audio model for playback of N64 music, I guess you probably would do best to invest in a cycle-accurate core indeed like what Hacktarux has been doing. If you're lucky there may even be a format similar to USF which you could compose, similar just enough to be able to quickly port music files to USF format to something more purified you could come up with.

Ah, and also ...
had no idea it was Valentine's Day yesterday. Guess I remember birthdays better than any other day, being an astro freak and all.
Reply With Quote
  #637  
Old 16th February 2014, 08:18 AM
kode54's Avatar
kode54 kode54 is offline
Project Supporter
Junior Member
 
Join Date: Mar 2013
Posts: 14
Default

Also, I did not mean hcs any disrespect by that remark. He did devise the format in the first place, and save states were a quick way of getting the sound code bootstrapped. Unfortunately, that also means that all the rips floating around require a similar emulator, or at least something capable of porting the save state data over. It's really only memory, register, and some hardware state.

Yeah, I suppose it may be a good idea to start something more accurate, but for now, I'll settle for something that works. And thanks to the library I've assembled, there's something that works, and in a fashion that may even be portable to non-x86 architectures, if their development products' auto vectorizers are any good.

I guess many people prefer to convert their emulated formats to lossy audio files, but I prefer to keep them as-is, and sometimes even let them loop for hours on end.
Reply With Quote
  #638  
Old 16th February 2014, 03:49 PM
shourah shourah is offline
Junior Member
 
Join Date: Feb 2014
Posts: 2
Default

i guess it require a similar emulator






Reply With Quote
  #639  
Old 17th February 2014, 09:16 AM
V1del V1del is offline
Project Supporter
Senior Member
 
Join Date: Feb 2012
Posts: 442
Default

Sod off troll, but +1 for effort, a spammer that somewhat tries to be on topic is a rare sight
Reply With Quote
  #640  
Old 17th February 2014, 05:59 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

Thank you; thank you.
I do find it hard to keep on-topic to this thread sometimes, but I do try.

Heh, but I'm probably taking too much credit. You meant the other troll.


Anyway I'm glad that you feel my endeavor for portability of this module was a success. At the time of my introducing this RSP plugin I was still unaware of some ANSI technicalities and other factors behind portability to other machines, (Mupen64Plus were quick to pry those icicles.) but I'm glad that the main dimension of focus for that was what you'd wanted kode54.

Quote:
Originally Posted by kode54 View Post
I guess many people prefer to convert their emulated formats to lossy audio files, but I prefer to keep them as-is, and sometimes even let them loop for hours on end.
In fact, I also dislike converting USFs to lossy audio formats. I was simply stating that most people do.
I usually just play the raw USFs themselves for a very long time, or, rip them into lossless raw WAV audio format and trim them to the infinitely looping section. The result matches reasonably well to the sound of infinite looping in USFs.

About portability to systems where auto-vectorization was different...it was my method to let GCC do it since I knew of no other option on Windows; hopefully it can find analogous solutions on the operating system of your choice. MarathonMan's method was to do #ifdef USING_SSE ... #else for everything, but I don't really like that method because it feels like I'm half-hazardously defining everything twice. In the future, if not with possible revisions of this software then others, I'd rather use the straight SSE2 vector functions, and finish an ANSI abstraction layer that does those SSE functions in terms of scalar instructions any system today should do.

Last edited by HatCat; 17th February 2014 at 06:02 PM.
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 04:38 PM.


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