It is currently Thu Dec 14, 2017 11:38 pm

All times are UTC - 7 hours



Forum rules


Related:



Post new topic Reply to topic  [ 171 posts ]  Go to page Previous  1, 2, 3, 4, 5 ... 12  Next
Author Message
PostPosted: Sun Apr 26, 2015 10:08 am 
Offline

Joined: Sat Apr 25, 2015 1:47 pm
Posts: 336
Location: FL
UnDisbeliever wrote:
Thankyou for working on this project. I'm sure I'll spend many hours with it trying to track down a stack smash or incorrect register size in my future SNES Development work.

But I can't get it to work.
I'm using your pre-compiled windows binary on Windows 8.1 and can't get it to start without error.

Try downloading again, sorry about that. I didn't realize that the snesfilter plugin had any additional dependencies (I basically built and included them at the last minute since I wasn't doing anything with them myself, yet), but libgomp-1.dll is included now (and I assume pthreadGC2.dll was a dependency of the versions you had found elsewhere, since my stuff uses libwinpthread-1.dll instead).


Top
 Profile  
 
PostPosted: Sun Apr 26, 2015 10:52 am 
Offline

Joined: Fri Mar 01, 2013 4:46 am
Posts: 251
Also, (sorry for all these questions) is there a reason why the ram values have such a significant lag, when being inserted? I noticed that Geigers also did this, and I see it happening here as well? You can clearly tell this when you know the exact ram address for the controller push bits. I'm using Megaman X as my rom of choice, for using your current debugger, and when I press whichever pushbit I want, it takes nearly a second 1/2 to display. This is for every kind of action within the hex viewer. I didn't know if this was something unavoidable, or if this is a symptom of my Windows 7 OS?

I've already began finding new things within MMX, that I was never able to before, until now! Really cant wait for new revisions! :-) Having a lot of fun with this!


Top
 Profile  
 
PostPosted: Sun Apr 26, 2015 11:24 am 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19346
Location: NE Indiana, USA (NTSC)
Myask wrote:
Revenant wrote:
On-the-fly ROM saving and reloading from the memory editor for quick hacking and testing

This sounds like an open invitation for user error; some extra "safety" features might be in order to help avoid the "Aw crap I just saved over the base/good ROM" headaches. (Sure, the user could make it read-only, but if they already didn't have backups...) actually, that sounds like a simple way to do it: Make a default-on "prevent overwrite" option somewhere in options so it forces one to save a new version (or patch?) each time.

That or an actual version control library. How hard would it be to adapt Git?


Top
 Profile  
 
PostPosted: Sun Apr 26, 2015 12:05 pm 
Offline

Joined: Fri Aug 01, 2014 3:13 pm
Posts: 29
This is gonna be really useful, thanks.


Top
 Profile  
 
PostPosted: Sun Apr 26, 2015 1:11 pm 
Offline

Joined: Thu Feb 07, 2013 1:15 am
Posts: 96
Location: Sweden
Wow, super nice work!

How much work would it be to migrate to Qt 5? Trying to build on OS X and Qt 4 relies on Carbon which is 32-bit only. Trying to target 32-bit only now, let's see if that does the job...

EDIT: Got some compiler errors, which at first I thought would be remedied by forcing a 32-bit only build. Which didn't help, so I then found that this patch to the Core Graphics headers did the trick: https://gist.github.com/jweinberg/3336233


Top
 Profile  
 
PostPosted: Sun Apr 26, 2015 1:28 pm 
Offline

Joined: Sat Apr 25, 2015 1:47 pm
Posts: 336
Location: FL
Qt 4 supports both Carbon and Cocoa, so I'd probably rather just switch to the Cocoa version of Qt 4 instead of going to Qt 5 (Qt 4 is also much more lightweight out of the box than Qt 5 is, and I've had serious issues with Qt 5 on OS X in the past, so I'd rather play it safe and stick with 4.8.6).

Also I'll make a note of that CoreGraphics fix for later. If that's all you had to do to get it to build, though, then that's good news; I know AWJ was making some headway at trying to get his own fork to build without issues on OS X but hadn't been able to test it yet.


Top
 Profile  
 
PostPosted: Sun Apr 26, 2015 1:50 pm 
Offline

Joined: Thu Feb 07, 2013 1:15 am
Posts: 96
Location: Sweden
Revenant wrote:
Qt 4 supports both Carbon and Cocoa, so I'd probably rather just switch to the Cocoa version of Qt 4 instead of going to Qt 5 (Qt 4 is also much more lightweight out of the box than Qt 5 is, and I've had serious issues with Qt 5 on OS X in the past, so I'd rather play it safe and stick with 4.8.6).

Also I'll make a note of that CoreGraphics fix for later. If that's all you had to do to get it to build, though, then that's good news; I know AWJ was making some headway at trying to get his own fork to build without issues on OS X but hadn't been able to test it yet.

Yup, that macro fix made it build without any problems – and everything seems to work fine as well except for the minor annoyance that you get a 32-bit Carbon build. Will try to build Qt 4 Cocoa and see what happens... It seems that there are some references to Carbon in the ruby/input stuff too, maybe it's possible to def those to use SDL instead so any references to Carbon can be abolished completely.


Top
 Profile  
 
PostPosted: Sun Apr 26, 2015 7:38 pm 
Offline
User avatar

Joined: Mon Mar 02, 2015 1:11 am
Posts: 76
Location: Australia (PAL)
Revenant wrote:
Try downloading again, sorry about that. I didn't realize that the snesfilter plugin had any additional dependencies (I basically built and included them at the last minute since I wasn't doing anything with them myself, yet), but libgomp-1.dll is included now (and I assume pthreadGC2.dll was a dependency of the versions you had found elsewhere, since my stuff uses libwinpthread-1.dll instead).


Thanks for that.

There is ONE feature that I would like to see in the debugger, I would like the debugger to accept breakpoint locations from the command line.

I currently have a script that scans ca65's .memlog file for BREAKPOINT_ and displays its address for me. I normally would have to click buttons and copy+paste it into the window, but hopefully in the future..

After quickly looking though the Application::main code I think I can add it myself :D , I'll try to make the argument parsing as clean as possible.

Expect a push request sometime during the weekend.


Top
 Profile  
 
PostPosted: Sun Apr 26, 2015 9:40 pm 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1339
> How much work would it be to migrate to Qt 5? Trying to build on OS X and Qt 4 relies on Carbon which is 32-bit only.

I've built the old Qt 4 bsnes to use 64-bit Cocoa before. It had all the usual Qt-caused bugs you'd expect, but it worked. You might have to do some digging if (whoever owns Qt this week) has buried said builds, though.

> It seems that there are some references to Carbon in the ruby/input stuff too

Cocoa never added a simple method to query the state of keyboard keys, so we had to.

SDL could work at the cost of another dependency. Or you could warp your mind, lose your grip on sanity, and implement polling through the HID manager API. That has to seriously be the most hideous API that I've ever looked at ... and I've investigated SSL/TLS libraries.


Top
 Profile  
 
PostPosted: Mon Apr 27, 2015 5:12 am 
Offline

Joined: Thu Feb 07, 2013 1:15 am
Posts: 96
Location: Sweden
byuu wrote:
> How much work would it be to migrate to Qt 5? Trying to build on OS X and Qt 4 relies on Carbon which is 32-bit only.

I've built the old Qt 4 bsnes to use 64-bit Cocoa before. It had all the usual Qt-caused bugs you'd expect, but it worked. You might have to do some digging if (whoever owns Qt this week) has buried said builds, though.

> It seems that there are some references to Carbon in the ruby/input stuff too

Cocoa never added a simple method to query the state of keyboard keys, so we had to.

So now I've tried builds with both 64-bit Qt4 and Qt5. Actually, as a side note, not a whole lot of changes were needed to make it build and it seemed to work just fine – but I suppose there's no real argument to be made for migrating this project to Qt5 at this point.

Anyway, my goal with this tinkering was to get proper HiDPI rendering (seeing all the debugging views with chubby pixeldoubled font rendering urged me to), and actually it wasn't Qt4 or the use of Carbon that was the culprit – the build was 64-bit Cocoa all along. So then I realized that you need an Info.plist with the "NSPrincipalClass" and (optionally, at least on 10.10) "NSHighResolutionCapable" keys set, and all text are rendered with beautiful tiny pixels... (:

The GL viewport didn't automatically accomodate for the higher DPI though, but I'll dig in and make it play nicely one of these nights. I'm absolutely thrilled to not have to use my old WinXP VM for SNES debugging anymore!


Top
 Profile  
 
PostPosted: Wed Apr 29, 2015 7:31 am 
Offline

Joined: Fri Mar 01, 2013 4:46 am
Posts: 251
Would you happen to have a time frame, for when we can expect a revision to bsnes plus's debugging features?

Thank You!


Top
 Profile  
 
PostPosted: Wed Apr 29, 2015 8:05 am 
Offline

Joined: Sat Apr 25, 2015 1:47 pm
Posts: 336
Location: FL
Nope, sorry. I'm developing this in my spare time without any kind of release schedule. I'm still trying to put a little bit of work into it (in some way or another) every day but it could be a few weeks before I have anything actually substantial to release.

ARM9 wrote:
Very cool, thanks a lot for your effort, I can see myself using this one a lot. I wonder, does this debugger have any support for keybinds? I might try to contribute something myself otherwise, because it would be nice for stepping and setting breakpoints for example.

Not yet, though I'm planning to add hotkeys for some of the debugger functionality.

ARM9 wrote:
The MESS debugger has superfx support, I believe it does sa-1 too but I haven't tested it myself.

Interesting. I've never actually used MESS but if there's anything specifically useful about its own debugger that you'd like to see in mine then feel free to make suggestions.


Top
 Profile  
 
PostPosted: Wed Apr 29, 2015 8:53 am 
Offline

Joined: Fri Mar 01, 2013 4:46 am
Posts: 251
I appreciate your hard work! I'll keep checking back every now and then. Thanks for the speedy reply btw!


Top
 Profile  
 
PostPosted: Wed Apr 29, 2015 6:24 pm 
Offline

Joined: Sat Apr 25, 2015 1:47 pm
Posts: 336
Location: FL
Optiroc wrote:
byuu wrote:
> How much work would it be to migrate to Qt 5? Trying to build on OS X and Qt 4 relies on Carbon which is 32-bit only.

I've built the old Qt 4 bsnes to use 64-bit Cocoa before. It had all the usual Qt-caused bugs you'd expect, but it worked. You might have to do some digging if (whoever owns Qt this week) has buried said builds, though.

> It seems that there are some references to Carbon in the ruby/input stuff too

Cocoa never added a simple method to query the state of keyboard keys, so we had to.

So now I've tried builds with both 64-bit Qt4 and Qt5. Actually, as a side note, not a whole lot of changes were needed to make it build and it seemed to work just fine – but I suppose there's no real argument to be made for migrating this project to Qt5 at this point.

Anyway, my goal with this tinkering was to get proper HiDPI rendering (seeing all the debugging views with chubby pixeldoubled font rendering urged me to), and actually it wasn't Qt4 or the use of Carbon that was the culprit – the build was 64-bit Cocoa all along. So then I realized that you need an Info.plist with the "NSPrincipalClass" and (optionally, at least on 10.10) "NSHighResolutionCapable" keys set, and all text are rendered with beautiful tiny pixels... (:

The GL viewport didn't automatically accomodate for the higher DPI though, but I'll dig in and make it play nicely one of these nights. I'm absolutely thrilled to not have to use my old WinXP VM for SNES debugging anymore!


Could you try building again from the latest source without the modified Qt 4 headers? AWJ changed things a bit in his upstream fork so that macro issue should no longer happen, so you should be able to build on OS X 100% problem-free now (hopefully...)


Top
 Profile  
 
PostPosted: Thu Apr 30, 2015 4:39 am 
Offline

Joined: Thu Feb 07, 2013 1:15 am
Posts: 96
Location: Sweden
Revenant wrote:
Could you try building again from the latest source without the modified Qt 4 headers? AWJ changed things a bit in his upstream fork so that macro issue should no longer happen, so you should be able to build on OS X 100% problem-free now (hopefully...)

Yes, now it works without modified CoreGraphics headers! Nice. I wonder if there's any demand for pre-built OSX binaries? I'd be happy to help with that.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 171 posts ]  Go to page Previous  1, 2, 3, 4, 5 ... 12  Next

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