string size limit

[HaWe]

safecall means: this function or procedure can only be called once at a time, if many different threads try to call this function at the "same" time it is protected of being called before the first thread is finished with it, then the next, and so on - it's sort of using mutexes.

[afanofosc]

The safecall option makes it so that if two threads tried to acquire the bitmap handle "at the same time" only one of them would be able to execute either of these two functions at once. The second thread that tries to call AcquireBitmapHandle would wait until the first thread returned from the function call. It makes these non-inline functions thread-safe. It also makes sure that two threads can't race to acquire the bitmap handle at the same time. Once one thread has acquired the handle the other thread would get back an invalid handle (0). Functions in NXC are only thread-safe if they are declared as inline or safecall.

The magic numbers and the color table have a trailing null because the SysFileWrite system call expects that the Buffer field is null terminated. So I could have used ByteArrayToStr to copy from the magic number buffer or the color table buffer into the rwArgs.Buffer field or I could just move the value using = if the original buffer already has the null at the end. So technically, I was wrong to say you shouldn't use strings since at the point where you call the Write operation you do have to use a null terminated byte array, aka, a string. But generally I think is is best to not use the string type for binary data unless it is absolutely required like when calling SysFileWrite. Because these two buffers have a null at the end I use StrLen instead of ArrayLen to retrieve the length for the header and for the Write operation.

John Hansen

[mattallen37]

Okay, that makes sense. Thanks for the explanations!

[mattallen37]

Just so you know, I changed the function __getBitmapPixelDataSize() to:

Code: Select all

inline unsigned long __getBitmapPixelDataSize()
{
  unsigned long result;
  byte delta = __bmp_width % 32;
  if (delta){
    result = (__bmp_width + 32 - delta) * __bmp_height;
  }
  else{
    result = __bmp_width * __bmp_height;
  }
  result /= 8;
  return result;
}

so that it takes into account the multiple of 4 byte requirement.

I didn't test it with arbitrary sizes before, but I did afterwards, and it seems to work fine.

This function is only used to determine the number of elements required for the buffer, as well as ensuring the proper buffer size, and both of those need to be a multiple of 4 bytes per line.

BTW, 493x493 seems to be the max size, assuming you don't really use any RAM for other stuff, and 491x491 works perfectly for my simple example program (although I want it to be an even number, so I am using 490x490).