Ati - Vista - OpenGL drivers out

Lockhart, I just installed that latest version of VistaSL - and I've been able to log in and walk around for the first time since I downgraded to Vista (lol)

(the official client would crash on startup)

I don't know what you're doing, but keep doing it please

(everything works fine for me with this, as good as the official version on XP, except it's... erm... choppier. Very technical term, I know lol. What I mean is when you turn around, for example, its not smooth, it jumps or clicks around... like if its doing in it in 10 frames instead off 100. Does that make sense?

Anyhow, fantastic work

Steve/Lockhart:

Have either of you debugged into that GL call to see if the ATI driver is crashing because of input it isn't handling properly...i.e. trying to write the partial texture beyond the width/height and offsets given to it, causing a seg fault? I haven't done so myself. Perhaps we can just pay the performance cost and write the full textures instead of the subtex calls. I haven't dug into the draw pools deep enough to see textures are being put into the pools as LLImageGL's with only partial texture data...the work I've been doing w/ the rendering pipeline hasn't extended past the renderGeom and renderAvatars methods.

EDIT: Question to Steve...is LL going to make a supported move to Visual Studio 2005 anytime in the near future? Some functionality is broken in the game w/ compiling with VS2005...i.e. when you open the Map, it'll crash the game. Compiling w/ VS2003 and it's fine. Now I'm guessing its either hte differences in the Win32 dependent libs, or the 8.0 C runtime as opposed to the 7.1 C runtime (unlikely). Any clue?

It's not going to move to a microsoft platform as it's not microsoft exclusive software. The current compile environment is fine.

Umm, they compile using VS2003 for their Windows build It's ok, you're probably not a developer and don't understand the differences between the include files and static/dynamic libs associated w/ each compiler, and what native (read platform-specific) functions the client is using for each different platform. The fact is, they're building for windows in VS2003 and their project files and dependent libraries are built against VC 7.1, and I'm just wondering if they'll ever upgrade to VS2005 and VC 8.0, as the two compilers are *quite* different compared to the difference between VC 6.0 and VC 7.1.

I actually am a developer, thanks.

I was under the impression they used a more cross-platform compiler, there are other compilers for windows besides VS. Regardless, my point still stands. There's no reason to change the build environment.

Don't patronize me.

Lockart,

I am able to run SL, after installing your SLVista.
Thanks and keep up the good work!

I think it is a shame that Linden, Microsoft and ATI are blaming each other!

I've installed the VistaSL program, everything is running the way it should (altho it's lacking the background for the log in screen.

I just hope it will update along with the other clients correctly...

Unfortunately, it's not going to.

The updates rely on the person maintaining this software to create his version, and he's not on the same schedule as LL. Also, I'm pretty sure he's not running his own update server.

Once there's a client update, we'll need to wait until a new version goes up in this thread.

Well Kalemika, I apologize. But good news, they actually did update the source tree for VS2005...it has a few minor issues with it (can't just open and compile it), but it works well enough. I can post my VistaSL version w/ the next viewer release. The only thing it lacks is the LLMozLib that's used to render the website you see when you're at the login screen, so instead all you see is black Everything else seems fine.

Most cross-platform projects use either a mix of VS and GCC or just use GCC and Cygwin's (MinGW) GCC, depending on the complexity. Either route ends up requiring many #define blocks. In this case it's a lot more, especially since the viewer requires a lot of Win32 calls that aren't translated through MinGW from the equivalent Unix calls...not to mention it's a GUI application and they are using native windows messaging and not a cross-plat library like GTK+.

Before you do that, try incorporating the changes that were done to the actual VistaSL viewer. Not an attack, but your build is beyond unreliable and suffers from frequent and unpredictable crashing (last I tried it.) It got to the point that I had to roll back to the older, non-fl build just to use the game. If you're going to do this, please make sure it's reliable.

Once again, I'd appreciate it if you didn't patronize me, it's rather aggravating. I'm well aware of how compilers work and such. Believe it or not, girls can use computers, too.

The major delay in release comes from the fact that it takes LL a couple of days after the new version to release the source code for that version. It would be nice if they could do it at the same time that they release the version.

Kalemika,

First of all, I'm not patronizing you, I'm simply stating a fact. If you already knew that fact, good for freakin' you. It sounds like you're a little insecure about yourself.

Second of all, I had no idea you were a girl, so why even bring that into the conversation. Why would I think that makes a difference?

Third, since the source tree has been officially moved to VS2005 by LL, the unstable parts of the last build I posted are no longer occurring in my current builds. The only thing left that's an issue is the one GL call into the ATI driver, which is easy to surpass without affecting the stableness of the viewer.

Hey dont wanna sound stupid, but i need to ask.

What and where is this VS2005?

VS2005 = Visual Studio 2005. It's Microsoft's development environment for building applications. There are free "Express" versions for hobbyists or those who are learning, and can be used to build the Second Life viewer for Windows.

Exactly - this week upgraded to what looked like a top of mid range dell. The aim to to run a bunch of SL projects from it. F**K! Why didn't I read about technical issues before hand. Works fine if a little small on the laptop now the upgraded machine...

Dimension E520 Pentium D 925 Processor Dual Core (3.00Ghz, 800Mhz FSB, 2x2MB cache) 1 502.12 502.12
Memory Dual Channel 2048MB (2x1024) 533MHz DDR2 1
Video card ATI Radeon X1300 Pro 256MB DVI/VGA output with 1xS-Video Output 1
Sound Blaster X-Fi Xtreme - VISTA ONLY

Spot the problem here. I AM GUTTED! How can Linden wash their hands of this. I think it is quite a big market for them? And if they don't address it they will get a number of power users lose faith in them.

Tried to install the Omega Drivers they conflicted with everything. So first day out of the box and I have a hunk of junk.

Is there a definative solution? Read all the posts here and see a mixed bag.

Don't be quick to judge. It is not their software that is buggy, it is more the problem of ATI. NVIDIA gfx cards work, so it is hard to blame only LL. Also, LL has been looking for a solution. Don't think they are just sleeping on the issue.


VistaSL works, but it will be missing a couple, non-essential things. There are also other builds on this thread that should work, but they have the same issues.

...of course it is silly of ATI as well to put something out that is missing something like GLwhatever it is.

Also those VistaSL links don't work. Anyone have a mirror
Thanks for the reply.

Well all i can say is that... vistaSL worked just fine for a few weeks, now....wow...it crashed without even saying "HEY I CRASHED, WANNA REPORT?! D: " just closed the window without logging me out correctly..hmmm


Any ideas as to why this is happening? Or is it just ati being stupid again?
not really complaining.. since i've gotten used to it now....

I'll post a build of the latest first look viewer as soon as the source is available for download. It will also have the crash reports turned on. The source tree turns it off by default because LL doesn't want to receive crash reports from people who are hacking around the code, and only from officially supported releases from them. Makes sense to me, but it's easy enough to turn back on for you

All I can say is-

This sucks... It really, really sucks.
I wish Vista was mandatory for all PC users, if it was, this would have been fixed long ago. Unfortunately, it's not that big of a problem for anyone except us Vista users.

The problem with ATI is that their openGL support is historically awful. Really, really bad. They took the "driver reset" (the new windows WDDM driver model) as a chance to re-write their openGL support from the ground up, but in an effort to beat nVidia to the punch, labeled drivers which are clearly beta as release drivers. Every release we've seen so far has increased speed and reliability exponentially. I think it's just something we have to wait out.

Sorry for the double post, but this is actually notsomuch the case. I'd imagine ATI users under vista are actually probably smaller in number than linux client users at the moment, as nobody's really been too compelled to upgrade for the most part.

New build based on new First Look viewer (1.13.3.59315). This build uses a new workaround that is very inefficient, but has greater functionality. You will notice the slow down mostly on the log-in screen, which makes use of the glTexSubImage function. In-game, the only major slowdown is while the mini-map is being drawn. If you don't move around a lot, you should only notice it temporarily. There might be other bugs involved, I have only done partial testing.

Here is the question. Which one is more important: speed or functionality? I personally think just taking out the calls to that function is best. All the things that it does are frivolous at the moment.

Link: http://www.noxforum.net/files/VistaSL Setup-Firstlook.exe

Current build is working well for me at the moment.

One strange thing is my fury base skin is the wrong tone when using this version, but the correct tone on the other builds and my XP computer. But it doesnt worry me that.

Thanks for all the hard work Lockhart Cordoso, Linden and the others that are making builds to get this working

Okay, I thought I noticed something like that, but I don't have an XP computer to see for sure. The older builds and this build use different methods to get around the gl call. This new build emulates the function better but has some side effects, like the one you mentioned.