Re: Problem with 64 bit gtk binaries in Win 7 (32 bit works fine)

[Jaroslav ÅmÃd <jardasmid gmail com>]

Well, glib is just depency of GTK+, GTK+ uses glib for things like
event loop, objects ... anyway, can you test my code? It works for me.

Add -std=c++0x to compilers command line for it to compile.

Note that you shouldn't use fscanf to get strings as it is quite
dangerous, anyway I used it so it matches your stuff

On Sun, Nov 7, 2010 at 8:16 PM, Mario M <maqueo mario gmail com> wrote:
> Sorry about the confusion, I do mean in callbacks. I have a Room class and a
> global room instance, the Room class has mesh members which when initialized
> read a specified file.
>
> The callbacks areconnected with:
>
> ////////////////////////////////////////////////////////////////////////////////////////////////////////
> g_signal_connect (grafWindow, "expose-event",
> Â ÂG_CALLBACK (glDraw), NULL);
>
> ////////////////////////////////////////////////////////////////////////////////////////////////////////
> in the main function, then the functions that read the files are called
> inside main from within the room instance with:
>
> ////////////////////////////////////////////////////////////////////////////////////////////////////////
> room.Init();
> ////////////////////////////////////////////////////////////////////////////////////////////////////////
>
>
> Âand then the glDraw function callback for the expose event is:
>
> ////////////////////////////////////////////////////////////////////////////////////////////////////////
> gboolean glDraw(GtkWidget *win, GdkEventExpose *event, gpointer user_data)
> {
> Â Â Â Â while(gtk_events_pending())
> Â Â Â Â {
> Â Â Â Â Â Â Â Âgtk_main_iteration_do(FALSE);
> Â Â Â Â Â}
>
> Â Â Â Â ÂgrafWinGL.beginGL();
> Â Â Â Â Âroom.Draw();
>
> Â Â Â Â ÂgrafWinGL.swapBuffers();
> Â Â Â Â Â grafWinGL.endGL();
> Â Â Â Â Â return TRUE;
> }
>
> ////////////////////////////////////////////////////////////////////////////////////////////////////////
>
> Basically, the room.Init is:
>
> ////////////////////////////////////////////////////////////////////////////////////////////////////////
> void Init()
> Â Â Â Â{
> Â Â Â Â Â Âmesh1.Init("3D/file1.obj");
> Â Â Â Â Â Âmesh2.Init("3D/file2.obj");
> Â Â Â Â Â Â... etc
> Â Â Â Â}
>
> ////////////////////////////////////////////////////////////////////////////////////////////////////////
>
> mesh1 and mesh2 are instances of a mesh class, and room.Draw()
> calls mesh1.Draw() mesh2.Draw() etc. The mesh class, which when reading a
> file in it's Init function, does basically:
>
>
> ////////////////////////////////////////////////////////////////////////////////////////////////////////
> char token[100];
> scene = fopen(obj_file.c_str(),"r");
> float vec[3]={0,0,0};
>
>
> Âwhile(!feof(scene))
> Â{
> Âtoken[0] = NULL;
> Âfscanf(scene,"%s", token);
>
> Â if (!strcmp(token,"v"))
> Â{
> Â Â Â fscanf(scene,"%f %f %f",&vec[0],&vec[1],&vec[2]);
> Â Â Â vList.push_back(Vec3(vec));
> Â}
> Â..........etc
>
> ////////////////////////////////////////////////////////////////////////////////////////////////////////
>
> And here is exactly where the problem is. When I used all of this in my 32
> bit system, everything worked fine. Then in the 64 bit system, fscanf works
> in reading the token, but then fscanf(scene,"%f %f
> %f",&vec[0],&vec[1],&vec[2]); is doing nothing! Apparently it is called the
> correct amount of times, but after returning, the values in vec[0], vec[1]
> and vec[2] are the same as before calling the function, always. Thus, the
> mesh isn't rendered correctly ( meaning it doesn't get rendered at all
> because all the vertices are garbage).
>
> Now, after everything I tried, I changed the previous code to work with
> fstream functions like this:
>
>
> ////////////////////////////////////////////////////////////////////////////////////////////////////////
>
> Âchar token[100];
> ifstream fin(obj_file.c_str());
> float vec[3]={0,0,0};
>
>
> Âwhile(!fin.eof())
> Â{
> Âtoken[0] = NULL;
> Âfin>>token;
>
> Â if (!strcmp(token,"v"))
> Â{
> Â Â Â fin>>vec[0]>>vec[1]>>vec[2];
> Â Â Â vList.push_back(Vec3(vec));
> Â}
>
> .....etc
>
> ////////////////////////////////////////////////////////////////////////////////////////////////////////
>
> And now it works fine! Although it takes a looot more time to read the
> files Â(containing a few thousand vertices), but that bit isn't a gtk+ issue
> but a c++ issue I guess (fstream being way slower than cstdio took me by
> suprise :S ).
>
> ÂI am very confused as to why it doesn't work with cstdio functions.
>
> Of course, I might still be doing something wrong, I think I may have
> slipped some of the gtk+ 32 bit dependencies when compiling gtk+, do you
> think that might affect this problem? I think it shouldn't but who knows. I
> haven't read about any similar problems so far.
>
> I haven't tried only with glib, I don't know much about it and I will have
> to wait until I have finished this project to try that, but thanks for the
> suggestion, I will try when I have time.
>
>
> Thanks!
>
> 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