That can be fixed. Wasn't aware of this issue.
Feedback Required - What benefits are there to the WxWidgets GUI
|
06-27-2018, 11:02 PM
(This post was last modified: 06-28-2018, 05:01 AM by One More Try.)
Some QT debugger issues:
The QT memory debugger needs serious fixing. 1. Zeroes don't work right. You can't zero out any more than a U8 without changing the address multiple times. 1b. I can't input 0001 because zeroes don't work right, it'll input as 01. 2. If you try to input just "1" it'll load as a U8 (01000000), but loading as a U32 (00000001) when that view is selected is way better and the way WX works. This would also probably solve 1 and 1b. 3. Breakpoints will only tag an entire row - something I have never needed, and can't use, as it generates spam breakpoints. The correct breakpoint for a U32 address should be address | address + 0x03 to tag half word and byte operations within the U32. 4. Not being able to see hex and float at the same time is annoying. Would be better if you could insert a float from a decimal value. /edit 5. Entering more than 8 characters into the replacement box will spill the changes over into the next memory address. If you accidentally put 9 in, then you just unintentionally wiped out a memory address you may not know the original value of, and have to restart. If entering more than 8 is a useful feature for some, perhaps recoloring the input box when 8 is reached to let you know would be a good solution. Otherwise just capping at 8 would be nice. Register tab has issues with font/size changes. It'll display 123456... instead of 12345678. Could be an issue with non-monospaced fonts. It was defaulted to segoe UI I think and I upped the size. The debug window panel resize divider is about 3 pixels wide and gets off center when doing multiple resizes while the game is paused, making it rather difficult to find it quickly and resize it. I don't see any way to tile debugger tabs or pop them out. Not being able to see code and register tabs at the same time is very bad. Maybe I missed something? These are just quick observations. I can't do any robust work inside the QT debugger, because the way my symbol files are loaded changed (globally, before QT) and they are largely incompatible with new builds (Add Function bug report). 06-27-2018, 11:54 PM
06-27-2018, 11:57 PM
(06-27-2018, 11:02 PM)One More Try Wrote: 3. Breakpoints will only tag an entire row - something I have never needed, and can't use, as it generates spam breakpoints. The correct breakpoint for a U32 address should be address | address + 0x03 to tag half word and byte operations within the U32. This has been supported for a while now. Quote:I don't see any way to tile debugger tabs or pop them out. Not being able to see code and register tabs at the same time is very bad. Maybe I missed something? You can just drag their title bar to pop them out or position them somewhere else within the window. 06-28-2018, 01:29 AM
Thanks, I was trying to click the tab to pop it out, but it was the title bar under the tab I had to drag.
I'm not sure how #3 can be achieved in the memory tab, any explanation? 06-28-2018, 04:01 AM
06-28-2018, 08:21 AM
TAS tools still have some functional issues on Qt.
-TAS input windows do not allow simultaneous use of the original controller (Standard Controller, possibly others). This is grossly inefficient for TAS work, and the number one reason I'm still using Wx. -Analog stick inputs don't center correctly by default in the TAS windows. While the choice of 128,128 over 127,127 (GCC) and 512,384 over 511,383 (Wiimote IR) is perhaps somewhat arbitrary, Dolphin otherwise still treats the former values as the default center and there are certain third party devices that operate with 128,128 centers by default. The interface should maintain these conventions for consistency. Wiimote orientation values are all 0 by default in Qt, which is slightly more problematic. X/Y were conventionally 512 each, while I believe Z depends on sensor bar placement? -Input windows should not remember inputs when closed and reopened. -Aesthetic criticism: L/R sliders take up unnecessary space in standard/GCC windows. The previous, more compact implementation was better and more intuitive (vertical sliders 0 high/255 low to match hardware behavior). 06-29-2018, 07:31 PM
06-30-2018, 06:09 AM
My most common TASing setup involves a Standard Controller configured with keyboard binds and a TAS input window open, such that I can play and use hotkeys with minimal hand movement. The TAS window is only used for precise analog inputs when required. At present, open TAS windows disable all other forms of input on that port. This also occurs with the GCC adapter, and likely any other form of external input. This occurs regardless of which window is currently in focus.
|
« Next Oldest | Next Newest »
|
Users browsing this thread: 1 Guest(s)