Posts for Danfun64

1 2
Posted: 1/18/2022 10:46 PM
(Edited: 6/4/2022 4:52 PM)
Quote
Danfun64
He/Him
Experienced Forum User
Joined: 7/25/2007
Posts: 50
Multiple guides, most notably this and this. I compiled using MSYS2's 32-bit MinGW mode. After issuing a "pacman -Syuu" command to make sure everything is up to date, I ran the command "pacman -Sy mingw-w64-{i686,x86_64}-ntldd-git mingw-w64-{i686,x86_64}-toolchain mingw-w64-{i686,x86_64}-SDL2 mingw-w64-{i686,x86_64}-openal mingw-w64-{i686,x86_64}-wxWidgets mingw-w64-{i686,x86_64}-libpcap mingw-w64-{i686,x86_64}-cmake mingw-w64-{i686,x86_64}-libslirp" to get everything it needed. Then, after cloning the repository with git, I ran the commands in the forum post linked as the second guide (though running "./configure --enable-networking --enable-release-build" and "make" seems to work just as well. I copied the specific folders and files from the root directory of the pcem folder to another folder, and then copied the pcem.exe from the src folder into the root of the second folder. After making a copy of the second directory, I then opened the pcem.exe in the MSYS2 MinGW 32-bit shell and checked out every dependency using Process Explorer, and copied over all 22 dlls to the root of the copied directory. Then I zipped it up and uploaded it. Although apparently, the latest version of PCem's upstream has a cmake solution that the TASVideos fork lacks.
Posted: 1/18/2022 5:02 PM
(Edited: 6/4/2022 4:52 PM)
Quote
Danfun64
He/Him
Experienced Forum User
Joined: 7/25/2007
Posts: 50
Made a Win32 build of 17+st-1. https://drive.google.com/file/d/13nnYbIOveKysHlve56aXf7snfHAVqRII/view?usp=sharing
Posted: 1/18/2022 5:53 AM
(Edited: 6/4/2022 4:52 PM)
Quote
Danfun64
He/Him
Experienced Forum User
Joined: 7/25/2007
Posts: 50
While I understand the simplicity in having three configurations, I can't help but feel that having an 8088 configuration (for the long list of early 80s games that predate the 386) and a 486 configuration (for games that run too slow on a 386 but too fast on a Pentium) would be very helpful. Is there any interest in creating official configurations for these microprocessors to go alongside the other three?
Posted: 8/2/2018 7:27 PM
Post subject: Re: Updated important information for TASing with Dolphin
Quote
Danfun64
He/Him
Experienced Forum User
Joined: 7/25/2007
Posts: 50
Fog wrote:
Bounding Box: Newer versions of Dolphin use hardware optimized implementations of bounding box, which produce different results at different resolutions and graphical settings, as well as being tied to specific hardware. To avoid this while using the latest versions, use the Direct3D backend with Microsoft Basic Renderer (as to be hardware agnostic), or use version 4.0-5124 or older to use the older software based bounding box solution.
It's been a couple years since the OP was made. Has there been any change in this front? Has anybody asked the Dolphin team to restore the software based bounding box solution? Reason that I ask is that my hardware is too slow to run Dolphin full speed with Microsoft Basic Renderer. Even using Intel graphics is a lot faster (my laptop uses i5-7300HQ and Nvidia Geforce 1050)
Posted: 7/24/2018 1:17 AM
Quote
Danfun64
He/Him
Experienced Forum User
Joined: 7/25/2007
Posts: 50
I compiled the most recent version of the Sonic Gens Hud as of this writing (here). To my surprise, there hasn't been *any* change in this since Jan 31, 2017... ...perhaps the next version is a port to Bizhawk/Genesis Plus GX. THAT BEING SAID, some things are broken in this build (hiding original hud and skipping boring stuff), so general use is not recommended.
Posted: 4/19/2018 4:49 PM
Quote
Danfun64
He/Him
Experienced Forum User
Joined: 7/25/2007
Posts: 50
IMO, the E-Reader levels should be done using the VC rom that has all 38 baked in and doesn't need a dirty SRAM. I'm pretty sure there's a patch somewhere to convert a normal GBA rom to the VC one, but I can't seem to find it ATM. edit: Kinda Sorta ninja'd by Fortranm.
Posted: 12/18/2017 8:20 PM
Quote
Danfun64
He/Him
Experienced Forum User
Joined: 7/25/2007
Posts: 50
WST wrote:
I’m sick and tired from explaining why Bizhawk is absolutely useless for Sonic TAS. It is just impossible, banning Gens will not make us move to Bizhawk, the reasons are fundamental.
...that wasn't an explanation. Why is it useless? Are you saying that the LUA scripts and stuff can't be ported to Bizhawk? Should a new TASing Genesis emulator be made to cover up Bizhawk's deficiencies ala LSNES?
Posted: 12/14/2017 11:53 PM
Quote
Danfun64
He/Him
Experienced Forum User
Joined: 7/25/2007
Posts: 50
Umm... my question was never really answered...
Posted: 11/23/2017 7:09 PM
Quote
Danfun64
He/Him
Experienced Forum User
Joined: 7/25/2007
Posts: 50
feos wrote:
We use internal replay format for Doom, since it can be tested against original Doom on a PC. And such runs would still be obsoleted by fully emulated DOS, since it won't have the limitations and downsides of the internal replay system.
How exactly would fully emulating DOS and running doom in that benefit Doom TASing compared to the internal replay system?
Posted: 11/22/2017 8:04 PM
Quote
Danfun64
He/Him
Experienced Forum User
Joined: 7/25/2007
Posts: 50
Amaraticando wrote:
Ilari wanted to support subframe input, subframe resets, hard resets, etc, stuff that is very hard to implement in a multi-system emulator like BizHawk, for some technical reason.
So...that stuff isn't in BizHawks SNES and GB/SGB/GBC cores now?
Posted: 11/22/2017 5:56 AM
Quote
Danfun64
He/Him
Experienced Forum User
Joined: 7/25/2007
Posts: 50
I guess I'm confused because BizHawk is apparently supposed to be the major all-in-one TASing emulator, yet you have LSNES which uses the same emulators as the former (different versions and lack of Same Boy for SGB aside)
Posted: 11/20/2017 7:38 PM
Quote
Danfun64
He/Him
Experienced Forum User
Joined: 7/25/2007
Posts: 50
How long is LSNES going to be around before it's depreciated, if that's the plan? Also, anybody have any compiled git builds of LSNES? Not that I plan on doing so, but are git builds considered acceptable for submissions?
Posted: 11/19/2017 9:03 PM
Post subject: Bizhawk vs LSNES ...which is better for SNES, GB, GBC, SGB ?
Quote
Danfun64
He/Him
Experienced Forum User
Joined: 7/25/2007
Posts: 50
I'm kind of confused by the situation for BizHawk and LSNES. Is one preferred over the other for SNES, GB, GBC, and/or SGB games? BizHawk apparently uses BSNES v87 and Gambatte SVN r344 while lsnes rr2-B23 (most recent compiled build) uses BSNES v85 and Gambatte r527? Is that correct? What about the trunk for lsnes? edit: Also, why does SRAM not seem to work with LSNES?
Posted: 7/2/2017 3:41 AM
Quote
Danfun64
He/Him
Experienced Forum User
Joined: 7/25/2007
Posts: 50
Question. Why was the BSNES Performance Profile abandoned in favor of SNES9x 1.54?
Posted: 8/9/2015 5:52 AM
Quote
Danfun64
He/Him
Experienced Forum User
Joined: 7/25/2007
Posts: 50
Well, I tried :P ATM I can't think of any more "curveballs" to "throw" at you, at least what directly relates to this specific thread.
Posted: 8/7/2015 8:22 PM
Quote
Danfun64
He/Him
Experienced Forum User
Joined: 7/25/2007
Posts: 50
As unlikely as this is, it would be nice to have the mono branch be the *only* branch, rewriting whatever code is necessary to maximize portability. Then again, I probably would have suggested that after everything was made mono-friendly that all the C# bits be converted or rewritten to C, C++ or Java because of .net patent issues, as well as to remove/replace all non-free code (which at least means getting rid of genesis plus gx entirely), both of which are even less likely...
Posted: 7/21/2015 2:41 AM
Quote
Danfun64
He/Him
Experienced Forum User
Joined: 7/25/2007
Posts: 50
Good Idea! Now where can we borrow a TARDIS...
Posted: 7/19/2015 3:13 AM
Quote
Danfun64
He/Him
Experienced Forum User
Joined: 7/25/2007
Posts: 50
I'm not sure this is the appropriate place to put this, but I couldn't think of anything better ATM. Yes, I was the one who uploaded this video. Link to video Moderator edit: Moved to the appropriate place. — moozooh
Posted: 7/17/2015 6:34 AM
Quote
Danfun64
He/Him
Experienced Forum User
Joined: 7/25/2007
Posts: 50
Well then, looks like Bizhawk will need the mupen64plus core updated, along with implementing the LLE plugins I suggested...
Posted: 7/16/2015 10:12 PM
Quote
Danfun64
He/Him
Experienced Forum User
Joined: 7/25/2007
Posts: 50
I've heard that the z64 video plugin requires one of the two aforementioned low level rsp plugins to work.
Posted: 7/16/2015 9:38 PM
(Edited: 7/16/2015 9:48 PM)
Post subject: Is using low level mupen64plus plugins feasable?
Quote
Danfun64
He/Him
Experienced Forum User
Joined: 7/25/2007
Posts: 50
While it will likely be years before Cen64 is complete enough to be implemented in Bizhawk, what about the low level plugins listed on the mupen64plus website? Would the accuracy gain in porting mupen64plus-video-z64, mupen64plus-rsp-cxd4 and maybe mupen64plus-rsp-z64 to Bizhawk be worth it? edit: Fixed typo. edit 2: added mupen64plus-rsp-z64 to list.
Posted: 7/16/2015 8:57 PM
Quote
Danfun64
He/Him
Experienced Forum User
Joined: 7/25/2007
Posts: 50
Huh? I was under the impression that psx support on bizhawk was cancelled. Or is it just psxhawk?
Posted: 7/14/2015 4:26 PM
Quote
Danfun64
He/Him
Experienced Forum User
Joined: 7/25/2007
Posts: 50
I take it that Anti-DS Mupen won't be accepted either xD. While that may sound obvious, it's still on the "Accepted but not preferred" list. On a related note, Doom demos are still in "Experimental", despite being officially supported now.
Posted: 7/14/2015 4:21 PM
Quote
Danfun64
He/Him
Experienced Forum User
Joined: 7/25/2007
Posts: 50
I know that these scripts will probably have to be rewritten in order to work on bizhawk, but before that is done, can you add Sonic 2 Delta compatibility?
Posted: 5/31/2015 11:18 AM
Quote
Danfun64
He/Him
Experienced Forum User
Joined: 7/25/2007
Posts: 50
I'd ask if you'd eventually support linkup in the vba next core, but I'm pretty sure what you are going to say is "we won't. we might put it in the mgba core (if necessary)...once it's considered finished enough to implement..." edit: What about the nes saveram? Does that have a 16 byte header too?
1 2