• Advertisement


  • Content count

  • Joined

  • Last visited

Community Reputation

122 Neutral

About Gazoo

  • Rank
  1. Hey ZHAO Peng, You're my hero. Thanks for this piece of info! Very helpful! Regards, Gazoo
  2. Hey, I know that specifying which profile to use in OpenGL 3.x has to be done when creating the context, and as it stands, I am using GLUT which seems to end up with the compatibility profile. However... I am kind of a stickler for control, so I'd like to query if the compatibility profile is actually the one in play. Does anybody know if that is possible, and if so - how? Regards, Gazoo
  3. Hey Experts, Short descriptive paragraph: (feel free to skip) I am currently working on displaying a volumetric texture on a 3D cube. However, I am having problem getting even the most basic stuff to work at the moment. Perhaps because I am not all to familiar with GLSL yet. I am trying to do the old - use the position of the fragment as its color value to see it change across the surface. The two issues I am having trouble with is properly passing the position and color between the vertex and fragment shader. I am running using GLSL version 1.3 (upgrading to 1.5 soon) and I am rendering a flat surface (to keep it simple), thusly: glBegin(GL_QUADS); glNormal3f(0.0f, 0.0f, 1.0f); glVertex3f(-1.0f, 1.0f, 0.0f); glVertex3f( 1.0f, 1.0f, 0.0f); glVertex3f( 1.0f,-1.0f, 0.0f); glVertex3f(-1.0f,-1.0f, 0.0f); glEnd(); Vertex Shader: out vec4 gl_FrontColor; varying vec3 position; void main(void) { //position = gl_Position.xyz; gl_Position = ftransform(); //gl_FrontColor = gl_Color; //position = gl_Position.xyz; //position = gl_Vertex.xyz; } For the vertex shader I wish to pass the color and position on to the fragment shader. I know the color value is irrelevant if I wish use the position as my color, but that is only to test out the code. Fragment Shader: in vec4 gl_Color; uniform sampler3D volTex; varying vec3 position; void main(void) { //gl_FragColor = vec4(1.0, 0.0, 0.0, 1.0); //gl_FragColor = gl_FrontColor; // Pass-Through Shader! gl_FragColor = gl_Color; // Volumetric Texture display! vec3 test = vec3(1,1,1); //gl_FragColor.rgb = texture3D(volTex, position).rgb; //gl_FragColor.rgb = texture3D(volTex, test).rgb; gl_FragColor.rgb = position; gl_FragColor.rgb = gl_Position.xyz; } As you can see, I have tried several approaches, and none of it really works as I wish. If I uncomment the first line of code, my quad turns red. So I am pretty sure the shaders themselves run. The code within them is just not up to snuff... I hope someone can give me a push in the right directions. Scowering the web has not brought me any closer to a solution :( Regards, Gazoo
  4. Thank you Brother Bob - So essentially, you're telling me that it IS necessary to write: glActiveTexture(GL_TEXTURE0); glDisable(GL_TEXTURE_2D); glActiveTexture(GL_TEXTURE1); glDisable(GL_TEXTURE_2D); ... for each Texture that I no long wish to use, because there is no call such as: glDisableActiveTexture(GL_TEXTURE0); Correct?
  5. Does OpenGL not simply use the texture units the texture is bound to when it is both created and bound? glTexImage3D( GL_TEXTURE_3D, 0, GL_RGBA, width, height, depth, 0, GL_RGBA, GL_UNSIGNED_BYTE, data ); glBindTexture(GL_TEXTURE_3D, 0); Your short answer hints at something I am not understanding... But I am too stupid to understand what... Further explination would be much appreciated.
  6. Hey Forum-dudez, Been a while since I posted - but then again - it's been a while since I messed around with Graphics... However, now I've done it, and I'm for another long graphics haul... But I digress - something has been bothering me for a while - for which I have no clear answer: I use glEnable to enable GL_TEXTURE_2D, GL_TEXTURE_3D, and GL_TEXTURE_RECTANGLE_ARB (I'm not sure about the non-ARB version). Right now I am under the assumption that I only need to call glEnable on these handles right before I render, and call glDisable right after I am done rendering with them... However - I've seen other posts and examples enabling these handles multiple times after selecting a new active texture... I am under the impression that the enable calls change the graphics pipeline to include these features in general and do not need to be enabled per texture... Can someone either confirm or deny this? So far my googelings have not helped me understand the matter further. Answers and especially explinations are very welcome! Regards, Gazoo [Edited by - Gazoo on July 22, 2009 5:58:36 AM]
  7. Hey Programmers, Now I have a question to pick peoples brain with. I don't know why, but I assumed that since Microsoft made their Windows SDK available for download free-of-charge (provided you have windows of course), using it was possible with any given compiler. Perhaps a foolish assumption. I have VS2008 in an acedemic version and using the SDK proved quite simple. Refer to the proper include and lib folders and off you go... Now obviously, using a different compiler outside of Visual Studio (such as GCC) might have quarrels with the MS code. But at the moment I'm just trying to figure out if it's legally possible. What I mean is - when I try to include Windows.h, the GCC compiler throws a number of errors at me, but at the top of the list is a missing file dubbed "sal.h". I search around and find it's not included in the SDK, however, it is included along with VS2008. I know its possible to just copy that particular file, but my intention was to use a much more light-weight IDE, and also avoid using any VS related files. In plain english: I want to use direct show in a simple project, perhaps commercially - but that's much less of a worry at the moment. Right now I'm trying to figure out if it is at all possible without having to copy or use files from Visual Studio (and stick with the Windows SDK). Any thoughts? Regards, Gazoo
  8. Well by dereferencing the iterator I am deleting the object it is pointing to and not the actual iterator, but you do have a point as iterators are often invalidated when deleting things from the container they reference. I'll have a look at it... :)
  9. As for the use of the container in question, the operation is carried out frequently, as in 1-20 times per frame and using a list of pointers is what I believe is the proper balance between functionality and maintainability. Shared pointers are nice, but I don't really need the control here since the lists are handled in a very closed environment and aren't passed further around in the structure. I used regular pointer since I'd prefer to avoid copying larger amounts of data. Regards, Gazoo
  10. Ok - I coded in the changes and the memory manager points to the "new" and not the push_back part. I'm not exactly sure when the rapport is generated, but I assume it's when the application closes since that's when the "memleaks.log" file is updated. I should mention that "mTempTagPoints" is a list and it is destroyed since it is allocated on the stack within an object which is deleted. ddlox - the lists are either of exactly the same size (4) or 0 in the beginning. But why is it important that they are same sized? The iterator goes through the entire list deleting every entry... Regards, Gazoo
  11. Hey Gamedev'erz, I have a question. I recently decided to have a look at the memory leaks in my program of which there are many. My goal is to essentially trim the worst off for good measure, and I've set up paul nettles memory manager to do some of the dirty work. I put to you the following snippet of code: CvPoint *tempPoint; for(int i = 0; i < 4; i++ ) { tempPoint = (CvPoint*)cvGetSeqElem( mPotentialSquare, i ); mTempTagPoints.push_back(new tagPoint()); mTempTagPoints.back()->imgFeedPoint.x = tempPoint->x; mTempTagPoints.back()->imgFeedPoint.y = tempPoint->y; } mCalcTag->updateTagPointsUnsorted(mTempTagPoints, mPotentialTagInnerContours); // Clear out any recieved "old" points for (listIterator = mTempTagPoints.begin(); listIterator != mTempTagPoints.end(); listIterator++) { delete (*listIterator); } mTempTagPoints.clear(); In essence, the memory manager goes ape-shit over the new tagPoint being created in the for loop. Which is fair enough, except that the points are deleted shortly after in the iterator section. To be fair, the contents of "mTempTagPoints" is actually swapped in the "updateTagPointsUnsorted" function, but it is continously swapped throughout the program. Kind of like a revolving door where the data is at most stored in an alternate list until this portion of code is revisited and then the contents is swapped "out" and the iterator cleans it all out. So I'm wondering if the memory manager is going wonky since the code is obscure or due to some other reason I am as of yet unaware of. A bug perhaps? Regards, Gazoo
  12. Hey Gamedev'ers, This is a relatively simple math related question, and I've found a few things on the net, but I'm having a hard time wrapping my head around the easiest and most straight forward solution to the problem. I basically wish to calculate the position along a uniform curve in 2D space. I have two points that make up the curve. Essentially, it's a simple 90° turn. I have calculated the distance of said curve, so I know how far along it I need to go. So what I'm missing is a formula for calculating the exact position along the curve. This page: http://www.gamasutra.com/features/20010314/pinter_02.htm describes the issue, using some psuedocode. But I'm having a hard time wrapping my head around how the positioning of the curve in the world affects the turning. In the world I'm working in the 90° turn can be positioned anywhere, so an entity crawling along it might be looking straight up as it starts, but it might also be looking down or at a 45° angle. The psuedo code on the page only seems to consider if the turn is going left or right. If someone has worked a bit with this before and can set me straight or knows any other online resources, I'm all ears... Regards, Gazoo
  13. Uhhhh no? Using your method the lookup will never actually perform lookups outside the "bottom" row of a texture where Y is 0. At least that has been my experience with your suggestion... I believe I'll stick with my own solution, unless someone else has anything to add? Regards, Gazoo
  14. Hey, Thanks for the response... I clearly did not express myself properly... I am by most standards an OpenGL noob :) In other words, I have never used the blending functionality. I wasn't sure that activating GL_BLEND was the only way to achieve blending which - as far as - I know now is absolutely necessary... Yes? Anyway... I am surprised by the fact that rendering quads using blending takes so much time. But I assume this is not uncommon. I was just not expecting such a performance drop... So uh... I think the issue is resolved... One must activate GL_BLEND and expect quite a performance hit in comparison to regular quads... Regards, Gazoo
  15. Hey Forummers, I hope you'll bare with me on this perhaps stupid endeavor... I'm having a bit of trouble alpha blending with OpenGL and Cg. I've searched this forum and found a handfull of posts, but almost all of them are related to DirectX and the rest I've been unable to gain any wisdom from. So basically I guess my question is if someone else has performed any alpha blending using only the vertex shader and OpenGL? I've tried messing a bit around with the alpha value and enabling blending in OpenGL, but so far no luck... And enabling blending in OpenGL (glEnable(GL_BLEND);) basically cuts my framerate to pieces (1/4) even if I haven't rendered a single quad... Much appreciate any hints or suggestions... Regards, Gazoo
  • Advertisement