Login
Username:

Password:

Remember me



Lost Password?

Register now!
Sections
Who's Online
36 user(s) are online (19 user(s) are browsing Forums)

Members: 0
Guests: 36

more...
Support us!
Recent OS4 Files
OS4Depot.net



« 1 ... 38 39 40 (41) 42 43 44 45 »


Re: SDL2
Just can't stay away
Joined:
2007/7/14 21:30
From Lothric
Posts: 1036
@kas1e

Quote:

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


In SDL or where?

   Report Go to top

Re: SDL2
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6295
@Capehill
Quote:

Has he tried your examples?


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
_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: SDL2
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6295
@Capehill
It seems I found what wrong with alt+enter (at least logically), and it seems very much like an issue you discuss with Raziel there:

https://github.com/AmigaPorts/SDL/issues/70

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
_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: SDL2
Just can't stay away
Joined:
2007/7/14 21:30
From Lothric
Posts: 1036
@kas1e

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.

   Report Go to top

Re: SDL2
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6295
@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.

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: SDL2
Home away from home
Joined:
2006/11/26 21:45
From a dying planet
Posts: 3705
@kas1e

I can and will try once there is a release version of sdl2 with the fix in place.

Thank you


Edited by Raziel on 2020/1/25 22:25:06
_________________
People are dying.
Entire ecosystems are collapsing.
We are in the beginning of a mass extinction.
And all you can talk about is money and fairytales of eternal economic growth.
How dare you!
– Greta Thunberg
   Report Go to top

Re: SDL2
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6295
@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 Interruptexception
Alert number
0x80000003

Register dump
:
GPR (General Purpose Registers):
   
07F9CAB38 62EC4710 00000000 00000000 FFFFFFFF 00000001 021D0F7C 00000000 
   8
19343D00 00000000 021C6A02 65098CE0 2A822444 686D8020 00000000 65E25340 
  16
7F8782B0 00000000 6878E4F0 655CF018 02270000 65E9CC60 00000000 00000000 
  24
64B776B4 00000000 6867DAEC 7F993DC8 62774B18 627747D8 64D6CF0C 65098CC0 


FPR 
(Floating Point RegistersNaN Not a Number):
   
0:              nan              nan              340                0 
   4
:                0            649.8             24.8                0 
   8
:                0              128            649.8          54.9254 
  12
:       4.5036e+15              365                0                0 
  16
:                0                0                0                0 
  20
:                0                0                0                0 
  24
:                0                0                0                0 
  28
:                0                0                0                0 

FPSCR 
(Floating Point Status and Control Register): 0x82004000


SPRs 
(Special Purpose Registers):
           
Machine State (msr) : 0x0200F030
                Condition 
(cr) : 0x6083BD80
      Instruction Pointer 
(ip) : 0x7F9CAB58
       Xtended Exception 
(xer) : 0x018216A4
                   Count 
(ctr) : 0x6083C0F8
                     Link 
(lr) : 0x0002000E
            DSI Status 
(dsisr) : 0x607EB354
            Data Address 
(dar) : 0x6083C0F8



680x0 emulated registers
:
DATA00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
ADDR
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
FPU0
:                0                0                0                0 
FPU4
:                0                0                0                0 



Symbol info
:
Instruction pointer 0x7F9CAB58 belongs to module "dosbox_native_threads" (PowerPC
SymbolSDL_SYS_CreateThread 0xAC in section 1 offset 0x002AAB34

Stack trace
:
    
SDL_SYS_CreateThread()+0xac (section 1 0x2AAB34)
    
SDL_SYS_CreateThread()+0x8c (section 1 0x2AAB14)
    
open_audio_device()+0x608 (section 1 0x2761E8)
    [
mixer.cpp:722_Z10MIXER_InitP7Section()+0x400 (section 1 0x10DEB8)
    [
setup.cpp:810_ZN6Config4InitEv()+0x54 (section 1 0x23AC24)
    [
sdlmain.cpp:3110main()+0x5ac (section 1 0x158838)
    
native kernel module newlib.library.kmod+0x000020a4
    native kernel module newlib
.library.kmod+0x00002d0c
    native kernel module newlib
.library.kmod+0x00002ee8
    _start
()+0x170 (section 1 0x1920)
    
native kernel module dos.library.kmod+0x00024c18
    native kernel module kernel
+0x000436f0
    native kernel module kernel
+0x00043770

PPC disassembly
:
 
7f9cab50831e8004   lwz               r24,-32764(r30)
 
7f9cab547d234b78   mr                r3,r9
*7f9cab588129005c   lwz               r9,92(r9)
 
7f9cab5c92c10108   stw               r22,264(r1)
 
7f9cab6093210114   stw               r25,276(r1)

System information:

CPU 
 Model
Motorola MPC 7447/7457 Apollo V1.1 
 CPU speed
999 MHz 
 FSB speed
133 MHz 
 Extensions
performancemonitor altivec 

Machine 
 Machine name
Pegasos II 
 Memory
1048576 KB 
 Extensions
bus.pci bus.agp


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.

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: SDL2
Just can't stay away
Joined:
2007/7/14 21:30
From Lothric
Posts: 1036
@kas1e

92 is DOSIFace.Input according to offsetof(). Native threads used IDOS instead of iDOS. IDOS seemed to be NULL.

Try the following patch: https://github.com/AmigaPorts/SDL/comm ... 95448630f60a40c6501cdc6c9

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.

   Report Go to top

Re: SDL2
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6295
@Capehill
Quote:

92 is DOSIFace.Input according to offsetof(). Native threads used IDOS instead of iDOS. IDOS seemed to be NULL.

Try the following patch: https://github.com/AmigaPorts/SDL/comm ... 95448630f60a40c6501cdc6c9


Works! Thanks!

Quote:

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.




Edited by kas1e on 2020/1/25 20:43:50
_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: SDL2
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6295
@Capehill
I made a small test via "testdraw2.exe" coming with sdl2, and:

Pegasos2 with Radeon9250:

testdraw2 --render software: 64fps
testdraw2 --render opengl: 114fps
testdraw2 --render compositing: 264fps

X5000 RadeonHD:

testdraw2 --render software: 288fps
testdraw2 --render opengl: 400fps
testdraw2 --render compositing: 600fps

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?


Edited by kas1e on 2020/1/26 6:45:06
_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: SDL2
Not too shy to talk
Joined:
2011/6/3 13:49
Posts: 260
If OpenGl used compositing in some cases it will need to have the texs in both formats: GL texture + Amiga bitmap

   Report Go to top

Re: SDL2
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6295
Not that i mean exactly usage of compositing, i mean anything so opengl will the same by speed as compositing.

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: SDL2
Just can't stay away
Joined:
2007/7/14 21:30
From Lothric
Posts: 1036
@kas1e

Quote:

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.

   Report Go to top

Re: SDL2
Just can't stay away
Joined:
2007/7/14 21:30
From Lothric
Posts: 1036
@kas1e

Quote:

testdraw2 --render software: 288fps
testdraw2 --render opengl: 400fps
testdraw2 --render compositing: 600fps


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.

   Report Go to top

Re: SDL2
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6295
@Capehill
Quote:

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:

8 bpp: no bugs
http://kas1e.mikendezign.com/aos4/dos ... dcolors/pcnbench_8bpp.jpg

15 bpp: have bugs
http://kas1e.mikendezign.com/aos4/dos ... colors/pcnbench_15bpp.jpg

16 bpp: have bugs
http://kas1e.mikendezign.com/aos4/dos ... colors/pcnbench_16bpp.jpg

32 bpp: have bugs (much less distortion, just green color swapped)
http://kas1e.mikendezign.com/aos4/dos ... colors/pcnbench_32bpp.jpg

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?).

See 2 threads where we discuss the things:

https://www.vogons.org/viewtopic.php?f=32&t=71547
https://github.com/dreamer/dosbox-staging/issues/144


Edited by kas1e on 2020/1/26 9:37:49
Edited by kas1e on 2020/1/26 9:50:01
_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: SDL2
Just can't stay away
Joined:
2007/7/14 21:30
From Lothric
Posts: 1036
@kas1e

It should not be rocket science.

1) Find the line that gets DosBox the surface
2) Find the line that writes the content to that surface

   Report Go to top

Re: SDL2
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6295
@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:

https://bugzilla.libsdl.org/show_bug.cgi?id=1235
https://sourceforge.net/p/dosbox/bugs/347/

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: SDL2
Just can't stay away
Joined:
2007/7/14 21:30
From Lothric
Posts: 1036
@Raziel

Wait no more, a new release candidate is here: https://github.com/AmigaPorts/SDL/releases

   Report Go to top

Re: SDL2
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6295
@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 :

https://github.com/dreamer/dosbox-stag ... 44#issuecomment-578533293

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! :)

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: SDL2
Home away from home
Joined:
2006/11/26 21:45
From a dying planet
Posts: 3705
@Capehill

Thank you.

Will test and report back to this thread and the issue tracker asap

_________________
People are dying.
Entire ecosystems are collapsing.
We are in the beginning of a mass extinction.
And all you can talk about is money and fairytales of eternal economic growth.
How dare you!
– Greta Thunberg
   Report Go to top


« 1 ... 38 39 40 (41) 42 43 44 45 »



[Advanced Search]


Powered by XOOPS 2.0 © 2001-2016 The XOOPS Project