How does the steam engine allow you to change variables via the console? As in, say there is a variable called engine_var1. How can you make it so that if you type engine_var 1 = 4 into the console it'll set the variable to be that. I can't imagine any way other than using a scripting language (which I now nothing of) or a huge switch with all possible variables.
Some sort of a table that contains the command names... It's similar to swapping creation switches for a factory but I'm so tired I can't describe it now someone help
[QUOTE=WTF Nuke;35488043]How does the steam engine allow you to change variables via the console? As in, say there is a variable called engine_var1. How can you make it so that if you type engine_var 1 = 4 into the console it'll set the variable to be that. I can't imagine any way other than using a scripting language (which I now nothing of) or a huge switch with all possible variables.[/QUOTE]
Going to assume you mean the Source engine.
What these variables are are "ConVars". They are built as a linked-list of ConVars, each point pointing to the next. Each Convar stores a few things: It's value as an Integer, it's value as a Float, and it's value as a const char *. When they are created in code they take their default value and they store it - They try to cast it as an int, a float, and a string. This all happens when the game starts up.
Then, as soon as the ConVars are initialized, the game looks through your config.cfg and adds each line to the "Command Buffer" - a buffer of text strings that are only executed at the beginning of each frame. At the start of the next frame, for every STRING OF TEXT "bind w +forward, engine_var1 4", it loops through all of the registered ConVars until it finds the the ConVar that matches (engine_var1), and then it sets it's internal value to "4", which is then casted as a float, int, and char *.
There's also ConCommands, which just run functions when the name is hit, and in reality it is more complicated then that, but that's the gist of it.
[QUOTE=ROBO_DONUT;35483403]Mentioned this in waywo, but I figure I'll post it here, too.
This varies by hardware. Check GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS.[/QUOTE]
Yea... theres my problem:
[cpp]Using OpenGL 2.1
Using resolution: 1024x576
Antialiasing Level of 2 was unavailable, using level 0 instead.
Status: Using GLEW 1.6.0
Max vertex textures: 0
Max combined textures: 16
[/cpp]
BTW is there any documentation on what parameters you can get from openGL? I want to make a tool that I can run on any computer and have it output a file with all sorts of openGL information...
Also do you need an open OpenGL context to get this data? or could I just have a console program?
[QUOTE=Lord Ned;35488747]Going to assume you mean the Source engine.
What these variables are are "ConVars". They are built as a linked-list of ConVars, each point pointing to the next. Each Convar stores a few things: It's value as an Integer, it's value as a Float, and it's value as a const char *. When they are created in code they take their default value and they store it - They try to cast it as an int, a float, and a string. This all happens when the game starts up.
Then, as soon as the ConVars are initialized, the game looks through your config.cfg and adds each line to the "Command Buffer" - a buffer of text strings that are only executed at the beginning of each frame. At the start of the next frame, for every STRING OF TEXT "bind w +forward, engine_var1 4", it loops through all of the registered ConVars until it finds the the ConVar that matches (engine_var1), and then it sets it's internal value to "4", which is then casted as a float, int, and char *.
There's also ConCommands, which just run functions when the name is hit, and in reality it is more complicated then that, but that's the gist of it.[/QUOTE]
Wait what
why would the game use a container with a linear access time that makes no sense
[QUOTE=Richy19;35488777]Yea... theres my problem:
[cpp]Using OpenGL 2.1
Using resolution: 1024x576
Antialiasing Level of 2 was unavailable, using level 0 instead.
Status: Using GLEW 1.6.0
Max vertex textures: 0
Max combined textures: 16
[/cpp]
BTW is there any documentation on what parameters you can get from openGL? I want to make a tool that I can run on any computer and have it output a file with all sorts of openGL information...
Also do you need an open OpenGL context to get this data? or could I just have a console program?[/QUOTE]
This is for OpenGL 3.3:
[url]http://www.opengl.org/sdk/docs/man3/xhtml/glGet.xml[/url]
In general, the API reference at opengl.org is indispensable.
[editline]9th April 2012[/editline]
[QUOTE=esalaka;35488882]why would the game use a container with a linear access time that makes no sense[/QUOTE]
Because the number of convars is relatively small and they are not modified very frequently.
[QUOTE=esalaka;35488882]Wait what
why would the game use a container with a linear access time that makes no sense[/QUOTE]
Because it's a very simple and direct solution that gets the job done. It's certainly not the most efficient solution, but it doesn't need to be because it's only happening during initialization. It's much better for the programmer to quickly write up a simple (but inefficient) system for this then move on to other, more important code.
[url=http://the-witness.net/news/2011/06/how-to-program-independent-games/]This talk by Jonathan Blow[/url] explains it very well. Skip to 9:15 for the basic explanation, 13:50 for an anecdote almost exactly like this.
[QUOTE=esalaka;35488882]Wait what
why would the game use a container with a linear access time that makes no sense[/QUOTE]
I think he was speaking more vaguely, it could be a map or vector or whatever.
[editline]9th April 2012[/editline]
[QUOTE=robmaister12;35489193]It's certainly not the most efficient solution, but it doesn't need to be because it's only happening during initialization.[/QUOTE]
Nah, convars are changed all the time, e.g. in scripts or when they use console commands.
[QUOTE=NovembrDobby;35489672]I think he was speaking more vaguely, it could be a map or vector or whatever.
[editline]9th April 2012[/editline]
Nah, convars are changed all the time, e.g. in scripts or when they use console commands.[/QUOTE]
What I was trying to say was that there's not enough convars being executed per frame to make a difference were it O(1) instead of O(n). It's not part of the 10% of game code that's actually performance-critical.
[quote]Nah, convars are changed all the time, e.g. in scripts or when they use console commands. [/quote]
ConCommands and ConVars are executed every frame. Every user input (+forward, -forward, etc.) is translated into a ConCommand every frame, lots per frame. And you know what, even when you're doing a stringcompare against 500 strings per command, per frame, there's zero loss of speed. Computers are very fast and there's much more intensive calculations going on (animations, etc.)
Could someone explain me what the hell is going on here (C#):
[code]
Console.WriteLine("Dividing 800 by 600");
float ratio = 800 / 600;
Console.WriteLine("Answer is: " + ratio);
[/code]
And the console output is:
[code]
Dividing 800 by 600
Answer is: 1
[/code]
[QUOTE=Goz3rr;35493229]Could someone explain me what the hell is going on here (C#):
[code]
Console.WriteLine("Dividing 800 by 600");
float ratio = 800 / 600;
Console.WriteLine("Answer is: " + ratio);
[/code]
And the console output is:
[code]
Dividing 800 by 600
Answer is: 1
[/code][/QUOTE]
Integer division and float division are two different things. Even though you've said "float ratio", the two numbers being divided are both integers. You can fix this by making one or both a float - so change it to "800.0 / 600" or "800 / 600.0" or "800.0 / 600.0" or use a cast operator such as "(float)800 / 600" etc.
If you don't do this you'll end up with integer division, which returns the number of times that 'a' wholly divides into 'b'.
Oh wow, that was pretty obvious. Thanks for the quick fix. The weird part is that that code came directly from the XNA documentation. They were using Window.ClientBounds.Width / Window.ClientBounds.Height to calculate the aspect ratio, and all my cubes were turning into rectangles because of that rounding.
[QUOTE=Goz3rr;35493300]Oh wow, that was pretty obvious. Thanks for the quick fix. The weird part is that that code came directly from the XNA documentation. They were using Window.ClientBounds.Width / Window.ClientBounds.Height to calculate the aspect ratio, and all my cubes were turning into rectangles because of that rounding.[/QUOTE]
Hm, that's interesting. I thought it might have been because the Width and Height were floats internally but I did a quick google for their msdn specs and they are ints, so I'm not too sure what's going on there. But, at least your problem is solved now anyway.
[QUOTE=mechanarchy;35493279]Integer division and float division are two different things. Even though you've said "float ratio", the two numbers being divided are both integers. You can fix this by making one or both a float - so change it to "800.0 / 600" or "800 / 600.0" or "800.0 / 600.0" or use a cast operator such as "(float)800 / 600" etc.
If you don't do this you'll end up with integer division, which returns the number of times that 'a' wholly divides into 'b'.[/QUOTE]
Adding .0 makes it a double. 800f / 600f makes them both float.
[QUOTE=Frugle;35494110]Adding .0 makes it a double. 800f / 600f makes them both float.[/QUOTE]
Oh. In C++ "800f" generates an error, I'm not sure about the specifics in C#. But the fact remains integer division was his problem.
It's 800.f to make it a float in C++.
So i tested the program on my desktop this time and it runs fine, but with these textures and this image the lane is still flat...
[img]http://i.imgur.com/e7Wgi.png[/img]
[cpp]#version 120
uniform mat4 MVP;
attribute vec4 Position;
attribute vec2 UV;
varying vec2 color;
uniform sampler2D myTexture;
void main(){
color = UV;
vec3 col = texture2D( myTexture, UV ).rgb;
float height = (((col.x + col.y + col.z)/3.0f) / 255.0f) * 10.0f;
vec4 pos = vec4(Position.x, height, Position.z, Position.w);
gl_Position = MVP * pos;
}[/cpp]
[cpp]#version 120
varying vec2 color;
uniform sampler2D myTexture;
void main(){
gl_FragColor = vec4(1,0,0,1);//texture2D( myTexture, color ).rgba;
}
[/cpp]
Why are yoou dividing by 255?
[editline]9th April 2012[/editline]
Also, you can make position a vec2 because you only need X/Y coords. You should discard W anyway. W should always be 1 in homogeneous coords. If it isn't, you'll get weird results in projection.
[QUOTE=ROBO_DONUT;35497646]Why are yoou dividing by 255?
[/QUOTE]
Divide by 255 to get a value between 0 and 1, then times it by 10 to get a value between 0 and 10
[QUOTE=Richy19;35498953]Divide by 255 to get a value between 0 and 1, then times it by 10 to get a value between 0 and 10[/QUOTE]
It's already in the range [0, 1]. Texture lookups are normalized, since OpenGL supports a variety of different formats and whatnot. It would be a complete mess if you had to do the conversions manually.
Nevermind, figured it out.
[cpp]
#include <iostream>
int add(int x, int y); // forward declaration of add() using a function prototype
int main()
{
using namespace std;
cout << "The sum of 3 and 4 is: " << add(3, 4) << endl;
return 0;
}
int add(int x, int y)
{
return x + y;
}
[/cpp]
How does the compiler know what add(x,y) is when it's defined afterwards? Can you put the implementation anywhere you want? In a different file (that's included)?
It doesn't need to know. As long as the number of arguments, argument types, and return types all fit in, the function is abstracted from the context and can be defined anywhere.
[QUOTE=Number-41;35501563][cpp]
#include <iostream>
int add(int x, int y); // forward declaration of add() using a function prototype
int main()
{
using namespace std;
cout << "The sum of 3 and 4 is: " << add(3, 4) << endl;
return 0;
}
int add(int x, int y)
{
return x + y;
}
[/cpp]
How does the compiler know what add(x,y) is when it's defined afterwards? Can you put the implementation anywhere you want? In a different file (that's included)?[/QUOTE]
You can put the implementation (mostly) wherever you want, as long as its compiled. The implementation doesn't have to be included
[QUOTE=Eudoxia;35501737]It doesn't need to know. As long as the number of arguments, argument types, and return types all fit in, the function is abstracted from the context and can be defined anywhere.[/QUOTE]
I guess there's some deep assembly reason behind it? If so, could you point me to a source that explains this?
[QUOTE=Number-41;35502128]I guess there's some deep assembly reason behind it? If so, could you point me to a source that explains this?[/QUOTE]
No deep reason. You define a function 'add' that returns and integer and takes two integers.
Along the way the compiler found a call to the function, in which two integers were given, and the result was implicitly put inside and output stream, which accepts integers (Because object orientedness and what not), the same way you can do:
[CPP]cout << "derp" << 5 << 2.5;[/CPP]
The machine validated the inputs to the function and knows it can't possibly return anything other than an integer, which is valid in the context of std::cout.
So as long as the compiler doesn't reach the end without seeing a definition of the function, you can define things anywhere.
[QUOTE=Number-41;35501563]How does the compiler know what add(x,y) is when it's defined afterwards?[/QUOTE]
Because the add() function has been declared, the compiler knows all it needs to generate machine code for calling the function, [i]except[/i] the address that the call should jump to. So it generates code for the function call, but leaves the address blank, with a sort of note that says "address of add() goes here". That's often called an "unresolved reference".
Later, when all your source files are compiled and the linker goes to combine them into an executable, it finds all the unresolved references, and looks through all the object files to find the things that they refer to. The linker sees the reference to add(), finds the code of the function, and copies it into the executable. Now that the code has been placed at a known address, the linker can fill in the address in the unresolved reference, making it "resolved".
[QUOTE=Number-41;35501563]Can you put the implementation anywhere you want? In a different file (that's included)?[/QUOTE]
The [i]declaration[/i] has to be in the same translation unit as the code that calls the function, and it has to occur before the call. Typically you put it in a header file that's included from the source file that calls the function.
The [i]definition[/i] (the code which implements the function) doesn't have to be included in the file that calls it, but it has to be part of the linking step at the end. If you're using an IDE, this basically just means that it has to be in the same project. It can also be in a library, if the code that calls the function is in a project that you've configured to link with that library.
Typically you put some functions in a source file, declare them in a header file with the same name, and then include that header file in any other source files that want to call the functions.
[editline]9th April 2012[/editline]
BTW, when you do "#include <iostream>" or whatever, you're not actually pulling in code, you're just pulling in declarations. The code is in a library, called the "standard library", that's automatically linked into every project. So when you do cout<<"foo", it's no different than when you call your add() function. The compiler produces unresolved reference to ostream::operator<<(char const*), and later, the linker finds the code for that function in the standard library and inserts its address into your executable.
(This isn't necessarily strictly true because that operator<< might be a template, and code for templates [i]is[/i] in the header file. But somewhere along the line it'll end up calling other code that's just declared in the header, and defined in the standard library.)
I have been thinking over this the whole last weekend and trying to figure out how to put it in a working Visual Basic 2010 code.
Been desperately trying to figure out how to calculate the proper casualty rate related to thermal, blast, distance, and time. (Radiation added later on).
Atleast I have the relatively accurate calculations now of the effects per 2.5 kilotons put down which are
[code]Dim Y As Double = 2.5 'warhead in kilotons
'r_blast = blastwave
'r_thermal = thermal radiation
Private Sub TabPage1_Click(sender As System.Object, e As System.EventArgs)
r_therma_1st = Y^0.38^*1.20 'distance from ground zero = 4.3km
r_thermal_2nd = Y^0.40*0.87 'distance from ground zero = 3.2km
r_thermal_3rd = Y^0.41*0.67 'distance from ground zero = 2.7km
'calculations of thermal injury
r_blast = Y^0.33*constant_bl
constant_bl_1_psi = 2.2
constant_bl_3_psi = 1.0
constant_bl_5_psi = 0.71 'windspeeds up to 260.71 km/h, Most buildings collapse. Injuries are universal, fatalities are widespread.
constant_bl_10_psi = 0.45
constant_bl_20_psi = 0.28 'windpseed 804.67 km/h, Heavily built concrete buildings are severely damaged or demolished. Fatalities approach 100%.
[/code]
[editline]10th April 2012[/editline]
Hmmm, so for airburst 25 kiloton bomb, the relation of Psi for distance is
Psi 53-13 = 0.0-1.14 Km.
Psi 13-3.5 = 1.14-2.74 Km
Psi 3.5-1.02 = 2.74-6.6 Km
And the fatality rate in percentage would be
0.0-1.14 Km = 88.3% Dead
1.14-2.74 Km = 34.3%
2.74-6.6 Km = 1.1%
Does anybody here know anything about Mip64 and coding 8086 architecture? I have an assignment where I have to use WinMip64 and get a good instruction count and get as little stalls as I can and I have no fucking idea what to do
Sorry, you need to Log In to post a reply to this thread.
