[QUOTE=CmdrMatthew;39160878]Use externs. Just define the variables in a CPP file somewhere and either put this in either a header and include that header when you need it, or put it where needed.
[code]extern int screenx;
extern int screeny;[/code]
Don't forget to use your variable names lol[/QUOTE]It seems weird to just make one cpp file for two variables, but I guess it's what I have to do.
They can be defined in any source file.
Yes, but, say if I put that in a menu source file, and I don't need to use the menu header for every source file, what would I do?
You don't have to put it in the menu header just because it's in the menu source file.
[QUOTE=dajoh;39161261]You don't have to put it in the menu header just because it's in the menu source file.[/QUOTE]
I don't understand.
I've been learning C++ for a month or two now and I'd like to start learning graphics, where do I begin?
[QUOTE=Two-Bit;39163692]I've been learning C++ for a month or two now and I'd like to start learning graphics, where do I begin?[/QUOTE]
[url=http://sfml-dev.org/]SFML[/url] is a great place to start, or you could dive straight into OpenGL if you're feeling adventurous. For OpenGL I would suggest using a combination of [url=http://open.gl/]open.gl[/url] and [url=http://www.opengl-tutorial.org/]opengl-tutorial.org[/url].
Though I don't think two months is enough experience to dive into something like this.
For a tetris clone, which SRS is the one that should be used?
[url]http://www.tetrisconcept.net/wiki/SRS[/url]
SRS or "true" SRS guideline version?
[QUOTE=dajoh;39161261]You don't have to put it in the menu header just because it's in the menu source file.[/QUOTE]
you really should though...
[QUOTE=swift and shift;39164745]you really should though...[/QUOTE]
You shouldn't use globals in the first place.
Am I right in thinking this is how openGL (And every other 3D rendering engine I guess) works:
[cpp]
main()
{
//All models are loaded at 0,0,0 world space.
loadModels();
while (running)
{
For every model
{
//Moves and rotates the model to it's
//decided world space cordinate.
//Then moves and rotates the model so it
//matches up with the cameras position
//relative to point 0,0,0 and 0 in pitch, yaw and roll.
drawModel();
}
}
}
[/cpp]
According to open.gl the translation and rotation will then be happening with the vertex shader?
So, the vertices of every given model will always be saved in memory around 0,0,0, but because of the vertex shader they will be drawn as if they have moved around relative to the camera and their actual world space?
[QUOTE=dajoh;39164907]You shouldn't use globals in the first place.[/QUOTE]
i didn't even know we were talking about globals.
i just think it is a good idea to match headers with sources
Here's my current project on Github, you can see where I want the window parameters. When I try to run it, it gives me unresolved external symbols involving those externs and nothing else.
[url]https://github.com/Tetramputechture/Yttra[/url]
[QUOTE=Zyx;39165701]Am I right in thinking this is how openGL (And every other 3D rendering engine I guess) works:
[cpp]
main()
{
//All models are loaded at 0,0,0 world space.
loadModels();
while (running)
{
For every model
{
//Moves and rotates the model to it's
//decided world space cordinate.
//Then moves and rotates the model so it
//matches up with the cameras position
//relative to point 0,0,0 and 0 in pitch, yaw and roll.
drawModel();
}
}
}
[/cpp]
According to open.gl the translation and rotation will then be happening with the vertex shader?
So, the vertices of every given model will always be saved in memory around 0,0,0, but because of the vertex shader they will be drawn as if they have moved around relative to the camera and their actual world space?[/QUOTE]
At a very, very basic level yes. The model matrix transforms each model into world space, the view matrix transforms the world-space model into eye space, then you have a [url=http://www.songho.ca/opengl/gl_projectionmatrix.html]projection matrix[/url] that converts the eye-space model into clip space.
Typically a Camera class will store the view and projection matrices and the model will store the model matrix. You upload these matrices to the shader as uniforms, and this is how you transform it in the shader:
[code]gl_Position = projection * view * model * in_position;[/code]
It's generally better to pre-multiply these as either a single "uniform mat4 mvp" or as a projection uniform and a modelview uniform.
Also most 3d engines will have some sort of culling/broadphase instead of drawing every model. Things like frustum culling, occlusion queries, etc.
Could anyone try to set [url=https://github.com/Darkwater124/nmplayer]this[/url] up in Ubuntu? I've tried it, but it doesn't work and I have no idea why. It just won't find the files.
[QUOTE=WTF Nuke;39163932]For a tetris clone, which SRS is the one that should be used?
[url]http://www.tetrisconcept.net/wiki/SRS[/url]
SRS or "true" SRS guideline version?[/QUOTE]
It's up to you. You're making the game, so you make the rules.
In the VPhysics project, shadow controllers currently don't work, causing props to spaz out madly. I've been trying to figure out this issue for months, and so far I don't know what's wrong.
[video=youtube;t3QxkiLyFu8]http://www.youtube.com/watch?v=t3QxkiLyFu8[/video]
I know that the input target rotation is correct, the object's transform rotation is correct, and the ComputeController function (defined in CPlayerController.cpp) works perfectly on position, which leads me to believe it's hidden in one of our calculations.
Personally, I think it's our conversion of the delta quaternion to a vector, but honestly I don't know.
The code is available here, in the second half of ComputeShadowControllerBull:
[url]https://github.com/DrChat/Gmod-vphysics/blob/master/src/CShadowController.cpp[/url]
[QUOTE=Grayman;39174753]In the VPhysics project, shadow controllers currently don't work, causing props to spaz out madly. I've been trying to figure out this issue for months, and so far I don't know what's wrong.
[video=youtube;t3QxkiLyFu8]http://www.youtube.com/watch?v=t3QxkiLyFu8[/video]
I know that the input target rotation is correct, the object's transform rotation is correct, and the ComputeController function (defined in CPlayerController.cpp) works perfectly on position, which leads me to believe it's hidden in one of our calculations.
Personally, I think it's our conversion of the delta quaternion to a vector, but honestly I don't know.
The code is available here, in the second half of ComputeShadowControllerBull:
[url]https://github.com/DrChat/Gmod-vphysics/blob/master/src/CShadowController.cpp[/url][/QUOTE]
Maybe you just forgot to turn the washing machine off.
From the looks of it, it was only happening in a specific quadrant, maybe you're mishandling how it handles position in some manner?
[QUOTE=Topgamer7;39175080]Maybe you just forgot to turn the washing machine off.
From the looks of it, it was only happening in a specific quadrant, maybe you're mishandling how it handles position in some manner?[/QUOTE]
I have no idea. I know this is an almost direct copy from the 2003 vphysics shadow controller code which I presume was working at the time. I'm not familiar at all with these types of angle calculations, and I've been trying anything I could.
One thing I have noticed is that if the object's rotation matches the target rotation, it won't spaz out and the delta angles are 0. Although, very slowly the delta angles will increase until the object is in an absolute spin.
Also, I forgot to mention, there's some important variables being printed in the top left corner which you can see if you watch the video in 1080p.
Is there any way to make CodeBlocks use the executable directory as the relative directory?
[QUOTE=chaoselite;39177089]Is there any way to make CodeBlocks use the executable directory as the relative directory?[/QUOTE] What do you mean with that and why would you want it?
[QUOTE=dvondrake;39185231]Having some issues with shadowmaps.
[img]http://i.imgur.com/ssaOS.png[/img]
As far as I can tell, the actual shadow map storing depth looks alright. It's a directional light on a 45 degree angle. The issue seems to be in recalculating the same position from the light's point of view when checking if it's in shadow or not.
I'm doing all my lighting in view space, and since it's a deferred renderer I don't have access to the models' individual model matrices. Either I'm doing something wrong with how I'm getting shadow coordinates or the shadow map isn't getting stored properly--or both, I'm really not sure.
This is how I'm getting shadow coordinates in the light shader...
[code]vec4 ShadowCoord = shadowBiasMatrix * vec4( VSPosition, 1.0 );
float shadowDepth = texture( tShadowMap, ShadowCoord.xy ).z;[/code]
shadowBiasMatrix is defined as the same 2 matrices I use to render the scene. It then gets multiplied by the shadow bias matrix and the inverse of the actual camera's view matrix.
[code]glm::mat4 shadowProjectionMatrix = glm::ortho<float>(-10,10,-10,10,-10,20);
glm::mat4 shadowViewMatrix = glm::lookAt( light->GetDirection(), glm::vec3(0,0,0), glm::vec3(0,1,0) );
glm::mat4 shadowMatrix = shadowViewMatrix * shadowProjectionMatrix;
//RenderWorld( &shadowViewMatrix, &shadowProjectionMatrix );
glm::mat4 biasMatrix(
0.5, 0.0, 0.0, 0.0,
0.0, 0.5, 0.0, 0.0,
0.0, 0.0, 0.5, 0.0,
0.5, 0.5, 0.5, 1.0
);
glm::mat4 shadowBiasMatrix = biasMatrix * shadowMatrix;
glm::mat4 invView = glm::inverse(mat_View);
shadowBiasMatrix = shadowBiasMatrix * invView;
// render lights[/code]
I'm not entirely sure what I'm doing wrong here. My gut tells me I'm not getting the shadow coordinates right, but I'm not sure how to get there. I've tried multiplying shadowBiasMatrix by inverse projection and inverse view projection with similar results.
Anyone know anything about shadow mapping care to lend a hand here? I'm really stumped.[/QUOTE]
Take a look at this, it pretty much uses the method you want to use
[url]http://www.opengl-tutorial.org/intermediate-tutorials/tutorial-16-shadow-mapping/[/url]
My GLSL shader loader keeps giving segmentation faults for some reason that appears related to std::string, could someone have a look and see if they can find the issue because I can't see it, the debugger stops on line 152.
[url]http://pastebin.com/zMWiaZXt[/url]
[QUOTE=Grayman;39174753]In the VPhysics project, shadow controllers currently don't work, causing props to spaz out madly. I've been trying to figure out this issue for months, and so far I don't know what's wrong.
[video=youtube;t3QxkiLyFu8]http://www.youtube.com/watch?v=t3QxkiLyFu8[/video]
I know that the input target rotation is correct, the object's transform rotation is correct, and the ComputeController function (defined in CPlayerController.cpp) works perfectly on position, which leads me to believe it's hidden in one of our calculations.
Personally, I think it's our conversion of the delta quaternion to a vector, but honestly I don't know.
The code is available here, in the second half of ComputeShadowControllerBull:
[url]https://github.com/DrChat/Gmod-vphysics/blob/master/src/CShadowController.cpp[/url][/QUOTE]
Quoting because we started a new page and I want this issue to get exposure.
[QUOTE=Chryseus;39185531]My GLSL shader loader keeps giving segmentation faults for some reason that appears related to std::string, could someone have a look and see if they can find the issue because I can't see it, the debugger stops on line 152.
[url]http://pastebin.com/zMWiaZXt[/url][/QUOTE]
This isn't directly related to your problem but first up I think you should change the architecture a little.
On line 45 you're allocating an array of pointers yourself - personally, I'd avoid doing this and in my shader implementation I used an std::vector<Shader*> to handle it for me. It made it easier to write and debug and it means I didn't have to faff about with managing its memory. This also means you don't need to accept an index value for addShader, you can just do ShaderArray.push_back(newShader). You're not doing any error checking there with your code either, so if index is larger than MAX_SHADER you'll segfault.
Those two aren't big issues if this is just some "whip it up fast then clean it" code, but I don't think you should leave it like this indefinitely. The next one is a little more pressing but an easy fix:
On line 174, you're using "operator new[]", but you're only freeing the memory with "operator delete" on line 189. You must match "new" with "delete" and "new[]" with "delete[]", otherwise you will be leaking memory.
You're making the same mistake with lines 45 and 50.
How are you using this code, by the way? Let me know if any of this helps, but I don't think I'll be able to find the real problem just from what you've posted. If you like, I can show you how I'm dealing with shader and shaderprogram loading in my code.
User reading this, what's your favorite IMAP library for C#?
Any idea how I could use breadth first search to check if a graph is hamiltonian? Using backtracking was pretty straightforward.
[QUOTE=mechanarchy;39186226]How are you using this code, by the way? Let me know if any of this helps, but I don't think I'll be able to find the real problem just from what you've posted. If you like, I can show you how I'm dealing with shader and shaderprogram loading in my code.[/QUOTE]
Thanks I changed the array to a vector like you suggested and that seems to have fixed the problem, I probably should have done that in the first place but it's been quite a while since I've done any serious C++ so I'm a little bit rusty.
I would like to know how, in Garry's Mod, to get a camera to stop doing this:
[code]
\__/
/ \
[/code]
and to, instead, do this:
[code]
__
/__\
/ \
[/code]
Which is to say, I don't want things that are above the camera to show the bottom surface, and the things below to show the top surface. I want a camera like Mario's, where all you can see is the top of the surfaces and the side that faces the camera.
For that matter, I also don't want it do skew the sides of the view.
You want orthogonal view.
Sorry, you need to Log In to post a reply to this thread.
