OpenGL error when using GLSL/OpenGL renderer

Issue #105 new
Ristovski
created an issue

Running the sample produces the following:

OPENGL ERROR #1282: in file ../../src/sys_opengl_c.c on line 438
OPENGL Call: glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, conwidth, conheight,
 Type, GL_UNSIGNED_BYTE, data[dataType])

#1282 == 0x502 aka GL_INVALID_OPERATION

Getting the OpenGL stuff to compile is quite tough too (missing -lGL)

Comments (35)

  1. RMTEW FULL NAME

    You have provided an observation, but not any reproducibility instructions! :-)

    OS? Commands used to compile it?

    Off the cuff, this looks like a problem with your OS install, or the limited functionality it provides.

    Is it the GLSL? Or is it the OpenGL? Or is it both? They are different.

  2. Ristovski reporter

    Gentoo x86_64

    Does it work on your end? I am compiling the basic example (c/cpp_samples) with OpenGL support.

    How I compile it? I fixed up the Makefile.am to include sys_opengl_c.c since it was calling functions from there, and also added -lGL since there seem to be linker errors then I removed -DNO_OPENGL and -DNDEBUG.

    I don't think it has to do anything with my system as I'm here compiling and running advanced OpenGL/GLSL stuff just right. Oh and btw, I have mesa/llvm/Xorg from -git, so no outdated versions there ;)

    Why is the OpenGL support explicitly disabled?

  3. RMTEW FULL NAME

    Thanks for the information. It's good to know that you have a platform where this would be expected to work.

    We currently have no autotools maintainer, so if you want to submit a pull request for your local changes, it would be appreciated. CMake and Visual Studio already include OpenGL/GLSL as a matter of course.

    This code is likely years old and should have been working on Linux for many many people over the years. Someone needs to compare the arguments passed to what mesa takes, and work out what it does not like, that works everywhere else. I'll do it if no-one else does, when I get some time. As we're probably going to have to rely on you to test any fixes, given you're the only one who can reproduce it, it'd be best if you tried it. You don't need to be that experienced a programmer, it's more grunt work of comparing the documentation/implementation to the code and trying alternatives to work out what causes the error.

  4. Ristovski reporter

    I will see if I can debug this further to get something better than GL_INVALID_OPERATION.

    It would be nice if someone else running Linux could confirm this indeed is not working, just for the sake of eliminating any random issues.

    I shall look into this and update the issue when/if I find something.

  5. RMTEW FULL NAME

    There is no known link between the issues. Scaven is right that they could be related, but at this point it's conjecture and any time spent on it could be a wild goose chase.

    No-one other than you has reproduced this specific issue, and without the ability to do so or further information, it is unlikely we will be able to fix it. We'll need your proactive help to fix this. Debug the sample, break on the call to glTexSubImage2D and get the values of all the parameters. Compare them to the function prototype. If you have mesa compiled with debug information, step down into it and see where it raises the error and why.

    If I have time this weekend, I can look at whether this is the problem with the OpenGL rendering on all platforms. Maybe there's a type-based error in the arguments and your Mesa thing is more fussy about it. Maybe. Maybe not.

  6. scaven

    One more observation. I did some profiling with 1.5.1 and 1.6.3 versions, using RENDERER_SDL and noticed that 1.6.3 version is almost 10x slower.. example figures:

    LIBTCOD 1.6.3
    DRAW 13.79; 12.24 & 14.81 & 14.5;  12.42 & 13.46 & 13.53
    
    LIBTCOD 1.5.1
    DRAW 1.61;  1.61  & 1.6   & 1.65;  1.43  & 1.72  & 1.73
    

    I guess that SDL renderer tries to use opengl if it can discover any, and in 1.6.3 it fails to.. Looks like some problem with linking opengl libs.

  7. RMTEW FULL NAME

    Open the sample, run the sample screen with the console that has unbounded FPS. When I pushed the change from SDL1 to SDL2, I believe Jice was very firm about those numbers having to be acceptably close in both. And in fact, there's a good argument that it's the single-most important speed test that needs to be done when rendering changes are made. I check those whenever we make rendering changes, and encourage others to.

    I have never seen, nor heard reported, that these numbers are 10x slower.

    Also, you have given no context for your results. It might very well be that on your platform you get 10x slower FPS and that's what you're talking about. Or it might be that you're talking about 10x slower linking time on startup.

    ?

  8. scaven

    There is a built-in FPS counter in samples, it shows 2-3ms on libtcod-1.5.1-mingw32 vs 13-15 ms on 20170226-libtcod-1.6.3-msvs-Win32.

    The numbers I gave are just for example. I tested on same platform, same code (except for KEY_TEXT fix for SDL2). Actually I tested moving to another version of networking lib, but decided to check graphic output too. That is python, so no linking. It was done by opening app screen and calling keyboard macros to get same results. The numbers are arithmetic means of a whole app run (about 1 minute).

  9. jice

    I made a few tests and get a consistent 160fps on all 1.6.x versions (msvs-Win32) while 360fps on both mingw and msvc 1.5.1. All versions use the same software rendering code (TCOD_sys_console_to_bitmap) but the 1.6.x versions go through another step in actual_rendering :

        texture = SDL_CreateTextureFromSurface(renderer, scale_screen);
        SDL_RenderCopy(renderer, texture, &srcRect, &dstRect);
        SDL_DestroyTexture(texture);
    

    while the 1.5.1 version, using SDL1 was only using :

    SDL_Flip(screen);
    

    This additional step is required to scale the image. I wonder if it's possible to skip it when there's no scaling required.

  10. scaven

    Ok, so part of mystery is solved.. but I've got 360 to 70 fps falldown. Still, I'm convinced, this also is linked to opengl problem. As I said already, if i run samples program, 1.6.3 crushes on OpenGL and GLSL rendering, while 1.5.1 runs them easily. I think SDL tries to use opengl too, fails and makes a fallback to software rendering, which eats the other part of fps. Seems like dynamic opengl library linking, with your systems having needed sys libs, and my system (and OP's) - doesn't have. (Actually i don`t think it's so simple as just wrong type of lib, but something along the lines)

  11. RMTEW FULL NAME

    Huh, I don't remember the SD2 vs SD1 fps differences being so large when we merged in the changes. Skipping the scaling step is a good point Jice.

    @scaven What version of SDL2 are you linked against? Where does it crash when you try it?

    Windows builds build in OpenGL/GLSL by default.

  12. RMTEW FULL NAME

    As behaviour should in most cases be consistent across Windows versions, for the same binaries, I've tried 1.6.3 and it appears to be broken. The FPS is fine for me, but switching to OpenGL or GLSL crashes.

    Can you try an unstable release? Those work for me.

  13. scaven

    I've tried 1.6.3 and it appears to be broken.

    Actually, all 1.6.x releases are broken. I guess there`s a reason why most 3rd party ports stick to 1.5.1.

    Can you try an unstable release?

    Unstable release works on my host machine (Win 8.1), 200fps SDL and nice 2450fps on GLSL Unfortunately it still has problems in VM. It doesn`t crush now, but gives some errors and screen flickers yellow and black. Screens are coming.

  14. scaven

    I'm using VBox with 3D Support enabled. I'll point last time that v1.5.1 didn't have problems with OpenGL/GLSL.

    I use VM as an indicator if my game could be run smoothly on slower or basic-hardware systems. I think roguelikes should be as modest on hardware as they can.

  15. jice

    one possible cause would be that 1.6.x requires higher version of openGL. Maybe the drivers on your guest system are older than the one on your host machine. Did you install any "Guest Additions" in virtual box ? I'm not very used to using 3D acceleration in Vbox, but this appears to be sometimes necessary for the VM to have proper drivers. http://www.virtualbox.org/manual/UserManual.html#guestadd-3d

    [update] : you can use this to check the opengl driver version on your VM : http://realtech-vr.com/admin/glview

  16. scaven

    Hi, yes I've got guest additions. Only basic though, as experimental one doesn't work for me.

    Vbox fully supports only OpenGL 2.1 (https://askubuntu.com/questions/858407/how-to-update-to-latest-opengl-version-on-virtualbox-ubuntu-linux-machine/896712#896712) and for me it shows this: 2017-09-26_22-07-16.png

    But when I try to run tests from that program from your link, I can see a flying cube only for 1.1 version, so maybe it`s a problem with my own system here..

    Do you know if you started to use some extensions from OpenGL 3.0+ versions?

    2017-09-26_22-09-11.png

  17. RMTEW FULL NAME

    No idea. When I upgraded the OpenGL support to work with SDL2, the approach was:

    1. Code errors.
    2. Google the error for the standard fix, or guess closest similar approach.
    3. Success.

    I expect most of the fixes were trivial.

    It's not on the cards to hold back the code to support older versions of GL, just to run in a VM.

  18. RMTEW FULL NAME

    I should add @Ristovski that your error is OpenGL specific, that code is not hit by the GLSL renderer. However, you likely can't switch to GLSL without going to OpenGL first. If you edit the sample (Python or C) to skip/remove the OpenGL renderer, you or anyone else experiencing the original issue could use the better GLSL rendering instead.

  19. RMTEW FULL NAME

    I took a look at the MESA code, it factors in some constants with conwidth and conheight and if the outcome is foo high or too low, then it returns the given error. I suggest you chuck in a printf and see what it's passing in as arguments when it errors. The rest of the arguments look effectively constant, and should have no relationship to this error.

  20. jice

    @scaven, libtcod's GLSL implementation requires shaders version 110 which are available only for openGL 2.0+. So if your VM only works for opengl1.1, it makes sense that the GLSL renderer doesn't work.

    I'm not aware of specific requirements for the OpenGL renderer though. This should work almost everywhere. This is very difficult to adress as it might be a bug if the VBox driver, a bug in SDL2 or an issue in libtcod when only a very old version of openGL works.

    You should try to make glView work for version 2.1 and check back libtcod behaviour then.

  21. Ristovski reporter

    @RMTEW FULL NAME, What do you mean? I can switch to GLSL without going to OpenGL first, and it produces a white screen (as opposed to weird yellow/white boxes on OpenGL). I can even choose what renderer to use from the config itself.

    I added a debug conwidth/height for both OpenGL/GLSL: conwidth: 80, conheight: 50

    Edit: I also double checked all parameters going to glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, conwidth, conheight, Type, GL_UNSIGNED_BYTE, data[dataType]) and they all seem fine, so I think the error is in the OpenGL context created or something.

  22. Log in to comment