Woody - openAL physical modeling synthesis

BlitzMax Forums/BlitzMax Programming/Woody - openAL physical modeling synthesis

Taron(Posted 2016) [#1]
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:




Taron(Posted 2016) [#2]
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?


col(Posted 2016) [#3]
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.


Taron(Posted 2016) [#4]
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!


col(Posted 2016) [#5]
No I've not tried it, at work for a little while longer. I assume you've tried rebuilding all of the modules?


Taron(Posted 2016) [#6]
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...>.<


col(Posted 2016) [#7]
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.


GW(Posted 2016) [#8]
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.


Taron(Posted 2016) [#9]
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!