News:

Simutrans Tools
Know our tools that can help you to create add-ons, install and customize Simutrans.

Functions for drawing primitives using direct color values

Started by Ters, October 06, 2013, 10:40:34 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Ters

Currently, all functions for drawing geometric shapes and text take a PLAYER_COLOR_VAL, limiting them to the colors in the special colors table. While useful, I believe the new GUI could benefit from being able to draw arbitrary colors. The patch extracts the color table lookup from the rest of the code. New functions have an _rgb postfix. The functions with the old name typically look up the color value, then call the _rgb function.
With GCC, the _rgb functions are inlined into the indexed functions, so there should be no performance degradation from an extra function call. The size of the machine code grows however. For some of the functions, there should be a tiny performance gain from not having to look up the actual color value in the special colors table. A few other functions which also just call other primitive functions could also be altered slightly to take advantage of this, but I haven't done it.
display_ddd_proportional actually does use PLAYER_COLOR_VAL for what it name implies, and have not been given an _rgb equivalent. It could be, but only for the text color.
Although I have changed both simgraph16.cc and simgraph0.cc, I have only test run simgraph16.cc. There might also be some functions that are only used in obscure places that I haven't be able to check the behaviour of.

Max-Max

Great!  :thumbsup:

I just have to revert my implementation then ;)
I will try out yours...

Question, does PIXVAL need to be RGB1555 or RGB5155? I found out that RGB5155 is the final format used for drawing, but a lot of colours used where in RGB1555. By using RGB5155 directly I could skip one look-up table.
- My code doesn't have bugs. It develops random features...

Ters

I've never heard of RGB5155. Simutrans uses either RGB555 or RGB565 in the framebuffer, depending on the backend/OS/driver/hardware. Images loaded from pak files use RGB1555, where the upper bit signifies a special color. They are converted to RGB555/RGB565 during recoding. get_system_color(r, g, b), and everything based on it, should give the value my _rgb functions want.

Max-Max

- My code doesn't have bugs. It develops random features...

Ters

Quote from: Max-Max on October 06, 2013, 03:53:36 PM
Ahh, so the green component is 6 bit?

Yes. The human eye is actually more sensitive to green, so that's why they put the spare bit to use there, or so I've read.

Max-Max

Yes, you are right... Will keep this in mind, thank you.
- My code doesn't have bugs. It develops random features...

prissi

That patch is a good idea. I just make specialcolormap a public member and then just #define something in simugraph.h accordingly. Then all the magic would be in the header file.

That reduces the unneeded functions in simgraph16 and would point more forward to using RGB throughout than having both functions.

Markohs

What about adding ",bool use_indexedcolors = false)" to all headers?

Just an idea.

prissi

Just a define to avoid this. Much easier as it can be removed later (we should do this also on the display_proportional defines and rather use the magic of default parameters now that this file is only used under C++ ...

EDIT> Submitted more or less Ters patch, but removed the old functions and replaced them by macros. Some of those macros shoudl go to (like the many displa_por... and just use default parameters, imho).