Previous Page | Next Page
- by Mouser X at 9:35 PM EDT on July 30, 2005
- The new tag I want is something like "HLE=On" or "HLE=Off" or something. That way, the sets that work just fine with HLE on can use it, and thereby decrease CPU usage, for those on slower CPUs. I've been wanting that since the beggining, but apparently it never happened. I noticed that Super Mario 64 runs a lot better (takes less CPU but sounds just as good) with the HLE on, whereas Golden Eye sounds quite messed up. Also, apparently, this is the case with some of the Zelda tracks. They don't sound right with HLE on. Basically, if the "HLE=??" is blank, or doesn't exist, it would take no action on those sets. As such, if the user has HLE on in their settings, then the sets with "HLE=??" blank or non-existent would run with HLE on, since that's what the settings are. However, if they have HLE off in their settings, then it would run the songs with HLE off. But if the "HLE=??" is set to off, or on, it would run the set as such.
Of course, the plugin settings would probably need a new selection. I'm thinking something like "Overide HLE tags." With it selected, it would run all sets as the plugin is set to do (if HLE is off in the plugin, then all sets, regardless of tag, will be run with it off).
Those are ideas I've had, and wanted for some time. However, I can see reasons why you wouldn't want to include such a feature. If the user has a high enough CPU speed, HLE won't make a noticeable differance in CPU usage. It will also make that much more work for taggers to add it (not that they'd be required to, unless it was obvious the set didn't work with HLE on, such as Golden Eye).
Anyway, if I was to place a request, that's what it would be (oh, and put the settings in the "plugins.ini" or "winamp.ini" file, instead of the registry (the registry is already a big enough mess/pain, it doesn't need to be any worse...(opinion, I suppose))).
That's all for that, I guess. Mouser X over and out.
- by hcs at 11:13 PM EDT on July 30, 2005
- HLE tag observance would be disabled by default, but I can see how it would be a useful option.
Regarding the .ini, apparently this is what the GetPrivateProfileString functions are for, when it comes time for the new program to save settings it'll use an .ini.
- by hcs at 9:38 PM EDT on August 22, 2005
- I've started work on the new version of 64th Note. I'm still at the "getting it to work in PJ64 at all" stage, though. Seemingly everything I've thrown at it works great under the interpreter (including the troublesome Bust-a-Move '99 set and some recent rips that wouldn't work on the interpreter) but only a few seem to work right in the recompiler without crashing or bizarre behavior.
Mario Party is one that works in the new recompiler. So I guess that's nice.
It really makes me appreciate how relatively stable the current incarnation is, and how very much work I had to put into it to get it that way. I'm really dreading this project, especially with all this trouble right off the bat...
edited 1:41 AM EDT August 23, 2005
- by hcs at 1:22 PM EDT on September 2, 2005
- I decided to try moving the 1.4 recompiler back into the 1.6 source I'm working with now, and that seemed to fix the recompiler issue. I didn't want to just sloppily throw the old code in there, though, as I'm trying to start off fresh with 1.6, so I did some tedious testing to find just what changed that affected the recompiler so. It turned out to be the stack analysis that was added in. Even with SPHack set to false there were a few things done which apparently break a few games. I removed all the stack-specific code from 1.6 and I now have that working. I've tested the recompiler and the interpreter on all sets I have (prelim and released, 43 in all) and it seems to work perfectly. I also fixed zilmar's Basic Audio Plugin so it now isn't totally useless for listening purposes. I'll be writing my own AI handling routines when I move things over to Winamp but until then the Basic Plugin will suffice.
So yay, progress.
- by R. Belmont at 3:30 PM EDT on September 2, 2005
- Oh, and zilmar gave me an interesting argument for not releasing the source: when you know that the code is out there and anyone can make bug fixes and add new support it lessens your desire to do it yourself.
That's crap and you know it :-) As long as there's some way for external folks to contact you before they start doing something it's not a problem. MAME has over a dozen devs "on staff" and we get external submissions all the time, no problems. I think it's more like stupid elitism as the driving force, just as it's always been in N64 emulation.
- by hcs at 2:42 PM EDT on September 4, 2005
- Well I don't know what motivates him to work, and if he doesn't want to release his own code then any reason he gives is fine with me. In any case I have it now and I'm making progress.
I've finally achieved a single binary which plays every existing set.
- by R. Belmont at 8:11 AM EDT on September 5, 2005
- In any case, I'm going to look at playing USFs portably with the latest Mupen64 source - while nobody was looking it's turned out to be pretty nice, and it's already portable. The minus is that it only has audio HLE, but music played great in all the games I tried (including Conker) so that may not be much of a problem.
- by Josh W at 4:23 PM EDT on September 5, 2005
I've finally achieved a single binary which plays every existing set.
Excellent, maybe this one will fix the errornous errors given by our attempts at many newer roms.- by hcs at 9:58 PM EDT on September 5, 2005
- 64th Note 1.0 (beta 2)
The "1" in "1.0" implies "first major revision", not "complete".
It has all the functionality of 0.09 and 0.10 beta with the exception of Audio HLE at the moment. There are still bugs, evident due to crashes when switching tracks. You can safely discard your RSP.dll files now. This plays everything I've tried it with yet. That means Mischief Makers, Bust-a-Move '99, and Mario Party with the recompiler. (btw, the problem with BAM'99 is that it keeps reading the controller. I've left minimal support in (the port returns an error for all controllers)).
I was going to use UPX, but it seems to crash the Interpreter... so you've got a 728 KB (-ish) .dll instead of 131 KB.
Bug reports... missing features... put 'em here. If you can get it to reliably crash please tell me your circumstances.
you guys owe me a case of Mountain Dew and about 8 burritos which I consumed in the few days I've been working on this almost continuously.
edited 2:07 AM EDT September 6, 2005
oh, yeah, it uses winamp.ini (which it will locate even if you're running it with the foo_winamp_input wrapper). to get it to work with foobar's replaygain scanner you must enable "round frequency".
edited 2:08 AM EDT September 6, 2005
- by marioman at 5:39 AM EDT on September 6, 2005
- Good job; the plugin sounds great. Thank you. I did find a few things that you should know about:
#1 - After about 20 sec. the standard Winamp visualization bogs down and eventually ceases to work. It also does this when it is approaching a loop point. I don't know if this is a minor problem or a symptom of an underlying bug.
#2 - I did manage to get the player to crash a few times. The first time it did give me an window that said that Winamp had encountered a serious error. However, the other times I got it to crash Winamp just disappeared (as if I closed it normally). The player seemed to like crashing when I tried to switch to a short (>30sec) track after playing a track that was stalling because of problem #1. Maybe the two problems are related.
Thanks for giving your time and Mountain Dew toward this great plugin.
edited 10:22 AM EDT September 6, 2005
Previous Page | Next Page
Go to Page 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
Search this thread
Show all threads
Reply to this thread:
HCS Forum Index
Halley's Comet Software
forum source