Clearing things up - R14/15 SDK and VS 2012, 2013
-
On 13/02/2014 at 00:46, xxxxxxxx wrote:
For R13 you will need to compile with the R13 SDK. 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).
If the plugin is compiled with the R14 SDK it should be fine in R15. If it's compiled with earlier SDK versions it might not work in R15, never tried that either
For C4D plugins I wouldn't touch VS 2013 with a bargepole until Maxon recommend its use (because then the SDK examples will contain the correct project setting files for that version of VS).
-
On 13/02/2014 at 00:56, xxxxxxxx wrote:
Thanks a lot for this!
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 am very very very curious about how many paying C4D users there are out there, and what versions they use. And where they are located around the globe.
Are there thousands, tens of thousands, hundreds of thousands? I have absolutely no idea. Yes, Maxon will not reveal those numbers. But some indicators of these numbers ought to be possible to find. -
On 13/02/2014 at 01:23, xxxxxxxx wrote:
Basically, plugins are not backwards compatible (only forwards compatible - to certain degrees). The API of R13 can not possibly recognize the API changes in R14. You may have also noticed a similar situation with saved C4D documents at times.
Typically, older plugins will work without problems in new versions of C4D. In the case of R13, there were changes that required all plugins to be built against the R13 API. In most cases, my R13 plugins builds work fully in R15. I do have one that required a specific R15 build because some features no longer worked as expected.
From my years of experience, the greater percentage of users will be using the latest version (within the year of its release), next using the previous version, and the percentage drops quickly for even older versions. For instance, I do not even support R6-R12 any longer. For sales, it is not even worth the effort since there are so few users with those versions (and they probably can't afford commercial plugins if they are still using such antiquated versions).
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.
-
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://developers.maxon.net/forum/topic/7389/9085_storing-baselinks&KW=basearray&PID=36266#36266Edited:
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.