@zukov
Quote:

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 ]

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 ]

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.

Quote:


Edit : is there a way to show fps? I think that I might be getting double figures with JIT :)

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 ]

@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 ]

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.

@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 ]

@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 ]

Quote:
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 ]

@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 ]

I'll write a more informative post on Vogons.

Quote:
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.

@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 ]

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 ]

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

@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.

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 ]

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

He fixed vgaonly driver (which emulates first vga card), there is no speedup here, this driver was broken earlier.

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)

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

@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.

DosBox tells me that CD0:/ doesn't exist.

[ Edited by Cego 18.03.2020 - 14:45 ]

@zukow: Is there any updated beta of the JIT version of DosBOX?

Thanks