#33 (open) Glide support

open
nobody
None
5
2014-07-27
2005-02-22
Simon White
No

Would be nice to get glide dos drivers. The openglide
ones work very well (wrap glide to opengl) I guess
could go direct for native 3dfx cards to.

Under Windows, somebody wrote a vitural device for the
dos box amounting to nothing more than a two way pipe.
It shipped requests through to Windows which then call
the real (or emulating glide library).

This allowed the old glide games to run in newer
versions of Windows extrememly well and the same code
should work here to providing some sort pipe can be
setup to allow requests in/out of the programme running
under dosemu to linux.

Discussion

  • Stas Sergeev

    Stas Sergeev - 2005-02-22

    Logged In: YES
    user_id=501371

    If you know how to use openglide without any documentation,
    or if you know where is that documentation, or if you know how
    to build it under linux - feel free to enlighten us:)
    But looking into their CVS, it was not updated for almost a
    year already.
    Thats a waste of time I think.
    Also, what progs use that? I think perhaps Carmageddon1
    does, but there seem to be not too much to bother.

     
  • Nobody/Anonymous

    Logged In: NO

    Granted there are not a lot but there are more games than
    that. I was not expecting you guys to deal with the
    openglide issues, I'll be looking at that myself. I am in
    contact with them and will sort something out.

    If, as and when the time comes the only support I'll need is
    to hook something into the dos environment to comnicate to
    linux.

     
  • Alzheimer

    Alzheimer - 2007-04-29

    Logged In: YES
    user_id=1024324
    Originator: NO

    There are several 3dfx games in DOS. I still have a machine that runs DOS with a 3dfx card in order to play some of them.

    • Battle Arena Toshinden
    • Blood
    • Carmageddon
    • Descent II
    • Dreams to Reality
    • Extreme Assault
    • Grand Theft Auto (also had a Windows version which will probably run in Wine though)
    • Red Guard (Elder Scrolls)
    • Screamer 2
    • Tomb Raider I
    • etc

    Many of these games were developed specifically with 3dfx cards in mind; although they usually also have a software mode, these look extremely crappy. With 3dfx cards there were already texture smoothing, mirroring, etc effects that are simply missing in the software versions, so graphics look extremely dull without it.

    I don't think it will be easing implementing support for this in dosemu (or any other emu), there is one project called "glidos" for windows that does it, but it requires very specific hacks for each game. And as far as I know it is not free...

    But still, it would be a great feature... and we are allowed to dream, aren't we ;)

     
  • Simon White

    Simon White - 2007-05-01

    Logged In: YES
    user_id=59929
    Originator: YES

    I have access to the Glidos "closed" source and wouldn't consider it a hack. The wrappers are all written for dosemu, half being in openglide already and the rest as a plugin for dosemu (requires vxd support). The patch is not in the repository here and it is about a year and a half ago since I last played with it.

    In terms of use the glide.ovl needs building with a compiler that I have no access to. As a result tests were all performed by adding the wraper code directly to the test examples. Unfortunately I never managed to find out how to create the right kind of binary from djgpp or open watcom.

    Patch is here (against a version of SVN just as it switched from CVS). I can devote some time to getting it updated/merged if a developer of dosemu has interest in supprting me.

    Patch file: http://sidplay2.sourceforge.net/dosemu.patch.gz

     
  • Simon White

    Simon White - 2009-01-31

    Update:

    Tombraider now runs with 3dfx support under DOSEMU.

    Build details and a screen shot can be found here:

    http://openglide.cvs.sourceforge.net/viewvc/openglide/openglide/platform/dosemu/

    The glide2x.ovl must be built with openwatcom, a patch exists for DOSEMU 1.4.0.

    Issues:

    Code crashes when the DOS code tries to open an opengl display (permission denied). A temporary work around is to open the screen from DOSEMU before the game starts:

    plugin_openglide - thunks.i:
    @@ -193,7 +193,7 @@
    ENDDECLARE

    DECLARE_THUNK0(GRGLIDEINIT, void)
    - //fcall ();
    +
    fcall ();
    ENDDECLARE

    DECLARE_THUNK1(GRGLIDESHAMELESSPLUG, void, int, a)
    @@ -246,9 +246,8 @@
    GrScreenRefresh_t, c, GrColorFormat_t, d,
    GrOriginLocation_t, e, int, f, int, g)
    FxBool ret;
    - printf ("%u %u %u %u %u %d %d\n", a, b, c, d, e, f, g);
    - //ret = fcall (a, b, c, d, e, f, g);
    - RETURNI (1);
    + ret =
    fcall (a, b, c, d, e, f, g);
    + RETURNI (ret);
    ENDDECLARE

    DECLARE_THUNK0(GRSSTWINCLOSE, void)

    plugin_openglide - openglide.c:
    @@ -265,6 +265,8 @@
    memset (thunks, 0, sizeof (thunks));
    / Configure thunks (Note this can be removed when
    * thunks can be directly registered and called
    /
    + grGlideInit ();
    + grSstWinOpen (0, 7, 0, 0, 0, 2, 1);
    thunks[CMD_GRGLIDEINIT] = &THUNK(GRGLIDEINIT);
    thunks[CMD_GRSSTQUERYHARDWARE] = &THUNK(GRSSTQUERYHARDWARE);
    thunks[CMD_GRSSTSELECT] = &THUNK(GRSSTSELECT);

    Lastly keyboard input is not accepted from the 3dfx window, so focus must remain on the DOSEMU window.

    Any advice on these issues to allow better integration with DOSEMU is welcome.

     
  • Stas Sergeev

    Stas Sergeev - 2009-05-28

    Sorry but I can't send the e-mails to you:

    Message from yahoo.com.
    Unable to deliver message to the following address(es).

    sidplay@ntlworld.com:
    81.103.221.10 does not like recipient.
    Remote host said: 550 Invalid recipient: sidplay@ntlworld.com
    Giving up on 81.103.221.10.


    Please fix your address and contact me again. :)

     
  • Stas Sergeev

    Stas Sergeev - 2009-05-28

    That was a note for s_a_white who tried contacting me by mail,
    others please ignore. :)

     
  • Simon White

    Simon White - 2009-05-28

    Stas - I've sent an email with my addresses (note the sourceforge email is active).

    The crash has finally been located. Issue is related to a stack overflow caused by large stacked items in the GL drivers. I'm not sure where this stack limitation comes from as my understanding is that Linux automatically grows stack pages. I presume something in DOSEMU causes stack page limits?

    The problem can been seen by the stack growing and overwriting the memory pointed to by emu_stack_ptr. For now pushing all calls to another thread fixes the problem.

    I'm trying to understand the setup of the stack in DOSEMU and how it is manipulated by direct dpmi transfer. Any details on this are appreciated.

     
  • Stas Sergeev

    Stas Sergeev - 2009-05-28

    You need to deal with the signalstack array in emu.c and
    cstack pointer in emu.h. (of course there could be only a
    single definition to adjust - don't ask me why not yet :)

    direct_dpmi_transfer is likely to be out of your interest:
    it only switches from dosemu stack to dos stack, but not
    backward. The backward switch is done by the kernel,
    because dosemu uses the sigaltstack() syscall.

     
  • Stas Sergeev

    Stas Sergeev - 2009-05-28

    And yes, linux does grow the stack, but not when you
    are on a sigaltstack's stack. Your code works in a SIGSEGV
    handler of dosemu, IIRC. There are mostly no pitfalls to
    this as the SIGSEGV comes from the DOS code (no reentrancy
    problems can arise), but you've found one. :)

     
  • Simon White

    Simon White - 2009-05-31

    Given what you have said is it possible to transfer control back to the real DOSEMU (with its stack) and complete execution there?

    For example in the can I call something that will:

    1. Store the scp containing the values from DOS.
    2. When exiting the SIGSEGV context will prevent the dos code restarting
    3. When exiting the SIGSEGV context will switch to dosemu context and either re-run the dpmi_fault or call one of my functions with the stored scp (since I already know the code path leads to my code). Note re-runing dpmi_fault would require detection of whether we have come from the dosemu or SIGSEGV context.
    4. Lastly on completion of that code will resume the dos program

    I was looking into dpmi_return_request, which looked like it returns back to the dosemu code. However I'm as yet unable to determine where it ends up after calling dpmi_control. It effectively calls a function pointer from emu_stack_ptr[-2], which I'm a little confused about, but seems stored from a previous dpmi_switch (DOSEMU->DPMI?).

    Conceptually would getting emu_stack_ptr[-2] containg the function I want called run the above sequence?

     
  • Simon White

    Simon White - 2009-05-31

    Oops, scrap that last section:

    dpmi_return_request uses emu_stack_ptr[-2] as the address to start execution when returning, stored from a previous switch I guess.

     
  • Stas Sergeev

    Stas Sergeev - 2009-06-01

    And now my e-mail is completely downeither. :(

    Given what you have said is it possible to transfer control back to the
    real DOSEMU (with its stack) and complete execution there?
    Yes, but why would you want that?
    Do your work in a SIGSEGV handler, then return to the DOS code.
    Just enlarge the sigaltstack, and you are fine.

    I was looking into dpmi_return_request, which looked like it returns back
    to the dosemu code.
    It does.

    However I'm as yet unable to determine where it ends
    up after calling dpmi_control.
    It returns from dpmi_control(), then from run_dpmi().
    Then dosemu does some stuff and calls dpmi_control() again.
    Or it may call run_vm86() instead. There is really a little reason
    to return via dpmi_return_request(), other than to call vm86().
    So why would you do that? You don't need to learn all that
    trickery at all, just do your work in a sighandler, or what is the
    problem?

     
  • Stas Sergeev

    Stas Sergeev - 2009-06-01

    Note re-runing
    dpmi_fault would require detection of whether we have come from the dosemu
    or SIGSEGV context.
    The detection is done in dosemu_fault1(), which looks
    a bit messy now. I still don't understand why do you want
    this all to happen, just enlarge the sigaltstack.

     
  • Simon White

    Simon White - 2009-06-01

    I still don't understand why do you want this all to happen

    I was investigating possibilities :). I was mainly doing this because:

    -There may have been easy support to do this and it might have been cleaner than passing between threads, which requires linking additional libraries. I assume support for calling an arbitary function on return is therefore not available, atleast at the moment.

    -I don't really know how big the stack needs to be for every case of the code I'm calling. It will depend on whose actual driver is used (NV, ATI, MESA, etc). I'd rather have a naturally growing stack if possible.

    -I'm still investigating the GL rendering context. It seems when you tie a rendering context to something, it only works from that something (glXMakeCurrent). I was certainly noticing some unexpected strangness of setting up a context but it not being available to the application. Originally I tried just having a call in my code that started a thread for "Window Open" only and terminate on completion. However the context died with it. I therefore don't know implications of using the SIGSEGV context to create a Window, or rendering from SIGSEGV (more investigation required).

     
  • Stas Sergeev

    Stas Sergeev - 2009-06-01

    -There may have been easy support to do this and it might have been
    cleaner than passing between threads, which requires linking additional
    libraries.
    Yep, don't mess with threads, if possible.

    -I don't really know how big the stack needs to be for every case of the
    code I'm calling. It will depend on whose actual driver is used (NV, ATI,
    MESA, etc). I'd rather have a naturally growing stack if possible.
    You can still do that. Use mmap() MAP_ANONYMOUS to map the
    address space for the stack. It won't be committed to the physical
    memory right away, but only as soon as the app really writes to the pages.
    So you'll get your dynamically growing stack.
    I can't speak for the dosemu developers any more, but IMHO that
    would be the preferrable way to have the stack setup. The only reason
    why not yet, is for compatibility with the old glibc-2.2, which had bugs
    and needed that work-around - the sigaltstack had to be on an
    app's stack, or the bug would appear. But such a glibc are too old,
    the one can simply bump up the requirements.

    I therefore don't know implications of using the SIGSEGV context
    to create a Window, or rendering from SIGSEGV (more investigation
    required).
    If there are any caveats, they have to be explored on a case-by-case
    basis. Unless you find something really fundamental, the simplest
    route is just to do all your work in a SIGSEGV handler.

     
  • Stas Sergeev

    Stas Sergeev - 2009-06-01

    And please don't consider the SIGSEGV handler as something bad.
    dosemu does all the necessary checks, and does its work in a
    SIGSEGV handler only if the SIGSEGV comes from the DOS code.
    If the SIGSEGV will come from your code, the handler will re-enter,
    but your code won't be called again. dosemu will detect that it is not
    the fault in a DOS code, and will terminate.
    So everything was done to make sure you can do your work in a
    SIGSEGV handler safely. If not for the bugs in an ancient glibc, there
    would even be a growing stack, but you can now do that yourself

     
  • Stas Sergeev

    Stas Sergeev - 2009-06-01

    Btw, you have to be extremely carefull when spawning the thread.
    For example, if you "just" spawn the thread, it will share the
    sigaltstack with the main thread, and will crash sooner or later.
    I don't remember the "correct" way of spawning the dosemu
    threads, but there were some. Just dont do that, youve beed warned. :)

     
  • Stas Sergeev

    Stas Sergeev - 2013-02-01

    The growing stack is implemented in this commit:

    commit 10573f745082049afeb6c7302b20138aab10a2ea
    Author: Stas Sergeev stsp@users.sourceforge.net
    Date: Fri Feb 1 13:30:25 2013 +0400

    remove linuxthreads supporting hacks and implement a proper signal stack
    

    Now you can do all your work in a SIGSEGV handler.
    Or, if it can be batched, you can hook into a dosemu
    periodic handling, or use SIGNAL_save() to schedule
    a handler.

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks