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.
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?
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.
(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?
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.