Skip to content
Open
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 6 additions & 0 deletions BasiliskII/src/Unix/video_x.cpp
Original file line number Diff line number Diff line change
Expand Up @@ -1637,6 +1637,12 @@ bool VideoInit(bool classic)
return false;
}
std::sort(avail_depths, avail_depths + num_depths);

#ifdef __APPLE__
// 15-bit color does not seem to work on OS X
int *last = std::remove(avail_depths, avail_depths + num_depths, 15);
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, you should call this "end" instead of "last", since it's a pointer past the last element.

num_depths = ( (size_t)last - (size_t)avail_depths ) / sizeof(int);
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can just do:

num_depths = last - avail_depths;

C++'s pointer subtraction semantics will do the right hing.

15-bit depth seems like a very weird thing to support and I wouldn't be surprised if SS simply doesn't work with it, but that XListDepths() doesn't return it on other platforms. I think we can just remove it from the list on all platforms (i.e. without the ifdef).

Also, might as well do it before the std::sort() call above.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removing 15-bit mode has the effect of removing the "thousands" color option in OS X. I'm concerned that if 15-bit mode is removed on all platforms, the "thousands" option will no longer be available on other platforms either. However, the "thousands" option is not that useful if you have "millions".

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't there still be a 16-bit mode that allows thousands of colors?

Looking up what 15-bit depth means, I guess it's to signify its a 555 rgb encoding (rather than 565 with 16-bit).

Can you provide details of what exactly happens without this? I'm curious what's actually failing.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The 16-bit color mode does not appear to function properly in OS X. It causes the image to be distorted. Specifically, the image is compressed horizontally, so the right half of the image is blank. Also, the colors are wrong (there is a purple tint), and there are horizontal lines. Also, when 16-bit color mode is enabled, the same happens for 8, 4, and 2 bit modes. When I disable 16-bit color mode on OS X, I lose 16-bit color, but I gain working 8, 4, and 2 bit color modes.

On Jun 3, 2013, at 1:41 AM, asvitkine notifications@github.com wrote:

In BasiliskII/src/Unix/video_x.cpp:

@@ -1637,6 +1637,12 @@ bool VideoInit(bool classic)
return false;
}
std::sort(avail_depths, avail_depths + num_depths);
+
+#ifdef APPLE

  • // 15-bit color does not seem to work on OS X
  • int *last = std::remove(avail_depths, avail_depths + num_depths, 15);
  • num_depths = ( (size_t)last - (size_t)avail_depths ) / sizeof(int);

Shouldn't there still be a 16-bit mode that allows thousands of colors?

Looking up what 15-bit depth means, I guess it's to signify its a 555 rgb encoding (rather than 565 with 16-bit).

Can you provide details of what exactly happens without this? I'm curious what's actually failing.


Reply to this email directly or view it on GitHub.

#endif

#ifdef ENABLE_FBDEV_DGA
// Frame buffer name
Expand Down