• Create Account

Awesome job so far everyone! Please give us your feedback on how our article efforts are going. We still need more finished articles for our May contest theme: Remake the Classics

Brother Bob

Member Since 26 Nov 2001
Online Last Active Today, 12:24 PM

#5062538How can I change [-1,1] range from gluPerspective?

Posted by on 17 May 2013 - 04:04 AM

You need to use different coordinates for your vertices since the coordinate systems are completely different. For a given vertical FOV and aspect ratio, you can calculate the range in X and Y direction at a certain depth Z.

yrange = Z*tan(fov/2);
xrange = yrange*aspect;


The range of the coordinate system at depth Z is from -xrange to xrange in the X direction, and from -yrange to yrange in the Y direction.

But why do this and not use an orthographic projection for your 2D, and a perspective projection for your 3D?

#5062038does this code look ok?

Posted by on 15 May 2013 - 07:35 AM

Use the debugger to determine where the error message is generated and under what conditions you'll get there, then figure out why it got there.

But you may not even have to use a debugger in this case, but rather just read the message and locate the corresponding message in the code: there's only one place in the code you posted where any string from the error window is present. If there is an error window with the title "Device Context" and the message "invalid operation", then these strings must come from somewhere.

#5061746SDL_net get MAC address from socket

Posted by on 14 May 2013 - 04:28 AM

This has nothing to do with SDL, but the MAC address is only a link-level address and is never transported outside the link. The only MAC address you, as the server, will see is the last node the packace arrived from, likely your server's gateway or router. That is, incoming TCP-data is wrapped in an IP message that has your IP as the destination and the client's IP as the source, but it is wrapped in an ethernet frame with your MAC as the source and the last gateway or router's MAC address as the source.

#5061178Am i doing this right? (OpenGL 3.0+ context)

Posted by on 11 May 2013 - 05:38 PM

So, i would have do

WGL_CONTEXT_FLAG_ARG | WGL_CONTEXT_FORWARD_COMPATIBLE_BIT_ARB

?

The bit goes into the value, not the option.

WGL_CONTEXT_FLAG_ARG, WGL_CONTEXT_FORWARD_COMPATIBLE_BIT_ARB


What's the point of using WGL_CONTEXT_FORWARD_COMPATIBLE_BIT_ARB if all it does is remove depreciated stuff?

You asked how to get rid of the deprecated stuff, and that bit gets rid of the deprecated stuff. So the point of it should be obvious to you

Posted by on 11 May 2013 - 04:38 PM

Relative paths are relative to the current working directory, which does not necessarily have to be where the executable is located. Since you mention that you use an IDE, check what the current working directory is when you execute your executable from the IDE if that is what you're doing.

For example, Visual Studio usually sets the working directory to the project directory, but the executable is located somewhere else. Here's my directory setup for my projects:

• Project directory: c:\path\to\project
• Executable directory c:\path\to\project\bin\x64\Release
• Data directory: c:\path\to\project\data

Thus, my Visual Studio executes the command "c:\path\to\project\bin\x64\Release\program.exe" with the working directory "c:\path\to\project", and my program thus accesses files in the data directory with "data\file.bmp" because that is the relative path to the bitmap from the working directory.

If I instead open the file explorer and double click on the executable, the working directory is the executable directory itself, and thus "data\file.bmp" will not found anymore. In that case I would have to use "..\..\..\data\file.bmp" to take three steps up to leave the "bin\x64\Release" substructure.

#5058854C++ - Passing array of textures through function

Posted by on 03 May 2013 - 03:13 AM

The function should take a pointer, and you pass the array as it is.

virtual bool initialize(..., TextureManager *textureM);
...
if(!gamePanels.initialize(..., panelTexture))


#5058559reinterpret_cast examples?

Posted by on 02 May 2013 - 02:37 AM

No, changing the type is not enough.

struct base1 { };
struct base2 { };
struct derived : base1, base2 { };

int main(int, char**)
{
base2 *b = new derived;
base1 *br = reinterpret_cast<derived *>(b);
base1 *bs = static_cast<derived *>(b);

std::cout << b << std::endl;
std::cout << br << std::endl;
std::cout << bs << std::endl;
}


Here, b is a base2-pointer to a derived object, and br and bs are base1-pointers to the derived object typecast via the derived class using reinterpret_cast and static_cast, respectively.

The br pointer is an invalid cast because you have a base1 pointer incorrectly pointing to the base2 subclass of the derived object. The bs pointer is a valid pointer because you have a base1 pointer correctly pointing to the base1 subclass of the derived object.

Try the program, the two last pointers should be different. The cast requires changing the pointer's value as well as changing its type.

#5058538Lock window size

Posted by on 02 May 2013 - 01:04 AM

You need to resize the window. Call glutReshapeWindow if the size is not the correct one.

#5058479FreeImage Texture not appearing on the OpenGL polygon.

Posted by on 01 May 2013 - 07:07 PM

You cannot bind texture inside a glBegin/glEnd pair, you have to bind the texture before calling glBegin. But that actually lead me to something I didn't notice in your first post: you have commented out the glBindTexture after generating a texture ID but before you start working with the texture. You must bind the texture to upload its image data and set its filter parameters and such, but you have commented out that line.

#5058466Lock window size

Posted by on 01 May 2013 - 05:53 PM

You have to control this at the windowing level, OpenGL has nothing to do with this. Since you mention GLUT, you are stuck with what it provides, which is next to nothing in this case. The best you can do it resize the window back to its original size if the user changes it.

#5058465reinterpret_cast examples?

Posted by on 01 May 2013 - 05:50 PM

No, with multiple inheritance the reinterpret_cast will just cast the pointer, but static_cast will correctly adjust the pointer for the different base classes. Base and derived types are related, so you use static_cast which is used to cast between related types.

That's the difference between the two that I hinted at earlier; reinterpret_cast will just cast the type, but static_cast will also cast the value if necessary.

#5058391reinterpret_cast examples?

Posted by on 01 May 2013 - 01:35 PM

If you want a really quick and basic summary, you can think of it like this:

• reinterpret_cast is use to change the type but it won't change the underlying bits. For example, change the type of one pointer to another, or to put the value of a pointer in an integer.
• static_cast is used to change the type and the logical value. For example, if you static_cast from a float to an integer, then the logical value is preserved; that is, if you cast from 1.0f, then the integer value is 1, even though the bits are completely different.

#5058379reinterpret_cast examples?

Posted by on 01 May 2013 - 01:00 PM

Well, you learn something new every day ;)

What used to happen before the new C++ casts? They're templated and were templates introduced at the same time as multiple inheritance? (EDIT: presumably virtual inheritance was a problem? EDIT2: Hmm I guess all MI would be a problem with a C-style cast presumably you had to add on the sizeof the first base to cast to the 2nd via a cast to char*)

I have to correct me a bit, but I'm still a bit uncertain about the exact details so keep that in mind.

It seems to be that is not that C-style cast cannot cast with multiple inheritance which I implied, but that the behavior of the C-style cast can silently change. The correct way to cast between base classes in multiple inheritance, as I understand it, is via static_cast and derived classes. The C-style cast will do the right thing if if the full definition of the inheritance hierarchy is present. If not, the C-style cast will go ahead and do an incorrect reinterpret_cast, while the correct static_cast will fail.

The C-style cast will therefore cast correctly when the cast is doable, but will silently work and do the wrong thing when the cast cannot be done correctly.

#5058370reinterpret_cast examples?

Posted by on 01 May 2013 - 12:34 PM

Well, a C-style cast trumps everything (can do all types of casts).

That is actually not true. It cannot do casts of pointer to classes with multiple inheritance in some cases. The C-style cast will just reinterpret the pointer value, but a proper C++ style cast may actually change the value to handle multiple inheritance correctly.

#5058367reinterpret_cast examples?

Posted by on 01 May 2013 - 12:32 PM

I've been reading a little bit about reinterpret_cast,and I have a problem thinking about when I could really use it.I can use it to cast a pointer to a totally unreleated type of pointer.

reinterpret_cast is for casting between unrelated types, so yes, you can use it to cast a pointer of one type to a pointer of another unrelated type.

Are there some good examples to show some situations you can't solve without reinterpret_cast?

Well, casting between unrelated pointer types requires a cast, and a reinterpret_cast is the cast for that.

PARTNERS