ATI and the latest R4's (just a mention)

[rabidhamster]

does 'watery tunnel' not work for you? 'Water tunnel' has problems i know, but 'watery tunnel' is different

As for the net thing, you don't open the files directly from the hard disk with internet explorer - i imagine this is the mis-parsing you're reporting. You have to go into R4's settings menu, turn on network access and restart. You then access the webpages via http://localhost:8888

No-one else has reported any problems with this, so i'd be very surprised if you had issues. As for telnet, you need to turn on network access before that too.

Net access is off by default because some firewalls pick it up and say R4 has a backdoor

As for the tearing thing on tunnels, can you give me a screenshot? if its the case i could be pretty certain that ATI's drivers are screwed again since the tunnels don't use anything non-standard. Also, i imagine a lot of effects would look REALLY bad at 500fps - you seriously need to stick vsync on or i'll be forced to put a framerate limiter on the next version . 70fps is fine - and a lot of scenes will look very different to what they were intended to be at anything else. have ATI still not properly fixed vsync?

There are mini-screenshots of the scenes when you get net login working, and as for the sound input i'm very surprised. The only thing i can think is you either a) have noise coming down your CDROM audio cable, b) have a microphone or something plugged into line-in. Try going to the 'wavescope' scene with no sound playing - it should display a flat line.

[teleguise]

Maybe he just needs to reboot (Like my odd Net/Scene issues I had)

Damn 'talesin' that thing flies...My ti gets full to sync(100) and then varies uncapped but not quite the warp zone you blurrrrr in. I bet things dont look quite the same.

Actually couldnt you put a 'optimize to ... fps' option? Or do you figure that most sync is set at (75-120) and should be on so your fine.

And damn... you can still find 92's local after dropping in the 30s.
I figured I could send him my old ATi when I replaced it but come to think of it that might be pretty insulting to him

[Talesin]

[rabidhamster]

[Rovastar]

[Talesin]

Gah, was just going to report a crash-on-exit problem with .15... will lock the video card for one reason or another. Hasn't been a problem before.

Also, have tried turning the PBuffer dimensions down to 128x128... which seems to fix *most* of the transition-slowdown errors. Just looked and watched it churn through eight PBufs at once on a given transition, so at the higher res that I normally use, it may be dipping to system memory.
Which still doesn't explain why the slowdown only happens with vsync on... but feh. (Going to have to run a search for a way to force the texturespaces on this card to a lower level, as on the R9000... that it's apparently eating this much card RAM seems to be a major source of problems on the 9500+.)

Oh, and before I forget. A friend had a thought about the ATI multitexturing problem, and it sounded reasonable enough... apparently nVidia has a particular function listed as an ARB to load a 'pack' of textures at once, when it's not an actual part of the OpenGL spec. The spec (from what he'd said) requires that textures be loaded one by one into their array positions. Not sure how R4 handles texture loading, but might that be what's causing the multitexture to fail?


(edit) The exit bug seems to have remained. Only happens when R4 is fullscreened. Seems to lock the video card, or at least sufficiently confuse it to the point where it does not return the desktop, though the system responds to 'blind' commands to shut down and restart. Has happened twice in a row so far, though a good number of times before that without keeping specific track. (/edit)

[rabidhamster]

ATI removed the vsync option from their setting menu on some drivers so you can no longer vsync. Also, if you can change it, its broken

As for the texture problems/lockups, i don't use any extensions to 'GL for texture loading, and i think the problem is still pbuffers. However, i haven't changed any of that code since v11 i think, so any bugs will be due to either extra load put on by scenes or a new (improved???) ATI driver with more bugs.

As for the slowdowns, it could just be the card is being used to the max - scene fades often do go down to 35fps on mine - a good half what they were usually - thats normal - its drawing 2 scenes at once.

And the crash on exit? I think since the system works fine and its just the graphics that are messed we can probably quite safely day that its another ATI bug. I definitely haven't changed any of the code on exit since at least v11 (except 1 or 2 non-graphics-related things), so any developed bug will be ATI i guess.

This is really pissing me off I try and fix R4 for ATI's bugs, i even remove all the scenes i think will be troublesome, and then ATI introduce MORE bugs and instability. grr.

have you tried an earlier version of R4 to see if the problem is drivers or v15?

[Talesin]

Eh? Far as I know, VSync is in every version of the Catalysts... you just go to the '3D' tab, then select OpenGL or D3D, click 'use custom settings', then the 'customize' button. It's a slider near the bottom that goes from 'always off' to 'default off' to 'default on' to 'always on'. And it certainly seems to work for me...
And I've been using Cat3.10 since .13, with no crash problems up 'til .15.

Paticularly interesting.. how are you loading textures into memory then? Still trying to find a way to cut down the card's memory usage to an R9000 level. Setting the pbuffers to 128x128 results in no slowdown during transitions, 256x256 just a little, and 1024x1024 halving the framerate (when frame-limited or with vsync on only).

Just as a thought for a temporary kludge, is there a possibility that you'd be able to code an option into the fps limiter that would temporarily double its setting (or have a 'standard framerate' and a 'transition framerate' for fine-tuning), while doing a transition? That might be enough to keep the framerate stable on a card beefy enough to handle it, while still allowing medium-resolution (1024^2) pbuffers to be used.

[teleguise]

Have not seen a verison w/o Vsync either.. I guess if you only loaded the drivers w/o ATI's control panel there wouldn't be a vysnc option.

Using Cat 3.10 as well and 0v16 running Ati safe distro totally locks up in fullscreen after just a few minutes..Ill try to see if I can narrow down the scene/fade.

Since your were soooo busy crankin releases out I missed a few so I dont have 0v15 to try but I know 0v13 for sure and I believe 0v14 worked w/o a hitch.

[Talesin]

Might be at that point where it locks his up that it just won't exit on mine. Noticed one thing about it that I'm not sure if was intended or not... the little spinning R4 cube on the menu will 'flip' itself. Essentially, reverse its own normals so you're only seeing the inside. Might not be related at all, or even intentional, but it looks like it could be a symptom.

Also, switched from fullscreen to windowed and it still seemed to lock up... but with a snow crash, spewing the memory buffers onto the screen. Including stuff like the font template. Y'think of just trying to use the installed system TTFs?

And yeah... so long as you install the ATI control panel, you'll always have VSync. But then, if you don't install that, you'll lose a metric buttload of the card's functionality anyway, so there you go...

As well, a comment you'd made earlier just came to mind. If R4 is using OpenGL, it should perform identically regardless of if the card in question is a DX8 part or a DX9 part... because it's not making any DirectX calls. It'd seem that it should assign texture memory based on OpenGL standard. Which would leave me at a loss to explain exactly why the R9500 can't handle 2048x2048 pbuffers, and chugs on 1024x1024, but the R9000 can zing along with the maximum quite happily.

[Rovastar]

the r4 cube thing is I beleive intentional we at least it happens on my GFTi4200 and another GFTi4800. IT first appeared v0.10 I think??!

It only sometimes appears to it appears to be 50-50 a solid cube or seeing inside teh box thing cannot work it out *shrug*

I am getting more confused with the ATI cards/users.

THe pbuffer size of 2048x2048 is insane. I run at 512x512 pbuffer for my GFTi4200 and GFTi4800 (Maybe 1024x512 for the Ti4800).

Running at 2048x2048 I would expect and do get huge slowdowns and another trying to run on my GFTi4200 64MB at 1024x1024 pbuffer I will get an out of memory error.and sometimes at 1024x512 I get them too doing complex transtions between scenes where at lot is happening.
Of course the transtions will slow down your machine is doing twice as much work.

BUt why would you want to run at 2048x2048 what sort of res are you using? IT is a huge load on the machine to have all pbuffers at that size and not needed surely is your res is 1024x768 or so. ANy pbuffer a lot bigger than res size really isn't doing much is it? Maybe I am wrong *shrug*

BUt the R9000 can handle a 2048x2048 pbuffer I don't get it

[Talesin]

That wasn't the point, Rova... the point is, the R9000 can HANDLE 2048x2048 without problems, while the R9500 grinds to the point of crashing after the first scene. Previously, this was explained away as being a DX8/DX9 'thing'. But how does that relate, if it's using OpenGL? It'd be using the OpenGL texture sizes... not the DX standard ones.

I'd normally be running at 1024x768, but the only pbuffer size with acceptable performance is 128x128, or 256x256 with a noticeably greater amount of chug during transitions.

As well, I'd noticed that R4 tends to 'freeze' for a few seconds any time it creates a new PBuffer, and that in a number of instances, it'll make new ones without re-using old ones first... even buffers that had been sitting there for a half-hour. Perhaps allow the user to define how many 'default' PBuffers to open when the program first starts? I know I'd kick it to about 16 and forget about it from that point, though I've seen as many as 27 in use under v.16.

I'm still not fully sure Gordon isn't using nVidia extensions without realizing it... if he /is/ using pure OpenGL standard, there should be none of the problems we're seeing. ESPECIALLY with something so basic as multitexturing.

[rabidhamster]

I AM using fully opengl compliant extensions. Either way, it queries the ATI card first to check it will support them, and it says it will

As Rovastar points out, i think the framerate halving in R4 is simply the ATI card struggling. It happens on NV cards too - after all its doing twice as much work.

As for vsync - R4's vsync tries to keep to the given framerate. If rendering takes more time, it waits less, so the framerate halving isn't due to that, and increasing the limit won't help it. I think what you're finding is that the FPS meter 'smooths' out FPS values over time, so if you start with a large framerate it won't appear to go down as far in the first second as if you started off with a lower value. I was told by someone that vsync had gone. They must have got confused or something. grr.

Its possible ATI's OpenGL uses ATI's DirectX driver. I'm not sure about that though. It might be possible that the new ATI cards are incapable of rendering to the old format - it wouldn't really surprise me. Keep trying tho' - if you can lip them back it'd be way faster.

PBuffer reusing seems to work fine - there are a few reasons why it might appear wrong... Main one is that PBuffers can be different sizes - not just the 'default'. A few of scenes now use smaller pbuffers either for speed or other reasons (128x128 or 256x256 mostly) - these can't be reused as larger pbuffers for obvious reasons so on scenes that don't use them they're unused. Also, some pbuffers are used during rendering and then freed before the end of the frame - you don't see these.

The halt on pbuffer allocation is, again, not my fault. Nor is the random crap on the screen - it may be R4 that is causing it, but its def. and ATI bug since OpenGL should NEVER be able to do that.

as for fonts, i can't use the TTF ones (i use some standard ones for 3D text, but not bitmaps). The fonts have a tinted black edge on them so you can see them on white backgrounds, and you don't get that from TTF. It could be worked out on load, but it'd take ages and there is absolutely no point.

The cube is gay. I'm damned if i can figure out whats wrong, but its not major, and it wasn't on my list of vital things to do so it hasn't been looked at much

I load quite a few textures, but most of them are smallish. 256x256 or something. You can count the entries in the log file if you want to :p The major hit will be pbuffers, since they have to contain all the extra rendering info. I could modify R4 a load again and copy back to normal textures, but to be honest it'd be pretty slow too.

I probably missed out something there so let me know if i did...

[Talesin]

The interesting part is, it *shouldn't* be the ATI card struggling, as all framerates with vsync off are between triple and 10x the vsync-on rate (between 180 and 600fps) on this machine. So unless it's vsync that's somehow incurring a HUGE stress on the card by having it enabled, to the point of bringing it to its knees, then it's much more likely to be something in the code being handled in a 'clever' way that the nVidia cards can deal with, but others can't.
Has anyone tried R4 out on a Parhelia yet? Or one of those TwinX cards? Would be interesting to see if any other brand tosses errors as well.

It's just incredibly weird Has ATi gotten back to you about it? As I recall you'd mailed them about the glitch.

And really... is there that much slowdown in RTT versus PBuffering? R2E seems to run perfectly well on this card, and IIRC it just uses RTT. But I suppose there's forward-thinking to do.

[rabidhamster]

Probably the ATI card is very quick rendering, but very bad at pbuffers. On a scene transition the pbuffer usage is probably treble - maybe more. Also, it could be your processor - Having the configurability does put a huge strain on the processor, and thats just magnified when you have a scene change.

Believe me, the vsync code does absolutely nothing clever at all. Plus it seems strange even ATI's Vsync does the same thing.

Because i knew RTT was slow i didn't use too much of it in R2e - about the only time was on changes and in the custom scenes, and then only occasionally. R4 uses pbuffers way more.

Plus i have a bad feeling that new ATI cards will go hopelessly slowly on it, because they're probably going to be converting floating point down to 8 bit colour.

I don't hold out a lot of hope for Parhelia cards unless Matrox have sorted themselves out. Last time I looked their OpenGL was very poor indeed. It may well have got better though.