Site Admin, Skilled player (1251)
Joined: 4/17/2010
Posts: 11475
Location: Lake Char­gogg­a­gogg­man­chaugg­a­gogg­chau­bun­a­gung­a­maugg
As I said, until I minimize BH, it occupies so much memory, and if I close BH any method before minimizing, my system will crash as well (BSoD). If it really lets go memory after it stops needing it, not forcing me to minimize to quit successfully, it'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.
Editor, Emulator Coder
Joined: 8/7/2008
Posts: 1156
.net chooses when to hold onto memory and when to release it, not us. and holding onto memory doesnt make a computer BSOD. I suggest you switch to the gdi display method in bizhawk or upgrade or downgrade your video drivers.
Lord_Tom
He/Him
Expert player (3143)
Joined: 5/25/2007
Posts: 399
Location: New England
Hopefully this is the right thread for this sort of problem, but this is what I get when I try to play Pitfall II - Lost Caverns (1984) (Activision) [!].a26 on BZ 1.4.0: :( I read this game cartidge has some custom features which I'm assuming aren't emulated correctly (or at all), though I'd love to hear it if there's a way to play/tas this title.[/img]
Joined: 3/11/2012
Posts: 149
Location: WI
Lord Tom wrote:
Hopefully this is the right thread for this sort of problem, but this is what I get when I try to play Pitfall II - Lost Caverns (1984) (Activision) [!].a26 on BZ 1.4.0:
I'm surprised you got that far. The last time I tried it, it told me the mapper wasn't supported yet and wouldn't let me run it. The Colecovision version works fine, if that's worth anything to you.
Lord_Tom
He/Him
Expert player (3143)
Joined: 5/25/2007
Posts: 399
Location: New England
Thanks, Sappharad, I'll give that one a try.
Joined: 11/15/2012
Posts: 67
Location: Upstate, NY
I found a weird glitch that is very subtle for the SNES section of Bizhawk. It shows one extra pixel at the bottom of the screen and one pixel less at the top of the screen. This is something most people would not notice, but when measuring 16 x 16 tiles for maps I see that this is an issue. On another note: Also the size is 224 x 256. The NES has the 224 x 256, but you can also display the 240 x 256 to show more graphics from most games. Is this something that can/should also be available for the SNES? The above image shows the Bizhawk window in Magenta and the full graphics that are being missed. 1 pixel at the top and 15 pixels at the bottom.
creaothceann
He/Him
Editor
Joined: 4/7/2005
Posts: 1874
Location: Germany
Because sprites are loaded during (or at the end of) the previous line, there would be no sprites on the very first line. The SNES "fixes" that by not rendering the first line of backgrounds either. Games either ignore that completely, or compensate by setting the vertical scrolling registers so that the first line becomes visible again. Maybe you could do something with LUA by intercepting and modifying writes to these registers, but that's just a guess.
Editor, Emulator Coder, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
The NES is 256x240. 256x224 is a convenience crop that emulators do, so it's easy to just not do that. The SNES, unless it's set to the 256x239 mode, is actually 256x224. There are no extra hidden lines to show. "Extrapolating" what the extra lines should be sounds like a giant mess; better to just use the graphics debugger or similar tool if that's what you want. As far as the one line missing/one line extra bug, could you give some easily reproducible place in an easily obtainable game where I can see this? It doesn't sound like there's any bug at all, but I can check against lsnes and bsnes just to be sure.
Joined: 11/15/2012
Posts: 67
Location: Upstate, NY
The title screen of Super Mario World is a great place to view the missing pixel at the top and the extra one at the bottom. You will see the wooden blocks around the boarder of the screen. The top blocks are missing the dark color line around the top part of the wooden blocks (The missing line). And there is a solid 1 pixel solid line at the bottom (the extra line). This extra line at the bottom does start to show the 1st of the missing 16 pixels that would add up to the 240. That extra line at the bottom will sometimes have content in it depending on the game and location of the game you are in. If you take a screen shot and measure of the height of each wooden block that makes up the boarder around the title screen, you will see they are all 16 pixels tall except for the top ones that are only 15 pixels tall due to the missing row of pixels.
Editor, Expert player (2073)
Joined: 6/15/2005
Posts: 3282
As of BizHawk 1.4.0, when a movie is loaded in the Play Movie box and its length is listed in minutes:seconds:hundredths_of_seconds, if the seconds portion is less than 10, it only appears as one digit, as shown in the image below. This isn't a particularly serious thing. Just reporting it, that's all.
Skilled player (1827)
Joined: 4/20/2005
Posts: 2161
Location: Norrköping, Sweden
Hi, I have a question about version 1.4.0: Although gui.text displays the text on the same frame the values change, gui.drawBox seems to be lagged 1 frame. So if I have a lua script that draws a box around my position, it will always be 1 frame behind. In FCEUX this could be solved with gui.register. Is there any way to solve this in BizHawk 1.4.0? I've tried commands like emu.on_snoop, but I couldn't get it to work.
Masterjun
He/Him
Site Developer, Skilled player (1987)
Joined: 10/12/2010
Posts: 1185
Location: Germany
Randil wrote:
Although gui.text displays the text on the same frame the values change, gui.drawBox seems to be lagged 1 frame. So if I have a lua script that draws a box around my position, it will always be 1 frame behind.
It's not the problem with gui.draw<somthing>, it's a problem with gui.text that is 1 frame too early. I asked about that in IRC some time ago and they considered creating something like gui.drawText to make them both sync.
Warning: Might glitch to credits I will finish this ACE soon as possible (or will I?)
Skilled player (1827)
Joined: 4/20/2005
Posts: 2161
Location: Norrköping, Sweden
But gui.text updates on the same frame as RAM watch, RAM search and Hex editor, so in that case all the built in tools are also 1 frame early. For example, when moving right, if I display my X position in lua with gui.text, it will always have the same value as the value in RAM watch. So in my eyes gui.text works as it should, but maybe I'm missing something? gui.draw on the other hand updates 1 frame later than the built in tools (if I ask it to draw a pixel on my position, it will update 1 frame later than the built in tools)
Joined: 11/15/2012
Posts: 67
Location: Upstate, NY
I don't know if this is connected or not. But I noticed when I record an uncompressed .avi file to capture a long frame animated sprite it starts recoding 1 frame after I tell it to start recording. I know in FCEUX it would start recording on the frame I was on.
Joined: 2/18/2010
Posts: 156
Location: home
I was playing through Mega Man X2 and stumbled across this: http://gyazo.com/fcdb03f23a89ca98903da20bcc38cddc I'm aware that there were bugs in the Cx4 emulation in snes9x (like when Serges turns into Crystal Snail's shell in midair in Agwawaf's Tri-game TAS), but this seems to be different. Not only are the graphics not displaying correctly, but those green energy bubbles at the top have been there since the first time he jumped during the fight, and if it helps any, they still deal damage on contact to them. I was playing using BizHawk 1.4.0 downloaded fresh from the google code page and I do have the Cx4.rom file placed in the firmware folder. (I also have no prior knowledge if this bug still exists or existed in the version of bsnes used for the SNESHawk core)
My user name is rather long, feel free to call me by htwt or tape.
Editor, Emulator Coder
Joined: 8/7/2008
Posts: 1156
can you get this to happen if you play the game from a fresh boot with no savestates and rewind disabled? That will tell whether it is a savestate bug (more likely than a core emulation bug)
Joined: 2/18/2010
Posts: 156
Location: home
zeromus wrote:
can you get this to happen if you play the game from a fresh boot with no savestates and rewind disabled? That will tell whether it is a savestate bug (more likely than a core emulation bug)
I'll get to work on doing so as soon as I can, which is most likely sometime tomorrow. Alright, I just finished playing through up to Serges from a fresh boot without savestates and with rewind turned off and the bug that I reported did not occur. I recorded this to a .bkm for reference purposes if you were interested, but I probably won't upload it if you don't need it. I also played back the .bkm I was recording when I found this, and the bug does not occur during that Serges fight either.
My user name is rather long, feel free to call me by htwt or tape.
Editor, Emulator Coder
Joined: 8/7/2008
Posts: 1156
sounds pretty confidently like a bug in the cx4's savestate. thats never a surprise with the bsnes core. I dont know how long it takes you to do that much playing through the game, but if you could make it that far (fast forwarding the bkm) and then spam save/loadstate a lot when the glitchy art is on screen (or just before that screen loads) and make it actually glitch, then that would seal the deal. that's what I'll be doing first to debug it anyway. can you post the bkm?
Joined: 2/18/2010
Posts: 156
Location: home
zeromus wrote:
sounds pretty confidently like a bug in the cx4's savestate. thats never a surprise with the bsnes core. I dont know how long it takes you to do that much playing through the game, but if you could make it that far (fast forwarding the bkm) and then spam save/loadstate a lot when the glitchy art is on screen (or just before that screen loads) and make it actually glitch, then that would seal the deal. that's what I'll be doing first to debug it anyway. can you post the bkm?
It took me about 20 minutes or so last night to get to Serges if I pick the stage that he's in as soon as I can fight the X-hunters. Here's the file that I recorded last night without savestateing and with rewind turned off. bkm I've also uploaded the file I was working on when I stumbled upon this, which gets to the same point in about half the time. bkm EDIT: I played back the first bkm and saved and loaded states in the Serges battle, and sure enough it glitched just like it did when I found the bug.
My user name is rather long, feel free to call me by htwt or tape.
adelikat
He/Him
Emulator Coder, Site Developer, Site Owner, Expert player (3572)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
What you see is my attempt to implement that mapper. As you can see, I have a ways to go! It is by far the most complicated atari board including custom sound chips.
It's hard to look this good. My TAS projects
Player (16)
Joined: 7/3/2012
Posts: 35
When I right-click on an address in the RAM Watch and select Poke, I expect to see the address already in the box, rather than having to enter it manually. Could someone fix this?
Skilled player (1738)
Joined: 9/17/2009
Posts: 4980
Location: ̶C̶a̶n̶a̶d̶a̶ "Kanatah"
How do you turn off autofire in 1.4.1 in gbc mode? I disabled autofire but every button keeps autofiring. Edit: I'm an idiot. I made "n" frame advance without knowing it triggers autofire. I got another bug for the GBx modes. The game telefang has a real-time clock i t depends on for stuff. However, unlike in VBA and Desmume where the clock will stop advancing when paused during movie recording mode, the clock runs anyway, making the time inconsistent to the previous frame, expecially after you afk for like 5 minutes as a break, and come back and fine the next frame's ingame timer is 5 minutes ahead.
Post subject: Two different autofire methods in BizHawk...
Moderator, Senior Ambassador, Experienced player (907)
Joined: 9/14/2008
Posts: 1014
jlun2 wrote:
Edit: I'm an idiot. I made "n" frame advance without knowing it triggers autofire.
I was messing around in Atari 7800 with autofire and I had the opposite problem - in both BizHawk 1.4.0 and 1.4.1 I couldn't seem to get the autofire controller field to do anything. Then I discovered that setting a specific button to autofire with a particular key does not work, although setting the autofire hotkey *does* work. This may not be of use but I figured I'd throw that out there in case someone else made the same mistake dealing with rapid fire / rapidfire / auto fire / autofire / whatever other search keyword I should have included there. :) A.C. ******
I was laid off in May 2023 and became too ill to work this year and could use support via Patreon or onetime donations as work on TASBot Re: and TASBot HD is stalled. I'm dwangoAC, TASVideos Senior Ambassador and BDFL of the TASBot community; when healthy, I post TAS content on YouTube.com/dwangoAC based on livestreams from Twitch.tv/dwangoAC.
Active player (426)
Joined: 3/21/2011
Posts: 127
Location: Virginia (United States)
Bizhawk seems to register lag in Sutte Hakkun weirdly (not sure if it happens in other games). For instance, it starts registering lag on both the title screen and in levels, but when playing frame by frame, everything continues to move even during the "lag frames" and input is still registered. In addition, lsnes doesn't count any lag frames in those places.
YouTube Channel - Twitter Current projects: Sutte Hakkun, Hyper VI, RTDL, own hacking projects
BigBoct
He/Him
Editor, Former player
Joined: 8/9/2007
Posts: 1692
Location: Tiffin/Republic, OH
I was using Bizhawk something like 9-10 hours ago, trying to get the SNES core running at a decent speed. I just had occasion to open the Task Manager, and the libsneshawk-comptibility-32 process was still going. EDIT: I may have closed Bizhawk by closing the console window. I know I did that at one point, but I don't remember if I did it the most recent time.
Previous Name: boct1584