Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
CoolKirby wrote:
Oh, wow! This new release is a huge improvement in performance on my machine. Max throttle speed in GBCHawk went from 77 fps in 1.5.1 to 400 fps in this! Thanks, BizHawk team!
GBC should be faster in next release (well, might not make 1.52? Might be not until 1.6).
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
feos wrote:
If we drop 10bit444 tag for these encodes, it will cause huge confusion between the old encodes without tags that were 8bit420 and the new ones. And yes, since 512kb encode is officially provided for compatibility, it must do it to maximum, avoiding opus until it is supported freaking everywhere.
In times gone by, the primary encodes have been all sorts of things that they aren't now, due to changes in technology. I don't see any problem there.
I agree on the 512kb; the whole point of it is to run in LOLFLASH. Looking ahead, I'd replace it only with something that would run in all major browsers' html5 video implementations.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
I like this idea. Do we want to Opus up only the 10bit444 encode, or both? Of course, now that we're talking about it, 10 bit should probably be added to regular encodes and the current specialty "10bit444" should be retired, to be replaced by hevc at some point.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Spikestuff -- That one's been fixed on SVN.
hegyak -- Could you give the .xml that you're using when you did the test "I tried combining the XML and ROMs into a single 7z file, but it doesn't work. I get the error messages: "?
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Hmm... I've tested archive loading before. If you take the following xml file:
pastebin
and put it into an archive container with a file named
"Legend of Zelda, The - Oracle of Ages (U) [C][!].gbc"
and
"Legend of Zelda, The - Oracle of Seasons (U) [C][!].gbc"
then it should load properly. Does that not work?
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
I wasn't able to reproduce the black screenshot bug, but I may have fixed it anyway. Not sure about that cue file, maybe zero knows. Can you explain your problem with dual GB xml in more detail?
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
I am aware of the major GBA bug; it's not a big deal to fix, but I haven't done it because that core has some showstoppers in it and isn't going public any time soon.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
I think there are two different revisions of the FDS bios? The one I built and tested the FDS mapper core against is 57fe1bdee955bb48d357e463ccbf129496930b62; offhand, I don't know where the other one is from. I will look into it.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Sure. Can you tell me; is it safe to always have a 4MByte dram cart plugged in? IE, is there any game that would not work with a 4MByte dram cart, or any reason that you'd want to install a different cart?
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
creaothceann wrote:
Derakon wrote:
The NES is normally limited to at most 8 sprites per scanline; if the game has more than that then some of the sprites will flicker on and off.
If the NES works like the SNES then it's the game logic that produces the flickering (to keep them at least partially visible). If it wouldn't do that then some sprites would be permanently on and some would be permanently off.
Yes, this is true; why sprite limit removal usually works is a little more complicated.
During the rendering of each line, the NES goes through the sprites in numeric order, stopping after it's found 8. So if you have more than 8 sprites on a line, there are two ways your game can choose to flicker amongst them:
1) Reorder the sprites each frame, so that which ones are the first visible are always changing.
2) Remove sprites beyond 8 from the line entirely, so they are not considered for display.
1) is generally easier to implement, because you don't have to do any of the per line detection at all: you can just blindly reorder sprites each frame, and your game will show as little flickering as is possible.
This is why the remove sprite limit functionality usually works; because even though the sprite flickering is controlled by software, the other sprites are still there waiting to be rendered.
However, a game can choose to swap out sprites entirely when there are too many (in which case the remove sprite limit option will be nonfunctional), or use the sprite limit intentionally for other effects (in which case the remove sprite limit option will create graphical problems), so it's still a hack.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
I made some lua a while back that would do input display as an .srt track; it was for VBA, but of course bizhawk could use a similar setup.
Capturing the whole OSD in a non-video manner would be more complicated...
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
That video source isn't appropriate for that encode script as is. The "Youtube HD" script is about taking very low resolution inputs and blowing them up really big. Your 1280x720 input is HD already, so the script is trying to blow it up into something ginormous which won't work.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Also, when I record a movie from power-on, it starts recording and I can stop and save the movie, but when I try to load a save state after that, BizHawk crashes with a similar error message.
To clarify, what you're saying is that in this situation, you:
1) Load the rom
2) Record new movie from poweron
3) Stop the movie
4) Try to load a non-movie savestate
And then it crashes. Is that correct?
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
BrotherMojo wrote:
Also, I know that in DirectX, there are ways to access the actual mouse X/Y velocities that Windows later interprets into changes in mouse cursor position and all that. The WM_ messages seem to all pertain to after that interpretation takes place, since they reference things like the X and Y location on screen where the mouse (has moved to, has clicked, etc.)... I'm not sure if it will be relevant for Dustforce, but does anyone know how those functions could be hooked into?
Right, there are multiple APIs for accessing mouse data. I was thinking only of the windows messaging one, but of course you'd probably have to cover some others as well. So there's windows messaging, dinput, and then raw mouse input...
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
I think the Bizhawk run should be accepted and replace all others. It takes more frames to complete, which clearly shows greater effort from the author, as more frames means more time needs to be spent optimizing each one.
Alternatively, additional versions should be prepared for other emulators (bsnes-SGB, vba v23, vba v24), as it's possible that one of them is longer than the Bizhawk version.