-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Discussion] Can SDLV1 handle BW 1 bpp source frame #35
Comments
I found the culprit that cause SDL failed in src/CrossPlatform/video_blit.cpp: 0580 // The UAE memory handlers will blit correctly
0581 // --> no need for specialised blitters here
0582 Screen_blit = Blit_Copy_Raw; In SDL, the destination is one byte per pixel while emulated Mac is one bit per pixel. However, it didn't handle this case for SDL. |
Well, I sort of fixed 1 bit per pixel issue in SDL. When expand one bit to one byte for SDL surface, I added line 307. I don't quite follow color mask and palette in video_sdl. I wonder if SDL2 supports one bit per pixel? 304 /* -------------------------------------------------------------------------- */
305 /* --- 1/2/4-bit indexed to 8-bit mode conversion --- */
306 /* -------------------------------------------------------------------------- */
307 #define CONVERT_BW(byte) (byte)==1?0:255
308 static void Blit_Expand_1_To_8(uint8 * dest, const uint8 * p, uint32 length)
309 {
310 uint8 *q = (uint8 *)dest;
311 for (uint32 i=0; i<length; i++) {
312 uint8 c = *p++;
313 *q++ = CONVERT_BW(c >> 7);
314 *q++ = CONVERT_BW((c >> 6) & 1);
315 *q++ = CONVERT_BW((c >> 5) & 1);
316 *q++ = CONVERT_BW((c >> 4) & 1);
317 *q++ = CONVERT_BW((c >> 3) & 1);
318 *q++ = CONVERT_BW((c >> 2) & 1);
319 *q++ = CONVERT_BW((c >> 1) & 1);
320 *q++ = CONVERT_BW(c & 1);
321 }
322 } |
Offhand, I vaguely recall SDL2 having code to work with 1-bit graphics. I know that I have tested black and white color modes in the SDL2 backend, and I think Basilisk was assuming that a 1-bit buffer was around somewhere, but I'm not 100% certain of this offhand. Regarding the SDL2 backend, it deals with things a bit differently than with the SDL1 backend. In particular, it leaves much of the color conversion work to SDL2. I set things up to assume that there is, at minimum, always a 32-bit ARGB buffer somewhere in memory. If the guest OS needs to work with something other than 32-bit ARGB, the SDL2 backend will create a 2nd buffer, in the format that the guest OS wants. As screen-updates are detected, the SDL2 backend will convert that portion of the buffer, from the guest OS' format, to 32-bit ARGB (which, from there, will typically get uploaded to a GPU texture, via SDL_Texture APIs). With regards to the SDL1 backend, I vaguely recall it trying to get the host OS to give it a buffer in a compatible format, but I am hazy on the details. If you could use a hand with further work on this, or have any other questions regarding the SDL backend(s), let me know. |
To add: I do recall Basilisk doing some work with regards to color conversion, and I recall re-enabling some of it, when getting certain guest-OS color modes working. It is, admittedly, an area of code I could probably stand to learn more about. |
I skimmed through SDL v1 and BII emulation in video driver for 24 bit ROM bank addressing. Here is my understanding:
IMO, unless you have a guest OS frame buffer like I recently enabled in 24 Bit ROM in System 6, you may not get into this case from your test. I will also share my Python script and method to grab frame buffer from your machine:
import cv2
import numpy as np
# 512x342
np_array = np.fromfile('/Users/Ricky/repo/github/sf-macemu-sdl/BasiliskII/src/Unix/24bit-sdl.bitmap', np.uint8)
bit_stream = np.unpackbits(np_array).reshape(342, 512)
bit_stream *= 255;
cv2.imshow('image', bit_stream)
cv2.waitKey(0)
cv2.destroyAllWindows() Computer graphics is not my expertise, I'd wonder if you could share your insight of SDL palette in BII. More specifically, how that R,G,B mask work. Thanks in advance! |
Here is a high-level overview of SDL palettes:
Does this make sense? |
Correct me if I'm wrong.
|
|
This is NOT an issue in your SDL2. But I can't find anyone who can discuss this topic with. Sorry to abuse your issue board.
Recently, I'm working on enabling 24 bit ROM in BII. Someone fixed broken frame buffer memory access. I fixed emulated hard drive. Now I want to make it work under SDL.
I traced the frame buffer drawing in the host down to the function in below.
Before I asked you questions, here is some background
a0000000
.Here are my questions regarding to the function below:
1. I understood that it tries to find the minimum rectangle that contain different pixels between the currentthe_buffer
and the previousthe_buffer_copy
, but what does variablewide
andhide
mean?1. I have forced SDL use 1 bit per pixel, but the Destination bytes per row are still 512, which is one byte per pixel under 512 x 342.-- I got the answers.
The text was updated successfully, but these errors were encountered: