VOGONS


Various patches for OpenGlide

Topic actions

First post, by gulikoza

User metadata
Rank Oldbie
Rank
Oldbie

Hi,

I have developed several patches for OpenGlide, improving performance and platform independence. I have tried to keep MSVC compatibility and added support for MinGW and x86_64 linux targets. The patches are mostly separate, but will also apply without conflicts.

1. openglide-ac: general configure improvements (including proper SDL detection, SDL will be used if it's detected; --disable-sdl can be used to compile native version) and architecture independent data types.
This patch also makes openglide compile with MinGW, although the resulting DLL will not work (libtool bug?); def file has been added to support MSVC style name mangling on win32.

2. openglide-fscall: handle fastcall properly and some other minor issues fixed.

3. openglide-mmx: improve MMX Support. Fallback to C functions on platforms where MMX is not available, will now also compile on x86_64 hosts (thanks `Moe` 😉)

4. openglide-lfb: LFB rewrite. Use a textured quad instead of glRead/WritePixels to improve performance. LFB reads are also improved by reading textures in RGB32 and converting to 565 on the CPU (for some reason works much faster then reading 565 directly). There's still some room for improvement by adding a mmx version of Convert8888to565 😀

With the above patches, OpenGlide should (in theory 😜) compile on any target that is supported by SDL. There are still some endianess issues to be considered with some opengl functions, but that can be fixed with a simple #define...

Attachments

  • Filename
    openglide-lfb.diff
    File size
    12.26 KiB
    Downloads
    1497 downloads
    File license
    Fair use/fair dealing exception
  • Filename
    openglide-mmx.diff
    File size
    36.81 KiB
    Downloads
    1566 downloads
    File license
    Fair use/fair dealing exception
  • Filename
    openglide-fscall.diff
    File size
    8.95 KiB
    Downloads
    1460 downloads
    File license
    Fair use/fair dealing exception
  • Filename
    openglide-ac.diff
    File size
    24.83 KiB
    Downloads
    1827 downloads
    File license
    Fair use/fair dealing exception

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

Reply 4 of 73, by qsonic

User metadata
Rank Newbie
Rank
Newbie

Huh? I fear I do not understand what your question targets at.

As per definition (see Wikipedia): "In software engineering, a project fork happens when developers take a copy of source code from one software package and start independent development on it, creating a distinct piece of software."

As for why I came up with the suggestion: I was just throwing that in because OpenGlide seems to be pretty much dead by now, and Gulikoza has made some really nice changes to it. AFAIK, he is working with Moe on improving OpenGlide, and I suggested to channel their efforts in a new project, so that improvements could be made available in one specific place.

Reply 5 of 73, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

Why not just add to the OpenGlide project? Why is a fork necessary?

DOSBox Compilation Guides
DosBox Feature Request Thread
PC Game Compatibility List
How To Ask Questions The Smart Way
Running DRM games offline

Reply 7 of 73, by qsonic

User metadata
Rank Newbie
Rank
Newbie

DosFreak: nobody said a fork would be necessary, it was merely a suggestion.

Glidos: yeah, sure, that would be nice, but I am pretty sure those guys have more stuff in the pipeline, and it would ease and speed up development if they had commit access, I think. As I said, it was merely a suggestion to ease and speed the development. Obsolete of course, if you grant them commit access to your repository...

Reply 8 of 73, by wd

User metadata
Rank DOSBox Author
Rank
DOSBox Author

Forking doesn't make much sense here.

Anyways, Glidos, did you review the changes? Glide games seem to be
rather rare, so it might not be too easy to verify things.
Hope gulikoza posts/contacts you if he wants to be added to the SF project.

Reply 9 of 73, by gulikoza

User metadata
Rank Oldbie
Rank
Oldbie

I'm not a big fan of forks, but things have progressed a bit...I was checking out MACGlide a bit closer and noticed it's a lot more advanced then OpenGlide (but based on the same code). The author has certainly spent some time improving the code, it is unfortunate that he dropped most of platform independent code...I mentioned it to Moe and we quickly put together MACGlide and some of my OpenGlide SDL patches and made it compile under Linux and Windows again. We thought it would be best to switch to SDL completely and use cmake for Makefile/Project files generation. I am hosting the source on my cvs server at the moment and it looks less and less like either openglide or macglide 😀. I'm not sure what would be the best next step...

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

Reply 11 of 73, by wd

User metadata
Rank DOSBox Author
Rank
DOSBox Author

MACGlide seems to still be actively developed, gulikoza are you in contact
with the guy?
Maybe merging again macglide and openglide (which is basically what you
already did), as an OpenGlide_v2 project at the original place, something
like that. Suppose it'd be possible that the macglide guy joins you if SDL is
fine speed-wise on mac targets.

Reply 13 of 73, by `Moe`

User metadata
Rank Oldbie
Rank
Oldbie

wd, MacGlide must be considered a true fork because of binary compatibility: Glide on the mac ran on MacOS 9, which seems to have unique requirements. I doubt SDL is supported well enough on OS9 (including OpenGL) for any code sharing between gulikozas and mine code. Furthermore, MacGlide includes lots of Mac-Specific addons (GUI control panel, for example) which make sense, but are incompatible to our approach (which feels more like OpenGLide).

The reason why our code continues to diverge from both is maintainability: OpenGLide is not an example of uniform, maintainable code, mixing in MacGlide stuff doesn't improve things. Just by refactoring and unifying file after file, I already found several bugs. In some parts, it is simply a big mess. We have access to the three major platforms, both endiannesses and both 32 and 64 bit, so we can ensure portability.

Not all parts are well-integrated yet, especially the framebuffer is extremely slow. I guess gulikoza will post a DLL whenevert it is useful showing off 😉

Reply 14 of 73, by wd

User metadata
Rank DOSBox Author
Rank
DOSBox Author

Well even if it's a large rewrite, it should be possible to maintain different
trees on sourceforge, so sticking to the original name (OpenGlide) while
keeping the (out of development as it looks) old glide code as well as switching
to the new implementation.
But of course it wouldn't matter much to set up a completely new project,
to have stuff separated.

On zeckensack's homepage is a nice list of glide games including testings
with his wrapper. Anybody in contact with him?

Reply 15 of 73, by Glidos

User metadata
Rank l33t
Rank
l33t

Why do we want to maintain the old version if the new is altogether better?

And is there anything wrong with the way the current OpenGLide supports multiple platforms? I'd have thought the technique used could support MacOS too, and by that means unify with MacGlide, pushing all the MacGlide improvements through the platform dependent files.

Reply 16 of 73, by `Moe`

User metadata
Rank Oldbie
Rank
Oldbie

Well, when gulikoza and I started out with the plain situation of "hey, I've heard MacGlide is based on OpenGlide but more complete, but misses some other things", we didn't know what to expect.

Reality showed that both have sufficiently diverged to not allow drop-in integration. We decided to mainly use the MacGlide sources and port anything that OpenGlide does better, but that had it's own set of problems as well, as Mac-specific code has creeped into the "portable" base. Jens-Olaf Hemprich (the MacGlide author) already tried to improve portability again, but his approach simply doesn't mix with OpenGlide's approach. He created a library well-integrated with MacOS Classic (or so I assume), which is great for MacOS users, but bad for portability.

We decided to go SDL only, as it is already difficult enough to ensure portability across platforms with a single toolkit. We have the hard- and software to actually test the most important platforms (Linux 32/64bit, Windows mingw/msvc, MacOS X little- and big-endian), so instead of having several versions of differently performing platform-specific code maintained by different contributors, there is now one single SDL-based codebase that we can confirm to work everywhere. The current test suite (something entirely new 😉 ) confirms that this approach works.

So if less complex code can do more than the old code, is there any reason to support the old way?

MacOS Classic (the only Mac platform with commercial glide games, and the target of MacGlide's binary compatibility) is explicitly unsupported due to two reaons: Compilation and system integration is too different from all other platforms, and Intel Macs don't support it anymore, so it will become inaccessible anyways. I have access to a PowerPC OSX machine with Classic emulation, but if MacGlide does such a great job to support the small number of MacOS glide games, with game-specific enhancements and workarounds, why should we try to compete?

The name change is simply an indication that the new code, while based on two important ancestors, will have little in common with them. Some important parts (the GL rendering core) will probably stay close enough to allow easy re-merging of new development in MacGlide, but most of the auxillary parts are already or will be replaced with completely new code.

Finally, there are also license issues behind our move: OpenGlide contains code copied verbatim from the Glide SDK, and it's license is more or less like the LGPL, but contains a few obnoxious clauses that make it incompatible. Those parts need replacing. I already got rid of all SDK headers, now there are only some minor code fragments left. Furthermore, using the name "Glide" is explicitly not allowed by the SDK license, so a name change seems to be neccessary anyways.

Reply 17 of 73, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

How about Voodoo? Is that allowed?

Possible names:
Voodooemu
VoodooGL
GLVoodoo
VoodooOGL
OGLVoodoo
OpenVoodoo

DOSBox Compilation Guides
DosBox Feature Request Thread
PC Game Compatibility List
How To Ask Questions The Smart Way
Running DRM games offline

Reply 19 of 73, by MiniMax

User metadata
Rank Moderator
Rank
Moderator
collector wrote:

How could Voodoo not be allowed? It is a real word that existed before it was used as a name for hardware. So is glide, for that matter.

MEEEEK - DOES NOT COMPUTE!!
You are trying to use logic in connection with trademarks. Try calling your new OS Lindows and see what happens. Not even the same word.

DOSBox 0.73 ReadMe | DOSBox Wiki | 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 | Win 10 Pro