- December 1, 2010 at 9:32 am #30382
Hi ,When i launch my application in msdev 2008 in debug mode my application linked to pvr frame libraries works fine. However the same application when launced from outside Visual studio fails to initialise. It throws the following error.PVR : VFrame attempted to use one of these functions:PVR: wglChoosePixelFormatARBPVR : But these are not available on your machineIgnore?On chosing ‘yes’ to ignore the app crashes.December 1, 2010 at 11:04 am #34584
It sounds like you’ve placed the VFrame libraries in a directory that Visual Studio can see, such as the working directory, but your application does not have visibility of them outside of Visual Studio. If this is the case, you can resolve this by placing the VFrame libraries in the same directory as your executable.December 2, 2010 at 8:44 am #34585
Hi Joe,To test your options i did the following,1. Made sure that the exe is build correctly with the PVR Frame libs2. In the execution directory i renamed the two dll’s libEGL.dll and libGLESv2.dll.Now the application failed to launch (as expected), therefore it is using these two PVR Frame dll’s.Regards,SumerDecember 2, 2010 at 9:38 am #34586
I’m not sure I understand the change you’ve made. In 2., you should not have renamed anything. Instead, you should have copied the .dll files from the VFrame folder of the SDK (e.g. PVRVFrameOGLES-2.0Windows) to the same directory as your executable.
JoeDecember 2, 2010 at 11:26 am #34587
The same issue I am facing while running my OpenGL ES 2.0 application when launced from outside Visual studio:- It fails to initialise.
But the application runs fine when I also use PVRTrace libs. I put the PVRTrace libs in the working directory & PVRVframe libs (actual Opengl ES 2.0 libs) in the system32 directory. Please clarify what might be the issue.
Piyush M (India)December 3, 2010 at 10:29 am #34588
I feel you have the same issue as sumer (with the application not being able to find the libraries) The reason that it works with the PVRTrace libraries is because the application finds the trace libraries within the executable directory. When they are found a pvrtrace.cfg file is made (if one doesnt exist) which specifies where the actual libraries are (this .cfg file points to the system directories by default).
Now you may have either changed the .cfg file to point to the directory where you have placed the libraries (which you can do) or you have placed the libraries where the the .cfg file is already looking (in the system directory)
I hope this helps
TomDecember 3, 2010 at 11:56 am #34589
Thanks for the reply. But the problem is still unsolved. Let me explain in a bit more detail.
My application works when the following is done:
Paste the PVRTrace versions of libGLESv2.dll ,libEGL.dll & PVRTrace.dll in the folder where the exe is present. Paste the PVRVFrame versions of libGLESv2.dll & libEGL.dll in the system directory where by default it will be searched. Then just double clicking the executable, it works fine. Even from within Visual Studio also I can run the application by pressing F5(Debug mode).
I get the same error as Sumer gets if I use the following obvious setup (I do not need Trace always):
Delete PVRTrace versions of libGLESv2.dll ,libEGL.dll & also PVRTrace.dll from the folder where my exe is present(this is the Bin folder where Visual studio generates the exe after compiling & linking). Replace it with PVRVFRame versions of libGLESv2.dll & libEGL.dll. Then just double clicking the executable, it throws the error as Sumer gets. However it runs fine from within Visual studio by pressing F5.
This should work. It is not proper to give so many dlls & request my client to paste at different places. And also if the applications runs for an hour the trace file will become huge. I am unable to figure out the problem.
PiyushDecember 3, 2010 at 12:39 pm #34590
To enable the emulation to run correctly there should only need to be
one copy of each of these DLLs on your
system. This may be in (amongst other places) system32 to be available
globally _or_ in the working directory of the executable. By default, the
version in the working directory will be searched for and loaded first.
By default, Visual Studio projects set the working directory of their built executables to be
the project directory and not the executable directory so this can
sometimes explain different results when launching from the explorer or
from inside the IDE. If DLLs are in the executable directory then they will not be found when VS launches them and so DLLs in other locations, like system32, are searched for and used, if available.
I’m not sure that this is relevant to the problems you are encountering, however, as PVRVFrame is giving an error message and Windows is not complaining of a mising DLL. This suggests that PVRVFrame has been loaded, but is encountering an error. There may be an issue with the normal PVRVFrame libraries that isn’t present when combining these with the PVRTrace libraries.
Which version of the SDK are you using and what version of Windows is this on? Do you have a minimal project that displays these problems?
Can you do the following, please:
– remove all of the mentioned DLLs from your system
– place the normal PVRVFrame DLLS (libGLESv2.dll and libEGL.dll) in the executable directory
– double-click the exe and post the output here
On another note, our emulator is designed to enable development for mobile and is not really intended for distribution as part of a commercial product.
If this is your intention then please get in touch with us on
email@example.com and outline exactly
what you are distributing the PVRVFrame libraries for.
For further DLL information please see:December 6, 2010 at 9:55 am #34591
I am not using the PVR SDK. I downloaded PVRVframe (Build: 2.07.27.0493), Built my application using the libs. Place the Dlls in the folder where the exe will be generated. Then double click the exe.
I am using Windows XP professional version 2002 Service Pack 3.
I did whatever you had suggested & below is the message on the MessageBox:
PVR: VFrame attempted to use one of these functions:
PVR: but they are not present on your machine.
Whether it should search for wglChoosePixelFormat when I built using EGL stuff, I do not know. This API is not there in my program.
Also be assured that I am using PVR Libs & Dlls for development of OpenGL ES 2.0 applications on Windows. It is in development phase. I am into automotive domain.
PiyushDecember 7, 2010 at 11:29 am #34592
A further problem/issue that is related to this topic I found out. As earlier told, a MessageBox appears in the begining showing the mentioned error message. If I click ‘ yes ‘ to ignore, instead of “wglchoosepixelformatARB”, the following OpenGL ES APIs are shown with the same error message in the following order :
glCreateShader, glCreateProgram, glGenbuffers, glGenbuffersARB, glUseProgram.
If I click at any stage “not to ignore”, my application exits. If I ignore then my opengl window comes up, but black. Also in the log tab window of the PVRVFrame GUI, errors like “In glBufferData error: 502(GL_INVALID_OPERATION): currently bound buffer is zero”
are shown. These don’t appear when application is launched from inside Visual Studio. I again compiled my App with PVRVFrame libs & placed the Dlls in the same folder as my executable. But same problem.
PiyushDecember 7, 2010 at 3:52 pm #34593
What grphics card have you got ? And what graphics drviers do you have installed for it?
JacekDecember 8, 2010 at 6:05 am #34594
Following are my working environment info:
OS: Windows XP Professional SP 3 (5.1, Build 2600)
Device: NVIDIA Quadro FX 1800
Drivers: Main Driver: nv4_disp.dll (version: 184.108.40.20665)
Driver Date: 22/04/2009
NVIDIA Compatible Windows 2000 Display driver.
Driver version: 182.65
I hope the above info is sufficient. Still I am unable to figure out what difference occurs when an application is executed through Visual studio & directly double clicking the executable with the Dlls placed in same location.
PiyushDecember 9, 2010 at 3:35 pm #34595
I have this same problem on my Windows 7 machine, ATI card and very latest driver.
Steve.December 10, 2010 at 2:34 pm #34596
I’ve filed this as an issue in our bugtracking system (BRN32024) and the engineer who works on PVRVFrame will investigate it.
Any details of your system that you can add may be helpful.
If any of you can send a minimal reproduction of the problem to firstname.lastname@example.org then this may help us solve this too.December 11, 2010 at 8:47 pm #34597
Firstly apologies, my failing card is nVidia, not ATI.
Unfortunately even a small test case would drag in a great deal of our cross platform source, so a sample would not be possible at the moment.
I can give you the spec of the PC it fails on:
Intel i7 CPU @ 2.8Gz
4 gig RAM
Windows 7 (32 bit)
NVidia GeForce GT220
This codebase works with my ATI Radeon 7800 at work.
This error also occurs on the GLES 1.1 SDK (as you would expect if the PVRFrame is the same?)