Would it be possible to add support for Nach's JMA ROM compression to the SNES core? I asked Ilari about doing it for lsnes, but I was wondering if you guys would be able to do it independent of the core.
sure, its possible. doesn't sound very exciting. itd almost positively be independent of the core.
this is caused 98% of the time by a broken .net installation. uninstall any .net related stuff you can find (starting with .net framework 4.0 related things) and reinstall them.
are you able to run the discohawk program that comes with bizhawk? it sounds like your .net installation is completely broken. you may need to try uninstalling it and reinstalling it.
Can you choose between 1x and 2x? should be possible.
Let's do some math. in windows XP, the bizhawk window frame is 69 pixels. The taskbar is 28 pixels, at least. Both of those things are more bloated, if anything, in windows 7. Most snes games are 224 pixels tall. Now for the math: 69 + 28 + 224*3 = 769. Therefore, 3x scale wouldn't fit on your screen. That's why the client is preventing it.
Did you know? you can drag the edge of a window to resize it and work around the snap-resize menu item functionality of bizhawk. Then you can make it any size you want.
the_randomizer wrote:
"none" looks pretty bad on an LCD.
Clearly not everyone thinks so, or you else you wouldnt be the only one saying so and it certainly wouldnt be the way it is. Allow me to word this correctly for you: "I'm the_randomizer and I think scaled up emulators look bad without filters"
Anyway, our paltry set of filters we have right now are coded in c# so they're gonna be slow. That stuff's just been thrown in to prove it can be done as icing for folks whose systems can handle it. Obviously it isn't made for you yet.
Ignore whatever vecna said about bilinear filtering. That was accidental and uncontrollable bilinear filtering on some video cards that we were able to suppress with some effort. If you want fast bilinear filtering, that's just a work order
if you want an emulator that actually will feel at home on a raspberry pi, try mednafen. putting bizhawk on a rasberry pi makes as much sense as putting pepperoni on an apple pie.
I dont expect people to go out of their way at all, since usually their problems are minor and they don't care much. I expect people to spend more energy working on a solution if the issue is important to them, and that includes registrations and postings some other way. SuperMario12 was lucky, as I said, for getting a solution without that much investment.
the first post is 3 years old and hasnt even been edited to be up to date.
the part that says 'please discuss any issue you have with the rerecording version here' is clearly marked as old junk. this is a suggestion that it may be out of date.
since there isnt even an independent rerecording version, anything referencing a rerecording version is a suggestion that it may be out of date.
and finally, ill give you one guess where me or anyone else would expect desmume issues to be discussed. i think if youre honest youll only need one guess.
fixed in r4269. there havent been any timing changes since the 0.9.8 release, so feel free to use this svn version if you want for tasing and just verify the results in 0.9.8.
this really isnt the primarily place in 2012 for talking about general desmume bugs. youre lucky i caught it.
BrandonE's infinite variations on his loathing for .tas are always a delight to read. I hope after the issue is closed he'll still keep posting them, as I would hate to say goodbye to his semiweekly performances.
If anyone ever adds some kind of 'cheat prevention' measures into bizhawk, i will circumvent said measures in a custom build and post it somewhere myself. This will be because the challenge will be irresistable, and additionally, it is a courtesy to the cheaters' guild which we are insulting by wasting their time; and because the cruft accrual from ever-escalating levels of halfassery will make me really angry.
Or you could just make WolfHawk.
And now for my vote: .bhr
I've always thought the use of the term 'movie' here was really confusing. If folks are seriously bringing up the idea of calling them replays instead, then im all in favor.
right now, the code that composites the screen layers and draws the HDU only works in the direct3d display method. bizhawk will switch to the gdi+ display method when it has trouble starting up the direct3d display method for some reason. yeah, this is crappy, sorry.
hegyak, it seems youre using the aladdin version. There are two versions of the game which can be called good. The aladdin version may have a mistake in bootgod's cart database which is tripping up the emulator. In r2011 i just checked in a hack to load this game, which will be removed when the DB gets straightened out at some unknown point in the future.
then youre probably using a bad rom. i still havent had a chance to do the work to make the rom loader more lenient for all sorts of bad roms. itll load all those bad roms one day.
mednafen did change its file format at some point. im not well versed on the subject but i think theres a chance that mednafen now uses a different format than it did when mednafen-rr was branched. I dont know anything about mednafen-rr but plain mednafen doesnt have platforms that only work in linux.
why does not having a mednafen-rr linux build mean your pc-fx tases must be kissed goodbye? isnt there wine or something?
I could understand that if it was just extremely accurate, but after testing it yesterday, that doesn't seem to be the case.
Its called: Laying Groundwork. An emulator isnt accurate just because its slow. But it can't be fast if it's going to be accurate. So step one is to make it slow.
rog wrote:
I cannot even begin to imagine what it is even doing.
Can you try imagining it doing bloat, junk, cruft, brokenness, bugs, and not having a chance to give a crap yet? Then you may understand better.