As far as I know , I need to firstly generate a buffer's name by calling glGenBuffers , which allocates some RAMs to a specific object(array) named by developer manually . That's why I need to write codes in the form of 'glGenBuffers(int, actually address)'. So whereby , if I want to give some RAMs a specific usage , I need to call glBindBuffer , attributing the target 'usage' to the first parameter , the RAMs to the second parameter .
That's the problem . Why should I attribute an int value to this second parameter?
Isn't a specific address like &xxx ?
Just like what I have done in glGenBuffers : confirm an area where the buffer datas should be stored.
Does glBindBuffer locate the certain address in its body automatically, but doesn't require developers to type in a pointer ?
glGenBuffers chooses a bunch of ID numbers for buffers, then stores the ID numbers into your variable. glBindBuffers selects one of the buffers based on its ID number. You don't get to see the addresses of any buffers.
Related
I am trying to import all the function symbols in the elf with the function base address to a text file.
I am using the below 2 commands to do that
PRinTer.FILE c:\temp\function_symbol.txt
WinPrint.symbol.list.function
But in this process, full function name is getting terminated. I am getting output like this:
__________address________|path\symbol_|type_____________________|scope_|location|info
P:C001608C--C00160E7|.sym_1\sym_2|(static void * ()) |module|static |frame: * . push
I want the address and full path\symbol(2nd column). Please note that the symbol table is very big and increasing clip board size and selecting "To Clipboard All" will not work. I know that if I have the function base address , I can get the function name. But, in my implementation, I need to know both base address and function full name for better efficiency.
I want to know if it is possible to increase width of 2nd column via some command so that I get full function names after using winprint command
The window sYmbol.List.Function has two columns (with white background) which have a flexible width. You can control the width of those flexible columns with the command WinTABS.
Thus, to export sYmbol.List.Function with a wide column for "path\symbol" use the following commands:
PRinTer.FILE c:\temp\function_symbol.txt ASCIIE
WinTABS 1000.
WinPrint.sYmbol.List.Function
By the way: The width of the address column on the left of the window (with gray background) is controlled via the 5th parameter of the WinPOS command.
With a printer that doesn't exist, I send to the spooler different files. In my software, I try to get all files existing in the queue of the spooler. For that, I tried the following instruction:
bool t = EnumJobs(hPrinter, 0,1,3, (LPBYTE) &h, sizeof(JOB_INFO_3), &pcbNeeded, &pcReturned)
I get jobId in the field 'JobId' of the structure.
In the structure type 'JOB_INFO_3', the field 'JobId' is well filled but the field 'nextJobId' is not filled. Why?
It's the same problem when I execute the following instruction:
bool t = EnumJobs(hPrinter, 0,3,3, (LPBYTE) &h, sizeof(JOB_INFO_3), &pcbNeeded, &pcReturned)
Moreover, the field 'JobId' is not filled. Why ?
Then, I don't know how to get info(filename, state, number of pages, etc) of a particular job. I tried the following instruction but it didn't work:
GetJobA(hPrinter, h.JobId, 1, (LPBYTE) &job_info_1, sizeof(JOB_INFO_1), & nbBytes)
And my last question is: Is it possible to get all the jobs from the spooler of the printer?
Do you have any solutions?
So, I'm not sure what the rest of your code looks like, but it looks possible that you're not using the API quite correctly. The MSDN documentation suggests that you should call the EnumJobs API twice.
To determine the required buffer size, call EnumJobs with cbBuf set to zero. EnumJobs fails, GetLastError returns ERROR_INSUFFICIENT_BUFFER, and the pcbNeeded parameter returns the size, in bytes, of the buffer required to hold the array of structures and their data.
https://msdn.microsoft.com/en-us/library/windows/desktop/dd162625(v=vs.85).aspx
The flow goes like this:
Call EnumJobs for the first time to see how much memory needs to be allocated for your JOB_INFO_n array.
Allocate the memory required for your JOB_INFO_n array.
Call EnumJobs with your JOB_INFO_n array.
Looking at the call to EnumJobs where you attempt to get the first three jobs, the size of your pJob appears to be sizeof(JOB_INFO_3), where it should be three times this size in order to hold all three jobs. What is the return from EnumJobs for that call?
The reason why nextJobId is not filled in is likely a misunderstanding of the field. This field is for print jobs that have been linked together, not to find out which print job is next in the queue.
NextJobId - The print job identifier for the next print job in the linked set of print jobs.
https://msdn.microsoft.com/en-us/library/windows/desktop/dd145021(v=vs.85).aspx
As for the information about the print job, this is going to be difficult. Unfortunately, there is no way I know of to get the name/path of the file printed. There's no concept of this in the spooler APIs. Consider a print job which isn't backed by a file for example. The best you get is the print job name, which is set by the printing application.
For pages, it looks like there is a TotalPages field in the JOB_INFO_1 structure. That may be of some use to you. It looks like you're already trying to get the JOB_INFO_1 structure but having some troubles. If the API is failing, you can use GetLastError() to identify what the issue is. Does the job ID you're passed in exist?
https://msdn.microsoft.com/en-us/library/windows/desktop/ms679360(v=vs.85).aspx
For the last question about getting all print jobs from the queue. It seems that the MSDN documentation suggests the following:
To determine the number of print jobs in the printer queue, call the GetPrinter function with the Level parameter set to 2.
https://msdn.microsoft.com/en-us/library/windows/desktop/dd162625(v=vs.85).aspx
Hope this helps.
I have a struct Vertex{glm::vec4 t,n,v;}. I have written a obj loader that takes two parameters, obj file path as string and reference to a vector of 'Vertex'es. This function populates my vector and returns the number of indices(In my case indices are just sequential numbers, anyway).
As I have 6 objects to render, after using that function 6 times I have the following
vector<Vertex> objects[6];
GLint SIZES[6],OFFSETS[6],SIZES_I[6],OFFSETS_I[6];
filled. SIZES are number of 'Vertex'es(object[i].size()) and SIZES_I are number of indices. The offsets are calculated as below
for(int i=0;i<6;i++)
{
if(i==0)
{
OFFSETS[0]=0;OFFSETS_I[0]=0;
}
else
{
OFFSETS[i]=OFFSETS[i-1]+SIZES[i-1];
OFFSETS_I[i]=OFFSETS_I[i-1]+SIZES_S[i-1];
}
}
I transferred vectors of Vertex into a single VBO all back to back. Similarly for indices, transferred into buffer bound to element array buffer. That part is shown below.
glBufferData(GL_ARRAY_BUFFER,(OFFSETS[5]+SIZES[5])*sizeof(Vertex),data,GL_STATIC_DRAW);
for(int i=0;i<6;i++)
{
glBindVertexBuffer(i,buffer[0],OFFSETS[i]*sizeof(Vertex),sizeof(Vertex));
}
glBufferData(GL_ELEMENT_ARRAY_BUFFER,(OFFSETS_I[5]+SIZES_I[5])*sizeof(GLuint),indices,GL_STATIC_DRAW);
glVertexAttribFormat(0,4,GL_FLOAT,GL_FALSE,offsetof(Vertex,v));
Now comes my problem. Of the two rendering codes shown below the first one doesn't work but the second works perfectly.
for(int i=0;i<6;i++)
{
glVertexAttribBinding(0,i);
glDrawElements(GL_TRIANGLES,SIZES_I[i],GL_UNSIGNED_INT,reinterpret_cast<void*>(OFFSETS_I[i]*sizeof(GLuint));
}
//second
glVertexAttribBinding(0,0);
for(int i=0;i<6;i++)
glDrawElementsBaseVertex(GL_TRIANGLES,SIZES_I[i],GL_UNSIGNED_INT,reinterpret_cast<void*>(OFFSETS_I[i]*sizeof(GLuint)),OFFSETS[i]);
To summarily say what I have done so u guys can understand whats going on here, in the first case i created 6 buffer bindings on the same buffer with 6 offsets. In the second case there is only one binding, but I used base vertex to offset 6 times. Btw both are compiling, so ignore any typos as I typed all this in my tab.
My first attempt at debugging: Since base vertex approach is working, obj loader is fine. Anyway to make sure of it, I just loaded a single model. Its working fine.
My second attempt at debugging: My suspicion naturally fell on binding calls and offsets. To resolve this, I removed the for loop in the first method and initialized i with 0(Since second method i.e. base vertex method works, we dont bother with it). My first model appeared on screen. Next I initialized 'i' variable with 1. My second model was displayed on screen. This I repeated till i=5. Each of my 6 models were displayed correctly. So my models were displayed individually. But when I combine my calls sequentially, I get some full models, some partial models and some not at all.
My third attempt at debugging: It seems that only last 2 models and so are displayed. Remaining are not drawn or partially drawn. So I reversed my for loop starting with i=5 and decrementing. Now first 2 models and so are displayed(Here 'first two' and 'last two' refers to the order in which models are loaded in obj reader. I did not change that). It is as if the subsequent drawing commands are somehow making the work of earlier drawing commands vanish. Sort of.
Thats it. Here I hit a dead end. Any ideas what might be wrong or how I might proceed with further debugging?
Turned out that it is due to a bug in my driver. The same code worked in my colleague's computer.
I need the maximum length of a uniform name. ie: given a used program with uniforms uniform test and uniform myuniform, glGetProgramiv(program, GL_ACTIVE_UNIFORM_MAX_LENGTH, outParam) should get output of 10 (for "myuniform").
I have a very simple test shader set up with 1 defined uniform: uniform float time
glGetProgramiv(program, GL_ACTIVE_UNIFORM_MAX_LENGTH, outParam) returns 5, the length of time. If I change "time" to something else, it returns the changed length (ex: change to "timer" it returns 6).
glGetProgramiv with GL_ACTIVE_UNIFORMS tells me that there are 2 uniforms.
The second uniform that it is reporting is gl_ModelViewProjectionMatrix.
I am fine with it including gl_ModelViewProjectionMatrix in the list - I am using it in the shader, but this brings up a problem when combined with the other return value. Why doesn't glGetProgramiv return the length of "gl_ModelViewProjectionMatrix" if it is including it in the list? I need the full names of attributes and variables for my application, but since I am getting a max length of 5, glGetActiveUniform is returning a uniform name of "gl_M" which is not acceptable.
Either the max name length should include the MVP matrix, or the list of names should not. It does not make sense to include the name in the list but not in the max name length calculation.
Is this happening only for me? I could not find anything else about it using Google. I could abandon a query for max length and always use very big buffers, but I've seen some very long variable names before, so the buffers would have to be huge to guarantee no errors. That's not a real fix anyway.
This test is working correctly for attributes. I use gl_Vertex and have no other attributes. The system reports 1 current attribute with a length of 10 and a name of gl_Vertex correctly. If I remove my time uniform entirely, that leaves the MVP matrix as the only used uniform, the system reports 1 current uniform, max name length of 0, so getting its name with the returned max length gets nothing.
For completeness, I include the code below. The code is in Java and uses JOGL to access OpenGL bindings. To highlight the relevant areas, I have deleted lines not relevant to this issue, which was mostly the GUI updating, including the GUI part that actually shows the values obtained in here. I also deleted the part that gets the attributes since that works fine, as stated above.
FYI for the C people who are wary of the Java-isms: think of a Buffer (IntBuffer, ByteBuffer, FloatBuffer) like a pointer, buffer.get() like buffer[n++], and buffer = IntBuffer.allocate(n) like a malloc(). I also use OpenGL in C and C++, so I can rewrite this in C if the GLSL gurus here prefer that.
Any suggestions?
// add options to panelShaderParameters
public void updateShaderParameters(GLAutoDrawable surface)
{
GL2 gl = surface.getGL().getGL2();
IntBuffer outParam = IntBuffer.allocate(1);
int numParameters = 0,
maxNameLength = 0;
IntBuffer size = null,
type = null;
ByteBuffer name = null;
gl.glGetProgramiv(shader.getName(), GL2.GL_ACTIVE_UNIFORMS, outParam);
numParameters = outParam.get();
outParam = IntBuffer.allocate(1);
gl.glGetProgramiv(shader.getName(), GL2.GL_ACTIVE_UNIFORM_MAX_LENGTH, outParam);
maxNameLength = outParam.get();
for(int i = 0; i < numParameters; i += 1)
{
size = IntBuffer.allocate(1);
type = IntBuffer.allocate(1);
name = ByteBuffer.allocate(maxNameLength);
gl.glGetActiveUniform(shader.getName(), i, maxNameLength, (IntBuffer)null, size, type, name);
byte[] nameBuffer = new byte[maxNameLength];
name.position(0);
name.get(nameBuffer);
}
}
You have found a driver bug. You can attempt to report it (this forum is a place where it may be seen), but there's nothing you can do to make it work correctly. So just work around it.
Rather than having a single max-size, just ask each uniform in turn what it's length is. In C/C++, you do this by passing NULL for the buffer to glGetActiveUniformName:
GLsizei length;
glGetActiveUniformName(program, index, 1000 /*large number*/, &length, NULL);
//Use length to allocate a buffer of the appropriate size.
I don't know how this would work using JOGL. Perhaps you should switch to LWJGL, which has a much more reasonable Java implementation of this function.
Also, stop storing the strings as byte arrays. Convert them into proper Java strings (another reason to use LWJGL).
We had exactly this problem, and I have seen it described here by other:
http://www.opengl.org/discussion_boards/showthread.php/179117-Driver-bug-causing-incorrect-glGetProgramiv-output
In my case, the problem arose after upgrading from nvidia 295.40 driver to 304.64, in various GPU models. In that forum above the bug was reported for an intel driver ¿ which driver are you using Ludowijk ?
I guess that perhaps builtin attributes starting with "gl_" are not considered for max name length computation, but even if this is true this behavoir should be considered a bug IMHO.
Thanks Nicol for the idea for the workaround.
I have a windows mobile 6 application using TAPI 2.0. lineGetAddressID() is needed to get the address identifier used by several calls in the telephone api, but I can't get it to work.
I have tried the following to no avail:
HLINE line; // valid handle from lineOpen();
DWORD addr_id = 0;
result = ::lineGetAddressID( line, &addr_id, LINEADDRESSMODE_DIALABLEADDR, L"1234", 5 );
result = ::lineGetAddressID( line, &addr_id, LINEADDRESSMODE_DIALABLEADDR, L"5551234", 8 );
result = ::lineGetAddressID( line, &addr_id, LINEADDRESSMODE_DIALABLEADDR, L"1115551234", 11 );
result = ::lineGetAddressID( line, &addr_id, LINEADDRESSMODE_DIALABLEADDR, L"11115551234", 12 );
All of them return LINEERR_INVALADDRESS. Can anybody point out what I may be doing wrong?
As a side question, how can I programmaticly get the address? It appears in the LINEADDRESSCAPS structure returned by lineGetAddressCaps(), but that requires an address identifier (which would need to come from lineGetAddressID(), which requires an address...).
Note: I realize I could use 0 as the address ID and it will probably work, but I have no guarantee it will work for every platform. I would like to get this solved 'right'.
Thanks,
PaulH
When you invoke lineGetDevCaps one of the members of the LINEDEVCAPS structure, dwNumAddresses, is a count of the number of addresses associated with the line device.
TAPI states that the value of address identifiers are defined as the following:
Address identifiers range from zero to one less than the value indicated by dwNumAddresses.
So you can iterate through each address identifier value in the range [0 .. (dwNumAddresses - 1)] and invoke lineGetAddressCaps as you have provided a valid address identifier. There is no need to use lineGetAddressID in this case as the address identifier is known and valid.
If you do this, do any of the addresses specified in the LINEADDRESSCAPS structure match the string being used in your calls to lineGetAddressID? Noting that your application is configured to use Unicode rather than ANSI.