If the matrix is the same for every pixel/vertex, then pass it as uniform, otherwise it has to be calculated each time.
Well, the projection matrix should be the same as I understand it but the modelview matrix will depend on the object the vertex belongs to.
Also, what does it matter if it has to be calculated each time? Uniform doesn't mean it has to be constant.
I need help with finding tutorials or information on programming C# forms without the visual studio designer. I've tried google but its giving me the opposite of what I want. I don't like the way it generates code for me. I'd like to manually do it. Any help?
[QUOTE=Darwin226;24119104]Also, what does it matter if it has to be calculated each time?[/QUOTE]
It doesn't matter. Both will get you the same result, one method will just be a little faster. Calculating the projection-modelview matrix once per model on the CPU will generally be faster than doing it once per vertex in the vertex shader if your model contains a large number of vertexes. However, since video hardware can handle many vertexes at once and is designed specifically for vector/matrix math, I believe it might actually be faster to do the calculation many times in the vertex shader for models with few vertexes. This is mostly just speculation, though. I haven't benchmarked both methods.
If you want to do skeletal animation, you're going to have to keep the projection and modelview matrixes separate and calculate them per-vertex in a vertex shader, anyway.
Oh wow... and just a few days ago I thought shaders only make stuff shiny and sparkly in games.
I'm not sure if this would go in the tech support section or here, but I'm trying to install Visual Express 2010 and it says it can't install in compatibility mode. I can't disable it, but it looks enabled for Vista. I'm on 7 Home premium x64
I've tried redownloading.
[QUOTE=Darwin226;24121027]Oh wow... and just a few days ago I thought shaders only make stuff shiny and sparkly in games.[/QUOTE]
In OpenGL 3.0 they've done away with all the fixed-function stuff completely. No more pre-defined projection or modelview matrixes. No more glColor or related vertex attribute functions. Your whole rendering pipeline is defined by shaders.
Using VBOs and glLoadMatrix + a custom matrix class is enough to conform to non-depreciated OpenGL, right?
You mean glLoadMatrix? Im not sure but I dont think you are allowed to use that.
You have to pass your matrices into your shaders yourself
[QUOTE=Overv;24124003]Using VBOs and glLoadVector + a custom matrix class is enough to conform to non-depreciated OpenGL, right?[/QUOTE]
I'm assuming you mean glVertexPointer/glBufferData or something, but yes, that should be OpenGL 3.0+ compliant.
Alright, so basically load vertices with arrays and use shaders to do the rest.
[QUOTE=Overv;24124247]Alright, so basically load vertices with arrays and use shaders to do the rest.[/QUOTE]
Yep. If you want to know precisely what functions you have access to in OpenGL 3.3, check out [url=http://www.opengl.org/sdk/docs/man3/]the reference[/url].
Khronos is already on the OpenGL 4.1 spec, apparently. I haven't looked into it much (I've just migrated to OGL 3.0 :saddowns:), but I think it's mostly tweaks for compatibility with OpenGL ES.
One of the new features of OpenGL 4.1 is the ability to compile shaders, save them to a file, and then just load them at runtime, rather than having to load, then compile.
[QUOTE=ROBO_DONUT;24122021]In OpenGL 3.0 they've done away with all the fixed-function stuff completely. No more pre-defined projection or modelview matrixes. No more glColor or related vertex attribute functions. Your whole rendering pipeline is defined by shaders.[/QUOTE]
Almost the same with DX11.
I really like it, it's about time really.
I was reading [URL="http://duriansoftware.com/joe/An-intro-to-modern-OpenGL.-Chapter-3:-3D-transformation-and-projection.html"]this[/URL]
and little by little I got everything up to Homogeneous coordinates and the introduction of the w coordinate.
Should I be able to understand stuff like
[quote][code]From these variables, we can come up with a general function to construct a projection matrix for any view frustum. The math is a little hairy; I'll describe what it does in broad strokes. With the camera at the origin, we can project the z axis directly to w axis values. In an affine transformation matrix, the bottom row is always set to [0 0 0 1]. This leaves the w axis unchanged. Changing this bottom row will cause the x, y, or z axis values to project onto the w axis, giving a perspective effect along the specified axis. In our case, setting that last row to [0 0 1 0] projects the z axis value directly to the perspective scale on w.
We'll then need to remap the range on the z axis from zn to zf so that it projects into the space between the near (–1) and far (1) planes of projection space. Taking the effect of the w coordinate into account, we'll have to map into the range from –zn (which with a w coordinate of zn will project to –1) to zf (which with a w coordinate that's also zf will project to 1). We do this by translating and scaling the z axis to fit this new range. The angle of view is determined by how much we scale the x and y axes. A scale of one gives a 45° angle of view; shrinking the axes gives a wider field of view, and growing them gives a narrower field, inversely proportional to the tangent of the angle of view. So that our output isn't distorted, we also scale the y axis proportionally to the aspect ratio (r) of the viewport.
Let's write one last shader using the view frustum matrix function. We'll translate the rectangle to set it 3 units in front of us. In addition to rotating around the x axis, we'll also change the translation over time to set it moving in a circle left to right and toward and away from us. Here's the code, from view-frustum-rotation.v.glsl:[/code][/quote]
I mean, the guy goes over that like "From now on the math is a bit hairy but..."
Are there any tutorials that explain that better?
It's an awesome tutorial all together but unless you know all this matrix stuff already, you are not going anywhere.
Where can I learn how to program with the newer standards of OpenGL? I've learnt the deprecated stuff
I also had a look at DirectX, and gave up after about 30 minutes. I just find the whole thing a lump of disgusting naming conventions. Much like the Win32 API itself :ohdear:
The tutorial I linked to in the last post is good, just make sure you know matrix math before you read chapter 3.
Ah, didn't see the link on "this" :P
Thank you
[QUOTE=Zaldos;24119150]I need help with finding tutorials or information on programming C# forms without the visual studio designer. I've tried google but its giving me the opposite of what I want. I don't like the way it generates code for me. I'd like to manually do it. Any help?[/QUOTE]
Look at any form's .designer.cs file, it basically consists of the following:
[code]
namespace YourNameSpaceHere
{
partial class Form1
{
private System.ComponentModel.IContainer components = null;
protected override void Dispose(bool disposing)
{
if (disposing && (components != null))
{
components.Dispose();
}
base.Disposing(disposing);
}
[/code]
After this, you create private class-wide form objects, like so:
[code]
private System.Windows.Forms.Button button1;
private System.Windows.Forms.CheckBox checkbox1;
private System.Windows.Forms.Label label1;
[/code]
Finally, in your initialization method, add in all the parameters:
[code]
//
// button1
//
this.button1.Name = "button1";
this.button1.Location = new System.Drawing.Point(100, 50);
this.button1.Size = new System.Drawing.Size(200, 25);
this.button1.Text = "Click Me!";
// example event:
this.button1.Click += new System.EventHandler(this.button1);
[/code]
The default .Designer.cs has the parameters in a private void called InitializeComponent, but you can really load it at any time. There are also some form-wide settings that are necessary for the form to function, mainly the form object's settings (this.Name = "Form1";, etc.)
I would recommend you find some page or section of MSDN which contains all the parameters for every type of form object.
[QUOTE=robmaister12;24131087]Look at any form's .designer.cs file, it basically consists of the following:
-awesome snip-
I would recommend you find some page or section of MSDN which contains all the parameters for every type of form object.[/QUOTE]
Thanks I'll look at this.
What do I lose by using unsafe context?
[QUOTE=Darwin226;24134073]What do I lose by using unsafe context?[/QUOTE]
Nothing, but it makes it possible to use pointers.
Why is it not auto enabled then?
Why do I need unsafe context at all if I lose nothing?
[QUOTE=Darwin226;24134983]Why is it not auto enabled then?
Why do I need unsafe context at all if I lose nothing?[/QUOTE]
The pointers you gain are the loss. Pointers (and other stuff you gain by unsafe, but they're mostly there because they're so closely tied to pointers, like fixed arrays) are inherently unsafe, and the reason you need to use the "unsafe" qualifier is for the compiler to remind you of that fact and take no responsibility when you inevitably segfault left and right.
Ok so I made an GUI Encrypting program in NetBeans IDE and I ran the build application to get it as a single .jar file.
When I run it in NetBeans (basically test it) it works fine, but in the .jar file it says that it can't find the main class (which it thinks is encrypter.EncrypterApp)and then it exits it.
What do I do? I can zip up the project files if you need them for whatever reason. I just want it to work =D
I'm designing (and programming) a Scorched Earth / Artillery type game, and I was wondering - is it worth using a physics library (like Box2D) or should I write some simple trajectory code instead?
I would love to have actual forces being enacted on my objects (so for example, powered missiles will push themselves along, whereas grenade type weapons would be lobbed around) so it kinda makes sense to use a physics library - but is that worth it?
Also worth thinking about is terrain generation and destructible terrain. Destructible terrain is something I can work with easily (as it isn't too hard to manipulate) but generation is a little trickier. Any tips for generating then texturing a map?
What GUI library do you guys use for C++? or whats the best one?
this is for general programs not ingame so it would be better if its an easy one to learn
Also i dont want to use platform specific ones i would like it to be a 3rd party one so it can be used in other platforms
thanks
I would say no for any physics library. Anything that you need in a Scorched Earth game you can code your self no problem. (Unless ofcourse you want to use some objects like covers and want them pushed around and stuff, but that isn't Scorched Earth then)
As for the ground, I just made some algorithm that uses a random number and added on a lot of multiplier and what not. Then just fiddle with it until you get it right XD
I used pillars 1 pixel wide and color them gradually. The top layer would start green and it would get more red and brown as it went down.
But that was flash, so using textures wasn't really an issue (or even an idea)
[QUOTE=Richy19;24157921]What GUI library do you guys use for C++? or whats the best one?
this is for general programs not ingame so it would be better if its an easy one to learn
Also i dont want to use platform specific ones i would like it to be a 3rd party one so it can be used in other platforms
thanks[/QUOTE]
Qt or WxWidgits. Qt is better IMO.
[QUOTE=Jallen;24158119]Qt or WxWidgits. Qt is better IMO.[/QUOTE]
If you make a commercial program and used Qt for the GUI would you have to pay to use it?
Sorry, you need to Log In to post a reply to this thread.
