Already updated the sources removing unused files, debug code and did a major clean-up and layout organizing.
Download it and see if it helps in any way... Paul, I disabled the vertex snapping on the current release but we must put it back in some way.

Damn Stiletto,
You are always asking for difficult things... Paul, do you think you can do a package release with the DLL compiled with the .ini file and everything?
We need to do that in some regular way, so others can test our releases...

GoldFinger wrote:Damn Stiletto,You are always asking for difficult things... Paul, do you think you can do a package release with the DLL compiled with the .ini file and everything?We need to do that in some regular way, so others can test our releases...

Yes, but probably not 'til tomorrow. I wondered about releasing all the versions I've tagged in the repository between your initial one and the latest, in case along the way I've fixed something and then broken it again. But I think probably just the latest is best.

If we do a release, I probably should tag the repository at its current state, and update the version string (not in that order ).
Any thoughts on what version we should call it? 007, maybe?
Actually that seems very appropriate for the return of "GoldFinger" to the project.

I have uploaded the OpenSource Glide I had at home to the following link:
http://ps2pe.ngemu.com/Glide_source.zipI am almost sure that it is the same of that SF link, but you may want to download it and take a look, there are good stuff there.

Paul, I was browsing SF yesterday and got the same problem, no problem... Well, I don't remember exactly why the window creation it was needed, but I can figure it out how to do it without a window ( I did not look at the code yet ), how is it being done?

GoldFinger wrote:Well, I don't remember exactly why the window creation it was needed, but I can figure it out how to do it without a window ( I did not look at the code yet ), how is it being done?

Well grSstWinOpen has either a window handle or NULL passed into it. If it is NULL you call GetActive Window, to pick up one of the window owned by the game. So you definitely have a window at that stage.

Then if the create-window options is enabled in the INI file, you create a new window as a child of the first, and you set up the WinProc to pass some messages from the child to its parent, with some strange conditions I don't understand.

My guess was that sometimes the window that is passed in isn't suitable for OpenGL, so you create a new one. The WinProc has to pass messages because otherwise the new window you open will block keyboard and mouse messages from getting to the game.

I've put some of this back in (although not commited it) so that I could experiment with Hind, but it doesn't seem to help. Hind causes lots of "invalid operation" errors from OpenGL calls. IHind seems to be assuming a video-feed-through type card, so it may be leaving what it thinks is the 2D-support card in a nasty full-screen DirectDraw mode, and that might be inhibiting OpenGL. I don't know; just guessing really. I do get a similar problems with full-screen DOS modes in Glidos, but I don't think the solution I use there will help us here.