I'm trying to extract ARP packets from captured packets (SharpPcap/PacketDotNet), but I'm having trouble with the Packet.extract( Type type) method. I'm not exactly sure what the type should be. Type.GetType( "ARPPacket" ) doesn't seem to work. :v:
Any ideas?
I'm writing some sort of 3d engine in cpp, and I'm still learning this language.
So because I'm coming from Java/C#, I still don't get how pointers really work.
And now I have (VS2012):
[CODE]Unhandled exception at 0x008D2588 in SnowEngine.exe: 0xC0000005: Access violation reading location 0x0000001C.[/CODE]
This happens when I'm getting a pointer from [I]std::vector<Shader*>[/I] in my ShaderManager class.
Here's some code (I don't know if it's enough, let me know):
ShaderManager.h:
[CODE]
#pragma once
#include <string>
#include <vector>
#include "Shader.h"
class ShaderManager
{
public:
Shader* get(const std::string& name);
private:
std::vector<Shader*> shaders;
bool add(const std::string& name);
};
[/CODE]
ShaderManager.cpp:
[CODE]
#include "ShaderManager.h"
#include <iostream>
bool ShaderManager::add(const std::string& name)
{
Shader* shader = &Shader(name);
if (shader->loadFromFile("Shaders/" + name))
{
shaders.push_back(shader);
return true;
}
else
return false;
}
Shader* ShaderManager::get(const std::string& name)
{
bool found = false;
while (!found) {
for (unsigned int i = 0; i < shaders.size(); i++)
{
if(name == shaders[i]->name)
{
found = true;
return shaders[i];
break;
}
}
if(!found) {
if (add(name))
{
found = true;
}
}
}
return NULL;
}
[/CODE]
And this is code for drawing:
[CODE]
Shader* cubeShader = Engine::instance->shaderManager.get("Cube");
glm::mat4 mvp = Camera::currentCamera->projection * Camera::currentCamera->view * glm::mat4(1.0f);
cubeShader->setParameter("MVP", mvp); // this is where exception is throwed
cubeShader->setParameter("Color", color);
cubeShader->bind();
GLuint vertexbuffer;
glGenBuffers(1, &vertexbuffer);
glBindBuffer(GL_ARRAY_BUFFER, vertexbuffer);
glBufferData(GL_ARRAY_BUFFER, sizeof(vertex_data), vertex_data, GL_STATIC_DRAW);
glEnableVertexAttribArray(0);
glBindBuffer(GL_ARRAY_BUFFER, vertexbuffer);
glVertexAttribPointer(
0,
3,
GL_FLOAT,
GL_FALSE,
0,
(void*)0
);
glDrawArrays(GL_TRIANGLES, 0, 12 * 3);
glDisableVertexAttribArray(0);[/CODE]
I will be grateful for helping me :)
(and I can upload everything to GitHub if needed)
(also I'm sorry for my awesome cpp skill)
[QUOTE=zero_slo;41411477]I'm trying to extract ARP packets from captured packets (SharpPcap/PacketDotNet), but I'm having trouble with the Packet.extract( Type type) method. I'm not exactly sure what the type should be. Type.GetType( "ARPPacket" ) doesn't seem to work. :v:
Any ideas?[/QUOTE]
You can dump the types of the packets you're getting to see which kind of types it expects.
Something like println(Packet.extract(typeof(Object)).GetType());.
[editline]11th July 2013[/editline]
To the one above me:
[cpp]Shader* shader = &Shader(name);[/cpp]
You're taking the address of a temporary object here. The anonymous instance will cease to exist after this statement, but you're hanging on it its address.
Couldn't you just store the Shader directly in the vector, instead of Shader*?
[QUOTE=ZeekyHBomb;41411722]
Couldn't you just store the Shader directly in the vector, instead of Shader*?[/QUOTE]
I've tried, but it was still crashing. Apparently that's because of temporary object that you've talked about.
But I still don't know how it should be done, because this:
[CODE]
bool ShaderManager::add(const std::string& name)
{
shaders.push_back(Shader(name));
if (shaders[shaders.size() -1].loadFromFile("Shaders/" + name))
return true;
else
return false;
}[/CODE]
is still not working.
[QUOTE=ZeekyHBomb;41411722]You can dump the types of the packets you're getting to see which kind of types it expects.
Something like println(Packet.extract(typeof(Object)).GetType());.
[/QUOTE]
I completely forgot about the typeof operator. :suicide: p.Extract(typeof(ARPPacket)) works.
Thanks for the help!
[QUOTE=Sonic96PL;41411912]I've tried, but it was still crashing. Apparently that's because of temporary object that you've talked about.
But I still don't know how it should be done, because this:
[CODE]
bool ShaderManager::add(const std::string& name)
{
shaders.push_back(Shader(name));
if (shaders[shaders.size() -1].loadFromFile("Shaders/" + name))
return true;
else
return false;
}[/CODE]
is still not working.[/QUOTE]
Note that the shader will still be in the vector when you return false.
What does you get function look like now?
[editline]11th July 2013[/editline]
Also, maybe a std::map<string, Shader> would be cleaner. It's a associative container with the first template parameter as key and second as value type.
[QUOTE=ZeekyHBomb;41413145]Note that the shader will still be in the vector when you return false.[/QUOTE]
I know, will change it later.
get function:
[CODE]
Shader* ShaderManager::get(const std::string& name)
{
bool found = false;
while (!found) {
for (unsigned int i = 0; i < shaders.size(); i++)
{
if(name == shaders[i].name)
{
found = true;
return &shaders[i];
break;
}
}
if(!found) {
if (add(name))
{
found = true;
}
}
}
return NULL;
}[/CODE]
I just noticed that the address is very close to 0. Check that get is not returning NULL.
It can be a little offset because it tries to access 0 + offset(classmember) instead of 0 itself.
[QUOTE=ZeekyHBomb;41413389]I just noticed that the address is very close to 0. Check that get is not returning NULL.
It can be a little offset because it tries to access 0 + offset(classmember) instead of 0 itself.[/QUOTE]
I should have known...
:suicide:
Many thanks!
Oh god, because of me two people committed suicide today :tinfoil:
I should stop trying to help people...
[QUOTE=WTF Nuke;41401665]Do you guys have any tips on how to optimize this?[/QUOTE]
[cpp]for(int i =0; i<size; i++){
if(elements[i] != i)
continue;[/cpp]
This isn't necessarily trivial. If there is no way the processor can predict it, it can really slow your code down. Is there any other way to approach this? I can't tell from your code if there's a faster way to sort (and skip) the elements.
[editline]11th July 2013[/editline]
More specifically, if a significant portion of the elements array contains something other than the norm, the processor is likely to mispredict it (thus invalidating the cache, and with modern processors that's a significant cause for poor performance) and you might want to consider an alternate way to do the entire looping thing. We can't tell how without more information.
[QUOTE=MakeR;41406308]Make sure that dirToLight is in camera space and that you have transformed the normModelSpace to camera space.[/QUOTE]
They are now, same issue as the one pictured.
This is how EyeDir (not dirToLight) is being calculated :
[cpp]vec3 PositionCamSpace = (V*M*vec4(position, 1.0)).xyz;"
EyeDir = -PositionCamSpace;"[/cpp]
[editline]11th July 2013[/editline]
[QUOTE=ThePuska;41413753][cpp]for(int i =0; i<size; i++){
if(elements[i] != i)
continue;[/cpp]
This isn't necessarily trivial. If there is no way the processor can predict it, it can really slow your code down. Is there any other way to approach this? I can't tell from your code if there's a faster way to sort (and skip) the elements.
[editline]11th July 2013[/editline]
More specifically, if a significant portion of the elements array contains something other than the norm, the processor is likely to mispredict it (thus invalidating the cache, and with modern processors that's a significant cause for poor performance) and you might want to consider an alternate way to do the entire looping thing. We can't tell how without more information.[/QUOTE]
The whole idea behind this code is to find if there are any same vertex/UV/normal points, so that I can use an element buffer and they would point to the same data.
So I made a game in a few hours yesterday, super simple, but I actually somewhat completed it which made me happy. However there's this one bug that I can't seem to figure out. I'm at work and can't post a vid/gif, but the game is there's a ball that falls down. You move the paddle around and hit the ball back up, see how long you can keep it up and there are walls on each side. The bug is that whenever it hits the left wall after approaching it slowly, instead of reversing the x velocity once it keeps flip flopping the velocity and stays at the same x value (16, the value at which the wall begins). When the ball goes at it faster it's fine. I've done the math in my head a lot and I don't know why it works out this way. It doesn't happen to the right wall at all, which baffles me. The code that updates the ball...
[code]
// paddle missed the ball
if (ball->getY() > paddle->getY())
{
newBall();
delta.start();
if (frame > highScore)
highScore = frame;
frame = 0;
}
// update the ball's position
ball->update(gravity, d);
// check collision with paddle
if (ball->getY() >= paddle->getY() && ball->getX() - paddle->getX() >= -24 && ball->getX() - paddle->getX() < 64)
{
ball->setY(paddle->getY() - 32);
ball->setVY(-12.5);
ball->setVX(ball->getVX() + ((double) ball->getX() - (double) paddle->getX() - 16.0) * 0.1);
}
// check collision with walls
if (ball->getX() <= 16 || ball->getX() >= SCREEN_WIDTH - 48)
{
ball->setVX((double) ball->getVX() * -1.0);
}
[/code]
[code]
void Ball::update(double g, int d)
{
vy += g * (d / 25.0);
x += vx * (d / 25.0);
y += vy * (d / 25.0);
if (x < 16)
x = 16;
if (x > 608)
x = 608;
if (y > 472)
y = 472;
}
[/code]
You can also download it to try it yourself here [url]http://www.mediafire.com/download/f0wmzc15qbftvqm/BallGame.zip[/url]. You can just run it in the release folder, compiled for 64 bit.
I'm writing an OpenGL app in which I have separate classes for the Shader and Program, is there any way to go about knowing what Shader's have been attached to a Program without 'mirroring' the state (I read somewhere that this is bad practice), I know there's glGetAttachedShader's, but then I'd have to somehow look up my Shader objects from the returned IDs.
[QUOTE=TVC;41422938]I'm writing an OpenGL app in which I have separate classes for the Shader and Program, is there any way to go about knowing what Shader's have been attached to a Program without 'mirroring' the state (I read somewhere that this is bad practice), I know there's glGetAttachedShader's, but then I'd have to somehow look up my Shader objects from the returned IDs.[/QUOTE]
Track the shader IDs in your shader class? I don't really see what's wrong with "mirroring" the state anyway, otherwise youll have to keep a dictionary or such of all your shader class instances by id...which is worse no?
Anyone here know of any books or sites that talk about optimizing programs? I want to not only be able to write code, but write efficient code.
[QUOTE=elevate;41430835]Anyone here know of any books or sites that talk about optimizing programs? I want to not only be able to write code, but write efficient code.[/QUOTE]
It's probably better to focus on writing straight-forward, well-documented, maintainable code. If you pay attention to the big picture and define good interfaces you can probably safely optimize bottlenecks [i]after[/i] you're done with the writing.
Also, if you have to do something un-intuitive during optimization you should document it well.
I just realized I didn't answer your question :v:
[QUOTE=elevate;41430835]Anyone here know of any books or sites that talk about optimizing programs? I want to not only be able to write code, but write efficient code.[/QUOTE]
Don't optimize your programs.
[QUOTE=Jookia;41431930]Don't optimize your programs.[/QUOTE]
unless it becomes a problem. Then run a profiler and it should be fairly obvious what you have to change.
First rule of optimisation is not to do it.
[QUOTE=Rayjingstorm;41431385]It's probably better to focus on writing straight-forward, well-documented, maintainable code. If you pay attention to the big picture and define good interfaces you can probably safely optimize bottlenecks [i]after[/i] you're done with the writing.
Also, if you have to do something un-intuitive during optimization you should document it well.
I just realized I didn't answer your question :v:[/QUOTE]
Ironically enough this is probably the best answer. It matches what I've heard from other sources, so thanks. I will write my code first, pay mind to other things, and optimize when I'm done. BUT, at the same time, surely I should keep certain optimization tricks in mind, especially the obvious ones, such as passing constant references as opposed to values, except for built-in or basic types? As for the others, why would you NOT want to optimize your programs, unless I'm mistaken on exactly what you're talking about?
[QUOTE=elevate;41432675]Ironically enough this is probably the best answer. It matches what I've heard from other sources, so thanks. I will write my code first, pay mind to other things, and optimize when I'm done. BUT, at the same time, surely I should keep certain optimization tricks in mind, especially the obvious ones, such as passing constant references as opposed to values, except for built-in or basic types? As for the others, why would you NOT want to optimize your programs, unless I'm mistaken on exactly what you're talking about?[/QUOTE]
A lot of optimizations can simply obfuscate the intent of the code, which you and others then have to read. One (poor) example is multiplication by bitwise operations: it's not straightforward (and I still have trouble picking up on it). You can, however, rectify this by adding a comment explaining what the code actually does.
I guess the point is that optimized code is often far less self-documenting, so you end up spending time optimizing something that in all probability won't have an actual substantive effect on performance, while simultaneously [i]removing[/i] documentation inherit to the code itself, forcing you to waste more time writing even more documentation in English, a language which is certainly less interesting that whatever programming language you are currently using, no matter how unoptimized it is.
[QUOTE=Rayjingstorm;41433260]A lot of optimizations can simply obfuscate the intent of the code, which you and others then have to read. One (poor) example is multiplication by bitwise operations: it's not straightforward (and I still have trouble picking up on it). You can, however, rectify this by adding a comment explaining what the code actually does.
I guess the point is that optimized code is often far less self-documenting, so you end up spending time optimizing something that in all probability won't have an actual substantive effect on performance, while simultaneously [i]removing[/i] documentation inherit to the code itself, forcing you to waste more time writing even more documentation in English, a language which is certainly less interesting that whatever programming language you are currently using, no matter how unoptimized it is.[/QUOTE]
I have noticed that with the increase in computer power, programmers have adopted the new trend of making readable programs as opposed to building efficient programs. I'd imagine it makes everyone more productive and allows technology to continue moving forward, and I think that's a good thing. Self-documenting code is a great thing too, something I've been trying to work on lately myself. Yet at the same time, I just hope people don't completely forget about optimization and end up making pixel indie games that use up a gig of memory.
[QUOTE=elevate;41433973]I have noticed that with the increase in computer power, programmers have adopted the new trend of making readable programs as opposed to building efficient programs. I'd imagine it makes everyone more productive and allows technology to continue moving forward, and I think that's a good thing. Self-documenting code is a great thing too, something I've been trying to work on lately myself. Yet at the same time, I just hope people don't completely forget about optimization and end up making pixel indie games that use up a gig of memory.[/QUOTE]
As much as I agree with Knuth that premature optimization is bad, I have to agree with this. This idea that you can just disregard processing time is what leads to programs like Calibre - Otherwise a very useful program, but god damn it's slow as shit and Python will never be statically compiled becaues of the GIL.
[QUOTE=Eudoxia;41434356]As much as I agree with Knuth that premature optimization is bad, I have to agree with this. This idea that you can just disregard processing time is what leads to programs like Calibre - Otherwise a very useful program, but god damn it's slow as shit and Python will never be statically compiled becaues of the GIL.[/QUOTE]
The difference is that Calibre is (if I under you correctly) limited by the higher-level language it is implemented in, placing a hard-stop on how much optimization can even be done. If you profile just the Python code and see that the bottleneck is really in unmanaged code (CPython for example) then there is very little you can do. I suppose the same could happen in C++ (only the unmanaged code would be the OS or perhaps a library) but in most cases you could probably identify managed code that could be optimized (again, after you identify a performance problem)
I do agree with you that you should pay attention to performance concerns while writing, but letting it detract from the code itself seems counter-productive.
Then again I'm still very new to this, and I've never worked on anything where performance even came close to being the issue; in every case so far it's my own poor design, so I may be biased to focusing on that.
[QUOTE=Rayjingstorm;41433260]One (poor) example is multiplication by bitwise operations: it's not straightforward (and I still have trouble picking up on it).[/QUOTE]
Translate it to base 10:
24 * 100 == 24 << 2 (base 10 shift, not base 2, so you just prepend two 0's)
642 * 100000 == 642 << 5
Now instead of 2, 4, 8, ... I use 10, 100, 1000, ... because the former ones are 2^x for base 2 and the latter ones are 10^x for base 10. It's really the same thing, translated to base 10.
If you transform 2, 4, 8, ... to binary notation, you get 10, 100, 1000, ... that should ring a bell ;)
[editline]13th July 2013[/editline]
Note that you can do division with right shift (just remove the first digit and you've divided by 10 (base 10, or 2 in base 2).
[QUOTE=elevate;41433973]I have noticed that with the increase in computer power, programmers have adopted the new trend of making readable programs as opposed to building efficient programs. I'd imagine it makes everyone more productive and allows technology to continue moving forward, and I think that's a good thing. Self-documenting code is a great thing too, something I've been trying to work on lately myself. Yet at the same time, I just hope people don't completely forget about optimization and end up making pixel indie games that use up a gig of memory.[/QUOTE]
One reason not to pre-optimize is because generally, you don't actually gain any noticeable performance. Loosing code quality and and maintainability for that extra millisecond of speed is not worth it.
And compilers today already optimizes things quite heavily. And they tend to know very well what needs to be optimize and what doesn't.
As pointed out, if you do notice performance issues you should use a profiler to see exactly what the bottleneck is and fix that.
And at the last part: Stuffing things in the memory IS optimization in a way. It's faster to read from RAM than it is to read from the harddrive (even if you have an SSD).
[QUOTE=elevate;41430835]Anyone here know of any books or sites that talk about optimizing programs? I want to not only be able to write code, but write efficient code.[/QUOTE]
For low-level optimization on Intel's architectures, Intel provides a good book: [url]http://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-optimization-manual.html[/url]
For general programming, Donald Knuth's "The Art of Computer Programming" is a nice series. Volumes 1, 2 and 3 at least; don't know about the fourth.
I've read some books that at least indirectly deal with Windows and POSIX-specific optimization, but none were good. I doubt good ones even exist. MSDN is the best available reference on Windows features, but it's certainly not infallible (sometimes outright wrong) and undocumented features do exist. For individual features and their performance (low-level locks, threads, memory allocation, etc...) there are a plenty of good papers, but they're all scattered around.
I don't know much about graphics programming, but Nvidia has some papers regarding specific technologies.
You might also be interested in reading up on computational complexity, just for some theoretical basis on algorithms. "Introduction to Algorithms" by Thomas Cormen isn't a bad introduction. One really good book I read was in Finnish ("Tekoäly, laskettavuus ja logiikka" by Ilkka Kokkarinen), though it was more about computability than complexity. Regardless, it's useful to learn about algorithms - they're very fundamental to programming and applicable regardless of what language and tools you're using.
-snipped-
I've never had anyone review my code before and I've been doing this for a while now.
If anyone has time go nuts and criticize me, I'm self taught so I probably have some(or lots of) bad habits that need pointing out.
Here is one of my projects.
[url]https://github.com/Reevezy/GenericEngine/tree/master/GenericEngine[/url]
Sorry, you need to Log In to post a reply to this thread.