@aristurlte The C++ preprocessor changes the source code and expands the macro, yeah?

Could your C++ to C# 'converter' do the same? So there is no method or func just the expanded code?

Or do you need to be able to apply the macro to new code?

If you see what I mean

@PumpkinGames oh, I'm not that fancy that im using a coverter. I'm porting it manually.

Like cpp on one monitor and I'm coding it in c# on another.

It's a small handful of methods I'm porting over (~25) but they all make use of ~10 macros.

(For reference, I'm porting portions of the blend functions from Aseprite https://github.com/aseprite/aseprite/blob/main/src/doc/blend_funcs.cpp)

@aristurlte In that case, probably a static Blend class with static methods for each macro.

Probably wouldn't inline either unless a profiler showed this was some sort of bottleneck.

The jitter (assuming not !AOT) has it's own ideas on whether to inline so I think the attribute is just a hint anyway

@aristurlte PS - I think Noel Berry has done some of this already so you might get a leg up maybe...

https://github.com/NoelFB/Foster/blob/master/Framework/Graphics/Images/Aseprite.cs

@PumpkinGames Yea, Noel's only supports Normal blend mode, which I think is what most people would use anyway.

I wrote the MonoGame.Aseprite library that has full blend mode support

https://github.com/AristurtleDev/monogame-aseprite

But it is in desperate need of refactoring which I'm in the process of doing now as AserpiteDotNet

https://github.com/AristurtleDev/AsepriteDotNet/tree/develop

Originally did write the blend_funcs as static methods, but remembered that Func<T> delegates where a thing started wondering.