NewsForumsCodeLogsGallerySpecsSearch

Passing a byte ptr to C++?

BlitzMax Forums/BlitzMax Programming/Passing a byte ptr to C++?

JoshK(Posted 2011) [#1]
How do I pass a byte ptr to a C++ library?

This is the C++ command declaration:
void SetTexturePixels(le3::Texture* texture, char* buf, int miplevel, int framenumber, int cubeface);

And here it is declared in BlitzMax:
Function leSetTexturePixels(texture:LETexture,buf:Byte Ptr,miplevel:Int,framenumber:Int,face:Int)="SetTexturePixels"

It doesn't appear to be working.

Last edited 2011


SebHoll(Posted 2011) [#2]
Is your C++ Declaration wrapped inside an extern "C" block to force standard C calling convention?


JoshK(Posted 2011) [#3]
Yes.

The function gets called, but the data contained in the byte ptr is not being read.

Last edited 2011


Chroma(Posted 2011) [#4]
In the C++ function you called it "cubeface" but in the BMax function you call it "face". Does that matter?


Brucey(Posted 2011) [#5]
Does that matter?

No.


beanage(Posted 2011) [#6]
Maybe an issue with Strict<>SuperStrict, void declaration, and the bmx function trying to return an int or something along those lines? Have you looked into what kind of data arrives in SetTexturePixels?


JoshK(Posted 2011) [#7]
Is the way I have this declared supposed to work, or has no one ever even tried doing this?


col(Posted 2011) [#8]
Hi, I'm currently doing similar things ( mixing c++ and BMax ) and I'll explain what I've found on my travels, hopefully it may help you to trace what may be going on there......

I was getting mixed up what was being returned by the c++... was it a pointer to data or a pointer to a pointer to the data. It took me a while and still trips me up now.

Ive also noticed that within BMax say you have a Type with 3 Fields. If you use a Byte Ptr to the type the pointer points to the first Field, not the address of the Type itself. Say you have a new Type at address $00403020 then use a Byte Ptr to it, the Byte Ptr will be $00403028, something to consider when passing into c++ using Byte Ptr or Var.

I'm messing with the D3DX and associated libraries with getting the D3DX skinned meshes, shaders, animation controllers etc working from within BMax, and its going really well already, boned skinned meshes and static meshes in text or binary are all loading and displaying perfectly after a tiny hackup thats easy to correct later so others can use it.

Anyway....For the most part I had confusion with what I should really be sending and receiving to/from the c++ code, maybe this is my bad c++ skills, but we've all got to learn somewhere.

Consider this....... where you have 'buf:byte ptr' this will point to the first piece of data in your buffer, your c++ code will probably want an address ( char* ), which is one reason it may not be working, the c++ will try to use the first 8 bytes of buffer data as an address and read from there.

Hope this helps in at least trying different things in getting it to work.

All the best

Last edited 2011


JoshK(Posted 2011) [#9]
I printed out the point values. They look correct:

BMX:
Print(Int(buf))
result: 37979488

C++:
Print(le3::String(int(buf)));
result: 3.79795e+007


col(Posted 2011) [#10]
so what is not happening ? i assume you are passing in a buffer of data and you want it assigned to the texture? in which case i assume thats happening ? but the texture in BMax isnt updating ?


JoshK(Posted 2011) [#11]
When I call SetTexturePixels() the texture is filled with what looks like random memory. When I call GetTexturePixels() the pixmap is unaffected, presumably because the memory is being copied to somewhere else.


Zeke(Posted 2011) [#12]
Function leSetTexturePixels(texture:byte ptr,buf:Byte Ptr,miplevel:Int,framenumber:Int,face:Int)="SetTexturePixels"


this is interesting:
SuperStrict

Import "test type.cpp"

Extern "C"
	Function dump_type(t:mytype) 'wrong values (correct values if using padding)
	'Function dump_type(t:Byte Ptr) 'correct values if no padding
End Extern

Type mytype
	Field a:Int=4
	Field b:Int = 7
	Field c:Int = 8
End Type

Local a:mytype = New mytype

dump_type(a)
bmx_dump(a)


Function bmx_dump(m:mytype)
	Print "bmx_dump"
	Local point:Byte Ptr=Int Ptr(Int Ptr((Varptr m))[0]) 
	
	point = point + 8 'skip 8 padding bytes
	
	For Local i:Int = 0 Until SizeOf(m)
		Print Hex(point[i])
	Next
End function


test type.cpp:
#include <stdio.h>

extern "C" 
{
struct mytype {
	int padding1; //comment if using byte ptr
	int padding2; //uncomment if using blitzmax type
	int a;
	int b;
	int c;
};

void dump_type(mytype* type) {
	printf("c++ dump\n");		
	printf("mytype.a=%i\n",type->a);
	printf("mytype.b=%i\n",type->b);
	printf("mytype.c=%i\n\n",type->c);
	
}
}


Last edited 2011


JoshK(Posted 2011) [#13]
The texture object isn't a problem. It's an Externed C Type, and all the other texture commands work fine.

You are right that for BlitzMax types, you do have to pass them to C++ as a Byte Ptr, and BlitzMax Null for Types is not the same as C Null for Types.


Gabriel(Posted 2011) [#14]
When I call SetTexturePixels() the texture is filled with what looks like random memory.

Where is the data you're "sending" coming from? A pixmap? What format of pixmap? Is this SetTexturePixels command one of your own or a particular API or library? What format is the created texture in? Is the texture you're trying to use compressed or uncompressed?


JoshK(Posted 2011) [#15]
It's an RGBA8888 pixmap

I am using it like this:
SetTexturePixels(pixmap.pixels,0,0,0)

The pixmap is an RGBA8888 pixmap.

Using this command in C++ to load textures works fine.


JoshK(Posted 2011) [#16]
The error had to do with how I was creating those textures.

The proper way to pass a Byte Ptr to a C++ lib is to use char* in the C++ parameter.

Confirmed, once and for all.


col(Posted 2011) [#17]
Excellent, I'm glad you got it fixed.


Czar Flavius(Posted 2011) [#18]
What is the padding used for in Blitz types? Virtual table and type id? Ref count?

Last edited 2011


col(Posted 2011) [#19]
c++ class constructor and deconstructor

edit: oops, I see the padding is in the c++ code, I've only seen and used it in the BMax code....hmmm.

Last edited 2011


Gabriel(Posted 2011) [#20]
The ref count is/was definitely in there, because there's the old typeinstance[0] hack to retrieve it. That's from before the new GC though, so whether it does the same with both the old and the new GC, I don't know.


Czar Flavius(Posted 2011) [#21]
Interesting. How does run-time type information work? This is more of a general question. When I cast a type to an extended type, how does it figure out whether it's an extended type or not?