The call to set_thickness() must be made before the call to draw_line(). Also, line thickness is only supported in OpenGL, so make sure you are using OpenGL in your Config.prc file.
Are you saving the AudioSound object returned from get_sound() in a PT(AudioSound), or just in an ordinary AudioSound *? The former is correct. If the latter, it will destruct and make itself invalid before you can use it.
first off, the problem i have with panda at c++, only the dx is supported, if i try to run panda on opengl my application crashes.
before i tried to run a autonom audiofile, i wanted to include a video with audio supported, that why i used PT(MovieAudio)ā¦
yes, im used/using PT(AudioSound) (sorry i forgot to write this lines in here), so i changed my code to this, but this is also not working (neither on openAL, or fmod):
Hmm, if your OpenGL isnāt working, perhaps you just need to install a new graphics driver? If you canāt use OpenGL at all, you wonāt be able to use thick lines, because itās an OpenGL-only concept. You could use the more-complex RopeNode class instead of LineSegs, though; and RopeNode provides the RM_tube or RM_tape render modes, which can simulate thick lines, even on DirectX.
I donāt understand this sentence:
Do you mean the audio only works for 5 seconds, and then it stops working?
then i have to use dx (i have already the newest drivers installed) anyway, i just use this lines for displaying my raster at my AI and particle mode. i can work with that.
the sentence which you dont understand.
it means that the sound only gets 5 seconds playback, then it stops to play.
so now it works via fmod, but i cant fix it for openAL. there is still this 5 sec behavour.
if you mean the developing platform = vc++ 2008 express
if you mean the os, then its win 7.
if you mean the panda3d = 1.7
// sound
sound = high definition audio device 6.1.7600.16385
the audio support on openAL isnt that importing at moment.
but the graphic ~bug, is a bit a pita. its not really smooth that i can only compile for dx8. it would be ok, if the dx9 would work, but neither dx9 is working for dev on c++. yes, i installed the dx9 sdk.
maybe i have to fix the reg. for?? which keys needs to be changed?
maybe someone have a idea? i need to build shaders and i wanna create those with dx9 or opengl supporting.
thanks
(if there is no solution for, i have to work on my other machine. but i love to work on the laptop)
First of all, I take it that you are using the panda binaries and didnāt build your own panda. If you have problems building Panda with DX, let me know, thatās a whole other story.
You donāt need to install a DirectX SDK to build a Panda app that can use DX, because the DX support is already linked inside your panda distribution, you just need to install the runtime to run the app. Did you install the DX9 user runtime?
EDIT: krid, about the sound. I would like you to try something, Iād like to find out if this fixes your problem.
When I say ābinary dirā I mean the dir where the panda dllās are, typically c:\Panda3D-1.7.0\bin.
Go to your binary dir, and remove (make a copy somewhere) pandaopenal32.dll and pandawrap_oal.dll. Or to make sure they arenāt loaded from the path rename them to .dl_.
A guy on irc had exactly the same sound problem with Openal, but in Linux, that kinda gave away it was a ffmpeg problem. He gave me his mp3 and I was able to reproduce the problem and fix it. Note that the problem also occurred when converting the mp3 to a simple wav format. The problem is the length.
In FfmpegAudioCursor::read_samples() thereās a max number of tries, by default 100, to read a valid sample. This fails because larger files may need more tries (I donāt know what those invalid samples are but they could be a lot of things). The fix was merely to remove that and rely on the amount of samples received to know where to end.
So any clue what was the purpose of that limitation? If it was there for a reason Iāll need to find a proper replacement before removing it.
Doh, Iām ashamed it didnāt occur to me to just check CVS, I assumed the limitation would have been there from the initial commit.
So it seems to me the proper fix instead of the arbitrary 100-tries limitation was to convert reload_buffer from void to bool, check for 0 but return false on <0 and true on 0 so that the loop at read_samples() can break. Then again the only way to check that this still fixes the original problem is to get an offending audio file that caused this infinite loop from the author, I donāt know if thatās possible. Also, Iām not even sure of the implications of the change, for example Iām not sure under what circumstances ffmpeg produces silence, Iām not treating it as a loop-breaking event. Summary: little confidence in this patch.
So hereās the patch with the solution described above pastebin.com/HwRG71Tw . It fixes the āsound cut-offā problem people have been reporting for 2 years but for your own tranquility you should try to test it with eiforallās broken sound sample and see if you still get the infinite loop, so Iām not committing it unless you want me to go ahead.
(Also, maybe we should update the ffmpeg build we have in the thirdparty package, itās ancient. I looked into building it for MSVC but it looks like a pain.)
EDIT: Updated the link to a new patch, first one had a vestigial debug message and bad indentation.
After discovering the shocking identity of the original committer Iāve been talking to him. We have decided to go ahead with my patch as we havenāt been able to determine for sure the nature of the original bug. In any case this will fix more things that it breaks for sure. Iām committing it, but let me know if you experience freezes while playing audio.