GlideGL64.1b

I ran across a bug that was slowing zelda64 down considerably. The grTexTextureMemRequired function was returning 4 times the value it should. Anyway GlideGL64.1b no longer will fill up the debuf file Ultrahle produces with unable to clear memory anymore. I also took a few minutes to make it so opengl doesn't have to change states so often. This change speed things up a small amount too. Well thats about all there is to this release. Enjoy!

---anonymous

GlideGL64.1

I konw I said I was done with this but it wasn't working on other machines quite right, so
I had to fix a few things and let other issues remain. This release should speed up some areas considerably for people with card that don't support certain opengl modes. I don't know what video card these might be except for riva128 i know. But anyway as long as this doesn't
crash like the last release I will be done with it (yeah right!). If anyone would like to
continue the project I have a couple of suggestions for you. First you should be able to
speed it up considerably by changed the structure just a little. Right now opengl changes
states for every single triangle drawn. This is aweful and was the very next thing i was
going to fix. States should only be changed when a glide combine function is called, and
probably when a triangle needs 2 passes. Doing this ought to speed this up significantly
with a small amount of effort. Basically after a glide combine function is called a master
comine function should be called evaluate all the glide combine variables much like i did
in the triangle function and set the opengl state. Then the triangle function would be just
a few lines of code to draw the triangle.

Since the changing of resolution is one of the problems that made it crash on other peoples
machines I just disabled it. It will play in the upper left corner with whatever resolution
ultrahle is told in the ini file. You can manually change the resolution of course, but thats a pain i know. This was the 2nd problem I was going to fix. I really hope someone does these 2 small things.


few hours later: I'm having second thoughts on my above argument. I'm not so sure changing states slows opengl down too much. There might be some other thing i'm not thinking of. maybe some of the good opengl programmers out ther know how to speed up this beast.

---anonymous

GlideGL64

I found the whole Glide emulator idea fascinating and thought I would jump on the bandwagon and give it a try. Shortly after I started my project the Ultrahle was released and like everyone else I turned my efforts to trying to get my wrapper to work with ultrahle. I'm busy as school right now and I knew i had to unload this project from my shoulders and so I am releasing this wrapper along with the source code. I will not continue the project. I hope the source code is helpful to other working on wrappers. If you like you may continue my project. However, with opengl I started to run into lots of areas of Glide that are simply impossible to emulate with opengl (as far as my limited knowledge is concerned).

A few notes to users... This wrapper was tested and developed on a Diamond Viper v330. In a few areas, most notably on Mario's face, the opengl driver switched to software mode because a texture mode (blend and decal) was not supported in hardware and basically came to a standstill. I hope the TNT and other popular cards do have hardware acceleration for these area's.

Toward the end of my development I started to hack things so they would look right on the Ultrahle. Hacks upon hacks, the whole project quickly became a mess and was a nightmare for me. I'm glad to rid this burden from my daily life.

---anonymous

P.S. Its called GlideGL64 :)