Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
snesmaster wrote:
I have no idea how to convert Photoshop files to different colors using color conversion tables from the BizHawk emulator. Is that something you know how to do? There would be about 4,500 image files to convert. Many of those have multiple layers that would all need converting.
How much work would it take to have an option to use the zSNES / snes9x color palette? Keep in mind it's not just zSNES / snes9x that use that same palette, most map editors for SNES games also use that same palette.
Photoshop, ehh? Could be tough; I wouldn't trust anything but Photoshop to open a psd.
I'm in the process of examining snes9x code to confirm what it does. The next bizhawk release should have some sort of color adjust system.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
snesmaster wrote:
1. Add a feature to be able to set the color pallet so it is the same standard that both zSNES and SNES9x use to keep consistency in mapping projects.
I took a look at some color conversions in sneshawk, and compared them to a few reference images on http://www.snesmaps.com; as far as I can tell, the latter is wrong. Granted, it's not a "big deal"... but why not convert all of your projects to use more correct color conversion formulas, instead of converting the emulator to use less correct color conversion formulas?
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
creaothceann wrote:
zeromus wrote:
BG mode switches should never be needed to view a layer correctly. choose the correct scanline, and the game should be switching to the right BG mode.
Does that work via the HDMA table? Some games switch modes 'manually' via vertical interrupt.
No. The emulator breaks on the requested scanline, and at that moment, the emulation state is used to generate the GPU view. So any change method at all can be properly detected; DMA, interrupt, timed code. That's not to say there couldn't be a runtosave() related issue... but a better question would be, can you produce a game that isn't working as expected with the scanline control?
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
vba-rr v24 svn422
File: Legend of Zelda, The - A Link to the Past & Four Swords (USA, Australia).gba
CRC-32: 8e91cd13
MD4: a161ca265e2e34ccfaa4fc823c2ab113
MD5: 3287ca66e5cc285a9fe3a922051e84c6
SHA-1: a272055abbbf6c26b0cd54c87395d01699589161
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Yeah, that will work. I can't help but wonder if there's some subtle analog effect inside the NES's video output track that's not being emulated correctly, though...
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Warp wrote:
I don't see the problem in brightening the videos. It's not like we are modifying the game or doing video editing. It's completely akin to gamma correction.
And it's not like there can be an "absolutely correct" brightness setting. Even if you knew the exact luminosity of every single palette entry as presented by the real console on a standard average analog TV with factory-recommended brightness and contrast settings (which most TVs probably don't have anyways), it would still be really difficult to reproduce in an exact manner in a computer display, because also the display's brightness, contrast and gamma settings would have to conform to exact specifications (which 99.9% of people don't.)
I'd say that if brightening the video makes it look better, go for it.
What I don't want though, is to have encoders to have a burden to "correct" crappy games, or be subject to complaints from users "this game looks/sounds like crap, why not make it better", especially when it's not really possible.
If someone's actually going to encode something, could I maybe see a comparison screenshot or two, "hack off" vs "hack on"?
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
The evidence is presented isn't very strong: any photograph of a TV screen is going to involve the camera doing all sorts of exposure/light level correction. I also wouldn't trust any end-user off the shelf video capture card to not muck with levels.
Still, it's probable that AGC made these shitty games look less shitty on real hardware. I've noticed a few genesis titles with suspect light levels as well.
I'm a bit worried that mucking around will make a precedent of "fixing" things that look bad.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Masterjun wrote:
If I use the Trace Logger in Tetris (NES) it somehow pauses the game by itself (even while movie playback)... there is also something strange going on with the sound after logging...
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Stupid question: If the whole game is an autoscroller, how is this run 20 seconds faster than any other attempt? Boss times don't seem to count for that much.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
DiscoRico wrote:
So just to make sure this is feasible, SNES games in which UP+DOWN and LEFT+RIGHT are allowed are viable input?
Would a SNES bot be more reliable in terms of syncing if a SNES controller were disassembled and the mechanical switches for each button were replaced with signals from an Arduino corresponding to each button input?
U+D/L+R is entirely possible from an electrical standpoint. It's a mechanical lockout on some controllers that can prevent it, depending on how hard you press.
I don't think gutting a SNES controller is useful. The only electronics in it are a simple shift register which is very well understood.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Thanks for the bug report, and for the movie file that reproduces it. Unfortunately, we don't really have a GB emulation guru here. The core is from gambatte, and has only received minor changes in bizhawk.
Does this bug also occur in gambatte itself? If so, you might take it up with the author of gambatte. If he makes a change to gambatte proper that fixes it, then we can easily add the change here in bizhawk.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Cooljay wrote:
Find it weird that Snes9x 1.43 had the color flash correct with console for the intro but the others had green which never appeared at all.
Not to mention it's funny how inaccurate it is blazing through screens compared to the console taking it's precious time to go through the text.
Thanks for the comparison.
this is youtube, the flash is a 60hz effect, dropping individual frames will completely screw it. a simple "off by 1" doesn't indicate great inaccuracy, but would cause that to look wrong.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
trlky wrote:
the_randomizer wrote:
There are only two Snes ROMs that are 48Mbit or 6MB in size, the rest typically range from 2Mbit to 32Mbit. Not being able to compress them should not be an issue.
Especially because you can compress them (at least on NTFS file systems). Just use the built-in Compression option in Windows on the properties tab. Yeah it's not the tightest compression, but it does get close to ZIP level.
That's assuming BizHawk doesn't have other archive support. If it does, use that. RAR is so far the best I've seen for SNES games.
Bizhawk supports quite a few different regular archive formats. I don't know if RAR is amongst them, but gzip and zip are.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
tetora_X wrote:
i've started to make a movie tonight and found 2 problems.
1. BizHawk-1.1.1b doesn't save a GBC movie properly.
When I stop recording a GBC movie, the recorded movie is full of no input.
It works fine for me in a SMS game, so maybe the problem is yet another GBC problem.
2. savestate.loadslot doesn't load slots. savestate.saveslot works fine, though.
This problem might be already fixed in latest SVN by the fix of savestate.load issue.
2. should already be fixed for next revision. I can't seem to reproduce 1; if I open a GBC rom and record a simple movie, the resulting file contains input and plays back. Could you give me checksum details for the rom you're trying to record, as well as the resulting broken movie file, and possibly any special instructions to reproduce the bug?
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Randil wrote:
Some things I've noticed when playing around with version 1.1.1b:
1. Under Config->Paths->SNES tab, clicking the folder symbol for "Save RAM" doesn't do anything.
2. I think the lua command savestate.load doesn't work. The lua script
both fixed on SVN. thanks for the bug reports, please keep them coming in!
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
hegyak wrote:
Mega Man X2 and X3 will not "load" properly. X3 is confirmed a good ROM. X2 is not. dsp4.rom is SHA1 confirmed as good and is in the same place as all the other DSP ROM files.
On loading X3 the Emulator gives the same "SNES core is referencing a firmware file" error. The ROM does load, but gives an error of it's own. After pressing any button, the game proceeds to run. Though, I did not play the intro myself.
If you get the "referencing a firmware" error, the core didn't manage to load the firmware. Both mega men x2 and x3 work fine here, so I'm not sure what's going on. Double check your paths and whatnot.