Seconded. It's too nonstandard for a random 2D application to require working in 32-bit colors, so it should definitely at least bring up a warning and have that known.

That'd actually be a separate request, since that still kind of lacks the point of the program alerting the player beforehand to switch to 32 bits if possible because not doing so could have adverse effects. Being able to tell the color bits in-game would be considerably less useful then, say, the resolution (cough) itself, even though it might be possible to rearrange some of the game's interface functionality without having the player losing functionality.

What Alathon has in mind could be, say; if you know a player's running in < 32-bits, instead of (unintendedly) outputting a black box to them, don't output anything. That's a little better, but still not useful and frankly is more work for the programmer instead of just having the program tell the player to switch to 32-bits before he joins the game. <.< I don't think there could be a reason any currently-still-in-existence computer to not be able to do that, or something.

Alathon wrote:

If you can check the color depth, you can do the popup yourself. This whole mantra of making BYOND take care of things you're perfectly capable of with some exposed information (In a far better fashion) is a step in the wrong direction.

What reason would there be for each game to have its own system for handling a message/pop up, which is providing information about a global BYOND feature/bug?
The message shouldn't even come up during games, it should come up when the pager is launched.

In certain/most matters, it is of course better to handle things yourself if and when possible. However, this isn't one of them.

You've been ranting since the IsBanned() topic. IsBanned() kills players before anything happens (client/mob creation, resource downloads, etc), sure you COULD use client/New(), buts its less efficient.
My main concern was the resource downloads. Are you even sure client/New() is run before resource downloading is complete?

Falacy wrote:

What reason would there be for each game to have its own system for handling a message/pop up, which is providing information about a global BYOND feature/bug?

Uh, the same reason for games having their own system of displaying a GUI - Or being able to skin the layout of the game.

I don't want to be forced to align myself with some generic automatic warning that I can't control. I want control over the playing experience, all the way from attempting to launch the game to closing it down. What you're suggesting is taking more of that control away. Its a bad trend.

All you need is something like client.color_depth; then you can do whatever you want with the player if the color depth doesn't match the 32bit color depth you want.

Kaioken wrote:

As for something like giving the programmer the ability to boot a player using a given number of bits, that's frankly rather silly and I don't see a whole lot you could do with this number.

How about.. Booting them if their color depth doesn't match, or asking them to change their color depth? Or alerting them that if they stay in 16-bit or 8-bit color depth, they won't be getting the full experience playing the game.

Oh look dolly, options! Possibilities! Not being restrained to some generic message which won't fit the scheme of an umpteen amount of games if they even bother to skin their interface a wee bit.

Kaioken wrote:

If it's given it should just be part of the resolution in case that is easily accessible.

Why would you make the resolution harder to parse instead of just providing a seperate variable for color depth?

Kaioken wrote:

You might as well add a function to check a player's default browser or maybe e-mail program so you can ban him if you don't like it, or add the gender as an argument in world/IsBanned(). :P

Yes, because those things are all similar. Default browser could very well be relevant to check; what if you're launching an external browse that doesn't even work in IE? Then you'd want to warn the player about that.

Or you could just keep lobbying for BYOND to handle everything for you, making it harder and harder for those of us who try and create something that doesn't look like a generic skin. If the concept of having to write a 5-line function to handle this with exposed client info is too burdening for you, then I'll have to go with the idea that you're just arguing for the sake of it.

BYOND doesn't work without 32-bit colour. It's not the games that don't work without 32-bit colour. So BYOND should display the warning.

Which would you rather do? And since it's a problem with BYOND, NOT the games, BYOND should warn the user, NOT the games. And that way it would also only be displayed for versions of BYOND with the problem. It would also reduce the amount of (completely unnecessary) work the game's creator has to do, and it would reduce the amount of network traffic.

And: Can a game be written that displays a warning when you start the pager? I thought not.

Actually, you can already get screen width and height. I should make a library on it, it's pretty simple.

I'm referring to the winget() method. It's the only good method, and while a datum containing the vars would be nice, control over convenience :P.

Naturally the current method offers no more control than a datum describing the nature of a client's screen, and less convenience. As such some form of object exposing this information (even if read-only) represents a marked improvement as it exposes more data to the developer while also solving an inconvenient interface short-coming. There is no trade-off between control and convenience, which was the decision-making dilemma that the control over convenience notion was looking to address.

I've never seen a BYOND game that worked only in 32-bit color. I've been using 16-bit color on my monitor and all the icons look fine to me.