Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 25

Thread: Threads..

  1. #11

    Threads..

    Can't you just use OnIdle? I can't imagine that would be that hard. I would under no circumstance(unless paid) try to implement threadbased rendering
    Peregrinus, expectavi pedes meos in cymbalis
    Nullus norvegicorum sole urinat

  2. #12

    Threads..

    I don't know is this what you want... I wrote this simple program in Lazarus but you could port it to Delphi very easy (only Windows and GL functions are used).

    http://www.geocities.com/srki_82/GLThread.zip

  3. #13

    Threads..

    Threading and openGL are big enemies. This is known and future GL versions promise to fix it by changing the whole API from "set_state(x); do_something;" to "set_state(x); do_something(x);"

    Right now, threading and openGL results in slowdowns more than anything else. You need to add a hell load of locks to ensure proper functionality and even on multicores I doubt it'd be faster than single-threaded one.
    Feel the power of Open Source.
    <br />Feel the power of Free Pascal.

  4. #14

    Threads..

    Thanks for all the replys

    i have came across sooo many annoying bugs and problems so i have decided not to bother and just use the OnIdle event as suggested and all seems to work fine, a little slow sometimes, and an annoying problem with loosing the contents of the GL rendering context everytime i resize but i think thats an SDL issue.

    again thanks for the replys.
    M109uk
    <br />--------------------------------------------------------
    <br />www.pulse-soft.oneuk.com

  5. #15

    Threads..

    Create your window manually and you'll never lose the context. Still, you can lose some "less significant" pieces, like z-buffer, when you switch from 16-bit to 32-bit video mode.

    I wonder if the Doom3 way (require restart each time user changes screen resolution) is the only absolutely safe one.

    On the other hand, maintaining your window manually is *such a pain*...

  6. #16

    Threads..

    Yeah i looked into creating the windows manually, however i had several problems with initializing the OpenGL extensions, for some reason it never let me setup multi-sampling or any other extension. I tried looking at several examples, and used 3 different set of headers.

    Also although the game is being written for windows, i do want the option to be able to have it crossplatform compatible, and from my understanding SDL and OpenGL are probably my best option.

    Its not so much of a problem with restarting the game, it was more of an issue with in my editors, because it takes between 1-5 minutes to load all the data on start-up, and this will be a huge pain if you have to wait for soo long everytime the window is resized. Its kinda odd, i heard that this was a problem only with windows, but i dont recall having this problem before i started this project :s
    M109uk
    <br />--------------------------------------------------------
    <br />www.pulse-soft.oneuk.com

  7. #17

    Threads..

    Well, you can use SDL for the fullscreen mode and the custom-created window for the windowed mode.

  8. #18

    Threads..

    Quote Originally Posted by M109uk
    Yeah i looked into creating the windows manually, however i had several problems with initializing the OpenGL extensions, for some reason it never let me setup multi-sampling or any other extension. I tried looking at several examples, and used 3 different set of headers.
    You did remember that you need to allocate a temporary opengl context to get the addresses of the extension procedures used with multisample initialization BEFORE you set your main pixelformatdescriptor?
    Peregrinus, expectavi pedes meos in cymbalis
    Nullus norvegicorum sole urinat

  9. #19

    Threads..

    Well, you can use SDL for the fullscreen mode and the custom-created window for the windowed mode.
    I had though of having 2 Engine classes, 1 SDL and the other manual, how ever the problem is that i need the extensions in most of the editors, although the scene/world editor is now being built in to the game itself as a live (local/server) editor, and this is'nt as much of a problem. but in the end i though i'd just turn off resizing of the SDL window, until i can figure the problems out.

    You did remember that you need to allocate a temporary opengl context to get the addresses of the extension procedures used with multisample initialization BEFORE you set your main pixelformatdescriptor?
    Yeah, thats the strange thing, i initialized opengl then created the window and context, then initialized the extensions and then recreated the window, sometimes the extensions would load and sometimes they would but when i came to use them i kept getting access violations, i double checked my entire code for anywhere else that was initializing the opengl and/or extensions but there was none.

    I then tried to download the delphi translation of NeHes example, i compiled it using the original headers which failed, i then changed the headers to dglOpenGL which also did the above, and i then tried the the Gl, Glu headers and this just failed before the i even got to initialize the extensions.

    I have the latest OpenGL drivers, although they are still beta vista drivers.. but that cant be the problem otherwise it would'nt work in SDL :s
    M109uk
    <br />--------------------------------------------------------
    <br />www.pulse-soft.oneuk.com

  10. #20

    Threads..

    and then recreated the window,
    Maybe this is the cause. When you create OpenGL rendering context, you create it for a given device context. The device context, in turn, belongs to your window.

    So, you see, if you re-create the window your rendering context becomes invalid!

    Again, AFAIK, any extensions you load are valid *only* for the given rendering context. If you re-create the context, you must reload all extensions.



    ...Well, that was for Windows. In Linux it's even more painful, as user clicking on your window's "close" button leads to your program's instant death, and you should use some elaborate hack-arounds to allow to at least auto-save graciously..

Page 2 of 3 FirstFirst 123 LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •