Lack of recent progress and current news

    People have been asking for an update, so I thought I'd let everyone know what's going on. The past month and a half has been very busy for me. I'm now in college and working full time. I work 7 days a week 12 hours a day for up to two months straight then I get a week or two off. I was unemployed most of last year, so now I have a lot less time on my hands for code. My job does afford me some downtime most of which goes toward school. I'm currently pursuing a Associates of Applied Science in Computer Programming. I'm also looking at getting several IT certifications along the way to help keep my options open when I can finally make a career change. I do still have a decent amount of left over time most of which has been spent working on the forums and dealing with staff issues. The main changes I had planned there are done. (I got a staff hierarchy set up in order to reduce issues there and integrated the compatibility list with the site.)


    On the code side of things I've done some minor code clean-ups and I'm currently working on a few regressions. Along the way I've learned to better debug crashes which is a good thing. I also made my first attempt at moving code to the ME. I tried to move the "JPEG_Task" to the ME but this didn't go so well. So far it gets about half way through the code for it and crashes. Crashes on the ME are hard to debug, but this will be good practice for the CPU move. I've also started a full port of 1964Video(Rice 6.3.0r35) from the 1964 SVN which should kill 90% of the graphical errors and a few crashes from within the graphics plug-in. It will also increase the overall compatibility of the emulator as well. This will all take a while. The JPEG_Task isn't planned to be move and I'm only doing this as it much simpler than the CPU_Task and a good case for learning. As I stated I'm working on the regressions I introduced in Rev 432, this should only take a few days. Then I'll be back to debugging my JPEG related code and porting Rice.


    On a side note, both school and work are going well. Salvy has been adding a few bits of code related to uCodes and the blender lately and one of our forum members (Yamagushi)  has implemented a new GUI on Rev 463. I still have further plans for the GUI but his changes are a good starting point for my plans.

Rev 432

I just posted Rev 432 here's what happened. I had a few speed ideas, but thought ehhh... I'll throw in a fix for GoldenEye(GE) freezing since it's a regression (I.E. It didn't used to freeze.) just for the hell of it. Along the way of doing that (I found where it broke, but just reverting that one part broke other games) I remembered having to disable the loop optimization (A speed-up Strmnnrmn added for R14 that had some compatibility issues.) So, I decided to check what broke it and found that as well and I found it. All in all code from 3 revisions (All that Howard0su posted way back, 305, 316, 318) needed to be reverted, some of it I was still able use use and the rest will be brought back over time as we near Beta 3 and I track down each piece that was causing the breaks.

In the end, 432 includes: GE(No Freeze) + TS(No Freeze or Crash even on Phat) + Loop Fixed + Minor Texture Speed-ups + A few new settings for texture update. (It now has: 1, 2, 3, 4, 5, 10, 15, 20, 30)

The extra speed is enough to be noticeable(About 5%): The Mario head on Mario 64 goes at a consistent 19 FPS. Games the dynamic loop never worked on will still get some extra speed, but not as much. (It still freezes MM and a few others.)

For the next bit of code I post I plan on working on how DX64 handles Textures, on the Phat and even sometimes on the Slim DX64 runs out of memory for texels in both the VRAM and the secondary RAM buffer. This was my purpose in reducing the secondary buffer on the Slim a few revs back so I can do testing with the lower Phat value. Besides trying to get a bit of memory from else where (Some other buffers are a bit larger than needed.) I plan to work on the way Daedalus decides to throw away a texture when it's no longer needed. I thinking that I will have it throw away large textures sooner. Some sort of texture compression may be another possibility.  A couple games that are good examples of this are Transformers - Beast Wars, Tetrisphere, and Space-station Silicon Valley. All three have issues with texture memory with Beast Wars being the worst. This also causes the crash where if you go to the select menu several times the emulator crashes. I reduced the memory intrafont uses a few revs back to help with that. Right now DaedalusX64 keeps textures for 10 Frames automatically (Not 100% sure if this is 10 actual frames or 10 virtual frames). If I lower this to 1 Texture update is not needed as textures are all thrown away every frame, but then there is a speed cost. However at even a setting of 2 Texture update is need for persistent items like onscreen text it OoT but there is still a speed cost. Loading small textures take a small amount of time compared to large ones, but loading them too frequently causes cache thrashing. So in the end we need a more dynamic way of dealing with this. Also as an added measure large textures will likely get converted to 16Bit to cut there size in the memory in half which would help as well. This fix in the end should help a few crashes and possibly add just a bit of speed as more textures (Especially the small ones) will be stored in the VRAM (which is 2X Faster than the RAM) Also as part of this I will be testing various games to get a count of how much texel memory they are using at any given time to know how much I need to save. The fix for the Slim it's as simple as upping the secondary RAM buffer, but as you can see it's going to be a bit more complex for the Phat.

BTW: On a side note my crazy plan from a few posts back didn't happen... It will eventually just not yet. Also my wife's desktop died so until we get her a new system (which may take a while.) we will be sharing my laptop on which I do my developing. Other than that I will continue to try to udpate this around once a week to once a month depending on progress I make and life happenings.

A week away and forums down

I've been gone for about a week due to an elderly family member having heart surgery (It went great). I just got back today.

I noticed Dark-Alex took his forum down, but he has stated M33 isn't dead and I quote from the IRC "Forums closed down due to expenses. M33 is still alive and well. Don't believe or spread rumours! | forums.exophase.com"

Our situation isn't due to money but donations are still welcome, but it is due to a problem with our host. I have decided we are going to switch (Don't know about costs yet). I only have yet to decided to whom. I am looking at this now. I will likely purchase the new hosting myself and a friend wants me to set up a website for his business. (Which may offset the cost, but all new donations will go to hosting as well as the ad revenue. Anything beyond that will go to charity.)

Side Note about current code efforts: Soon myself, Strmnnrmn, Howard0su will all be working together on the ME move issue. Howard0su and Strmnnrmn have been busy with other things and will be available to help soon. Howard0su has given me his latest WIP code along with Strmnnrmn. Myself and Salvy are working on the memleak. I'm working on some of the crashes. Grazz is still mostly concentrating uCodes for compatibility. So, compatibility, speed, and crashes are all getting looked at.

Rev 424

Well I've just commited and posted Rev 424. Here's the changelog:
[+]Renenable SIMULATE_DOUBLE w/Mario Party hack
[+]Reduce resource usage of Double Display w/o breaking roms
[+]Removed need for extra sceGuSync for FPS Display
[+]Switched from string compare to flags for hacks
[+]Added hack flags to Roms.ini and as menu options Debug mode
[~]Added files the Vis C++ project to reflect Changes in Microcode Structure
[!]Fixed 007 Broken on Rev 423
[+]Reduced extra rendering steps on non-rendered frames with FS enabled
Note: Approx 10% Speed-up, some games that need DoubleDisplay to function correctly have issues under FS (Ex:Automobili only work properly under odd FS)

A total of 16 files were changed. As promised most of the speed we lost between 300 and 423 should be back now and hopefully without side effects. All you GoldenEye fans should note the GoldenEye sky uCode has been disabled until after the release of Napalm's source code or I find a way to fix it myself, but at least it's playable again after Salvy broke it. The speed increases will be more noticable in some games vs others. Next I'll be back to working on the CPU to ME move. Also don't forget to overwrite the roms.ini when you upgrade as new stuff has been added to it for per game hacks.

Cleaning-up

Well a couple of days ago together myself and Grazz have cleaned up almost all of the release mode warnings. We went from 90+ to 6. Next I'm going to work on the warnings in various compiler/debug options. Once I'm done with that, I'm going to help Salvy some on the uCode side of things a bit. Then it's back to my rebuild. I've also got more code from Howard0su to look at, but I'm going to be busy over the next few days without much time for DaedalusX64 which is why I'm only going to be working on small things like clean-up. Next week I should be back in to full swing working on the rebuild and will post another blog entry then. Also I plan to post a few things not DX64 related in about 2 weeks that will show you a little about me and just how crazy I am.