Issue is that in some dosbox apps/games, i have "bad palette" colors.
_any_ idea where we can to start a look at and debug things to find what wrong ?
One does by reading and understanding how Dosbox produces display.
Quote:
man who do PPC JIT saying that he didn't have such issues on his ppc build
Has he tried your examples?
Quote:
It looks like after swithcing to/from window/fullscreen mode "alt" somehow "holds".
If KEYUP event happens after the original window is closed and before the new one opened, then it's lost. And for example then ALT could "stick" if application is waiting for ALT (keyup) event.
I'm not sure how to deal with it. Maybe input.device handler?
Quote:
Crashlog point out that its nullpointer with 0x0000000 in dar
He say he didn't have such issues, but i reasked him again to be sure he checked it. To be honest for me, from the visuall look, it looks like dosbox's endian issues, not our SDL. But i will ask to recheck.
EDIT: seems another person have found the same issue on his PPC MacOS build. After some more invistegation and more game checks, i found that issue happens when we use 65k colors. So probably looks very much as DOSBox's endian issue. In SDL related parts of DOSBox or in the video emulation part, dunno.
Quote:
If KEYUP event happens after the original window is closed and before the new one opened, then it's lost. And for example then ALT could "stick" if application is waiting for ALT (keyup) event.
I'm not sure how to deal with it. Maybe input.device handler?
Oh dunno.. But as i remember, quake3 builded with SDL1 didn't have that issues, only when builded with SDL2 (i was in hope for some typo in sdl2 code or something..)
Quote:
In SDL or where?
All i can say at moment is that once i build dosbox with native threads, it start crashes on sam460 and x1000 , but not on x5000. As i on x5000 now i can't reproduce it, but will build debug version and ask someone run it on x1000 or sam460.
Edit: oh, i have pegasos2 by hands, i may try to reproduce it here, will be easer.
Edited by kas1e on 2020/1/23 8:18:14 Edited by kas1e on 2020/1/23 14:37:54
At the end of the ticket, before talks about OpenGL starts, there is even the same find that "alt" is ticked, and a workaround to make keys in ResedualVM to work you need to hit "alt": that exactly what happens in DosBox and Quake3.
And that _only_ with SDL2. Not with SDL1. With SDL1 all fine.
So, I do check the SDL1 version and it seems that when you hit "alt+enter", then SDL1 hit another "alt" ourselves. I can see it in file manager used in DOSBox: when a single alt is hitting, it makes some visual action (blinking cursor over the filename), so I can visually see what happens and when with "alt".
I.e. you press alt+enter, it switches mode, and then SDL1 hit and realize "alt". Now, if after that you hit again "alt+enter", then it switches to another mode, but this time "alt" didn't hit again (seems it take second time's "alt" hit from alt+enter combo in account). But if you do any action after switching mode (i.e. when SDL1 hit "alt" after), and then "alt+enter", then SDL1 always will auto-press/realize ALT.
In other words, it seems in SDL1 we have a logical workaround for, or just handling loop done like it has done to mimic necessary behavior.
EDIT: It seems that issue maybe related to what kind of screen you switch. I.e. if screens are different (your WB in one resolution, and you switch to another one), then issue seems here. But when resolution is the same for both screen then (seems so) issue didn't happens.
Edited by kas1e on 2020/1/23 7:25:37 Edited by kas1e on 2020/1/23 7:27:47 Edited by kas1e on 2020/1/23 7:33:52 Edited by kas1e on 2020/1/23 7:38:23 Edited by kas1e on 2020/1/23 14:36:32
After some digging I found out that SDL1 does explicitly reset the keyboard state during fullscreen toggle so I have added now a similar workaround. With some lucky it might help. It triggers key up events for known pressed keys.
@Capehill You are a man! It works! :) Probably for Raziel with ResidualVM it will work now too and we have one ticket less. At least with DOSBox, it surely works.
I will try now to build native-thread version of DOSBox with debug symbols and see if it crashes on my pegasos2, and if yes, in SDL2 at all or not.
@Raziel You may wait another year :) I can upload test version of libsdl with that fix if you wish to close the ticket. Or can not upload if you do not want to do anything now :)
@Capehill I was lucky enough and able to reproduce the crash in native-threads on my pegasos2, when DOSBox have "nosound=false" option set. There is crash log :
Crash log for task "dosbox_native_threads"
Generated by GrimReaper 53.19
Crash occurred in module dosbox_native_threads at address 0x7F9CAB58
Type of crash: DSI (Data Storage Interrupt) exception
Alert number: 0x80000003
Cleary SDL, with pthreads we didn't have that crash. Should i compile SDL with debug symbols, so you can see the line exactly?
Interesting that about that DOSBox's options "nosound" written that:
"nosound: enable silent mode, sound is still emulated through". And it crashes when we set it to "false". When we set it to true, then no crash when we use native-threads.
In other words it surely related to creating of audio process.
I don't understand why your SDL build doesn't have debug symbols though? You can strip them out when they are not needed anymore.
It just when I made some final releases I always build a version without gstabs or any debug, just in case if "strip" will not fully delete that info. Need to tests, maybe if compiled with -gstabs and then stipped, and compiled without -gstabs and stripped will be 1:1 the same, then yeah, you are right.
About the issue with wrong colors: we seem to find out from where it comes, it maybe PC vs no PC video modes (maybe on Macos PPC and Linux PPC there are no "PC/noPC" video modes at all, and that why it works). One man from some DOSBox fork help me out with, so we hope to sort it out inside of DosBox.
And about OpenGL speed .. Strange, but it shouldn't be that slower... Need to test MorphOS version how it with their OpenGL. Zukow says that it also slower for them in compare with "overlay" mode, but like not that much. Need to check.
Also, I notice another issue when using "OpenGL" renderer: remember I say that it starts to be "white", but it starts to be white after some frame. I.e. firstly I see the DOSBox logo, then how console draws, and then bah, all white. If I will many many times switch between window and fullscreen modes (and then, OpenGL context recreates with every switch in DOSBox), then sometimes that "all-white" disappear and I can see a picture. Need to test that one more as well.
I.e. all the time, compositing is faster than OpenGL. And fast for about 2 times (exactly the figures I have with DOSBox when using OpenGL -> all slows on 40-50%)
What I want to understand is why compositing is _that_ faster? I mean, why for example minigl/warp3d (and as well as warp3dnova), haven't used "compositing in some parts if it faster. I.e. be OpenGL, just use compositing inside for things where it will be faster.
Just such a massive difference... Can it be luck of DMA for example?
On win32, at least in DOSBox, be it opengl, or ddraw, FPS are the same (as expected).
Can anybody explain why OpenGL vs compositing should be that slow when it comes to simple texture drawing?
About the issue with wrong colors: we seem to find out from where it comes, it maybe PC vs no PC video modes (maybe on
When application request a surface from SDL it's supposed to use it correctly. It seems that it's using colorchannels wrongly, making some assumptions or shortcuts somewhere.
Quote:
And about OpenGL speed .. Strange, but it shouldn't be that slower... Need to test MorphOS version how it with their
You can build a profiling version of MiniGL if that helps but it's probably down to W3D.
Quote:
Also, I notice another issue when using "OpenGL" renderer: remember I say that it starts to be "white", but it starts to be white after some frame. I.e. firstly I see the DOSBox logo, then how console draws, and then bah, all white. If I will many many times switch between window and fullscreen
Do you mean OpenGL context and not SDL_Renderer with "opengl" backend here?
Sounds like a texture configuration issue. Maybe texture is not correctly created after context creation or something.
setenv SDL_RENDER_BATCHING 1 improves numbers in benchmark.
Quote:
What I want to understand is why compositing is _that_ faster? I mean, why for example minigl/warp3d (and as well as warp3dnova), haven't used "compositing in some parts if it faster. I.e. be OpenGL, just use compositing inside for things where it will be faster.
Compositing is a misleading name for AmigaOS 4 backend because CompositeTags is not be used for all kind of drawing. Backend uses various graphics.library functions and in some cases (alpha blended lines, point at least) it goes into SW mode.
Quote:
Just such a massive difference... Can it be luck of DMA for example?
OpenGL is a massive state machine and it needs more setup than graphics.library to draw something. OpenGL needs more function calls to make things happen.
But OpenGL can use primitive batching so drawing something like large line strips should be faster on OpenGL than graphics.library. Or drawing alpha-blended points or lines.
Quote:
Can anybody explain why OpenGL vs compositing should be that slow when it comes to simple texture drawing?
Texture upload is slower with MiniGL than with graphics.library at least on the platforms that I have tested. I don't know the exact reason, that's probably something that only a person who can read graphics.library and Warp3D code, could answer.
Do you mean OpenGL context and not SDL_Renderer with "opengl" backend here?
Sounds like a texture configuration issue. Maybe texture is not correctly created after context creation or something.
Yeah, sounds like this, and that exactly related to texture (because when i use some fork of dosbox, which give ability to set texture output, any combo with it and opengl output give that issue).
But that maybe for later if you doens't mind, for now trying to understand why we have color issues.
It start to be a bit more complicated that i think of. One of developers who use Wii and his own SDL port for , says that he not have those colors issues with the 15/16/32 bit modes (but hes answer not always very clear, so i can't be sure if he test 32 mode for example)
I find that PCPBench tool may be running with any depth i need, so i made a test and that what i have:
From screenshots above, probably it means that both 15 and 16bit modes suffer from PC vs no PC modes, and Wii maybe use "no PC" mode, so it works.
But 32bit issue, looks like some separate bug, which probabaly should happens on ALL big-endian machines, as in our case we have use PC screenmodes only for 15/16 bits (right?).
@Capehill If that was that easy :) Everyone keep repeating different things. One say it surely dosbox, another one says it surely sdl. I found they have such kind of bugs before with SDL1, and it was fixed partly in SDL, and partly in DOSbox, see:
@Capehill About color issues: some good news, our SDL out of question. Another developer do check it on his PowerMac G4, with Linux PPC on it, and he have _exactly_ the same issues 1:1 on the same video modes. See :
Just by some luck (or unluck), author of PPC JIT on Wii and his own SDL didn't have those issues. Or maybe he not very well understand them, or maybe he do something in his SDL for as well, dunno.
The point that if LinuxPPC have the same issues, then our SDL ports out of question, phew ! Sorry for bother with it then! :)
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
