Future graphics
Moderator: OpenTTD Developers
If we supported 32-bit graphics, nothing would prevent it from using 8-bit or 16-bit graphics would it? It just wouldn't be using all the available colors.
Development Projects Site:
http://www.as-st.com/ttd
Japan, American Transition, Planeset, and Project Generic Stations available there
http://www.as-st.com/ttd
Japan, American Transition, Planeset, and Project Generic Stations available there
24 bit colour
I would recommend against not supporting 24bit colour. Where as 32bit has increasingly become the norm, that are still people out there that do not have cards which support it. Given that 24 and 32 bit are practically the same, very simular (if not the same) code can be used to render in both depths (unless the powers that be decide to actually use the 8 extra bits for alpha).
By the way, 32bit is popular because most of us use 32bit machines, hence it is far quicker to send the full 32bit down the data bus in one go, instead of sending 3 lots of 8bits. Its all a matter of a memory / speed tradeoff.
By the way, 32bit is popular because most of us use 32bit machines, hence it is far quicker to send the full 32bit down the data bus in one go, instead of sending 3 lots of 8bits. Its all a matter of a memory / speed tradeoff.
Less than a year ago, I had a card that would not support 32-bit color, but supported 24-bit. I was stuck with 16-bit for apps that could easily use 24-bit.
If 32-bit is supported, there's absolutely no reason not to support 24-bit as well, since they use the same number of colors
.
If 32-bit is supported, there's absolutely no reason not to support 24-bit as well, since they use the same number of colors
.Scaling down to 16-bit isn't too difficult, but 8-bit color uses a pallete, and would require a different set of graphics.If we supported 32-bit graphics, nothing would prevent it from using 8-bit or 16-bit graphics would it? It just wouldn't be using all the available colors.
"If a man does not keep pace with his companions, perhaps it is because he hears a different drummer. Let him step to the music he hears, however measured or far away" --Henry David Thoreau
32-bit implies 24-bit color with 8-bit alpha channel. Downsampling that is a bit trickier than downsampling plain 16-bit color, 1-bit alpha to 8-bit color, 1-bit alpha.krtaylor wrote:If we supported 32-bit graphics, nothing would prevent it from using 8-bit or 16-bit graphics would it? It just wouldn't be using all the available colors.
But heck, I just want to draw, I'll leave the coding to other people.
Not THAT more difficult, if you create smart graphics. My daily job is creating 32-bit XP styled icons, which shall work on a 256 color (8-bit) display as well. It can be done with smart color choices and well planned source material (32-bit).CobraA1 wrote:Scaling down to 16-bit isn't too difficult, but 8-bit color uses a pallete, and would require a different set of graphics.
I just did a search and noticed that Ludde hasn't posted to this thread. He's the creator and only developer, right? (Though some other nick did respond to my bug reports...)
So, this thread is just hypothetical, until either Ludde steps in, or some people present a good design spec/actual implementation to him?
So, this thread is just hypothetical, until either Ludde steps in, or some people present a good design spec/actual implementation to him?
Great. You draw when the format for the new graphic engine is knowneobet wrote:But heck, I just want to draw, I'll leave the coding to other people.
There will be A LOT of new graphics to make, so the project will need everybody, who are able
The same goes for coding. We have more things to do than people to assign to the tasks
Not really. Both involve creating a pallete and mapping the colors to the pallete.32-bit implies 24-bit color with 8-bit alpha channel. Downsampling that is a bit trickier than downsampling plain 16-bit color, 1-bit alpha to 8-bit color, 1-bit alpha.
16-bit color does not have 1-bit alpha. It's just 5/6/5 RGB.
8-bit color doesn't have 1-bit alpha, either. It's possible to set a pallete entry as transparent, but as far as the video card is concerned, it's just remapping a bunch of colors.
BTW, setting a pallete entry as alpha is not the same thing as setting a bit as alpha. If you set a bit as alpha in 8-bit color, you would have 128 transparent colors and 128 non-transparent colors!
Also, we have to be careful with the alpha byte in 32-bit color: Older video cards simply used it as a padding byte to make computations faster, and didn't support alpha. The extra byte can be used as alpha for storage and CPU purposes, but when sending it to the video card, we have to detect how the video card manages transparency.
"If a man does not keep pace with his companions, perhaps it is because he hears a different drummer. Let him step to the music he hears, however measured or far away" --Henry David Thoreau
Ok, of course, I simplified my statements. 8-bit usually implies 1 color masked off as transparent, while 32-bit implies a full 8-bit alpha channel mask.
But, doesn't SDL abstract this anyway? Isn't that what SDL is all about? Create a few hardware surfaces, ok. Load any image SDL can handle into one of them (say, a 32-bit PNG), ok. Show it on screen, ok?
Guess you know why I draw instead of coding, right now, because that's about as far as my SDL knowledge extends (I am trying to create a Speedball 2 SDL re-implementation, but I only have one sprite moving so far, and am fiddling with its animation).
But, doesn't SDL abstract this anyway? Isn't that what SDL is all about? Create a few hardware surfaces, ok. Load any image SDL can handle into one of them (say, a 32-bit PNG), ok. Show it on screen, ok?
Guess you know why I draw instead of coding, right now, because that's about as far as my SDL knowledge extends (I am trying to create a Speedball 2 SDL re-implementation, but I only have one sprite moving so far, and am fiddling with its animation).
Yes, it does, but it's always helpful to understand what's really going on. I haven't looked at SDL closely, so I have no idea how it handles color conversions. In general, going from 32- or 16- bit color to 8-bit color is ugly, I don't recommend it. It's better to have seperate, pallete-optimized, hand-tuned 8-bit graphics, and not to attempt a real-time conversion in the first place.But, doesn't SDL abstract this anyway? Isn't that what SDL is all about?
Dan: We will not be programming for a particular chipset . . .
"If a man does not keep pace with his companions, perhaps it is because he hears a different drummer. Let him step to the music he hears, however measured or far away" --Henry David Thoreau
Who is online
Users browsing this forum: No registered users and 26 guests