Woody - openAL physical modeling synthesis
BlitzMax Forums/BlitzMax Programming/Woody - openAL physical modeling synthesis
| ||
Hi everyone, I will post a tutorial to this (probably) in a while. I was just playing around with some ideas and came up with this: |
| ||
Now I'm using BlitzMax NG, which immediately works fine at x32. Once I switch to x64 architecture, it compiles, but with no sound. Any ideas? Whoops, it's even worse... now the x32 built has no audio anymore either?! Hmmm...this is not as easy as it seemed. Also it has some compiling issues as you may notice, if you try. Seems like the openAL mod is not the same as before, or something else is weird. For example... original openal.bmx goes: Global alcOpenDevice( devicename$z )=P("alcOpenDevice") NG openal.bmx goes: Global alcOpenDevice:Byte Ptr( devicename$z )=P("alcOpenDevice") This is just an example, maybe pointing towards some other incompatibilities? |
| ||
Hiya, Yes, you need to be aware that any object that is a pointer in the c/c++ code should also be a pointer in blitzmax code. Pointers are different sizes depending on which cpu you compile for. In legacy 'max everything was 32bit and so an object returned from a c/c++ call would be a 32 bit pointer that would also conveniently fit nicely into an 32 bit Int. While this works well in the legacy compiler it is technically wrong as the returned type should be a pointer. So now if those return value types aren't being correctly set to a pointer type then x64 versions will see errors as an x64 pointer is a 64bit value and not a 32bit integer value! By setting the type to a pointer type means it will handle the difference architecture automatically and correctly. Things to look out for are any object instances returned from a library made in another language or from imported code that's written in another language. This usually relates to c/c++ object/struct instances and sometimes strings that are a part of POD types. |
| ||
I totally thought of that, int32 being the hickup. However, I wonder what went wrong that I can't even make the 32bit compile have sound anymore? Have you tried compiling the above with NG? OH, and thanks, of course! |
| ||
No I've not tried it, at work for a little while longer. I assume you've tried rebuilding all of the modules? |
| ||
Yep, did that, too. Ah well, looking forward to where this goes for sure! I hope BLide will get a proper implementation to compile NG 64bit, too! Feels so dreadful in the old IDE, hehe...>.< |
| ||
Just curious... What OS are you using? edit: I'm using Win10 x64 and I get the same results as yourself - audio in x86 builds but silence in x64 builds. However building for x86 then I get audio every time, regardless of how many times I build for x64. |
| ||
Taron, I use NG with blide. I just made a tweak to the NG BMK in that It defaults some flags to true. "-G x86" and "-quick" I think.. going from memory. Then blide will compile with NG. but just 32bit. If I need 64bit, I have my main file also open in the NG ide and just hit compile there. It's bit hacky but it works. |
| ||
That's cool, I will give it a try with Blide! Would be exciting! But, yeah, what ever I did to mine, can't get sound back. <shrugs> At the end, though, for what I wanted to do, I need x64, also hoping to get rtMidi to work. Then the party could really start! |