OpenGL Blitter for OpenTTD

[jklamo]

This one is using 9800 PRO 128 MB

[Tiberius]

Uploaded a new binary version for ATI card users to test, please read the first post.

[Mchl]

A glitch when drawing graphs.
This was done using the binary from the first post (hf6bcefa7M), on Vista Business and nVidia GF 8400M GS.

[bokkie]

Apparently the bottleneck of OTTD is not at blitter, and FPS is greatly affected by 'visible sprite count'.
I think it's quite reasonable since OTTD Z-sorts sprites itself before sending them to blitter, and do many redraws assuming blitter don't have Z-testing functionality (yeah! after all they're 2D 'blitters')

I tested with #openttdcoop Public Server Game 96 extensively when implementing it, and the performance on my computer FYI:

C2D @ 2400MHz, NVIDIA 7600GT

(window size 1024x768)
zoomed in: ~230fps
zoomed out 1 level: ~180fps
zoomed out 2 levels:~120fps
zoomed out 3 levels: ~20fps (!)

(window size 1680x1050)
zoomed in: ~130fps
zoomed out 1 level: ~120fps
zoomed out 2 levels:~60fps
zoomed out 3 levels: ~15fps

The new build works on my ATI x1950pro. Now where did you zoom in? FPS in the city to the left is much lower than in the middle where there are not many buildings, and scrolling also affects FPS pretty much. What are your plans for the following future? Improving performance, adding features? Overall FPS seems to be good zoomed in and zoomed out level 1, but other levels aren't that playable yet (on my decent videocard, most OpenTTD players will have worse probably).

EDIT: newwater doesn't look good zoomed out, see attachment

[Tiberius]

Mchl:
Thanks. Will look into that issue ...

bokkie:
Thanks for your feedback. I won't add 'new features' just yet, the current priority is to stabilize performance. ATI X1950PRO seems way better than my NV 7600GT price-wise here, but as you see this blitter seems doesn't reflect the difference
Still need quite some work to know the 'taste' of ATI cards, perhaps some actions are showstoppers on ATI but not eating much performance on my GF .........

Oh, and be sure to DISABLE ANY antialiasing, texture interpolation, automatic mip-map generation things, since the scrolling is implemented as copy-to-texture -> draw a quad at new location ...

[Frostregen]

About the supplied patchfile:
(Toirtoise)Subversion 1.4.6 could not read it.
(Toirtoise)Subversion 1.5.0 could read it, but had some problems with "/dev/null" on windows
So i had to manually create the new files.

In case anyone else has trouble too, here is my resulting patchfile.
(GLee.h/c still need to be downloaded seperately)

[bokkie]

Mchl:
Thanks. Will look into that issue ...

bokkie:
Thanks for your feedback. I won't add 'new features' just yet, the current priority is to stabilize performance. ATI X1950PRO seems way better than my NV 7600GT price-wise here, but as you see this blitter seems doesn't reflect the difference
Still need quite some work to know the 'taste' of ATI cards, perhaps some actions are showstoppers on ATI but not eating much performance on my GF .........

Oh, and be sure to DISABLE ANY antialiasing, texture interpolation, automatic mip-map generation things, since the scrolling is implemented as copy-to-texture -> draw a quad at new location ...

Mmm after reading your reply I'd like to rephrase, I just didn't notice any stuttering in these two zoomlevels, as opposed to the other two zoomlevels.

Maybe it's worthwile to provide a benchmark: the said scenario, center on 'Roelofarendsveen' and then FPS on the four zoomlevels @ 1680x1050 (windowed, unpaused): ~250 / ~210 / ~90 / ~20 FPS (on the different 4 zoomlevels). While 90 is playable, scrolling makes the FPS drop a lot so this zoomlevel isn't 'stutter-free' while playing. I'm playing at a Core 2 Duo @ 2 GHz with an Ati Radeon x1950pro (Catalyst 8.3)

[Tiberius]

bokkie:
Thanks for your feedback! Please try the updated binary, I think I've nailed the scrolling problem
It should make zoomed out 4x very playable, but I dunno if 8x will. Perhaps you can provide some updated benchmarks?

And actually I fixed an transparent-buildings-get-smeared-when-scrolling bug too

The updated binary/patch is at the first post.

[CommanderZ]

It still drops to ~3 fps when max zoomed out and scrolling for me.

[Spaz O Mataz]

This is now working on my RADEON 9550.

[StopRightThere]

It's working great on Radeon 3870 here.

[ccfreak2k]

The story isn't over yet! An OpenGL SDL video driver is HERE for those who don't play on the Win32 platform!* Check the first post.

OpenTTD runs a LOT smoother using the sdlgl/opengl driver/blitter pair than with the standard sdl/32bpp-anim pair on my desktop Slackware box. Callgrind seems to concur. Your mileage may vary.

The only known issue remaining so far is switching to a "pre-baked" resolution causing the screen to not render correctly anymore. Restarting OpenTTD fixes it. This problem may be in the opengl blitter instead of sdlgl...




* You still need SDL and OpenGL for it to work...

[Tiberius]

Updated the patch to include SDL OpenGL video driver hacked by ccfreak2k, please check the first post

[bokkie]

the said scenario, center on 'Roelofarendsveen' and then FPS on the four zoomlevels @ 1680x1050 (windowed, unpaused): ~250 / ~210 / ~90 / ~20 FPS (on the different 4 zoomlevels).

Now it is: ~310 / ~280 / ~185 / ~20. Performance-while-scrolling is also a lot better but it still eats FPS, f.i. FPS drops from ~185 to ~90 when scrolling.

[Tiberius]

(The updated patch is at the first post of this thread, as usual.)

Updated the patch so that MinGW/Cygwin users can build it correctly. Also it won't compile OpenGL stuff anymore while OpenGL is not enabled. Bugfix in SDLGL driver too.

The OpenGL blitter itself isn't changed much however. I was trying MSAA but didn't get very pleasant results yet ...

[VoxDissident]

Haven't tested it yet, because honestly my video card is pretty terrible (it has a terrible time rendering transparencies and particle/smoke effects in 3D).

However, I was wondering what the plan is for openTTD graphics if there's OpenGL support now. Will the 32bpp graphics somehow benefit from this?? Or is someone working on a complete 3D overhaul?

[CommanderZ]

OGL works natively in 32 bpp and works faster (even with my old weak GeForce) than 8 bpp. I've tried 32 bpp once (I meant without OGL) and the game suffered massive slow-down - it was unplayable on my computer.

[Tiberius]

However, I was wondering what the plan is for openTTD graphics if there's OpenGL support now. Will the 32bpp graphics somehow benefit from this?? Or is someone working on a complete 3D overhaul?

Please refer to my earlier post about the topic

And for anyone who want to compare benchmark with 32bpp blitters -- remember to add this line into your openttd.cfg:

Code: Select all

sprite_cache_size = 64

Since a large zoomed-out screen with 32bpp sprites will hardly fit in the default 4MB sprite cache, thus wasting MASSIVE time reloading/re-encoding sprites (Those original 8bpp sprites will get converted to 32bpp during encode, too ...), and 64 (MB) is the maximum allowable size hardcoded in the source.

Under this settings 32bpp-anim would be well-playable on my computer, but the profiling result still shows OpenGL blitter have some performance improvement, which is probably a good news for 32bpp-sprites users having a capable graphics card (this one's done by ccfreak2k):

080629-ottdcallgrind.jpg (112.9 KiB) Viewed 973 times

A complete 3D overhaul is very unlikely, even if possible, since we have to support original blitters for those who don't have suitable hardware to use OpenGL blitter. But given this blitter, it's probably easier to do some hacks like ... the good-old doublesize filter (now with bilinear filtering) ?! But no, I don't even start coding this yet

I've also updated the Win32 binary pack in the first post. The graph-line problem should be fixed now.

==
And for the Fraps fps thing.

I believe it means 'how long did it take to render a frame', not 'how much frames did it actually rendered' in the past second ... so when it displays 500fps it doesn't mean OpenTTD actually displayed 500 frames in the past second, but means OpenTTD can display 500 frames if every frame only need so much time to render. In other words, under the 500fps situation we have much more CPU power left to handle other things like larger maps, more vehicles, etc. than a 30fps situation.

[Frostregen]

And for the Fraps fps thing.
I believe it means 'how long did it take to render a frame', not 'how much frames did it actually rendered' in the past second ... so when it displays 500fps it doesn't mean OpenTTD actually displayed 500 frames in the past second, but means OpenTTD can display 500 frames if every frame only need so much time to render. In other words, under the 500fps situation we have much more CPU power left to handle other things like larger maps, more vehicles, etc. than a 30fps situation.

My experiments showed fraps really shows the amount of rendered frames within the last second.
I limited the fps with some sleep() calls and measured the time like:
starttime = now;
render();
fps = 1 / (now - starttime);

fraps showed only the fps which were really rendered, instead of what could be (the fps i measured myself above)

[Tiberius]

An update regarding repeatedly encoding of PNG sprites. Please refer to the first post.