VOGONS


Various patches for OpenGlide

Topic actions

Reply 40 of 73, by pk

User metadata
Rank Newbie
Rank
Newbie

No luck with the const I'm afraid. That results in the following errors when processing the assembly:

FormatConversion.cpp:468: error: memory input 3 is not directly addressable
FormatConversion.cpp:468: error: memory input 4 is not directly addressable
FormatConversion.cpp:468: error: memory input 5 is not directly addressable
FormatConversion.cpp:468: error: memory input 6 is not directly addressable

Reply 41 of 73, by gulikoza

User metadata
Rank Oldbie
Rank
Oldbie

@MiniMax: Openglide mostly uses Fx* data types, but these need to be defined to real data types somewhere. And FxU32 is incorrectly defined as unsigned long in the headers 😀. *nix software usualy checks for the length of data types in configure step (like dosbox, when defining Bit* types).

How about using something like: http://www.azillionmonkeys.com/qed/pstdint.h ? This one seems to be quite portable...

@pk: Does moving the Mask variables inside the function fix the problem then? This should be then also fixed in the cvs...

Happy New Year everybody! 😀

http://www.si-gamer.net/gulikoza

Reply 42 of 73, by pk

User metadata
Rank Newbie
Rank
Newbie

@pk: Does moving the Mask variables inside the function fix the problem then? This should be then also fixed in the cvs...

Yup, moving these variables onto the stack frees up 4 general purpose registers, and solves the compilation issue on my 32bit system (I've attached the patch for you).

Reply 43 of 73, by gulikoza

User metadata
Rank Oldbie
Rank
Oldbie

Catalyst 7.12 no longer supports GL_EXT_abgr. This extension is marked as required but I don't see it being used. If it is not used, the check should be removed to get rid of the error message.

http://www.si-gamer.net/gulikoza

Reply 44 of 73, by glid_tester

User metadata
Rank Newbie
Rank
Newbie

Thank you for this great work! I have tested the cvs version on Debian Linux with the patches from this forum applied. First I had a problem with "invalid machine code" (translated from my German Box). The problem was the -msse flag which will be set by your Makefile but my CPU can not handle. I changed this in configure.ac and now openglide is working. I don't think that this flag is required here for performance reasons, so you should better delete it and let the user enable in with the CXXFLAGS environment variable if he wants. In addition I also deleted the -fomit-frame-pointer an -march flags since those are also included in my CXXFLAGS.

I have still the problem, that I don't know, where opengl is looking for the configuration file and which name it should have on Linux (on Windows it is "OpenGLid.ini")

Reply 45 of 73, by ForToday

User metadata
Rank Newbie
Rank
Newbie

Hi all,

I just recently found out about the possibility to play Voodoo-enabled games with Dosbox and OpenGlide!

I compiled OpenGlide from sourceforge CVS and Dosbox from the CVS sources of gulizoka (25.2.08). I had to use gcc 3.4 for Dosbox since 4.1.2 (the default in Fedora 8) gave errors. I also had to patch OpenGlide with pk's patch (openglide-mmx_32bit_reg_fix.diff) since I got the same errors reported in this thread about registers.

Anyway, the 3DFX Diagnostic Kit works fine, as does Tomb Raider, very fluid. Redguard, instead, which is the game I really want to play, has problems. Two different problems happen actually:

* When I run the game with dynamic core, the loading phase is quite fast, but when the scene loading appears, it gets stuck at 98%. Dosbox is obviously freezed, since top reports a >90% resource consumption, and the cycle value in the window title doesn't change as it instead does during all the loading process. Waiting doesn't solve anything, the window is unresponsive to attempts to close it, and the only solution is to brutally kill Dosbox.

* When running the game with normal core instead, the loading phase is way slower, but it doesn't get stuck at 98%. However, after the loading process the screen gets all pink, even if the game appears to be active, with sound in the background, and I can hear the menu coming when I press ESC. The exact pink value is RGB 200 100 100 (C86464), but I really don't know where this could come from. I tried playing with all the available settings in Openglide.ini with no results.

By looking in the old threads, I found out that the dynamic core issue should be a known problem. I also read the game should actually be started at a low cycles value, which should then be raised when the loading process appears, but I actually did not encounter this problem. Anyway, whichever core value I choose, Dosbox seems to ignore the exact cycles value I set, which keeps on changing during the whole execution as if the core were dynamic.

I also found out another guy mentioning the pink screen issue, but there seems to be no provided answer to that. Is it a known issue or is it a problem I only am encountering?

Are there any new experimental Openglide builds I may try? I'm just guessing the problem is in OpenGlide and not in the modified Dosbox, considering it's OpenGlide which actually wraps the system calls. Just let me know if there's anything I can do to try and understand where the problem actually resides.

Thanks!

Reply 46 of 73, by gulikoza

User metadata
Rank Oldbie
Rank
Oldbie

What memsize= do you have set in dosbox? Try raising it to 63, RedGuard is very memory hungry 😀

http://www.si-gamer.net/gulikoza

Reply 47 of 73, by ForToday

User metadata
Rank Newbie
Rank
Newbie

Hi gulikoza,

thank you for your answer.

Yes, I read this too in old posts on this forum and so I already had set memsize to a very high value (64). So I'm quite sure the memory is not the issue. I also raised the memory values in OpenGlide.ini when trying to play with its settings, but nothing changed unfortunately.

Reply 48 of 73, by MiniMax

User metadata
Rank Moderator
Rank
Moderator

I don't know what DOSBox does with memsize=64. I guess there is an upper limit. Perhaps 64 is above that limit and DOSBox wraps around and gives you only 16? So why not do as gulikoza says?

DOSBox 60 seconds guide | How to ask questions
_________________
Lenovo M58p | Core 2 Quad Q8400 @ 2.66 GHz | Radeon R7 240 | LG HL-DT-ST DVDRAM GH40N | Fedora 32

Reply 49 of 73, by ForToday

User metadata
Rank Newbie
Rank
Newbie

Hi MiniMax,

sorry, I didn't know there was such a distinction, I actually thought 64 was the value to use. I set it to 63 but nothing changed anyway.
I attach a screenshot of what appears after the loading process. If I switch window and go back to DosBox, the screen is redrawn (so the all-pink-screen is not the result of a first, and then forgotten, blit), so I guess the window is refreshed as it should, just not *how* it should 😉

Thanks!

PS: the cycles value you see there is not constant, and changes all the time, whether or not I statically set it in dosbox.conf. Is this an expected behaviour?

Reply 50 of 73, by gulikoza

User metadata
Rank Oldbie
Rank
Oldbie

You need to set 'cycles=fixed [number]', it's all explained on my page.

Did you select the 3dfx option when installing Regduard? Redguard installs different files when selecting 3dfx or software renderer, just copying the executable is not enough.

http://www.si-gamer.net/gulikoza

Reply 51 of 73, by ForToday

User metadata
Rank Newbie
Rank
Newbie

Hi gulikoza,

you're right, the 'fixed' attribute does the thing. I frankly didn't know of such a feature, and looking at your CVS page I still can't find where it's mentioned. Or are you talking about a different page?
About the GL issue, yes,I installed the 3dfx version. I'll try with another PC as soon as I can to see if it just depends on me.

Reply 52 of 73, by ForToday

User metadata
Rank Newbie
Rank
Newbie

I tried with a different PC and the results were only slightly different. A screenshot is attached. I could see glimpses of textures every now and then, with characters appearing and disappearing (one of the enemies for instance, in the screenshot you can see hist floating sword). A couple of times I could even get a view of the deck, but just to see it disappear in the pink again.

I guess it's not a matter of graphics card, since on my PC I have an nvidia while the other one I tried has an ATI. Do you have any ideas about what it could be? Can I be of help in any way?

Thanks.

Reply 53 of 73, by gulikoza

User metadata
Rank Oldbie
Rank
Oldbie

I only tested on ATi and I never managed to reproduce this bug, linux or windows...I'll try a few things and send you an updated patch via PM.

http://www.si-gamer.net/gulikoza

Reply 54 of 73, by glid_tester

User metadata
Rank Newbie
Rank
Newbie

@gulikoza

I'm trying to use your patches under linux with dosbox and the game Redguard. It is working in principle, but all the textures get somehow distorted and show wrong colors. I guess that it has something to do with the endianess (you wrote about in your post), but I have no idea how to fix it. I'm not really a programming guy, but I'd try to fix it, if you could point me to the direction how to find out what to fix and what the #define statement should look like. The game tombraider is working without these problems.

Reply 55 of 73, by gulikoza

User metadata
Rank Oldbie
Rank
Oldbie

More patches. Glidos, I tried contacting s_a_white on sourceforge, but apparently the mail did not get through.
He broke the x86_64 target, attached patch will fix it.
Also, the SDL depth buffer precision is broken that's probably the reason for the troubles above. The second patch fixes that.

http://www.si-gamer.net/gulikoza

Reply 56 of 73, by Glidos

User metadata
Rank l33t
Rank
l33t

Ok thanks. Will commit these soon. Remind me if I seem to forget.

Reply 57 of 73, by gulikoza

User metadata
Rank Oldbie
Rank
Oldbie

Thanks for applying these so fast. I have more 😁:

The following patch fixes:

  • signed/unsigned & similar warnings on MSVC
  • SDL compilation on windows (setenv() is not available)
  • a few more asm errors (put more Masks* on the stack so more general regs are available, GCC RDTSC() should be defined w/o clobber args since =A assumes eax&edx will be clobbered)
  • follow glid_tester's advice and do not set -msse and CXXFLAGS in configure
  • do not limit LFB texture to 1024, use dosbox code (😉) to calculate optimal texture size
  • add support for MinGW (finally! 😀)

Notes on MinGW: I have finally managed to produce a working output with mingw. I have used entire automake/autoconf chain from Mingw so I don't know if it works with others. MinGW has specially modified versions of these tools (including libtool). There are a few issues remaining however:

  1. The output file will be named libglide2x.dll. It has to be manually renamed to Glide2x.dll; libtool issue
  2. SDL contains dxguid dependency_lib that is automatically linked with glide2x by libtool, but then libtool refuses to create the dll; I have manually edited libSDL.la and removed dxguid from dependency_libs (affects SDL version only).
  3. there's something broken in gcc 4.4.0, libtool wants to link with libstdc++.dll.a which doesn't exist (more info here); the solution is to change "library_names=" to empty string in C:\MinGW\lib\gcc\mingw32\4.4.0\libstdc++.la

These issues all seem to be libtool limitations. Seems like some projects (like SDL) already include a modified libtool in their cvs to overcome these problems. Either that or some Makefile hacking of the generated libtool script seems to be necessary 🙁 If somebody knows something more...

Compilation tested on the following platforms:
* MSVC6 (native and SDL)
* Mingw (gcc 4.4.0, native and SDL)
* Linux x86 (Centos5, native and SDL)
* Linux x86_64 (Centos5, native and SDL)

No errors! 😀

http://www.si-gamer.net/gulikoza

Reply 58 of 73, by gulikoza

User metadata
Rank Oldbie
Rank
Oldbie

A few changes:

- fix a bug where lfb texture size is still assumed to be 1024 pixels (texture coordinates)
- use smallest possible lfb texture size *
- preserve window/fullscreen mode for SDL aplications (override config setting)

* hey wd, int_log2() incorrectly calculates size when the size is exactly pow 2. It will return 1024 when size is 512 for example 😉

http://www.si-gamer.net/gulikoza

Reply 59 of 73, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

I'm not able to compile openglide cvs on OS X 10.6.1
First problem I ran into was that I have glibtool and not libtool (for whatever reason that happens when I install/build libtool 2.2.6a with MacPorts). I symlinked glibtool/glibtoolize to libtool/libtoolize - don't know if that will make me run into trouble.
The next problem I ran into was that bootstrap complained about missing /platform/windows/makefile.in.
I followed the guide at Tutorial: dosbox with Glide under Linux

./bootstraplibtoolize: putting auxiliary files in `.'.libtoolize: copying file `./ltmain.sh'libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac andlibtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree.libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
configure.ac:16: installing `./config.guess'
configure.ac:16: installing `./config.sub'
configure.ac:18: installing `./install-sh'
configure.ac:18: installing `./missing'
platform/linux/Makefile.am: installing `./depcomp'
configure.ac:120: required file `platform/windows/Makefile.in' not found

any ideas on how to proceed?

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper