Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
You fixed recording issues and it can record on-screen displays on formats AVI and MKV, but it broke recording in MP4 format.
MP4 is my preferred video format of choice. How could you break recording in my preferred video format of choice? HOW?!
With a plethora of fixes, it shouldn't break a feature that already exists from day one. But how can it break something that was implemented since version 1.0?
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
^ that's needlessly rude.
@PikachuMan: A simple bug report without the whining will do. We do try to avoid regressions, surely someone will patch it up for the next release.
There is a little issue with disassembly on Genesis/68000, instructions SUBI and ADDI are not showing the correct registers
I found in CPUs/68000/Instructions/IntegerMath.cs at lines 192 and 519 that
int reg = (op >> 0) & 3;
should probably be set to
int reg = (op >> 0) & 7;
as it is on the other 2 functions (lines 135 & 465).
The bug can be reproduced on "Tintin Au Tibet (E) (M6) [!]" using the following lua commands :
emu.disassemble(0x135C88)
emu.disassemble(0x135C94)
emu.disassemble(0x12D1EE)
(I can submit the bug later in git if needed)
Now I know what's PikachuMan's problem with video dumping.
I was trying to dump video with ffmpeg writer, in the newest release it was updated, so in MP4, it tries to dump with libvo_aacenc, but it isn't a selectable codec anymore in ffmpeg, so I tried to change it to aac but at the first frame recording I notice the change doesn't applies (still uses libvo_aacenc), the only customable format is the custom (obviously), any change to other options doesn't do anything. So for encoding, the only change must be from libvo_aacenc to aac, the others work perfectly.
For MP4 encoding must be -c:a aac -c:v libx264 -f mp4.
PikachuMan, use this in the custom option while this is solved (or not, do it forever from now).
Now I know what's PikachuMan's problem with video dumping.
I was trying to dump video with ffmpeg writer, in the newest release it was updated, so in MP4, it tries to dump with libvo_aacenc, but it isn't a selectable codec anymore in ffmpeg, so I tried to change it to aac but at the first frame recording I notice the change doesn't applies (still uses libvo_aacenc), the only customable format is the custom (obviously), any change to other options doesn't do anything. So for encoding, the only change must be from libvo_aacenc to aac, the others work perfectly.
For MP4 encoding must be -c:a aac -c:v libx264 -f mp4.
PikachuMan, use this in the custom option while this is solved (or not, do it forever from now).
Fixed; all three codec presets that were using libvo_aac now use aac. If the UI is allowing you to customize the non-custom presets (or type something in there to make it look like you're doing that, then that's a different bug.
Now I know what's PikachuMan's problem with video dumping.
I was trying to dump video with ffmpeg writer, in the newest release it was updated, so in MP4, it tries to dump with libvo_aacenc, but it isn't a selectable codec anymore in ffmpeg, so I tried to change it to aac but at the first frame recording I notice the change doesn't applies (still uses libvo_aacenc), the only customable format is the custom (obviously), any change to other options doesn't do anything. So for encoding, the only change must be from libvo_aacenc to aac, the others work perfectly.
For MP4 encoding must be -c:a aac -c:v libx264 -f mp4.
PikachuMan, use this in the custom option while this is solved (or not, do it forever from now).
Fixed; all three codec presets that were using libvo_aac now use aac. If the UI is allowing you to customize the non-custom presets (or type something in there to make it look like you're doing that, then that's a different bug.
The proper solution would be to remember them all, and restoring defaults on request. But I didn't feel it was necessary. Edit the internal ones to experiment, use custom to remember the final command. Making them not editable will make experimenting way more complicated.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Save movie working data on disk instead of RAM may be a bit unstable. 2.3.1 broke MP4 recording. Many bugs have been fixed, but we haven't figured out the "not responding" issue yet.
So with the latest updates to GlideN64, Indiana Jones and the Infernal Machine is (mostly) working. However, it has a nasty crash bug that happens whenever the game tries to play any voice clips.
My assumption is due to the compression they use for the voice samples or something?? Regardless, if that could be looked into that'd be great.
effort on the first draft means less effort on any draft thereafter
- some loser
So with the latest updates to GlideN64, Indiana Jones and the Infernal Machine is (mostly) working. However, it has a nasty crash bug that happens whenever the game tries to play any voice clips.
My assumption is due to the compression they use for the voice samples or something?? Regardless, if that could be looked into that'd be great.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
I don't know if this is the case with other cores (I didn't have time to test), but with Atari7800hawk core (last dev version), for me it's impossible to make a video rendering by resizing it, I tested with most codecs, by not resizing the video at the output, no worries, the video is good, but by resizing, only the sound is ok, the image is not, there's just a black screen.
I don't know if this is the case with other cores (I didn't have time to test), but with Atari7800hawk core (last dev version), for me it's impossible to make a video rendering by resizing it, I tested with most codecs, by not resizing the video at the output, no worries, the video is good, but by resizing, only the sound is ok, the image is not, there's just a black screen.
woah that's weird. After a cursory glance I don't see any reason why this should be happening. I'll look into it.
EDIT: Seems to be broken in "Allow alpha to matter in screenshots. " here (BitmapBuffer.cs):
public void DiscardAlpha()
{
// HasAlpha = false;
}
The commented out code breaks scaled video capture here (MainForm.cs):
bbin.DiscardAlpha();
var bmpout = new Bitmap(_avwriterResizew, _avwriterResizeh, PixelFormat.Format32bppArgb);
bmpin = bbin.ToSysdrawingBitmap();
That's definitely the cause. not sure what side effects are are uncommenting out that.
EDIT: fixed in master
Saving cheats with comparison is still buggy
For example I insert a cheat that's 2-byte and entered either signed unsigned. I set a value of 16934 with a compare of less than 8430. I go to save, it takes all signed, unsigned, and binary and converts to hex. It takes the value of 16934 and displays it as a hex value of 4226. It then take the compare of 8430 and displays it as a hex value of 8430 instead of the actual value of 20EE. Which results the compare of 8430 in unsigned to turn into a bigger number.
If you try to save a compare of 100 or greater in 1-byte, 10000 or greater in 2-byte, or a compare of 100000000 or greater in 4-byte. You go to save it, it gets its information wrong as 100 is supposed to display as 64 in hex, not 00 in hex. 255 unsigned = FF in hex, not 55 in hex. All it's doing is taking the unsigned compare and using a modulo operation and converting to text then converting to hex. It's inconsistent as the unsigned value displays as hex upon saving.
Joined: 10/18/2017
Posts: 161
Location: San Francisco
On the first page it said,
System.Exception: Initialization of Direct3d 9 Display Method failed; falling back to GDI+ ---> System.BadImageFormatException: Could not load file or assembly 'SlimDX, Version=4.0.13.43, Culture=neutral, PublicKeyToken=null' or one of its dependencies. An attempt was made to load a program with an incorrect format. ---> System.BadImageFormatException: Could not load file or assembly 'SlimDX, Version=4.0.13.43, Culture=neutral, PublicKeyToken=null'. This assembly was compiled for a different processor.
at System.Reflection.RuntimeAssembly.nLoadFile(String path, Evidence evidence)
at System.Reflection.Assembly.LoadFile(String path)
at BizHawk.Client.EmuHawk.Program.CurrentDomain_AssemblyResolve(Object sender, ResolveEventArgs args)
at System.AppDomain.OnAssemblyResolveEvent(RuntimeAssembly assembly, String assemblyFullName)
--- End of inner exception stack trace ---
at BizHawk.Bizware.BizwareGL.Drivers.SlimDX.IGL_SlimDX9..ctor()
at BizHawk.Client.EmuHawk.Program.SubMain(String[] args)
--- End of inner exception stack trace ---
Then on the second page it said,
System.BadImageFormatException: Could not load file or assembly 'SlimDX, Version=4.0.13.43, Culture=neutral, PublicKeyToken=null'. This assembly was compiled for a different processor.
at BizHawk.Client.EmuHawk.KeyInput.Initialize()
at BizHawk.Client.EmuHawk.Input.Initialize()
at BizHawk.Client.EmuHawk.MainForm..ctor(String[] args)
at BizHawk.Client.EmuHawk.Program.SubMain(String[] args)
And then it said "BizHawk stopped working."
I also tried to install BizHawk 2.3.1, but it gives the same message.
Here is what happened to the cause:
The Direct3d app didn't open in the prereqs app, and started to delete files referred to Direct3d. It holds the same message, that I can't get access.
Planned runs:
Marble Madness (Arcade, Genesis J, GG/SMS)
Proposed:
Ecco the Dolphin (Genesis, GG/SMS, CD: regular, camera freeze)
Ecco: The Tides of Time (Genesis, GG/SMS, CD; normal mode)
Mario Kart DS (all cups, all missions)
In progress: Grand Poo World 3 (all exits hard mode)
Not sure if this is the place to ask, but somthing that has been bugging me for a very long time is whenever I attempt to select "avi writer" in any bizhawk 2.0 version, the emulator just crashes as soon as I select "ok".
I have downloaded the codecs many many times with no change at all. I have no idea how this can be fixed and it sucks because I have to rely on an uncompressed avi writer if I ever want to make encodes for my movies.
[14:15] <feos> WinDOES what DOSn't
12:33:44 PM <Mothrayas> "I got an oof with my game!"
Mothrayas Today at 12:22: <Colin> thank you for supporting noble causes such as my feet
MemoryTAS Today at 11:55 AM: you wouldn't know beauty if it slapped you in the face with a giant fish
[Today at 4:51 PM] Mothrayas: although if you like your own tweets that's the online equivalent of sniffing your own farts and probably tells a lot about you as a person
MemoryTAS Today at 7:01 PM: But I exert big staff energy honestly lol
Samsara Today at 1:20 PM: wouldn't ACE in a real life TAS just stand for Actually Cease Existing
I'm not sure if it's just me doing something wrong, but I'm having an issue where saving is actually impossible on FDS Zelda 1. It works fine on Metroid and Zelda 2, so it's not like FDS games can't save at all or anything like that.
It doesn't matter what I do; as soon as the emulation is stopped, save data is gone. If I do a Hard Reset instead, the game will remember the save data still in memory, but that doesn't really help anything because it'll still be lost once the emulation actually stops.
A difference I've noticed between those games that might be relevant, is that Metroid and Zelda 2 ask you to swap back to disc Side A when you save, while Zelda 1 always stays on Side B past the title screen. Maybe BizHawk has trouble with games that save onto Side B or something, but I don't know, I'm not an expert, and I don't know which other games function that way to try that out.
There are workarounds for sure, for example save states work, and the cart version also works, but it'd be a shame to have to rely on save states when regular saving exists, and FDS has that sweet sweet FDS audio that the cart version doesn't have.
I'll probably just end up sticking to the cart version, but I wanted to bring it up still just in case there's a real issue, so it at least has a chance of getting fixed for those who may care.
Also, this is in BizHawk 2.3.1; I also tried almost every version all the way back to 2.0 and it doesn't work on any of them either. I'm not sure how much I want to go through so many 1.x versions though, so I didn't try any of those.
This is for both v1.0 and v1.1 disks, CRC32 1F22CCB1 and 8F2202BF as per No-Intro.
I stumbled across an issue in BizHawk (2.3.1). Whenever I use 'gui.drawPolygon' I have to leave both the line and background colors null in order to get the shape to even appear on screen. Whenever I attempt to draw any other shape, both color parameters are accepted without issue. I can use 'gui.defaultBackground' and 'gui.defaultForeground' to successfully set the color for a polygon as a work-around, at the moment.
Am I mucking something up or is this just a bug?
local poly_square_a = { {5,5},{5,10},{10,10},{10,5} }
local poly_square_b = { {5,15},{5,20},{10,20},{10,15} }
gui.defaultBackground(0xFFA55900)
gui.defaultForeground(0xFFA55900)
while true do
-- Shape Will Appear Using Defaults
gui.drawPolygon(poly_square_a)
-- Shape Will Not Appear
gui.drawPolygon(poly_square_b, 0xFF086110, 0xFF005908)
-- Shape Will Appear
gui.drawBox(5, 25, 10, 30, 0xFF524131, 0xFF312821)
-- Shape Will Appear
gui.drawEllipse(5, 35, 5, 5, 0xFF6B0294, 0xFFDED3EF)
emu.frameadvance()
end
