Jump to content

  • Log In with Google      Sign In   
  • Create Account

Interested in a FREE copy of HTML5 game maker Construct 2?

We'll be giving away three Personal Edition licences in next Tuesday's GDNet Direct email newsletter!

Sign up from the right-hand sidebar on our homepage and read Tuesday's newsletter for details!


We're also offering banner ads on our site from just $5! 1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


__SKYe

Member Since 10 Jun 2011
Offline Last Active Today, 06:33 PM

Topics I've Started

Include file not found in GCC, due to path size?

28 August 2014 - 01:32 PM

Ok, this warrants some explanation....

 

I use Windows to program, and up until a few months ago, i always used Microsoft Visual C++ IDE (2010, mainly).

But recently i wanted to start developing projects with multi platforms in mind (desktops only, no mobile), and also to experiment on using multiple compilers on the same project, to start writing portable code (both platform wise and compiler wise).

So, in order to do this, i started using Code::Blocks with both GCC and VC10 as the compilers.

 

My current project is fairly large, but hadn't been a problem until recently, that is, when compiling using GCC only.

 

I'll explain further.

 

When i compile my code using GCC, i get the error "file something.h": No such file or directory.

This would be trivial, if the file didn't actually exist, but i noticed that the problem is with the way GCC handles the relative paths to the included file.

 

Here's a concrete example:

 

In the "MaterialManager.h" file, i include:

#include "..\..\Shader Manager\_Manager\Program Shader Manager\ProgShaderManager.h" 

Now, say that Renderer includes "MaterialManager.h" (which as above, in turn, includes "ProgShaderManager.h").

 

The problem, is that after a few nested includes, GCC expands this to something like:

D:\ZTUFF\Projects\EDGE\Source\Engine\Systems\Renderer\Render Engine\_Implementations\Render_GL_MultiPass\..\..\..\..\..\Gameplay\Core Objects\Light Object\..\..\..\Game\State Manager\..\..\Resource Managers\Material Manager\_Manager\MaterialManager.h

And this is what is printed in the build log, right before the "No such file or directory".

In my opinion, the reason it fails, is that it exceeds the maximum path size for relative paths, in WIndows (the large string above, has 250 characters, and i think that when GCC tries to append yet another file name, it exceeds the 260 characters).

 

I've confirmed this, in that, if i replace any #include path that gives an error, by the it's absolute path, it works.

For example:

"D:\ZTUFF\Projects\EDGE\Source\Engine\Resources\Material Resource\MaterialResource.h"

I thought about prepending a macro of the project source code's absolute path to each #include path, but i would like to avoid if possible.

 

I should mention again, that VC10 never gave me this sort of problem.

 

Again, this may end up being a simple thing, that i am simply unaware of, since i'm not that much experienced in GCC, and if someone could enlighten me in how to avoid this problem, I'd be quite thankful.

 

Thanks in advance, and if there's something that is not clear, I'll work to explain it better.


Calculate GPU memory usage

29 December 2013 - 07:44 AM

So, i'm thinking of calculating the VRAM in use.

 

Now, i don't intend to track every single byte in the VRAM (nor do i think it's possible), i was just thinking of keeping track of how much memory

I upload to the GPU, to get an estimate of the VRAM that is in use (by keeping track of the amount of memory textures, VBOs,buffers, etc occupy).

 

Of course i'd have to keep in mind packing, compression, etc. My question is mostly about the color/depth/stencil/etc buffers.

 

 

Say i create a window, single buffered, with a 32-bit (RGBA) color depth and a 16-bit depth buffer.

 

I know that the color buffer occupies 4 bytes per pixel, and has the same size as the window (say 800x600).

The depth buffer occupies 2 bytes per pixel and also has has the same size as the window.

 

My first question would be. If i switch to fullscreen mode with a bigger resolution (say 1280x800), am i correct to assume that they are expanded to match the new window size?

And if i return to windowed mode again, assuming the buffers are, once again, resized to match the window size, to the memory the buffers occupy in the VRAM actually shrinks, or is just a part of the memory that was used for the larger (fullscreen) size is unused?

 

Also, for double buffering, the window requires 2 color buffers, basically doubling the memory needed for the color buffers, right?

I also assume that using double buffering and support for stereoscopic 3D means 4 color buffers (back left & right, front left & right).

 

Another question would be, does the stencil buffer uses it's own memory, or is it shared with another buffer (say the depth buffer)?

 

Also, i've read somewhere that multisample requires a buffer per sample (say a 4x Multisample would require 4 buffers). If anyone could enlighten me at this, i'd appreciate it very much.

 

I'm nol yet accounting for user created buffers (like geometry buffers user for deferred shading, or a custom, floating point, depth buffer for HDR).

 

As a last note, is it correct to assume that all this things that can be created by the graphics API (OpenGL in this case) reside on the VRAM, or are there exceptions?

 

If something is not clear, then i'll be happy to explain.

 

Thanks in advance.


Crash in custom Linked List using delete

04 February 2013 - 11:01 AM

Okay, so i'm making a custom linked list class using templates, and i'm having a problem when removing elements from it, more specifically at the delete instruction.

 

Here's the code for the class

#ifndef _LINKED_LIST_H_
#define _LINKED_LIST_H_

#include <cstring>

template <typename Type>
struct sNode
{
    //Pointer to the next element
    sNode *next;

    //This element's data
    Type data;
};

template <typename Type>
class LinkedList
{

//Public Properties
public:

//Private Properties
private:
    //The root element
    sNode<Type> *first;

    //The last element
    sNode<Type> *last;

    //The number of elements
    unsigned short numNodes;

//Public Methods
public:
    //Default constructor
    LinkedList();

    //Destructor
    ~LinkedList();

    //Add an element (empty)
    bool Insert(Type **address);

    //Removes an element
    bool Remove(Type **address);

    //DEBUG: Dump the linked list
    void Dump();

//Private Methods
private:

};

//-------------------- Constructor / Destructor --------------------

template <typename Type>
LinkedList<Type>::LinkedList()
    :first(NULL),
     last(NULL),
     numNodes(0)
{

}

template <typename Type>
LinkedList<Type>::~LinkedList()
{
    //TODO: Clear the list here!
}

//-------------------- Public Methods --------------------

template <typename Type>
bool LinkedList<Type>::Insert(Type **pAddress)
{
      //Check if there are no elements
      if(!this->first)
      {

      //Allocate space for the new element
      this->first = new sNode<Type>;

      //The first element is also the last
      this->last = this->first;

      //Set the pointer to this struct (to return)
      (*pAddress) = &this->first->data;

      //OPT: Initialize data to 0
      memset(&this->first->data, 0, sizeof(sNode<Type>));

      //OPT: Set 'next' pointer to NULL
      this->first->next = NULL;
      this->last->next = NULL;

      }
      //There's already at least an element
      else
      {

      //Allocate space for the new element
      this->last->next = new sNode<Type>;

      //Point to the last
      this->last = this->last->next;

      //Set the pointer to this struct (to return)
      (*pAddress) = &this->last->data;

      //OPT: Initialize data to 0
      memset(&this->last->data, 0, sizeof(sNode<Type>));

      //OPT: Set 'next' pointer to NULL
      this->last->next = NULL;

      }

    //Update the number of elements
    this->numNodes++;

    return true;
}

//Removes an element
template <typename Type>
bool LinkedList<Type>::Remove(Type **pAddress)
{
      //Check for NULL address
      if(!(*pAddress))
      return false;

    //---------- Check if the 1st element matches ----------

      //Check if the 1st DATA address matches the given address
      if(&this->first->data == *pAddress)
      {

      //VAR: Pointer to the current node on the list
      sNode<Type> *ptr = this->first->next;

      //Delete the element
      delete this->first;
      this->first = NULL;

      //Set the next element as the next
      this->first = ptr;

      //Update the node counter
      this->numNodes--;

      //Set the address to NULL
      (*pAddress) = NULL;

      return true;

      }

    //---------- Check if any other element matches ----------

    //VAR: Pointer to the current node on the list
    sNode<Type> *ptr = this->first->next;

    //VAR: Pointer to the 2nd to current node on the list
    //     Will be used for pointing to the element after the one deleted
    sNode<Type> *last = this->first;

      //Loop through the list until the node is found (IF it is found)
      do
      {

        //Check if the addresses match
        if(&ptr->data == *pAddress)
        {

        //VAR: Pointer to the next element
        sNode<Type> *nex = ptr->next;

        //Delete the element
        delete ptr;
        ptr = NULL;

        //Set the element before, point to the next
        last->next = nex;

        //Update the node counter
        this->numNodes--;

        //Set the address to NULL
        (*pAddress) = NULL;

        return true;

        }

      //The address didn't match, so update the pointers
      last = ptr;
      ptr = ptr->next;

      }
      while(ptr->next);

    //---------- Check if the last element matches ----------

      //Check if the addresses match
      if(&ptr->data == *pAddress)
      {

      //Delete the element
      delete ptr;
      ptr = NULL;

      //Point to the last element
      this->last = last;

      //Set the element before, point to the next
      last->next = NULL;

      //Update the node counter
      this->numNodes--;

      //Set the address to NULL
      (*pAddress) = NULL;

      return true;

      }

    return false;
}

//DEBUG: Dump the linked list
template <typename Type>
void LinkedList<Type>::Dump()
{
    printf("Nodes: %i\n", this->numNodes);

    sNode<Type> *ptr = this->first;

      while(ptr)
      {
      printf("PTR: 0x%08X NEXT: 0x%08X DADR: 0x%08X DATA: %i\n", ptr, ptr->next, &ptr->data, ptr->data);
      ptr = ptr->next;
      }
}

//-------------------- Private Methods --------------------

//-------------------- Get / Set --------------------

#endif //_LINKED_LIST_H_

 

And, if it help, here's the main

#include <cstdio>
#include <conio.h>
#include "LinkedList.h"

int main()
{
    LinkedList<int> my;
    int *ptr1 = NULL;
    int *ptr2 = NULL;
    int *ptr3 = NULL;
    int *ptr4 = NULL;

    //printf("Nodes: %i\n", my.numNodes);

    my.Insert(&ptr1); *ptr1 = 333;
    printf("ADR: 0x%08X PNT: 0x%08X VAL: %i\n", &ptr1, ptr1, *ptr1);
    my.Insert(&ptr2); *ptr2 = 666;
    printf("ADR: 0x%08X PNT: 0x%08X VAL: %i\n", &ptr2, ptr2, *ptr2);
    my.Insert(&ptr3); *ptr3 = 999;
    printf("ADR: 0x%08X PNT: 0x%08X VAL: %i\n\n", &ptr3, ptr3, *ptr3);

    my.Remove(&ptr3);

    my.Insert(&ptr4); *ptr4 = 1222;
    printf("ADR: 0x%08X PNT: 0x%08X VAL: %i\n\n", &ptr4, ptr4, *ptr4);
    
    //my.Remove(&ptr3);
    my.Dump();

    _getch();
    return 0;
}

Now the problem is that when calling the Remove method, when the program reaches the delete instruction (any of them) it crashes with the error "Heap corruption detected".

 

I don't know if i'm just fed up with pointers, that i can't find the error, or if it is something else, so please help.

 

NOTE: I know that there are already Linked List classes, and that the way i made it may not (and probably isn't) be the best way to do it, but try to bear with it.

 

Thanks in advance.


GLSL Vertex Shader not compiling

10 December 2012 - 09:24 PM

Hi everyone.

So, i made a program in OpenGL using 2 different shader programs. One for 2D geometry and another for 3D geometry, both using two different vertex shaders, and the same fragment shader (whichi will post below).

Ah, before saying anything else, let me say i'm using Visual C++ 2010 Express edition, and running the program in 'Debug' mode.

I tested the program and everything worked fine, until i switched the building to 'Release' mode on the IDE, which made the 2D vertex shader and the fragment shader stop compiling, leaving only the 3D vertex shader working.

The errors were the same for both shaders:

Vertex(Fragment) shader failed to compile with the following errors:
ERROR: 0:15: error(#132) Syntax error: '<' parse error
ERROR: error(#273) 1 compilation errors. No code generated

By the way the shaders are these:

2D_Vertex.glsl
#version 330 core

in vec3 in_Position;
in vec2 in_TexCoords;

smooth out vec2 pass_TexCoords;

uniform mat4 uni_OrthoMatrix;

void main(void)
{

	 pass_TexCoords = in_TexCoords;
	 gl_Position = uni_OrthoMatrix * vec4(in_Position, 1.0);

}

3D_Vertex.glsl
#version 330 core

in vec3 in_Position;
in vec2 in_TexCoords;
in vec3 in_Normal;

smooth out vec2 pass_TexCoords;

uniform mat4 uni_PerspectiveViewMatrix;
uniform mat4 uni_ModelMatrix;
uniform mat3 uni_NormalMatrix;

void main(void)
{

	 pass_TexCoords = in_TexCoords;
	 gl_Position = uni_PerspectiveViewMatrix * uni_ModelMatrix * vec4(in_Position, 1.0);

}

Fragment.glsl
#version 330 core

smooth in vec2 pass_TexCoords;

uniform sampler2D uni_Texture0;

void main(void)
{

	 gl_FragColor = texture(uni_Texture0, pass_TexCoords);

}

So first i checked the fragment shader for something wrong, and the part that shows 'gl_FragColor = texture(...', i changed the 'texture' to 'texture2D', thinking maybe it wasn't supported in version 330 (even though it compiled fine on 'Debug' mode), and it worked, it compiled successfully.

Now the thing is, i can't find anything wrong in the 2D_Vertex shader, and it won't compile (and as i said before, the program works perfectly on 'Debug' mode).

All the uniform variables are correct for all shader programs, so the problem has to be in the shader.

The program does have an OpenGL 3.3 core profile (don't know if it helps, but...)
Oh, and i also tried changing/removing the #version tag, to no avail.

Any help is appreciated.

Thanks in advance!

#define vs const

08 June 2012 - 11:55 PM

Some time ago, i read somewhere (i think it was on an old C++ book, not sure) that one should use const instead of #define, the reason being that #define is a preprocessor directive, and if for some reason the compiler ignored it, error would occur.

Now maybe at the time, compilers weren't very safe, so this line of thought was understandable (i think).

But nowadays, i think it isn't so. Let me explain:

Defining a const variable (i know, const variable doesn't sound too good), ensures that variable always has the same value (or in case of pointers a 'ex. const <type> * const <name>', as in "constant pointer, constant value" (please correct me if i'm wrong). However it uses memory to declare this variable, and it works like any other variable (if somewhere in your program there's a reference to this const variable, the program will fetch it's value from memory.

On the other hand, #define is a preprocessor directive, so no memory will be used for that value, and when a defined value is found in a program, it will be replaced by the value at compile time, not run time.

So, i'm i right to think that #define is better than const, or am i wrong?

Post your thoughts, and do correct me if i'm wrong.

Thanks in advance.

PARTNERS