It is currently Wed Oct 18, 2017 7:00 pm

All times are UTC - 7 hours



Forum rules


Related:



Post new topic Reply to topic  [ 7 posts ] 
Author Message
PostPosted: Sat Jul 22, 2017 11:59 am 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2285
I just tried testing the "supersaw lead" demo on every emulator, and once again BSNES is the only one it works on. It's probably either the interrupts or SPC700 that's doing it. This isn't the first time I had this problem.


Top
 Profile  
 
PostPosted: Sat Jul 22, 2017 2:34 pm 
Offline
User avatar

Joined: Mon Jan 23, 2006 7:47 am
Posts: 70
It's probably because it's cycle accurate. Did you test forks?


psycopathicteen wrote:
every emulator

...


EDIT: The file is 262,143 bytes in size, maybe that one missing byte is throwing things off?


Top
 Profile  
 
PostPosted: Sat Jul 22, 2017 4:09 pm 
Offline

Joined: Wed Apr 01, 2009 12:03 pm
Posts: 13
Location: Langara
creaothceann wrote:
psycopathicteen wrote:
every emulator

...

Popular emulators:
* bsnes v0.87
Other emulators:
* higan v0.94
:shock:


Top
 Profile  
 
PostPosted: Sat Jul 22, 2017 4:10 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2285
I found out it didn't work in higan, because after the initial SPC load, I immediately zeroed $2142 and $2143 and forgot that they are supposed to be where the SPC700 initially jumps to. So I got rid of the stz $2142 and stz $2143 from my code, and modified the spc700 side code so that it expects the jump address instead of #0, and it works for both Higan and ZSNES. All that's left is SNES9x, which in my experience is a piece of crap.


Top
 Profile  
 
PostPosted: Mon Jul 24, 2017 2:50 pm 
Offline
User avatar

Joined: Tue Apr 05, 2016 5:25 pm
Posts: 121
For my own framework I'm shooting for bsnes/higan and snes9x compatibility. People using snes9x in place of bsnes for performance reasons seems to be a fairly common occurrence, so I want to support that configuration. It'd allow more people to be able to run my game and I think that's a good thing.

On the latest bsnes-plus, my system has trouble keeping up when I have the screen flooded with sprites. A couple times I even mistook this as my framework causing slowdown on the SNES system itself. But as it turns out, emulator FPS falls to 50 when all the hardware sprites are being used (though it depends on sprite size). I should probably note that the "performance/compatibility" profile does not seem to have this problem, but this is inadvisable for developer testing.

Personally, I've actually found that snes9x is more tolerant of programming bugs in my codebase. I've had total crash corruption bugs reproduced by bsnes-plus that snes9x is unaffected by (or just crashes more cleanly).

I can see justification for emulation issues outside bsnes/higan for cutting-edge, envelope pushing stuff, but for simpler things like doing a basic SPC upload, emulation issues in semi-proficient emulators that can otherwise handle other games doing the same thing is indicative of underlying issues in your code. Anything that relies unnecessarily on specific timing or other low-level details is going to reduce reliability and code reusability. What if your game has some exceptional circumstance where the system is kept busy for a significant amount of time but you have code that needs to run in a very specific scanline? You are going to miss that time window.

I know there's the drive to push hardware limits, but I think we should also strive for more reliable and robust solutions when we don't need to be doing weird things with the hardware.

Maybe not 100% relevant to the post but those are my two cents I guess.

Edit: Oh yeah, there's also the possibility that it only works on bsnes because that's the only one you test with, since you mentioned it broke on higan. Testing development against a single target when there is intention to support multiple configurations can be deceiving at the very least.

_________________
SNES NTSC 2/1/3 1CHIP | serial number UN318588627


Top
 Profile  
 
PostPosted: Mon Jul 24, 2017 5:36 pm 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1338
So the reason the older bsnes works more often is because it was the best combination of accurate but not stringent.

Register randomization came later on, and it exposes endless amounts of bugs, both in homebrew as well as in real commercial software.


Top
 Profile  
 
PostPosted: Mon Jul 24, 2017 6:54 pm 
Offline
User avatar

Joined: Tue Apr 05, 2016 5:25 pm
Posts: 121
I have no idea how compatibility profiles work, but an interesting idea would be to have compatibility flags, so users could enable/disable potentially breaking features. Or is the implementation between profiles too different to just toggle certain aspects on or off? Additionally, how do the "accuracy" and "compatibility" profiles differ in terms of rendering sprites? Given the amount of work that presumably goes into rendering even a single scanline of the sprite layer, I imagine it could easily become a bottleneck. I might be totally wrong here.

Looking in my game, it seems like there are mainly two things that don't get initialized like they should: the DMA registers, and the fixed color value. That latter one seems to be giving some other homebrew trouble as well. Might as well make the fix in my own codebase at least.

Edit: Looks like the fixed color bug, at least in Neviksti's InitSNES, is that register $2132 is covered in a for loop that zeroes out various registers, but a zero write to this register in fact does nothing. It should be writing $e0 instead.

_________________
SNES NTSC 2/1/3 1CHIP | serial number UN318588627


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 7 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 7 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group