Hello,
thanks for the info about the underscores : ), now I learned something
interesting.
I ended up downloading the source and MSYS and compiling GTK+ in my 64 bit
system. It was a long and tedious process :P getting all the dependencies,
setting up environment variables... also I had to install PERL because some
part of the compilation needed it, but...
In the end compiling it worked and my linker now recognized it and I didn't
have underscores problems anymore :)
However, I found that it didn't solve the vertex problem. I was so
frustrated that I ended up compiling WxWindows and trying to learn how to
use it (which has been a bit complicated because I don't have too much time
left for this project), but when I built the app using WxWindows, I had the
same problem!
Here is a more detailed description of this problem:
I have a class that stores values read from files in float arrays. I have
another class that uses the previous one, and this latter class is used in
the main file, in the GTK+ functions.
In my laptop with a 32 bit system, everything is cool. It works as
expected.
In my 64 bit machine (and another 64 bit machine), the array values are
messed up. If I initialize the arrays to some arbitrary number, that will be
the final value of the arrays when I call them. However, if I directly
called the first class from the main.cpp file without using the second
class, it works!
I built a test program that uses those classes the same way, without using
GTK+ (using GLUT for window creation), it works without a problem!
After discovering that WxWindows didn't solve the problem, I set up various
tests, and in the end found out the source of the problem. In the class that
reads from files, I was using cstdio functions (fscanf mainly). I found out
than when called from GTK+ with the intermediary class, the fscanf calls
would read the strings but not the floats, the values stored in the passed
variables would stay the same as before the call. (these values are vertex
positions)
I solved this issue changing all the csdtio calls to c++ calls ( from the
ifstream library e.g. ifstream fin("file"); fin>>floatVar; ). With the c++
calls the values were adecuately read and stored. There is a side problem,
now the reading process is significantly slower and I have to wait several
seconds for the program to read the files.
I am utterly perplexed by this, any insight is welcome : )
Thanks again for your time, and thanks Jaroslay for answering my first
e-mail.
Mario Maqueo
2010/11/2 Jaroslav Šmíd <jardas...@gmail.com>
> Mingw64 defaults to no leading underscores (this is quite new
> feature), make sure GTK+ libraries are compiled by mingw64 version
> built after this was done. If you use newer mingw64 and older GTK+ or
> vice versa - trouble ahead :-)
>
>
> On Tue, Nov 2, 2010 at 9:03 AM, Mario M <maqueo.ma...@gmail.com> wrote:
> > Hello, I have Windows 7 64 bits and I am working on a GTK+ project that
> uses
> > OpenGL in C++. I am using GLADE and the normal version of GTK+ (not
> gtkmm).
> >
> > I was working on a laptop with Windows 7 32 bits and the program worked
> > fine, but the video card in that laptop was really bad (Intel,
> integrated)
> > so I switched to a desktop with 64 bit windows and a better video card
> > (Nvidia GT 240).
> >
> > The code compiles fine in both versions of windows, using the 32 bit
> version
> > of gtk. However, some horrible things have been happening:
> >
> > - The OpenGL window would not update correctly, taking a long time to do
> so,
> > seemingly at random times. I was using gtkglext for the OpenGL binding
> but
> > I found out this problem was caused by gtkglext not being updated (since
> > 2006) and the problem is with Aero in Windows, If desktop compositing was
> > disabled, it would work fine. I decided to ditch gtkglext and use OpenGL
> > directly, after a while I managed to and this problem was fixed.
> >
> > - Some colors were messed up with lighting enabled, at first I thought
> this
> > and the previous problem had to do with the video card, but this was
> weird
> > because the same program without gtk would work fine. However I managed
> to
> > correct it adding a few simple OpenGL instructions. I'm not sure why it
> > worked fine without GTK+, but it seems to work fine now with my fix.
> >
> > - I have a library for loading 3d models, in my laptop it worked fine,
> but
> > on the new computer (and another one where i tested it), the 3d models
> > render as a single horizontal :S, all of them. They are drawn using
> openGL
> > functions and storing the vertex positions in lists. I discovered this:
> When
> > I load an object in the main.cpp file, and draw it, it works fine,
> however,
> > when I load it in an external file, and draw it, it doesn't work ( I get
> > just a horizontal line, and again, without gtk+ it works fine). This has
> me
> > really perplexed, I think it might have something to do with the linker
> but
> > I have no idea how. I added some debugging and I think the problem is in
> the
> > vertex positions, I printed their x,y,z values and they seemed to have x
> > position in -1,0,1 and the y and z positions were values like 3.43e-039,
> I
> > think the pointers might be messed up but I don't know how to fix them
> :S. I
> > manually drew a triangle in the file that draws the 3d models, and the
> > triangle rendered fine. I
> >
> > I thought this might somehow have something to do with using a 32 bit
> > version of gtk+, do you think that is the case?
> > I downloaded the 64 bit binaries, and tried to compile my code, but the
> > linker didn't find any function! As soon as I changed the library
> location
> > to point to the 64 bit version, I got a load of "undefined reference"s
> for
> > everything concerning gtk+, even if I manually added the libraries in the
> > project configuration of my IDE it would say the same.
> >
> > I am using Code::Blocks as an IDE and MingW as the compiler.
> >
> > Do I need to change additional configuration to use the 64 bit version of
> > gtk+? Please help me, I haven't slept in two days trying to solve this
> and I
> > am still confused. I downloaded the latest 64 bit version and then an
> older
> > one to see if it was broken, but the results were the same.
> >
> > Or is the problem not related to the 64 bit thing? Any ideas/thoughts are
> > welcome.
> >
> > Thanks in advance for your time.
> >
> > Mario Maqueo
> > _______________________________________________
> > gtk-app-devel-list mailing list
> > gtk-app-devel-list@gnome.org
> > http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
> >
>
>
>
> --
> Jaroslav Šmíd
>
_______________________________________________
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
