New Console.print method should use bg/fg=None as a default

Hey,

So, I’m looking on the new print method and I find the default bg behaviour weird.

Here is a simple example of what I would expect :

console = Console(width,height)
console.bg[:] = color1
console.print(x,y,value)
# I expect my value to be printed with bg=color1, not what is happening

Instead of having a value with bg=color1, I have a bg=(0,0,0). It’s weird and forced me to do that for every print I want to use :

console = Console(width,height)
console.bg[:] = color1
console.print(x1,y1,value,bg=color1)
console.print(x2,y2,value,bg=color1)
console.print(x3,y3,value,bg=color1)

You have de facto a default color palette here which is white on black. If you use None as default, you don’t have this issue anymore.

In fact, the deprecated default_bg/fg could still exist, but would never interact with this print method.

also : see my comment here

[HexDecimal]

So, it is safe to directly manipulate ch,bg,fg via Numpy method, without creating another Numpy array before-hand. In fact, it is better to manipulate ch,bg,fg directly especially if you don’t use the same Numpy data type between your Numpy array and ch,bg,fg (because, then there would need to be some kind of cast above the array copy). (tell me if I’m wrong)

Casting from any NumPy array to another is often just as fast as copying regardless of type (it’d likely hit a memory speed bottleneck first, so smaller types are faster,) but casting large amounts of Python values to anything is slow. This discourages using Python classes for tiles and such, you’ll want to implement them as a NumPy dtype instead.

So anything that could not be vectorized, I should use the printing function, and for the rest, I should use Numpy. So basically, I should use the printing function for anything that write text.

Methods like draw_rect are still good if you don’t need more functionality. You might prefer python-tcod’s pathfinding and field-of-view algorithms over making your own implementation, and you can profile your code to figure out what you need to improve right at this moment.

[HexDecimal]

I’ve been assuming that working directly with ch,bg,fg is equivalent to working with a distinct numpy array and then copying this array to ch/bg/fg. Or rather, I’ve been assuming that it’s better to directly work with ch,bg,fg, as it doesn’t have the overhead of copying an entire numpy array to another.

But looking at the source I don’t really understand how ch,fg,bg interact with console_c. If I understand well, methods like print uses the libtcod API directly. Wouldn’t it be better if instead of it they would manipulate ch,bg,fg instead, so that it does not leave the boundary of python until you want to blit the console ?

console_c is a struct TCOD_console* type. This struct is initialized once with pointers to the NumPy ch,fg,bg arrays which are created and owned by the Python Console itself. When console_c is used with a call to C only the pointer to the struct is passed and the C function can interact with the NumPy arrays as if they were managed by C the entire time. The overhead that remains comes from converting all the other Python parameters into a C format, which only adds up when you call the methods too frequently.

Re-implementing the methods in NumPy wouldn’t solve the problem since the “Python -> C” step still occurs even when working with NumPy. You’d have to write “NumPy -> NumPy” code to skip that step. Also, only draw_rect and draw_frame can be vectorised, the printing functions would be much slower written in Python as I learned the hard way when I wrote python-tdl.

To be clear, I am aware that looping over a Numpy array is also not a good idea, but sometime, you need the loop anyway and I assume that looping over a Numpy array is better than looping over the console_c with a call to the libtcod API.

It’s not always easy but if you can make sure your inputs are arrays then you can vectorise the entire operation once you’re more familiar with NumPy.