Drawing on MultipassBitmap's GeClipMap crashes in R16.050



  • I know R16 is old history by now, but I still want to keep my plugins compatible as much as possible.
    I had updated the R20 version of the plugin, and wanted to port back the updates to R19. However, due to compatibility reason, the plugin is being developed with the R16 SDK.

    Following is an excerpt of the implementation that was ported to R16.

    	const COLORMODE colorMode = COLORMODE_ARGB;
    	MultipassBitmap* multiBitmap = MultipassBitmap::Alloc(mBitmapSize, mBitmapSize, colorMode);
    
    	MultipassBitmap* layer = multiBitmap->GetLayerNum(0);
    	layer->SetParameter(MPBTYPE_NAME, "Background");
    	layer->SetParameter(MPBTYPE_SAVE, true);
    	layer->SetParameter(MPBTYPE_SHOW, true);
    	// draw onto this layer via a ClipMap
    	AutoAlloc<GeClipMap> clipMap;
    	if (clipMap && (clipMap->Init(layer) == IMAGERESULT_OK))
    	{
    		viewData->mClipmap = clipMap.operator GeClipMap *();
    
    		clipMap->BeginDraw();
    		viewData->DrawBackground();
    ...
    
    void ViewData::DrawBackground()
    {
    	Vector color(128);
    	mClipmap->SetColor(SAFEINT32(color.x), SAFEINT32(color.y), SAFEINT32(color.z), 255);
    	mClipmap->FillRect(0, 0, mClipmap->GetBw() - 1, mClipmap->GetBh() - 1);
    ...
    
    

    Building the plugin (with R16 SDK) and running it from Cinema 4D R19 yields no problem.
    However, when running in R16.050 it just locks up, or when ran in debug from VisualStudio it crashes when FillRect, or any other GeClipMap drawing function is performed.

    Now, I understand no support can be given for R16, but I just wanted to make sure it was a problem then (which has been fixed since). Or if I need to do something different in R16 to make it work.
    Have not yet tested with R17 or R18 to know where the boundary "works / does not work" actually is.



  • Hi,

    we are actually not aware of changes in this area.
    Is this some new functionality you were implementing or is this an issue, that came up by adding changes needed for R20? Or is it even a long standing issue?
    If you could provide us with more details at which version your problems start, it would help a lot to reduce any research needed.

    Cheers,
    Andreas



  • @a_block
    Sorry if I wasn't clear with my message.
    I had added new functionality in my R20 plugin, which works OK using the provided code snipped.
    From this I went back to earlier releases and ported the changes made in the plugin.
    The changes do work on R19, R18 and R17, but are an issue in R16. Tested with the same plugin, built with the R16 SDK, copying into the different releases' plugins folder.

    For now, I have added a check in the plugin, and avoid creating a multipassbitmap if version is prior to R17.
    Since nothing seems to have changed in this area, I am wondering what's the actual issue ... and if I might by accident have something working in R17 - R20.



  • Hi,

    I checked our change logs R16 to R17 and I see no mention of anything that could lead to your issue. So I would need to dig through lots of change lists in our revision control system, which I'd rather not do.
    Also I see no immediate issues with your snippet above.
    Not sure, we should dig into this further. Also because you seem to have a workaround.

    Cheers,
    Andreas



  • @a_block
    I don't actually have a workaround, I simply do not allow the feature to be used on pre-R16. (EDIT: should read "pre-R17")

    However, I don't see the point for further digging. If something didn't work in R16, there's no fix nor update to be expected.
    And since no problems seem to exist from R17 on, all is fine for users using R17 and above. Too bad for the R16 users, I guess.

    Seems it's time for me to move on and start skipping support for older versions.

    Thanks for taking the time to investigate.



  • Just some ideas and guesses:

    • check if layer is not actually a nullptr. Might fail there already.
    • I would try a dynamic_cast<BaseBitmap>(layer) for layer in clipMap->Init(layer) just to be sure the right vtable is used. AutoAlloc might do something fancy there.
    • why not use viewData->mClipMap = clipMap; ? Your use of operator*() seems strange. Also, why not just use it as parameter to DrawBackground()?

    Cheers,
    Martin



  • @martinweber said in Drawing on MultipassBitmap's GeClipMap crashes in R16.050:

    Just some ideas and guesses:

    Thanks Martin.

    • I do check if layer is nullptr, but hadn't included this in the provided code snippet, in order to keep it as short as possible.
    • Tried to cast the layer to basebitmap before using it to initialize a GeClipMap. Still same problem.
    • Using operator GeClipMap *() is something I picked up from ... (cannot remember). I confirm that simply assigning the clipmap to viewData->mClipMap, does work as well. However, passing clipmap as parameter to DrawBackground is not an option in my situation.

    Tried all of the above, but still get an exception thrown as a result of access violation writing location 0x00..03FF when performing a clipmap->FillRect.

    The SetColor is fine, and so are the GetBw and GetBh, but the actual FillRect throws an exception. But only on a MultipassBitmap. Doing exactly the same on a regular BaseBitmap is fine.



  • @C4DS I see. Does Clear() work?

    I am curious as we have a use case where we would go with GeClipMap as well.



  • @martinweber
    Never actually cared trying Clear() as this is a BaseBitmap method, and not GeClipMap.
    But I tried now just to check, and while it doesn't crash Visual Studio reports that it triggered a breakpoint. No crash, but not a good thing either.
    And so does calling SetPen() or Line().
    Unfortunately, the output is left empty. I have tried using a simple RGB colormode, instead of the original ARGB ... hoping the issue might have something to do with the alpha channel. But same issue no matter the colormode.

    Seems I am unable to draw on a MultipassBitmap in R16.