Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Image::loadDynamicImage not correctly wrapped in C# #2437

Open
dmacka opened this issue Apr 20, 2022 · 3 comments
Open

Image::loadDynamicImage not correctly wrapped in C# #2437

dmacka opened this issue Apr 20, 2022 · 3 comments

Comments

@dmacka
Copy link

dmacka commented Apr 20, 2022

I kind of don’t know where I should address it but there are a few changes to this engine since 2007 my project is old and linked to an older version of Axiom. I wanted to get my client upgraded to DirectX11.
I been looking for a change log to see how to address my internal errors making calls to obsolete functions. BUT that is one of the smaller issues.
Okay, I have the current Git cpp version of Ogre which I build my C# exports and then I added some function to the library source and recompile it to a new library. I made headwind into the old multiverse files until I needed to access the buffer.

The library Image.cs needs to create a buffer. I pass it as byte[] * but the Image
Error CS1503 Argument 1: cannot convert from 'byte[]' to 'org.ogre.SWIGTYPE_p_unsigned_char'

Ok so that is easy fix??

SWIGTYPE_p_unsigned_char sucks;

image.loadDynamicImage(sucks, (uint)pageSize, (uint)pageSize, PixelFormat.PF_A8);

Error CS1503 Argument 1: cannot convert from 'byte[]' to 'org.ogre.SWIGTYPE_p_unsigned_char'

Okay so of course suck = new SWIGTYPE_p_unsigned_char();

Error CS0122 'SWIGTYPE_p_unsigned_char.SWIGTYPE_p_unsigned_char()' is inaccessible due to its protection level.

If you get the Type of SWIGTYPE_p_unsignedchar_chr it does come back as byte[] and not a pointer to byte[]

I kind of don’t know swig that much. I’m trying to decide if it’s in the Swig compile files or if it is addressable inside the cs source. Actually I am a little concerned on how much the conversion is going to hamstring Ogre output to the frame buffer. Almost tempted to rip that out and use the old library and make using statements to point to that section.

Anyway, I thought it may be a issue addressable on your end.

@paroj paroj added the SWIG label Apr 20, 2022
@paroj
Copy link
Member

paroj commented Apr 20, 2022

SWIGTYPE_p_blah is a dummy meaning, that SWIG does not know how to handle that pointer type.

you could do something like this

%apply void *VOID_INT_PTR {void *}

which allows you to pass an IntPtr, where void* is used in C++. The same is probably also needed for char*

@dmacka
Copy link
Author

dmacka commented Apr 20, 2022

I think I'll rip the provokes and do direct access to stream. Like I said this reduces the clock cycles and since MV controls the library uses its own scene manager, it does this every frame. I don't think it will affect the Ogre threading since I'm calling Ogre allocation to get my pointers anyway.

@paroj paroj changed the title Pointer issue Image::loadDynamicImage not correctly wrapped Jan 13, 2024
@paroj paroj changed the title Image::loadDynamicImage not correctly wrapped Image::loadDynamicImage not correctly wrapped in C# Jan 13, 2024
@paroj
Copy link
Member

paroj commented Jan 13, 2024

in python we leverage the buffer protocol to cast input arguments:

%typemap(in) void*, Ogre::uchar* {

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants