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.ma...@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
_______________________________________________
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
