foobillard++ port

[kas1e]

As we discuss in another topic, there better to made a separate ticket for.

So .. While porting this to amigaos4, found it have some bugs, which probabaly will be good to fix not only for amigaos4 port, but also for Pandora's one. While topic created in the gl4es repo, at moment really one issue which need to be deal with, its adding opengl1.x antialisaing, so antialing in foobillard++ will works.

But , there is some other problems in the foobillard++ code, which trash memory , and heap as well.

One of issues we deal with it was in sound_stuff.c, in the strsound() function, where originally was strcpy(s,&s[strlen(s)-4]); , which should be strcpy(s,&s1[strlen(s1)-4]); or it will trash memory heavy. On amigaos4 it just cause crash, strange why it didn't crashes on Pandora and/or Win32..

Another issues, which also lead to crash, its seems some heavy heap corruption. Crash happens when we navigate over the menu items, and then it crashes in the function create_string_quad() from texobj.c , on the free(texdata) call. Adding pure if(texdata) free(texdata) check didn't help, which mean data is here always , just heap corrupted much so we crash. Issue present and on stable-soruce build, and on the latest code from repo.

So i then add -O3 and -Wall to see, if compile brings any errors , and yes, it bring when trying to build menu.c file:

menu.c: In function ‘menu_entry_set_settingtext’: menu.c:273:28: warning: ‘ : ’ directive writing 3 bytes into a region of size between 1 and 256 [-Wformat-overflow=] sprintf(str,"%s : %s",entry->text,entry->settingtext); ^~~ menu.c:273:13: note: ‘sprintf’ output between 4 and 514 bytes into a destination of size 256 sprintf(str,"%s : %s",entry->text,entry->settingtext); ^~~~~~~~~~~~~ menu.c: In function ‘menu_create_textobj’: menu.c:292:28: warning: ‘ : ’ directive writing 3 bytes into a region of size between 1 and 256 [-Wformat-overflow=] sprintf(str,"%s : %s",entry->text,entry->settingtext); ^~~ menu.c:292:13: note: ‘sprintf’ output between 4 and 514 bytes into a destination of size 256 sprintf(str,"%s : %s",entry->text,entry->settingtext); ^~~~~~~~~~~~~ menu.c: In function ‘menu_choose’: menu.c:273:28: warning: ‘ : ’ directive writing 3 bytes into a region of size between 1 and 256 [-Wformat-overflow=] sprintf(str,"%s : %s",entry->text,entry->settingtext); ^~~ menu.c:273:13: note: ‘sprintf’ output between 4 and 514 bytes into a destination of size 256 sprintf(str,"%s : %s",entry->text,entry->settingtext); ^~~~~~~~~~~~~

That looks very much as overflow come from there, which probabaly guilty for corrupt heap in end.

While simple changes of char str[256]; in those functions from warnings come on char str[1024]; deal with errors, it's probabaly just hide the real overflow problems, which in end cause heap corruption and because of which we crash later when do free.

I also can see this kind of warnings in the language.c and history.c files, but they of no use when i navigate over menu, so probabaly only those from menu.c relevant to the heap corruption. At least, while i didn't go to the history/language sections of menu.

Dunno how to detect from where it come through, on amigaos4 we have almost no tools to debug such things :(

[kas1e]

And that how looks like visuall glitches in menu (which maybe related to the corruption of memory/heap/crash). See there all letters "p, y and g" have an some line at bottom, its like some trail line from other buffers maybe, or the end of buffer overflows and put at top. Or, code just wrongly calculate from what place take the letter (or maybe freetype itself):

http://kas1e.mikendezign.com/aos4/gl4es/games/foobillardplusplus/foo_menu_trash1.jpg

(i point by red marks on those trailing lines)

[kas1e]

Oh, and the same visuall glitch i have in win32 version too. Just it a bit different: on amigaos4 tralining lines come only when i go to the menu which have those letters, but on win32, it shows just when menu renders. But on win32 it didn't crashes, but i suppose win32 can catch all sort of issues / corruptions and free/skip many kind of bad accesses without user notice.

[ptitSeb]

The trailing lines are probably a side effect of texture coordinate looping. Not sure its easy to fix, plus if the Win32 version have the same I'm not sure it's worth investigating more.

For the Antialiasing. It willl require me to write new stuff in fpe_shader.c (the FixedPipeline -> Shader generator). So it's on my TODO, but not on the top of the list.

[kas1e]

The trailing lines are probably a side effect of texture coordinate looping. Not sure its easy to fix, plus if the Win32 version have the same I'm not sure it's worth investigating more.

What i mean, is that maybe its related to heap corruption which has foobillard++ code (that trailing lines). And that heap corruption will behave bad on all platforms for sure, just on Pandora you was lucky when test that it didn't crash not in init_sound part, not now when you navigate over menu. I will try to find out what wrong and post there, so you can update pandora port as well to make it more stable. If you in interest :)

[ptitSeb]

I don't think the trailling lines are a side effect of the heap corruption. I think it's only GL stuff, with texture coordinates issue: Take a simple texture of 100x100 pixels (I take this coord for easier math), with the GL_WRAP_S and GL_WRAP_T setup to GL_REPEAT (that's the default setup). That means that the texture coord 0.0 is the 1st pixel of the texture. The last pixel is coord 0.99 (that is, texture is from ixel 0 to pixel 99, than it "normalized", so divide by size, wich is 100). With GL_CLAMP_TO_EDGE, using TexCoord of 1.0 is the same as TexCoord of 0.99, it's still the last pixel. But with GL_REPEAT, TexCoord of 1.0 go back to the 1st pixel (to handle repeated texture). My guess is that that trailling line is in fact the other side of the texture (I guees the White/Yellow is one texture, the block outline is another texture). But that's just me guess.

[kas1e]

Those little trailing lines for sure not the big problem, if they not related to heap corruptions game have, then be it of course :)

At moment i found that DrMemory for windows (kind of valgrind for linux) , have good ability to detect bugs, at moment when i run foobillard++ win32 version over it, it bring me lots possible issues, and in end that big list:

ERRORS FOUND: 62 unique, 2526 total unaddressable access(es) 7 unique, 112 total uninitialized access(es) 0 unique, 0 total invalid heap argument(s) 0 unique, 0 total GDI usage error(s) 0 unique, 0 total handle leak(s) 0 unique, 0 total warning(s) 205 unique, 249 total, 2326115 byte(s) of leak(s) 63 unique, 80 total, 1346702 byte(s) of possible leak(s)

POTENTIAL ERRORS FOUND: 39 unique, 71 total potential unaddressable access(es) 271 unique, 59317 total potential uninitialized access(es) 1 unique, 1 total potential invalid heap argument(s) 1 unique, 1 total potential GDI usage error(s) 77 unique, 88 total potential handle leak(s) 7 unique, 22095 total potential warning(s) 22 unique, 43 total, 44568 byte(s) of potential leak(s) 15 unique, 24 total, 209242 byte(s) of potential possible leak(s)

So for sure some of them are real bugs, just need to build win32 version with debug symbols.

Did i understand right, that for Pandora you don't have window mode, only fullscreen one all the time ? And if so, what happens when you trying to switch between window and fullscreen mode in foobillard++ ? Or for pandora you just comment out that code and force to be fullscreen all the time ?

[ptitSeb]

The Pandora is a Handheld with a small screen. While technically I can have 3D in a window, it's most of the time slower than fullscreen (for technical reason), so I force fullscreen most of the time yes. Now, the Pandora is linux base, so most of the time I use "ssh" (so remote access) when I develop / debug stuff on it. So I can let the game run fullscreen, I use another screen for debugging anyway.

[kas1e]

I was able to build original (without my changes) foobillard++ win32 version with debug symbosl, and run DrMemory on it (pretty good one indeed). And, it found for me 4 places where it leaks.

For first, its that sound_init stuff, which we before fix with Daniels help. It point exactly on that line, see:

Error #61: UNINITIALIZED READ: reading register edx 0 replace_strlen [d:\drmemory_package\drmemory\replace.c:412] 1 init_sound [D:\msys64\work\foobillardplus-3.42beta\src/sound_stuff.c:99] 2 SDL_main [D:\msys64\work\foobillardplus-3.42beta\src/billard3d.c:7637] 3 console_main [C:/repo/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/pseudo-reloc.c:374] 4 __tmainCRTStartup [C:/repo/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crtexe.c:339] 5 KERNEL32.dll!BaseThreadInitThunk +0x23 (0x743a62c4 <KERNEL32.dll+0x162c4>) Note: @0:00:53.360 in thread 7724 Note: instruction: test %edx %edx

What mean we kind of can belive to the report it generated.

So, next leak it found, which is probabaly cause heap corruption are:

1. same UNINITIALIZED READ for the menu.c in the function menu_create_textobj(), that line: if( entry->show_subsetting && entry->settingtext[0]!=0 ){ , and only in that function. Because at top of it another function, called menu_entry_set_settingtext and has same line, but in this one it didn't leak. So it only in the menu_create_texobject().

2. LEAK 8192 direct bytes 0x036f3100-0x036f5100 + 0 indirect bytes come from font.c , from getStringPixmapFT() function, at line : (*data)=malloc(w*h);. and data there is that texdata , on free() of which we crashes when navigate the menu.

3. LEAK 624 direct bytes 0x037d4c30-0x037d4ea0 + 0 indirect bytes come from textobj.c , from textObj_new() , line obj=malloc(sizeof(textObj));

So, i think one of those (or all of them) unfixed issues cause in end heavy heap corruption which cause free(textdata) to crash.

And its not even "possible" leaks, its leaks for sure (DrMemory have options to show if leak is possible one, or for sure leak/bug).

Strange that it didn't crashes on Pandora through. Too much protection probabaly from bad code ..

Trying to see what wrong there .. Maybe you will have any clue as well ?

[kas1e]

In short summary it looks like this:

From menu.c/menu_create_textobj() we have unitiialized read on if( entry->show_subsetting && entry->settingtext[0]!=0 ){ , then from same function we call after that leak textobj.c/textObj_new() , which also continue to have leak on the obj=malloc(sizeof(textObj)); string , and then , textobj.c/create_string_quad() called, which call font.c/getStringPixmapFT() in which we already on big leak when do (*data)=malloc(w*h);

In end of which it probabaly fuck the heap, and give us that crashes on free(). Only to understand from where it come :)

[ptitSeb]

This is a bit confusing. Are you looking at Leak or Heap corruption? Because that 2 completely different things. Leak will NOT provoke a crash (not directly). Leak are stuff that you malloc but never free. Unless there is a lot of leak that leads to a "no more memory" error, that are harmless (but should be fixed when possible). Heap corruption are, for example, writing stuff in a array but outside of array bould, overwritting stuff that should not be overwrote. That leads to crash. So now, I don't understand, that menu_create_textobj(...) function, does it leak or does it corrupt heap?

[kas1e]

I just looking for any kind of bugs, which can explain why it crashes on free(textobj). The only explain i have when free() crashes, its heap corruption. But heap corruption probabaly can be caused when some buffers overflows or overruns, and DrMemory probabaly say "leak" in logs with meaning that bytes copies wrong, or to wrong place => can be cause of heap corruption.

I also tested r170 version just to be sure : it have exactly same leaks, and same issues. So probabaly if you will run it over valgrind on unix, you will see the same as i see with win32 version with DrMemory.

The report for menu_create_textobj(...) grabbed from r170, looks like this:

Error #77: UNINITIALIZED READ: reading register eax 0 menu_draw [D:\msys64\work\foobillardplus-code-r170\src/menu.c:291] 1 DisplayFunc [D:\msys64\work\foobillardplus-code-r170\src/billard3d.c:5771] 2 sys_main_loop [D:\msys64\work\foobillardplus-code-r170\src/sys_stuff.c:889] 3 console_main [C:/repo/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/pseudo-reloc.c:374] 4 __tmainCRTStartup [C:/repo/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crtexe.c:339] 5 KERNEL32.dll!BaseThreadInitThunk +0x23 (0x743a62c4 <KERNEL32.dll+0x162c4>) Note: @0:06:09.642 in thread 8572 Note: instruction: test %eax %eax

[kas1e]

To add : i run DrMemory to show all possible errors. So far it found errors in sound_init() and claim them as UNITIALIZED READ, same for that menu_create_textobj(...). So it for sure can be cause crash if it the same kind of error.

Maybe it crashes on free() just as side effect, and corruption of heap happens after leaks happens, and something going wrong. At least its sound pretty logical, and bugs reported by DrMemory point out exactly on those parts which involved in crash.

[ptitSeb]

DrMomory "LEAK" are leak, meaning, malloc without free. What you should look for are uninitialized access and things like that.

Now, for starter, based on that DrMemory log, first thing to do I guess is line 259 & 260 of billard3d.c change the 2 lines with

menuType  *g_act_menu = NULL;  // start menu entries declared here and used from
menuType  *g_main_menu = NULL; // inside this and menu.c

So it's initialized.

[kas1e]

Yeah, drmemory report some unitialized accesses, which in our case all the time uninitialized reads, so that one from menu_create_textobj(...) can be guilty probabaly.

Tried what you suggest , make no difference sadly :(

[kas1e]

Hi, good news ! We found where issue is and fix it :

There was issue with the getStringPixmapFT()/my_draw_bitmap() which trash the memory, which trash heap and cause free(Textobj) crash later. Found that sometime it try to use negative coords (-1), so we add code which avoids blitting outside left bounds (and thus trashing memory there) . Those changes causes the bitmap to be allocated bigger/wider and the blits to be offset to the right so that final blit X position of each glyph (char in string) is always >= 0.

There was also some other issues : sometime crashes when choice one of the menu entries, and that happens because of parent_entry being uninitialized, so i just add a line to menu_new() which sets menu->parent_entry to 0.

If there is needs, i can made a diffs and share them, through you probabaly have no big interest in , as even with buggy code it still works fine on linux/pandora/macos/win32 by some reassons.

The last thing i have is to deal with z-fighting on the table like a show in the video before, and i compile the same code and for win32 and for minigl, and there is no z-fighting issue, so probabaly its gl4es (?). How to better fix it, inside of gl4es or adapt the game ?

Also, found another little difference:

That how looks like table on the win32:

http://kas1e.mikendezign.com/aos4/gl4es/games/foobillardplusplus/foo_shadow_on_table_win32.jpg

That how looks like table on gl4es/aos4:

http://kas1e.mikendezign.com/aos4/gl4es/games/foobillardplusplus/foo_shadow_on_table_gl4es.jpg

I.e. there is no shadows on the table. Is it expected to be like this (like something unimplemented maybe somewhere , like broken shaders in warp3d, or missing shadow-light-something in gl4es), or its bug ?

Thanks !

[ptitSeb]

Good work for the bug fix!

For the "shadow", I don't think it's actual shadow on Win32, but more a bug. For instance, I don't have this kind of visual on linux...

[kas1e]

Yeah, looks same as for me on os4. I also checked some youtube videos of foobillard++, and yeah, those ones which runs on linux/macos do not have those "shadows", only win32 vesion seems have it. And it didn't looks like something which should be on table , just wasn't sure if it bug or feature or what is it.. Maybe something with SDL on win32 or the way how it done.. Anyway, not problem then.

So only last problem is that Z-fighting, which happens with gl4es build only. Is it problematic probably to deal with inside of gl4es ? (because if it, you probabaly deal with it already for your previous foobillard++ ports, right ?:) ) , so seems better to adapt game for gl4es differences there ? See how it looks like for me now:

http://kas1e.mikendezign.com/aos4/gl4es/games/foobillardplusplus/foo_z_fight1.jpg http://kas1e.mikendezign.com/aos4/gl4es/games/foobillardplusplus/foo_z_fight2.jpg

Have you any idea how to deal with it ? Reading your thread on pyra forum i see that you deal with same kind of issues in the latest repo-code version, maybe can give a hint where/how/what to debug/change to make it be ok on gl4es ?

Thanks for help !

[ptitSeb]

Mmm, looking at your 2nd screen shot, you see there are some polygon missing (on the upper left hole). I'm less sure it's a z-fighting issue...

The previous z-fighting I add, I adapted the code, adjusting some glPolygonOffset(...). But it was to adapt the drawing of some "decals" (frame on the wall, tapistry on the floor). Here I'm unsure it's that. I would need to reproduce the issue on the Pandora (easily) and do a Capture to understand haw the drawing is done (tricky because the drawing is pretty complex). Another solution would be to pinpoint which drawing command do that, be searching for that command by comenting the draw command one by one to find the good one (probably some glCallList).

[kas1e]

Yeah, will try to pinpoint commands which cause that. But yeah you are right, i see now in compare with win32 build of the same stable-source, that on win32 all fine in that terms (no missing polygons). And on amigaos4/minigl version also didn't see it. So probabaly indeed something in gl4es in terms of glCallList.

[kas1e]

By "didn't see it on amigaos4/minigl version" i mean all fine too, polygons is where they should be.

[kas1e]

And yes, you are right : everywhere where i have that effect, i can see missing polygon at end of the line. I watch closer, and even where i didn't have that effect, that last polygon draws a bit wrong. See:

gl4es: http://kas1e.mikendezign.com/aos4/gl4es/games/foobillardplusplus/foo_miss_polygon_gl4es.jpg

minigl: http://kas1e.mikendezign.com/aos4/gl4es/games/foobillardplusplus/foo_miss_polygon_mgl.jpg

So it mean that something broks the choords of some x/y/z value (?), and final polygon of table's lines draw a bit wrong, in some parts (2/3) of table they still draws, just with some strange look, and in other 1/3 part they just missing (probabaly just choords mean x=y=z or something). Where polygon completely missed, its give that strange effect. And where it not missed, not this effect.

[ptitSeb]

Mmmm, maybe it's an optimisation that goes wrong here. Can you try with LIBGL_BEGINEND=0 to remove the glBegin/glEnd optimisation?

[ptitSeb]

Or also try to use Batch mode with LIBGL_BATCH=5

[kas1e]

LIBGL_BATCH=5 make no differences , but LIBGL_BEGINEND=0 make difference ! It start to be lots slower (of course), but that effect is gone. Through it then show other visual errors. But , probabaly for us important is that this particular effect gone , so its some bug in the optimisation ?

[ptitSeb]

Well, it looks like that yes. The glBegin/glEnd merger for a change :(

[kas1e]

Probably it will be some value misswriten like being negative instead of positive, or something like that :) Fixing glbegin/glend merger will be good anyway : more stuff will works as expected when time will come to port something else with those glbegin/glend routes.

Maybe i can help with adding printfs somewhere , etc ?

[ptitSeb]

It's better for me if I know exactly what drawing routine are called. If youc an identify the glCallList(...) or the glBegin(...)..glEnd() sequence that is not behaving correctly, that will help greatly.

[kas1e]

Seems found. In the last stable source , in the table.c , there is function void my_Bande(..). It has 2 parts with glBegin/glEnd blocks. First one with GL_QUADS (so this one for those border lines), and second one is with GL_TRIANGLES, which draw those final triangles at begining/end of lines. Once i comment out that second block, then all the triangles start to be misssing as in my screenshot few of them, and that effect disappear. Guilty block are:

glBegin(GL_TRIANGLES); autonormalize_triangle(p[1],p[10],p[0],order); autonormalize_triangle(p[2],p[3],p[11],order); autonormalize_triangle(p[0],p[10],p[8],order); autonormalize_triangle(p[0],p[5],p[1],order); autonormalize_triangle(p[0],p[4],p[5],order); autonormalize_triangle(p[3],p[9],p[11],order); autonormalize_triangle(p[3],p[2],p[6],order); autonormalize_triangle(p[3],p[6],p[7],order); glEnd();

And that autonormalize_triangle() are:

void autonormalize_triangle( VMvect v1, VMvect v2, VMvect v3, int order ) { VMvect n; n=vec_unit(vec_cross(vec_diff(v2,v1),vec_diff(v3,v1))); glNormal3f( n.x, n.y, n.z ); if( !order ) { glVertex3f(v3.x,v3.y,v3.z); glVertex3f(v2.x,v2.y,v2.z); glVertex3f(v1.x,v1.y,v1.z); } else { glVertex3f(v1.x,v1.y,v1.z); glVertex3f(v2.x,v2.y,v2.z); glVertex3f(v3.x,v3.y,v3.z); } }

[ptitSeb]

Ah, just some triangles after some quads. Mmmm. ok, I need to look into that.

[ptitSeb]

I don't reproduce the issue on my side. Which sources of foobillardplus are you using to get the issue? I used latest from svn and it's looking good on my side. If it's not this version, on what url did you get them?

[kas1e]

I use latest stable sources (latest from svn slower a lot ovet gl4es in my setup, probably 50% slower, so i use last stable source). And yeah, with latest svn one you will not have that bug triggered, as it didnt use glbegin/glend route in those places anymore).

Link on latest stable source:

http://sourceforge.net/projects/foobillardplus/files/source/foobillardplus-3.42beta.tar.gz/download

For pandora you imho need to use that one too, its really faster than one from svn.

[ptitSeb]

Ok, I reproduce the issue now.

[ptitSeb]

Ok, found the issue, and pushed a fix.

[kas1e]

Yeah ! Thanks a bunch:

http://kas1e.mikendezign.com/aos4/gl4es/games/foobillardplusplus/foo_glbeginglend_yeah.jpg

Btw, i notice, that sometime, when i move camera a lot, or just in some random situation, some walls are black, until i move the camera a little. Did you notice the same in svn version and that is those z-fighting issues ?

[ptitSeb]

The Walls drawing are were I adjusted the Polygon Offset yes, but it's not all the walls, just the one where there is something on the wall.

[kas1e]

Yeah, seems so. Through i can't reproduce it easyly, just can notice that sometime it black.

By polygon Offset you mean those 2 glEnable(GL_POLYGON_OFFSET_FILL); and glPolygonOffset() in some places of your diff ? (if so, i can probabaly easy backport those parts to the stable source).

I also noticed what do major slowdown (at least on my setup) - its just balls detail. On the low i have about 45fps, on the medium 37, on the high about 35 and when iset very high it just crawl to about 22 fps only.

Strange .. I mean, its not what need a lot of power to draw 15 balls imho.

[ptitSeb]

Well, I haven't looked at how balls are drawn, but detail is directly the number of triangle generated for the ball. Depending on the effect applied on the ball for the drawing (like some texgen and multitexture effect), that can makes a few calculation...

And yes, the Polygon offset are the few enable and offset commands in my diff. Not sure you need them, it's a bit hardware dependent I guess, but on the Pandora, it's better with those commands.

[kas1e]

Probably just game done as it done, in the readme on svn page it writen "With minimum graphics = 1,6 GHz CPU", so probably expect 60 fps in full details on 2.2ghz cpu its too much :)

[kas1e]

Found probably another gl4es issue : in some parts of table, bottom of pokets are empty/transparent. I rebuild the same 1:1 source from sratch over minigl ,and it didn't have that issue. So it probabaly gl4es at this time.

There is video of how it looks like: https://youtu.be/r__si0lmCUA

Check from second 17 till 28 for example (see that right middle poket have no bottom, i.e. sometime have, sometime not, it sometime just blinks, but sometime just there is no bottom).

[kas1e]

And as far as i can see, it happens only with 2 pockets : middle-right, and top-right. Other pockets always fine.

[kas1e]

Sometime it can be even like this:

http://kas1e.mikendezign.com/aos4/gl4es/games/foobillardplusplus/foo_poket_less.jpg

(see right top pocket)

[ptitSeb]

Did you tried with GL_BEGINEND=0 ? Also, did you find the rendering code?

[kas1e]

GL_BEGINEND=0 fix it, so it again merger :) Will check today what part of rendering code is involved in.

[kas1e]

Found. That again table.c , this time in big function create_table(). Search there for words black ground of hole , that will be 2 times comment at top of 2 glBegin/glEnd blocks. First block, starts at line 1638, are for the drawing bottom left/right and top left/right pockets. So commenting this out will made draws table without those 4 pockets, but 2 middles ones will still be there. So, second block starts at line 1674, and commenting this one, are for middle pockets to be not drawn.

It both cases, it is GL_QUADS + glVertex3f().

Bug happens in both of two blocks, just in second one (With the middle pocket at right) it visibly all the time easy, while same bug with the pocket at the right/top not always showups, you need to move table a bit , etc.

First block for the 4 pockets at top and bottom looks like this:

/* black ground of hole */ glBegin(GL_QUADS); glVertex3f( (-TABLE_W/2.0-HOLE1_XYOFFS-HOLE1_R*sqrt(2.0))*xf, (-TABLE_L/2.0-HOLE1_XYOFFS)*yf, -0.1 ); glVertex3f( (-TABLE_W/2.0-HOLE1_XYOFFS)*xf, (-TABLE_L/2.0-HOLE1_XYOFFS-HOLE1_R*sqrt(2.0))*yf, -0.1 ); glVertex3f( (-TABLE_W/2.0-HOLE1_XYOFFS+0.5)*xf, (-TABLE_L/2.0-HOLE1_XYOFFS-HOLE1_R*sqrt(2.0))*yf, -0.1 ); glVertex3f( (-TABLE_W/2.0-HOLE1_XYOFFS-HOLE1_R*sqrt(2.0))*xf, (-TABLE_L/2.0-HOLE1_XYOFFS+0.5)*yf, -0.1 ); glEnd();

And second one for the middle pockets:

/* black ground of hole */ glBegin(GL_QUADS); glVertex3f( (-TABLE_W/2.0-HOLE2_XYOFFS-HOLE2_R)*xf, +HOLE2_R, -0.1 ); glVertex3f( (-TABLE_W/2.0-HOLE2_XYOFFS-HOLE2_R)*xf, -HOLE2_R, -0.1 ); glVertex3f( (-TABLE_W/2.0-HOLE2_XYOFFS+2.5*HOLE2_R)*xf, -4*HOLE2_R, -0.1 ); glVertex3f( (-TABLE_W/2.0-HOLE2_XYOFFS+2.5*HOLE2_R)*xf, +4*HOLE2_R, -0.1 ); glEnd();

[ptitSeb]

Ok great. I'll probably try to fix that on monday.

[ptitSeb]

Mmmm, I don't reproduce the issue on my side. The pocket are always present, no mater the angle of view I choose, the table is always correctly drawn.

Do you have a specific settings, something not default?

[kas1e]

I tried to delete config file and run again : and issue still there.. Do you check on latest stable source (not on svn one) ?

[ptitSeb]

Yes, testing using 3.42 somthing sources.

[kas1e]

Very strange .. Will try to rebuild original table.c (maybe when i tried to find previous bug commenting out something by ancident)

[kas1e]

Recomplied all from scratch : same issue. Once i do setenv LIBGL_GLBEGINEND 0, issue disappear.

I made another video, to show that problem from different point : i just run it with default config, then go to menu, and choice in sound "on/off" few times, and you can see, that when i do change it , the right/top pocket, loose top of poket and being transparent. Check from second 10 to 20.

Then, in the same video, i set LIBGL_GLBEGINEND 0 , and run it again, and doing the same : no disappearing of the right-top pocket. See from the second 35 to 45.

There is video : https://www.youtube.com/watch?v=xVntJPnFtSI

Maybe you by some luck have GLBEGINEND be in 0 when test it ?