DosBox performance on MorphOS/Powerbook
  • Butterfly
    Butterfly
    kas1e
    Posts: 62 from 2005/10/31
    @zukov
    Quote:


    I managed to run Hugi with normal colors:
    - set ambient to 16bit
    - run dosbox, run hugi -> wrong colours
    - alt+enter -> go to fullscreen
    - alt+enter -> go to window mode -> good colors :)

    something is really broken here :)



    Maybe indeed our SDLs? Probably at the very beginning when the first version of SDL1 was done, we on both oses share some amiga-specific codebase for both os4 and mos forks and now have one issue for both?

    EDIT: tested on my mos3.11 on pegasos2, yeah you right, there the same.

    In 16bit mode it's even enough to run dosbox in fullscreen mode by default (so wrong colors), and then switch to window mode : colors good. But then switching back to fullscreen : colors broken again.

    But at least it for sure something about 16/24/32 bits.

    [ Edited by kas1e 24.01.2020 - 09:48 ]
  • »24.01.20 - 10:09
    Profile
  • MorphOS Developer
    zukow
    Posts: 542 from 2005/2/9
    From: Poland
    New beta, overlay mode works (with most games), and opengl (fixes from Stefkos) - works in fullscreen

    DosBox Jit - Beta2

    copy to LIBS:
    powersdl.library

    [ Edited by zukow 25.01.2020 - 08:59 ]
  • »24.01.20 - 23:46
    Profile Visit Website
  • Priest of the Order of the Butterfly
    Priest of the Order of the Butterfly
    Cool_amigaN
    Posts: 550 from 2011/11/30
    Alien rampage from Softdisk has also wrong colors which don't get fixed by changing window / full screen mode. Also the aspect ratio seems wrong. However when I edit the conf and replace overlay with surface all are back to normal for me =though game's screen is way too small). Haven't tested Hugi though. That's on MorphOS 3.12 with radeon 9800pro.
    Amiga gaming Tribute: Watch, rate, comment :)
  • »25.01.20 - 09:14
    Profile Visit Website
  • Priest of the Order of the Butterfly
    Priest of the Order of the Butterfly
    Cool_amigaN
    Posts: 550 from 2011/11/30
    Quote:

    Cool_amigaN wrote:
    Alien rampage from Softdisk has also wrong colors which don't get fixed by changing window / full screen mode. Also the aspect ratio seems wrong. However when I edit the conf and replace overlay with surface all are back to normal for me =though game's screen is way too small). Haven't tested Hugi though. That's on MorphOS 3.12 with radeon 9800pro.



    Edit : is there a way to show fps? I think that I might be getting double figures with JIT :)
    Amiga gaming Tribute: Watch, rate, comment :)
  • »25.01.20 - 09:25
    Profile Visit Website
  • MorphOS Developer
    zukow
    Posts: 542 from 2005/2/9
    From: Poland
    i'm using quake1 demo with timedemo demo1 to check fps
    Regarding overlay mode: it's a hack currently so it works only in some games and it requires powersdl.library from the link (but it is faster and gaves scaling for free).

    For surface you can select scaler mode with aspect and etc.
    For speedup i can suggest to set cycles to some const value (60000 here but for slower machine it should be lower).

    [ Edited by zukow 25.01.2020 - 10:17 ]
  • »25.01.20 - 10:15
    Profile Visit Website
  • Butterfly
    Butterfly
    kas1e
    Posts: 62 from 2005/10/31
    @zukow
    I with the help of one of the authors of some DOSBox fork start to dealing with that "bad colors" in HUGI and other games that use 65k colors. It's all about DOSBox in the end, not supporting properly bgra and stuff. Even taking a screenshot via "ctrl+f5" is broken. Once we will deal with, I of course will share necessary changes.

    Btw, is OpenGL mode slower, faster or the same for you? For example in quake1. Or there is some other good benchmark "PCNBench". Because OpenGL there just as blitter, which mean every frame take time => can be slower. Only bonus there to have scaling for free via it.

    [ Edited by kas1e 25.01.2020 - 10:10 ]
  • »25.01.20 - 11:10
    Profile
  • MorphOS Developer
    zukow
    Posts: 542 from 2005/2/9
    From: Poland
    Under MorphOS SDL opens 16bit screen for Hugi so i assume that it is RGB16 vs RGB16PC issue. Also for 16bit and 32 bit Dosbox opens surface output turning off overlay mode.

    Could you give me the color discussion thread link (if it is on some forum)? I haven't done extensive tests as i merged my and Stefkos changes very late yesterday. OpenGl seems to be slower that overlay but faster than scaled surface (i have X1950XT PCIe so it is quite a fast card both for memory access and 3d).

    I have also one strange thing, under Quake1 for some run i got ~15fps with timedemo and ~24fps for another run (for auto/max). I first thought that JIT needs to warm up before being fast but it seems it not the case. I have much better results with cycles set to const values (i played a bit and for my machine it is 60000 - 65000 cycles -> CPU is 98% - 99% (so it doest consume all cpu) and i don't have any issues with sound). I'm checking now with some functions moving to other .cpp files to have it better inlining.
  • »25.01.20 - 11:53
    Profile Visit Website
  • Butterfly
    Butterfly
    kas1e
    Posts: 62 from 2005/10/31
    @zukov
    At the moment there is not much, the developer seems to works on and I only help with tests. I also bring him your finds, and there is a thread where we discuss things: https://github.com/dreamer/dosbox-staging/issues/144

    In brief, he thinks that it's in the src/hardware/vga_draw.cpp, around C_UNALIGNED_MEMORY lines.

    And today I also find that PCNBench tool has the ability to choose in what screen mode to run it, so:

    8 bpp: no bugs
    http://kas1e.mikendezign.com/aos4/dosbox/badcolors/pcnbench_8bpp.jpg

    15 bpp: have bugs
    http://kas1e.mikendezign.com/aos4/dosbox/badcolors/pcnbench_15bpp.jpg

    16 bpp: have bugs
    http://kas1e.mikendezign.com/aos4/dosbox/badcolors/pcnbench_16bpp.jpg

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

    From screenshots above, probably it means that both 15 and 16bit modes suffer from PC vs no PC modes (that why it works on other platforms) , while 32-bit mode seems to suffer from some easy wrong byte orders, and strange if that will not happen on other big-endian platforms. As on amigaos4/morphos we use PC modes only for 15/16 bits (right?)


    [ Edited by kas1e 26.01.2020 - 08:25 ]
  • »26.01.20 - 07:10
    Profile
  • Butterfly
    Butterfly
    kas1e
    Posts: 62 from 2005/10/31
    @zukow
    Another thread where we tried to find an issue there:
    https://www.vogons.org/viewtopic.php?f=32&t=71547

    Jmarsh (author of that PPC JIT) keeps repeating that it's our SDLs and not all big-endian machines on the whole, and as an example, he says that he uses Wii and all the 15,16 and 32-bit modes work fine for him. I do not know is Wii has a use for 15/16 bits PC modes or not, maybe that reason.

    Through in 32bit, we didn't use PC modes, so why we also have there another kind of color swapping issue?


    [ Edited by kas1e 26.01.2020 - 08:26 ]
  • »26.01.20 - 09:10
    Profile
  • MorphOS Developer
    Piru
    Posts: 415 from 2003/2/24
    From: finland, the l...
    Quote:

    kas1e wrote:
    @zukow
    Another thread where we tried to find an issue there:
    https://www.vogons.org/viewtopic.php?f=32&t=71547

    Jmarsh (author of that PPC JIT) keeps repeating that it's our SDLs and not all big-endian machines on the whole, and as an example, he says that he uses Wii and all the 15,16 and 32-bit modes work fine for him.

    Jmarsh is wrong.

    The reason he is wrong likely stems from the fact that the Wii uses little-endian 15- and 16-bit modes, and the SDL implementation doesn't perform SDL_Surface shadow byteswapping as needed, in which case the missing byte swapping goes unnoticed. It'll break for Wii if/when DOSBox code is fixed.

    SDL only specifies shift and mask values for the color guns. These are the only operations that are needed to convert color to specific SDL_Surface format. If the frame buffer would be byte swapped, the values could not be converted by simple shift + mask. If you look at the SDL SDL_MapRGB function, it will create value for given pixel format, R, G, B combo that can be written to the SDL_Surface frame buffer as-is. This routine does no byte swapping at all. This means that on given platform the 15- and 16-bit SDL_Surface frame buffers need to be in the native byte order. Thus for big-endian systems this necessitates that the 15- and 16-bit SDL_Surface frame buffers are big-endian.

    For big-endian SDL implementations rendering to little endian native display bitmaps (RGB15PC and RGB16PC) this requires byteswap from big-endian "shadow" frame buffer to little-endian native target bitmap. SDL applications compiled for big-endian systems need to render big-endian 15- and 16-bit SDL_Surface frame buffers. In case of DOSBox this requires byteswap from the "PC native" little-endian frame buffer to big-endian SDL_Surface frame buffer. This conversion is currently missing in DOSBox. Yes, this means that there is double byteswap in case the target display is natively little endian (RGB15PC and RGB16PC), but SDL API is what it is and this is necessary for things to work in all cases.

    Note that this does not apply to modes where the guns are 8-bit since simple shift + mask can represent both little- and big-endian without problems.

    [ Edited by Piru 26.01.2020 - 22:55 ]
  • »26.01.20 - 21:48
    Profile
  • Butterfly
    Butterfly
    kas1e
    Posts: 62 from 2005/10/31
    @Piru
    It's hard to talk with him, too smart probably :) the last answer was that we don't know what we talk about, and "The Wii doesn't have any little-endian video modes. I already told you DOSBox doesn't output 8-bit - that means when the video mode is 8-bit, DOSBox is sending 16 or 32-bit output to SDL (depending on default desktop depth)... If it were the wrong format, even 8-bit modes would look messed up."

    But another user also confirms that he has _exactly_ the same issue on the latest up2date LinuxPPC:
    https://github.com/dreamer/dosbox-staging/issues/144#issuecomment-578533293

    So it's already 3 oses have that issue: OS4, MOS, and Linux. So kind of naive to think that his Wii does things "right" and everyone else (includes far more popular Linux) do thigs wrong.

    Sure it can be something else and not PCvsnoPC differences, but the bug is here surely. From his posts, it sounds like "it'd SDL, all SDLs around are wrong, and only Wii SDL do things right".

    [ Edited by kas1e 27.01.2020 - 08:48 ]
  • »27.01.20 - 09:36
    Profile
  • MorphOS Developer
    zukow
    Posts: 542 from 2005/2/9
    From: Poland
    I'll write a more informative post on Vogons.
  • »27.01.20 - 10:58
    Profile Visit Website
  • MorphOS Developer
    Piru
    Posts: 415 from 2003/2/24
    From: finland, the l...
    Quote:

    kas1e wrote:
    "The Wii doesn't have any little-endian video modes."

    If so then there likely is some explicit byte swap in Wii SDL where there shouldn't be one. It fixes rendering for dosbox but likely breaks it for everything else.

    However, this is pure speculation. I have no clue what the Wii SDL is really doing.
  • »27.01.20 - 17:02
    Profile
  • Butterfly
    Butterfly
    kas1e
    Posts: 62 from 2005/10/31
    @Zukow
    While you do not start making hack-version of SDL, if you have an interest you can follow there: https://github.com/dreamer/dosbox-staging/issues/144, the man who tries to fix it inside of DOSBox invite you as well, so we all can test/discuss things there.

    I mean, it surely better to fix DOSBox than making some hacks in SDLs.

    EDIT: Oh, and he was able to fix things the way you suggest, just he change different PMAKEs in some other places. See: https://github.com/dreamer/dosbox-staging/blob/77bff33870aed1622df871820e91ba470bb9f676/src/gui/render_templates.h


    And result in all 16bit modes and 32bit modes in a window and in fullscreen rendered correctly on our side now:

    http://kas1e.mikendezign.com/aos4/dosbox/badcolors/hugi17_newpmake.jpg

    In other words, no need for SDL hacking, and Jmarsh is wrong (At least, about "PMAke will not fix your issues"). It fixes it, just they need to be placed in another place.

    The only mode which still have wrong colors now is 15bit one, but that one probably can be fixed by another PMAKE.




    [ Edited by kas1e 28.01.2020 - 10:15 ]
  • »28.01.20 - 10:44
    Profile
  • Butterfly
    Butterfly
    kas1e
    Posts: 62 from 2005/10/31
    Oh, at the same time in main DOSBox repo fix arrive from Jmarsh :) The same kind of fix as Dreamer do, just in a different place and for all modes. Will test that one as well, but probably Jmarsh realized that he was a bit wrong, need retest it as well.

    EDIT: confirmed, with patch from Jmarsh everything works correctly in all modes now. Through ctrl+f5 to take screenshot still fail with the same ugly colors, but that just needs to be fixed in another place.

    [ Edited by kas1e 28.01.2020 - 11:05 ]
  • »28.01.20 - 11:30
    Profile
  • MorphOS Developer
    zukow
    Posts: 542 from 2005/2/9
    From: Poland
    Ok, i'll check after work. I have 32bits and 15bits also working here.

    and btw. rzookol = zukow (Michal Zukowski), i have my old login here :)

    and ... the real question is if we can fix dosbox earlier so vga card would provide Bigendian memory because there are multiple places where endian conversion occurs, maybe we can ommit the double conversions. It needs to be analyzed. If not, i would check also to do endian conversion using altivec and scalers aren't the best place to do it as they operate on single pixels. Regarding directly using PC modes in SDL, it works for 16bit screen very nicely (i've just disabled byteswapping in powersdl).
  • »28.01.20 - 11:43
    Profile Visit Website
  • Butterfly
    Butterfly
    kas1e
    Posts: 62 from 2005/10/31
    @zukov
    I checked with and without byte swapping in DOSBox for hi-res modes, and it seems didn't add any measurable difference for final usage with JIT.

    Also doing some more tests, and the parts I found which suffer from an endian issue at the moment are:
    1).taking a screenshot in 15/16/32 bit modes
    2).recorded sound of a video recorded via ctrl+alt+f5. The video itself records and plays correctly, but audio completely noise as jmarsh saying before.
  • »29.01.20 - 07:20
    Profile
  • MorphOS Developer
    zukow
    Posts: 542 from 2005/2/9
    From: Poland
    I got ~0.5FPS difference in 640x480 and 1fps in 800x600 although i tested another special version with conversion taking place in vga_draw.cpp.

    I still has problems with overall speed - i got ~11fps in 640x480 pcbench 16bit and a few runs later not more than 5.7fps.

    i've added conversion here in vga_draw.cpp so scalers got always BE data and PMAKE changes arent required:
    // unwrapped chunk: to top of memory block
    memcpy(TempLine, &vga.draw.linear_base[offset], unwrapped_len);
    // wrapped chunk: from base of memory block
    memcpy(&TempLine[unwrapped_len], vga.draw.linear_base, wrapped_len);


    [ Edited by zukow 29.01.2020 - 08:41 ]
  • »29.01.20 - 08:36
    Profile Visit Website
  • Butterfly
    Butterfly
    kas1e
    Posts: 62 from 2005/10/31
    @zukov
    They fix some more endian moments:
    https://sourceforge.net/p/dosbox/code-0/4313/

    Not sure what that fix give us, but they use now var_write(), which probably will be faster now (as in mem.h they endian agnostic and can be fast with writing words, so can give some + to speed).
  • »29.01.20 - 19:28
    Profile
  • MorphOS Developer
    zukow
    Posts: 542 from 2005/2/9
    From: Poland
    He fixed vgaonly driver (which emulates first vga card), there is no speedup here, this driver was broken earlier.
  • »29.01.20 - 22:34
    Profile Visit Website
  • Butterfly
    Butterfly
    kas1e
    Posts: 62 from 2005/10/31
    initial big-endian fix for ctrl+f5 to saving screenshots for 15/16/32 bit modes:
    https://github.com/dreamer/dosbox-staging/commit/5b81aef209ede4c4e338cdc44fabd341b105fcc5

    At least 16 bit works for sure (tested with same Hugi)
  • »02.02.20 - 08:09
    Profile
  • Priest of the Order of the Butterfly
    Priest of the Order of the Butterfly
    Cego
    Posts: 611 from 2006/5/28
    From: Germany
    has anybody tried mounting a virtual CD drive? neither a real drive nor a directory works here. Dosbox displays

    Directory of D:\
    File *.* not found.

    Mount Command is: mount d CD0: -t cdrom -usecd 0
    Powerbook G4@1,67GHz, 2GB DDR2 Ram, Radeon 9700, 60GB SSD, MorphOS 3.7
    PowerMac Dual G5 @2.3GHz, 4GB DDR Ram, Radeon 9600XT, 2x250GB HD, MorphOS 3.7, MacOS X Leopard 10.5.8
  • »17.03.20 - 17:24
    Profile
  • Butterfly
    Butterfly
    kas1e
    Posts: 62 from 2005/10/31
    @Cego
    That probably because when mounting virual drive dosbox add "/" at end. So if you mount just a directory somewhere, like "work:test", then for dosbox it will be "work:test/" which is ok for amigaoses, but when you mount pure drive it then add "/" at end and we have "work:/" , which is not ok for amigaoses.

    That mean that some simple ifdef should be added in dosbox's code where mounting of virualdrives placed.
  • »18.03.20 - 13:45
    Profile
  • Priest of the Order of the Butterfly
    Priest of the Order of the Butterfly
    Cego
    Posts: 611 from 2006/5/28
    From: Germany
    DosBox tells me that CD0:/ doesn't exist.

    [ Edited by Cego 18.03.2020 - 14:45 ]
    Powerbook G4@1,67GHz, 2GB DDR2 Ram, Radeon 9700, 60GB SSD, MorphOS 3.7
    PowerMac Dual G5 @2.3GHz, 4GB DDR Ram, Radeon 9600XT, 2x250GB HD, MorphOS 3.7, MacOS X Leopard 10.5.8
  • »18.03.20 - 15:43
    Profile
  • Just looking around
    Posts: 6 from 2018/10/14
    @zukow: Is there any updated beta of the JIT version of DosBOX?

    Thanks
  • »19.03.20 - 08:33
    Profile Visit Website