3/20/11 - Today, I'm continuing going through the Audio to find what broke the PC side. I've merged most of the changes and I haven't lost audio yet. I'm getting static (likely due to an endian issue), but that's easily fixable once I find what changes killed the sound.

Update: I've narrowed the changes down. Now I just have to go through the narrowed group. I should be able to finish this part today. Then I'll work on the asserts and the SS issue and R593 will be ready to commit to the -N64 Branch.

Update 2: I'm about half way through the narrowed group. I've eliminated OSHLE as the culprit as well as a few other things. I've got a bit more time today and I'll be working on it more tonight. I'll post again tomorrow with my progress.

Update 3: It does seem to be related to hardware.cpp as I thought originally. So I'm going to be working out the bugs there and seeing whats going wrong. I should be able to fix the SaveState and plug-in initialization problems at the same time.

Revert the hardware changes and see if it cures it?
BTW I recall there was changes done on the audio side when howard added the hardware stuff, that could be your culprit.

EDIT: that's why I always told ya not to do a supa merge, instead merge ~5 or so to not make regression hunting so painful.

But Revs were coming out faster than I could merge them. It's also not a matter of reverting the hardware changes and that's not the whole problem. It works in 591 which uses hardware, but not 592 in which hardware never changed from 591. The problem is elsewhere.

03/21/11 - I removed Hardware.cpp and video stopped working due to the UpdateScreen call being removed(I made a work around for that for the PC version since it uses an external plug-in). This shouldn't be the issue with Audio since even on the PC it uses Azimer's which is the internal audio. First the plug-in is registering as APM_DISABLED so I forced it to enable to make sure we were getting in to the sound at least. I'm currently going through the changes in sound process to see what isn't being called or working right there. It's obvious something is still missing. OSHLE is causing an issue or two but I reverted to an older version of the OSHLE files for now until I work out the base issue first. Then I'll move on to bringing all together once I find the core issue.

Update: On the PC side of thing the audio plug-in is being enabled and the the audio is being processed. It's just not being output. Similar to the ScreenUpdate for graphics. This was what I suspected. I have to find to equivalent to screen update for the Audio on the PC side of things. (For the PSP the Audio is direct).

Update 2: Found multiple issues affecting it. The main is endian related. It's is causing to Audio uCode detection to fail. It's the changes made to HLEMain as part of the Audio that is the issue. I will work on this (first by reverting those specific changes to make sure that is where the issue lays) and report my progress later tonight. (Edit: It was the changes from 561 that are the issue. ProcessAlist should not have been decpreciated. It is called by every single PC Audio plugin...) I'll write a work around for the PC side that will only affect it. Thx Salvy

Update 3: I've gotten all the breaking changes done to 5 files now and about 50 changes. These were my suspects early on on and now I'm going to create hybrids of these files so that they do work with the PC.

Update 4: I've now checked the endian issue by bringing that part of the code to 591 and that did stop the audio. While I know it's not the full issue(I did the reverse on 591 and no Audio), it is definitely part of the issue, but a simple define using the endianness flags will fix that part. The next part is figuring out why the plug-in is coming up disabled and getting the audio to actually run properly.

Final Update for 3/21: I've gotten it fixed and know exactly what the issues are. The fix is slower than the current code, but I'm going to work a bit more on it to bring it back up to speed. I have a few more bits to work on as well (such as why it's being detected as disabled, the SS issue, etc..) Then I will commit within a few days 593 to the -N64 SVN(593 will be 638 equivalent with PC fixes for code changes). I should be ready for the next round of merging (but back to a few at a time) then. Once the -N64 SVN is caught up to the DX64 SVN. I will be done with the merge. Then once my own code is caught up to the Dev SVN. I'll finally be working on new code/fixing current bugs while keeping current with dev versions so I can commit them when they are committed to the DX64 SVN. All the SVNs should stay in sync then. This means the "Async Bug", ME move, and DKR(Which BTW is a vertex issue if another dev wants to work on it first) will be on the horizon soon. (I should only take about a week to finish it all up and get to them).

Additional Info: When I 'm done and post my next commit it will be a fix for the audio and still include Hardware.cpp. Hardware.cpp is needed for the cpu move because it creates it as a separate thread. This thread will continue to run on the SC (the main PSP processor) and it will be used to manage what happens and when to get it all working together and allow us to use the ME for both the Dynarec and the CPU Emulation(actual execution of the fragments created). This part is critical otherwise graphics can't be called properly. This multi-threading is also useful on the PC for those with multi-core processors. Windows will allow us to take advantage of that fact and allow Daedalus to be even faster on the PC. AFAIK, there no other N64 emu that does this(some are internally multi-threaded but not designed for multiple threads to run at the same time). This also means Async audio, video, and well everything is possible on the PC. We may not need every single resource the PC platform has, but that doesn't mean we shouldn't take advantage of it. In short, this will be the fastest N64 emu.

This is very interesting reading Kreationz, keep up with the merging & fixing of bugs, i look forward to your updates.

I appreciate all that you & Salvy & Corn are doing, its just great to see the improvements & new games booting up, keep it up guys.

Check the latest Azimer's aspects and all modern audio plugins, Alist is deprecated. Anyways if you check the SVN log I reverted that change, so that can't be the reason of the audio failing.



Isn't windozed little endian? Can't see that can be an issue if that's the case.
Audio flag coming as disabled, is that regression? If yes tracking where it broke is the best shot.(If is inside the mega merge, could be almost impossible though)



What was the issue? could be interesting to know, could be a "bug" we introduced.
BTW hopefully the merge is done before B4 jk. Is been several months since was started




Hardware.cpp isn't the prettiest code out there, I don't like how value is passed around by a global variable.
I recall 1964 does similar to what Howard did, can't recall the function but is located in R400i.cpp if you want to get some ideas form it.

1964 is one that is "internally" multi-threaded... It uses multiple threads to keep track of what's going on but like with sync audio they are all done sequentially. What I mean is full Async processing. The most ideal situation would be a job manger that checks which of the two cpu's isn't busy and sends the code there (similar hyper threading on the PC but in software rather than hardware). Ideally each emulated component should have it own thread that can run as needed on any given CPU in a multi-CPU scenario.

PCs, with the invention of multi-core, are just beginning to truly embrace this on the software side. Invention is out pacing humans ability to keep up and necessitating a societal shift to more specialized jobs. Faster better machines are making some aspects of life easier/faster but they create whole new problems. Personally I think bloat is the biggest problem with modern software(just because resources are there doesn't mean you have to use every last one). DX64 is very optimized, but coming from the PC as a port, it would be a completely different piece of software had it been built for the PSP from the ground up... This was the reason I chose to depreciate the PC build in DX64 and reverse port new code backwards in the first place. Development is more productive if a team concentrates on one platform... but multiple platforms lend to greater creativity and allow us to look at code from different perspectives.

@Salvy - It can be called whatever you want you just need one file that calls the standard functions on a PC from that file to be maintained and keep multiple plug-ins working. (Example: we can use any gfx plug-in on the PC build, but not any audio plug-in. I plan to fix that and add RSP plug-in functioanlity eventually as well.) The issue was the changes in calling the plug-ins properly. I think you'll see where the issue was when I post 593 in a few days.

3/23/11 - Yesterday, I had a busy day so I didn't get to work on code. Today, I should have much mush time. I'll post an update later today on my progress.

Update: I've built a Hybrid version of R591(DX64 R432) and R592(DX64 R638) in which the sound is working and all major changes have been imported with the exception of changes to the Audio an OSHLE. I'll be handling the OSHLE changes next (Starting except the AI changes) then I'll move on to the changes in our Audio code (Audio Plugin, Buffering, ABI, etc...) and finally back to the AI changes in OSHLE. At that time I'll have 592 with Audio working, then I'll address the issues associated with Hardware/SaveState issues (they are related issues) and any other asserts that I find. This will be 593 and should be committed today or tomorrow with the Option to turn off OSHLE and to Enable/Disable Sound properly. Next I'll merge code through B3 as 594. Finally for 595, I'll be fixing options and allowing the debug console to be turned On/Off properly and disabling it properly in Release mode. This will be posted as Daedalus 0.11b for the PC and be the first official PC release since 0.08b about 9 years ago, but before that happens I'll be make a few changes to the forum to support this release... on that note stay tuned as I won't be posting any more updates here for the next few days until it's all ready.

P.S. After all that I'll be working on DKR(I know the main issues it has) and the Async Bug(Since I'll be able to work on it in near real time on the PC ).

You don't really have to worry about merging 595, I didn't commit much...

@psppwner300 - I'm not talking about DX64 Revisions, I was speaking of the -N64 branch. As follows:
592 = DX64 638
593 = DX64 638 + PC Bug fixes and a few options added (AKA PC Version 0.9b, not released, but you can build it if you want)
594 = DX64 677 AKA B3
595 = DX64 677 AKA B3 + Proper Release/Debug Options Fixed (To be released as 0.10b to the public with 1964Video)

@Salvy - Here's what I meant when I mentioned we do everything in the core needed for FB effects it's only a matter on implementing them in the GFX plug-in:

Even the jumbotron pic in inside the jumbotron pic is showing

Ahhh looks really good, still a mystery how the core can notify the plugin when the fb starts, as far as I seen we don't.
Atleast it means we are only missing the video part to get MK goin'.

Also the flames move on the MM opening...

3/24/11 - Another busy day at work today, so no code. I don't expect tomorrow to be any different and likely won't be able to code until Saturday. I should be able to commit 593 then and get to work on 594. I'm hoping to have it done by the end of the weekend and work on 595 next week along with some other stuff I've discussed with the staff. I'll be passing 595 around with our testers when I think it's ready before I commit it to avoid issues. Once testing and final bug fixes are done I'll make the planed public released I mentioned above (Likely with Beta 3 Update's code included in it and will hope to be able to do a simultaneous release.)

3/27/11 - I'm running at least two days behind my original plan (see previous entry) and so likely will have 593 finished up tomorrow. Just have to work out a few initialization and one more sound issue, the new re-sampling method(in AudioHLEProcessor) is causing all sound to just be static(Can use the define Corn put in for the legacy method though). I figure two days max until 593 is ready. It won't be very stable, but it will be the equivalent of DX64 R638's code on the PC with everything working.

Also interesting: Framerate on my system seems capped at 120VI/s (Runs that speed in SM64 pretty consistently in SM64 with GFX on, sounds funny and difficult to control, but fun), but turn off GFX and it runs at over 400-500% sync consistently in SM64.

3/30/11 - Plans currently on hold to to lack of time due to my job. I will have time beginning this weekend, but will be concentrating on getting B3 Update ready for release in the coming week or two. I may post on that after my testing and work is done as issue are fixed so you know what to expect and know what I tested. Some issues have already been fixed by Salvy/Corn, but it's not quite ready for a release yet until we can finish fixing some more of the stability issues. Expect B3 Update to crash a lot less... (Hopefully )