#1949 closed defect (fixed)
ALL: Failed assertion when using 1x scaler
| Reported by: | eriktorbjorn | Owned by: | sev- |
|---|---|---|---|
| Priority: | normal | Component: | Graphics: Scalers |
| Version: | Keywords: | ||
| Cc: | Game: |
Description
With the recent overlay changes, if I try to start ScummVM with the 1x scaler it will trip the following assertion:
Assertion failed: _transactionMode != kTransactionCommit, file backends/sdl/graphics.cpp, line 203
Does this mean the 1x scaler is no longer supported? I think that would be a shame, because I find it very useful for debugging.
Ticket imported from: #1160454. Ticket imported from: bugs/1949.
Change History (11)
comment:1 by , 19 years ago
| Owner: | set to |
|---|
comment:2 by , 19 years ago
comment:3 by , 19 years ago
How exactly are you trying to run it, which engine?
As of 1x, I don't think 2x makes that vig difference but anyway you can set overlay scale to 1 in initSize() in main.cpp and scumm.cpp
comment:4 by , 19 years ago
Well, my first attempt was to run MonkeyVGA since I was trying to verify that Fingolfin had fixed the "crashes when entering the church" problem, and since I had the 1x scaler in my config file that's what it tried to use.
But I don't have to run any particular engine. Here I've even removed scummvm.ini (I'm running it under MinGW at the moment):
$ ./scummvm -g1x Assertion failed: _transactionMode != kTransactionCommit, file backends/sdl/graphics.cpp, line 203
This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information.
comment:5 by , 19 years ago
I can't reproduce it here. Please, provide all graphics-related parameters from your config file, i.e. aspect_ratio, fullscreen and gfx_mode.
As I mentioned in comment on that assert: // NOTE: This should not be executed at transaction commit // Otherwise there is some unsolicited setGraphicsMode() call // which should be properly removed if (newScaleFactor != _scaleFactor) { assert(_transactionMode != kTransactionCommit);
So this is a design flaw somewhere. Another helpful thing would be a backtrace.
Still I wonder either 2x mode really does not let you run valgrind. If it is so, tell me and I'll add command line option, something like --force-1x-overlay.
comment:6 by , 19 years ago
> Please, provide all graphics-related parameters from your config > file,
As I said, in the example I quoted before I didn't have any config file whatsoever. Thus, the -g1x command-line option should have been the only graphics-related setting.
> So this is a design flaw somewhere. Another helpful thing would > be a backtrace.
Yes, I realize that. I didn't provide one because MinGW is awkward - to me at least - so I didn't have one. I *think* this is the backtrace at the point the assertion fails:
#0 OSystem_SDL::setGraphicsMode(int) (this=0x1d8c320, mode=1) at backends/sdl/graphics.cpp:202 #1 0x00401fdb in OSystem_SDL::endGFXTransaction() (this=0x1d8c320) at backends/sdl/graphics.cpp:83 #2 0x00408025 in launcherDialog(GameDetector&, OSystem&) (detector=@0x22ff28, system=@0x1d8c320) at base/main.cpp:228 #3 0x004092a7 in main (argc=3, argv=0x3f2598) at base/main.cpp:391
I'll see if I can dig up any information that's more useful than that.
> Still I wonder either 2x mode really does not let you run valgrind.
Well, obviously ScummVM will work under Valgrind with the 2x scaler. But even with the 1x scaler it runs sluggish on my 450 MHz PIII. Also, when doing more traditional debugging I find it convenient to use the 1x scaler so that the ScummVM window doesn't obscure the development tools.
comment:7 by , 19 years ago
I'm not sure, but part of the problem could be that launcherDialog() calls setGraphicsMode() before initSize(). The setGraphicsMode() function uses _overlayWidth. Is that variable initialized at this point?
comment:8 by , 19 years ago
Initializing variables didn't help, but I made that change anyway because it shouldn't hurt either.
This is what launcherDialog() does:
beginGFXTransaction() setGraphicsMode( ... ) initSize(320, 200, 2) endGFXTransaction()
When setGraphicsMode() is called, _screenWidth and _overlayWidth are both 0, so no matter what newScaleFactor gets set to the "Do not let switch to lesser than overlay size resolutions" check is not triggered. Thus _scaleFactor is set to 1, not 2.
The endGFXTransaction() notices that the mode has changed, so setGraphicsMode() is called again, this time in "commit" mode. This time _screenWidth is 320 and _overlayWidth is 640. Since newScaleFactor is 1, the test is triggered and newScaleFactor is adjusted to 2.
This means newScaleFactor != _scaleFactor, so we trip that test later in the code, still in commit mode. That, I believe, is why the assertion triggers.
If I call initSize() before setGraphicsMode() it no longer crashes, but I'm not familiar enough with this part of the code to know if that's the right thing to do.
comment:9 by , 19 years ago
Fixed now. The reason why I couldn't reproduce it earlier was that I didn't initialize _overlayWidth. On my system I get garbage there and MSVC initializes all class variables to zero.
Also I added --force-1x-overlay command line option so you could have your valgrinded box more happy :).
comment:10 by , 19 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
comment:11 by , 5 years ago
| Component: | --Unset-- → Graphics: Scalers |
|---|
Not to mention that 1x is pretty much the only scaler that is bearable to use for Valgrind debugging on my hardware.