| Summary: | No window shows up when runing my 3d engine | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Zacay <zico> |
| Component: | [OLD] Development | Assignee: | Gentoo X packagers <x11> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | major | CC: | azarah |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | patch to nff_load.cc to fix engine | ||
|
Description
Zacay
2003-04-09 17:00:20 UTC
I have geforce 4, tried running glxgears to check if that works.. and I get good results *** Bug 19058 has been marked as a duplicate of this bug. *** what ebuild version of xfree-4.3.0? xfree 4.3.0-r1 latest nvidia latest opengl and latest glut http://www.zacay.com/a1.tar.gz download this simple 3d engine. only 70kb in the directory $ gmake api=GL $ ./engine teapot.nff -s 50 should show some console stuff and a window with wire rendering I tried epsxe with petes mesa/opengl plugin, it doesn't work. .everytime I try to configure the video it gets segmentations fault. .Before it worked.,.. so maybe its the same bug,, or a epsxe bug.. I also tried with merging back to xfree 4.2.1 and tried the 3d engine,, doesn't work! so now I am back with 4.3.0-r1 Do not segfault here, but no teapot either ... I get: -------------------------------------- azarah@nosferatu a1 $ ./engine teapot.nff -s 50 Reading 1976 vertices. Reading 0 surfaces. Calculating normal vectors azarah@nosferatu a1 $ Oh good, someone else has this problem ,so I am not alone, I dont either get a seg fault when I run my engine, but I was talking about epsxe, when configuring the mesa plugin it get seg fault. But I epsxe isn't important. .the important thing is for me to continue on my 3d engine.. I am thinking of installing another linux on a new partition just for working with 3d engine :( So what do you think is wrong? why couldn't the 3d engine show the window with our versions of packages? Maybe try to downgrade the nvidia drivers ? I tried downgrading the nvidiakernel and glx.. still same problem.. :( I downgraded to 3123 I think the number is.. In your engine example, it is exiting before it gets to any of the glut / gl stuff.
It's dying at line 395 in main.cc where it loads the .nff file viz:-
if (!eng.load_object(argv[i])) {
exit(3);
}
glut demos work here, python gl glut demos too. Nvidia ti4200 (4395 drivers), xf4.3.0-r2 and glut-3.7.1
Micheal> I guess you haven't understood that the 3d engine works, with no problems with my friends computer. Exactly the same code.. Nothing wrong with the code. Its I guess some compatibility issue with the new packages. If everything work then my engine should work with no problems. Zacay > Take this off line if you want, leahcim@ntlworld.com - let's not turn this bug report into a "oh yes it does" "oh no it doesn't" sequence. It crashing where I said. It crashes because the file parsing is buggy. Look at the output in this thread. It says '0 surfaces' yet cube.nff and teapot.nff clearly have more than zero surfaces. That's not a glut bug or an xfree bug or an opengl bug. Created attachment 10679 [details]
patch to nff_load.cc to fix engine
I've attached a patch to the file handling code that makes the teapot et al
display ok here.
oh my god, is this really how bug reports are handled here? I thought you guys were serious.. This engine works perfectly as it is right now with my friends computer, he just downloaded the same tar file as you guys did. And it works, he gets a rendered object.. The surface stuff isn't done yet, this engine is far from complete. And this bug in the system keeps me from getting it complete. So now don't turn this bug report into a fight either. As the code is right now it should open a window and render the object in wireframe. It works at my school, my old system and my friends computer. My school has Sun Solaris, my old system and my friends computer runs Gentoo. If I wanted help coding I would go to a c++ coding forum, and not go to a OS bug forum. So get serious, this thing is a bug. If you don't see a window then you are experiencing a bug! I really do not see that he is trying to start a fight, so please calm down ? Secondly, he is right ... it never gets to rendering, as it does exit on that line. What is more ... his patch makes it work here. Please, before you reply, add some printf's/whatever, and just have a look. It never get past trying to load the .nff file ... As you will see from following, without the patch, it do not read in *any* surfaces, and with the patch, it actually reads the surfaces, and then display it properly .... ------------------------------------------------------------------------ azarah@nosferatu a1 $ ./engine teapot.nff -s 50 Reading 1976 vertices. Reading 0 surfaces. Calculating normal vectors azarah@nosferatu a1 $ patch -p1 <../a1.patch patching file nff_load.cc azarah@nosferatu a1 $ make api=GL g++ -o nff_load.o -c -Wall -O3 -ffast-math -Wno-deprecated -g -DRANGE_CHECK -isystem /usr/X11R6/include -DGL_GRAPHICS -I. -IGL -I/usr/X11R6/include -I/usr/X11R6/include nff_load.cc g++ -g -Xlinker -rpath -Xlinker /it/sw/gnu/lib -Xlinker -rpath -Xlinker /usr/X11R6/lib -Xlinker -rpath -Xlinker /usr/X11R6/lib draw_triangle.o engine.o globals.o main.o matrix4.o midpoint.o nff_load.o object.o transformations.o triangle.o GL/putpixel.o -L/usr/X11R6/lib -L/usr/X11R6/lib -lm -lglut -lGL -lGLU -lX11 -lXext -lXmu -lXt -lXi -o engine azarah@nosferatu a1 $ ./engine teapot.nff -s 50 Reading 1976 vertices. lines:1982 Reading 3752 surfaces. Calculating normal vectors azarah@nosferatu a1 $ leahcim -- you had some more comments, I believe? I had a closer look at the file handling to see whether
the behaviour could be a glibc issue.
In this snippet, that looks for the
normals after reading the vertices is the problem (line 85
of nff_load.cc)
//ok get rest of line to parse optional normal direction.
char buf[100];
infile.get(buf,100,'\n');
char* ptr=buf;
The infile.get(...) function is setting the stream's fail bit.
This is correct behaviour if no characters are extracted from the stream before hitting the delimiter. i.e if you're at the end of the input line.
Once the stream fail bit is set, the infile.good() checks in the while loops cause the rest of the loading to fail (no further vertices are loaded, no surfaces are loaded)
http://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/classstd_1_1basic__istream.html#std_1_1basic__stringstreamz32_2
I tried changing the nffloader as you said below, yes it load the surfaces.. But still no window.. and I will say it again, don't mind looking into the code. It works in another machine. I just need it to have it work on my machine.. I even tried it on a windows machine and it worked. Zacay, What do you want me to look at? I'm happy that it works with the code changed, you seem happy that it works too. I can't say why your machine has a problem, and none of ours do from the information you've posted so far. So you mean that it works for you guys.. you get the window and the Teapot is showing? if so .. maybe the bug I have is somewhere else in my system. Maybe not x-windows stuff.. I have no idea Well, Zacay, I downloaded your tarball and tried it. No teapot -- the zero surfaces thing happened. Honestly, it worked with Michael's patch to the code. Saw the teapot :) |
