Clearing things up - R14/15 SDK and VS 2012, 2013



  • On 13/02/2014 at 01:59, xxxxxxxx wrote:

    Thanks, Robert, this really cleared it up ;)
    I think I will put R13 support on hold, and concentrate on getting R14 and R15 out the door.
    And if I want a plugin to be used in a specific version only, there has to be a way to detect the C4D version, an API call, so that one can prevent a plugin to load at all, if the wrong version.

    Originally posted by xxxxxxxx

    As for numbers of C4D users, that is difficult.  Not being an industry standard like Maya or SoftImage, it is definitely less than hundreds of thousands.  My guestimate would be in the tens of thousands for sure.

    I contacted the local dealer here in Norway, with the response that, yes. Maxon does not reveal the numbers. But, way beyond hundreds of thousands, the representative wrote.
    Which I really doubt. Here in Norway C4D costs around $8,000 directly converted to US Dollars, it is definitely another price in other countries, but still. One hundred thousand paying users would mean ~500 million US dollars per year, provided all upgrade, so they would have enough for overtime pizzas and a 7-up per developer ;))
    Interesting figures.. I would guess 30 000 paying users world wide. But - I have absolutely no idea at all, absolutely not. Other companies are more open about sales figures.



  • On 13/02/2014 at 02:27, xxxxxxxx wrote:

    GetC4DVersion() returns the version number in LONG (Int32) format like 15000 (for R15).  So, if you would like to disallow users to use the R14 build in R15, you can check a build number (enumeration or define) against the returned version number.  Then you might want to open a dialog to instruct the user on how to get the proper build version.



  • On 13/02/2014 at 05:25, xxxxxxxx wrote:

    The version of VS recommended by Maxon for R13 was, IIRC, VS 2008 but you can probably do it with VS 2010 instead (I say 'probably' because I've never tried it, but I expect it can be done).

    It should be possible to use VS2012 to compile plugins for R12 and R13.



  • On 13/02/2014 at 08:09, xxxxxxxx wrote:

    I have had no problems making R13 builds in VS 2010 and Xcode 4.6.  Just make sure that the project settings are commensurate and that the plugin exhibits no anomalies and you should be in good stead.



  • On 13/02/2014 at 10:46, xxxxxxxx wrote:

    I use the BaseArray a lot. It is not supported in R13. But I can use the BaseLinkArray in all my code, and the sourcecode will redirect to the BaseArray in R14 and upwards. Am I right? See this thread:
    https://plugincafe.maxon.net/topic/7389/9085_storing-baselinks&KW=basearray&PID=36266#36266

    Edited:
    The BaseLinkArray is not a Generics array, whereas BaseArray is. So I will run into a lot of problems making my code work for R13. Because I stuff my BaseArrays with all sorts of items, not only BaseLink*.



  • On 14/02/2014 at 00:56, xxxxxxxx wrote:

    Originally posted by xxxxxxxx

    It should be possible to use VS2012 to compile plugins for R12 and R13.

    It is. I am using VS2012 to compile and it works flawlessly.



  • On 17/02/2014 at 06:32, xxxxxxxx wrote:

    Howdy,

    Originally posted by xxxxxxxx

    ...I wonder how many still are using R13 and are willing to pay for plugins.
    Those who use C4D for professional use (well, who don't, considering the price tag it has) have probably upgraded?...

    I've noticed that my user database statistics show that since R15 was released, only 25% of my plugin sales to new customers have been registered to R15. The other percentages are 39% registered to R14, 23% registered to R13, 5% registered to R12 and the rest were registered to versions prior to R12. Of the existing customers who had registered plugins to R14, only 20% of them updated their plugin serial numbers to R15.

    You can use preprocessor directives to make your code compatible with different versions of Cinema 4D's API so that you code once and compile for all. One strategy I use for this is to create my own custom compatibility "wrapper" functions to keep my plugin coding cleaner.

    Like this:

    Bool MyCustomFunction(BaseList2D lst, Real parameter)
    {
    #if API_VERSION < 12000
    	return lst->SetOldParameter(parameter);
    #else
    	return lst->SetNewParameter(parameter);
    #endif
    }
    

    In the above example if something changes in the R14 API, then I simply add another preprocessor directive to the custom function, and leave my plugin code as it is. 😉

    Adios,
    Cactus Dan



  • On 17/02/2014 at 06:43, xxxxxxxx wrote:

    Thanks a lot, Dan! And Howdy to you too ;)
    This is are interesting figures. I am surprised that the market for R13 still is worth considering, and I see that my assumptions were wrong. I am not surprised that people do not upgrade to R15 an mass, because R15 did not introduce much improvements IMO. Instead, it fixed the FBX importer bug, and broke the camera shader (arghh). And the Team Render, while ingenious on its own,  is immature IMO. It lacks several functions that the old net render had. At least it needs a monitoring function, so that I can see what is going on, what each client really is doing.

    And thank you for the tip on how to differ between versions, a great tip!!
    My challenge is to compile for R13, because I use the R14 BaseArray a lot, which uses Generics. and the R13 BaseLinkArray does not. So I have to find a solution here. Have I overlooked something, is there an easy way to deal with this?



  • On 17/02/2014 at 07:38, xxxxxxxx wrote:

    In R13 (and earlier), just use bNew (class array allocator) and bDelete() instead of BaseArray.  BaseArray is faster but since it isn't really supported well in R13 (it is there but 'unsupported'), these are the best alternatives.



  • On 17/02/2014 at 08:05, xxxxxxxx wrote:

    Originally posted by xxxxxxxx

    BaseArray is faster but since it isn't really supported well in R13 (it is there but 'unsupported')

    Aha? So it can be used after all?

    I have looked at bNew, and find so little use of it in both the R13 and the R14 sdk examples, that I still do not understand how to use it. I tried to follow the syntax in the files I found, but get compiler errors when I try it myself.
    Is bNew really a viable replacement for BaseArray if I want to compile my R14 code for R13?



  • On 18/02/2014 at 04:52, xxxxxxxx wrote:

    Howdy,

    Originally posted by xxxxxxxx

    ...My challenge is to compile for R13, because I use the R14 BaseArray a lot, which uses Generics. and the R13 BaseLinkArray does not. So I have to find a solution here. Have I overlooked something, is there an easy way to deal with this?...

    The solution to that is to write your own array class template so you can use it across versions. 😉

    Adios,
    Cactus Dan



  • On 18/02/2014 at 06:08, xxxxxxxx wrote:

    Yes ;)
    AFAIK, the BaseLinkArray will behave like this, behind the scenes. Be a "real" BaseArray when compiling using the R14 SDK, and an old BaseLinkArray when using the R13 SDK.
    I just need to find a way for it to support generics.


Log in to reply