Posts for zeromus

1 2
7 8 9
45 46
Posted: 4/16/2016 12:51 AM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
If you compiled the latest git code, it isn't from december 2015. its from april 2016 and contains a bug because there's 100000000000000 places dates and versions are written and it's impossible to keep them all up to date. gui.text is different between screenshot and av dump because gui.text gets cleared once a frame, at some point, and screenshots and av dumping each occur at different points, and if those points are in an unfortunate order, there's a mismatch. Don't make the mistake of trying to _understand_ this. It's all overly complicated and _broken_. There's no sense to it right now. I think the GB GPU viewer crash is related to your using a non-english operating system, which is always a mistake unless you just enjoy having buggy software (now I see why it happened for a russian guy too). I committed a fix for it, but I couldn't test it, since I don't enjoy having my OS show me WELKOMMEN DAS WINDOWS and then crash whenever I run anything.
Posted: 4/15/2016 9:39 PM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
I've explained to you why gui.text is different a billion times. It just is different, and will always be. It creates a label through the same system that the FPS and other stuff uses. If you don't like that, there's other functions for drawing text. If you dont like those other functions for drawing text, then write a bug about why they're deficient.
Posted: 4/15/2016 5:27 AM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
I don't. What core, and if it's snes, what bsnes profile?
Posted: 4/14/2016 6:58 PM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
delete your ini file. I thought that was only happening when you used an old ini file on a new version
Posted: 4/13/2016 8:47 PM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
i doubt this scenario works in bizhawk. you can't interrupt the emulation of a frame. We're currently discussing ideas for how to improve this in the future.
Posted: 4/11/2016 5:23 PM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
If youre reverse engineering and hacking a game, you're going to be pushing saturn waaaaaay harder than bizhawk can handle. And I can't believe bizhawk has added any features to the saturn core.. except I guess for the standard hex editor and stuff. If there's not saturn emulator with even that debugging capability, then we're in a pretty poor condition. Anyway excepting that, Bizhawk is not your best choice here except maybe for casual testing, which closely approximates a casual playthrough.
Posted: 4/10/2016 8:05 AM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
problems: the gif writer uses a standard palette. This makes virtually every video, even of 4 color GB games, be noisy and dithered and that bloats the size substantially due to the difficulty of compressing noise. Moreover, each frame comes with it's own palette--the same one copied, over and over. So the gifs we generate are basically goofy trash. Don't expect much. solutions: i just committed code to produce a palette optimized for each frame. The results look way better are half-sized previous, or better. It still may not be as small as you expect future work: option in gif writer to compute a global palette when the gif is ended (will save 5KB/sec with default settings best case; maybe worse for 32bit consoles). This could be done fairly easily in principle by concatenating all the frames, quantizing it as one image, and then dicing it back up--but the involvement of System.Drawing.Bitmap will mean theres a small upper limit to the number of frames that can be done this way. Therefore the quantizing code needs some reworking to skip the system.drawing.bitmaps. Should be a 2-4 hour job.
Posted: 4/6/2016 9:40 AM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
you didnt change the x64 build target to x86
Posted: 4/5/2016 8:05 AM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
It's already been fixed, if you can get a development build
Posted: 4/4/2016 8:19 PM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
build a size 4 fifo in lua; capture the value each frame and enqueue it. contents of fifo are always last 4 frames.
Posted: 4/4/2016 8:16 PM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
bizhawk won't support more than 1 xinput device until the next release
Posted: 4/3/2016 8:54 PM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
My guess would be theyre related to the current scroll values, and don't exist (not spawned in) until the map is scrolled to the right "section", but if youre even having this problem, it would mean theyre existing way too early?
Posted: 4/1/2016 8:21 PM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
did you try moving a tastudio project between bizhawk versions?
Posted: 3/31/2016 11:13 PM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
you could also... uhhhhh.. make your lua script a string containing the real script, with a line at the end to compile the script and output the error message if any or run it if none. I hate lua but ahhhhh it's cool.
Posted: 3/31/2016 7:12 PM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
https://github.com/TASVideos/BizHawk/issues/607 Ycam + Dy, <-- has comma after it
Posted: 3/30/2016 8:19 PM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
You could use openemu or retroarch
Posted: 3/30/2016 6:52 PM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
To be fair, if you go the mod-an-emulator route, you will have to put some kind of user interface on it. With bizhawk at least you do get some automatic UI. What I'd do is take a look at the bizhawk quicknes core and put your logic entirely in there. like add an api called "do_custom_simulation_logic()". That could run 1000s of frames and take 1000s of savestates before returning. Then bizhawk could display the frame it's on as usual, and you can add visualization in lua. (the work to remove rendering (harder) and audio (easier) would be an additional step)
Posted: 3/30/2016 6:19 PM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
Whatever you say. It isn't very hard. Guess you only need A FEW generations. I told you how to get MANY.
Posted: 3/30/2016 6:11 PM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
bugs happen, bugs get fixed.
Posted: 3/30/2016 6:17 AM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156 
gui.DrawNew("native"); --how to set the rendering surface by defaut.
gui.pixelText(0,20,"hi2u",0xff00ff00)
This depends on window size too.... if you want to render in a way that doesn't depend on window size then why are you using setclientextrapadding? use setgameextrapadding instead.
Posted: 3/29/2016 7:33 AM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
1. the debugger is essentially useless. the breakpoint infrastructure is more effectively used by lua right now 2. that sounds like an RDRAM address. the debugger would be based on system bus. consult a n64 memory map reference.
Posted: 3/28/2016 6:35 PM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
lua is not the fastest way to do anything. you could do more by choosing a game and platform which can be emulated at light speed (nes or gameboy using quicknes or gambatte for instance) and then going back to the original c++ sources and hacking them up. just by getting bizhawk out of the equation you could speed up by 50% at least I would guess. By further hacking the emulator (removing or conditionally bypassing all rendering logic and disabling the sound generation) you could speed up by a few times more. You should be able to run 100x faster than mari/o at least.
Posted: 3/27/2016 9:19 PM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
memorydomain pointers change on hard reset. fixed: https://github.com/TASVideos/BizHawk/commit/776e696e09c34e952fc2a792c939b282cb1a3b55
Posted: 3/24/2016 6:59 PM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
1. omfg that prereq installer is linked to from 1000000000 freaking places 2. OK, but only because we used to. Your reasoning is bad, "every small thing" adds up to Clippy.
Posted: 3/24/2016 8:36 AM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
upgrade or downgrade your video drivers. if that doesnt work, issue --gdi on the commandline once to disable 3d acceleration
1 2
7 8 9
45 46