If you're following the news about SDL (our video and keyboard interface), you know that after many many years, a new SDL version has been released (SDL 2.0). One person found that interesting enough to clone our github repository, and modify the program for the new interface. Unfortunately, he left before I had a chance to look at the changes in detail and discuss them.
Another thing that has come up at times is the question of 32bpp colour (aka full colour) support. At the start of the project, we considered 8bpp colours enough (just like the Rollercoaster Tycoon 1 & 2 programs). However, you see an increasing interest in full colour from users. Also, the video hardware is moving away from 8bpp. In other words, eventually, we will need full colour support for the program. Thus, I took this opportunity to add 32bpp support to the program, together with the switch to the new SDL 2.0 library.
At the top-right you see the before and after images. Looks the same, you say? Well, you're right about the grass. In both images it's the same sprite. The shop however is different, as you can see below at 800% zoom. The left part shows the shop as we had it from the start. The right part is the same shop, but in 32bpp. The right image is much smoother at 800%, without the weird coloured pixels here and there.
Technically, the program accepts and renders both 32bpp and 8bpp images. Our current shop sprite isn't a great example of what you can do with full colour support, but I am sure we will get shiny new colourful graphics somewhen.
Very nice work! Time for me to do some graphics!
ReplyDeleteNice, but I still prefer 8 bpp sprites. Please, keep the two options.
ReplyDeleteI am not sure I understand your remark. 32bpp gives you 2**32 possibilities to define a colour. 8bpp gives you 2**8 = 256 possibilities to define a colour.
Delete(And to be precise, FreeRCT uses about 18 colour ranges each with 12 shades = 216 of the 256 colours.)
That's the only major difference between 8bpp and 32bpp in terms of colours.
So while 32bpp has a lot more possible colours, there is nothing that forces an artist to use all those colours. He could decide to draw everything in 2 colours (eg black/white), or in 18 ranges of colours, each colour in 12 shades (this is what FreeRCT does internally, of course).
In my view, having 32bpp only lifts a limitation for a graphics artist, it is an artistic choice how to use that freedom. He can still make 8bpp-like graphics in 32bpp only.
I prefer 8bpp because I like it. The original RCT is based on 8 bpp graphics.
DeleteAlso, IMHO 8 bpp looks sharper than 32 bpp, which looks too smooth.
Thank you for keeping 8bpp as an option. Going 32bpp only would reduce the list of platforms FreeRCT could be ported to. Also, just a guess, 32bpp probably uses more resources effecting which hardware can run it a acceptable speed.
ReplyDeleteSorry, but you are a bit fast in jumping to conclusions. Being able to load 8bpp sprites into the program does not imply they are also drawn in 8bpp mode by the video blitter.
DeleteTo allow drawing 32bpp sprites, you need to have a 32bpp video blitter. The 8bpp sprites are simpy extended to their palette colours while drawing the sprite. Thus, the program is always drawing in 32bpp mode, and the artist is the person that makes the choice what type of images to supply.
The current video blitter implementation is pretty stupid, and does take more resources. However, if you improve it by moving more work to the GPU, performance should become much better. (Software-CPU rendering is slow compared to GPU rendering with dedicated hardware.) I haven't implemented this due missing insights in sprite recolouring.
If you really want 8bpp support only, you can build of course an 8bpp blitter and in some way ensure you'll always have an 8bpp sprite to draw, but how many platforms will need that in a couple of years?
CPU-based rendering and 8bpp video is becoming extinct at the desktop already, in my view, it's a matter of time until all platforms will have full colour support.
Yay! I thought this project was dead.
ReplyDeleteWow, wonderful project! Keep up developing the best game ever!
ReplyDelete