Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[BubbaBrown]

Just because its 2D doesn't mean it's not work!  It uses OpenGL and a strange and uncommonly used form of alpha-masking for rendering, which may or may not end up rendering in hardware depending on graphics hardware and drivers.  I've had horrible performance on a fast computer because of poor hardware acceleration on my video card.

I didn't say it wasn't work.  I did say it was very unlikely the cause for the issue.  From experiences with working in both DirectX and OpenGL, coding techniques can make or break a game quicker than hardware will.  There shouldn't be such a huge rendering overhead for this game.  For other games of the same graphical class (2D sprite and tile games) this game has a magnitude of order too much overhead.  I can think of a library of games with more complicated graphical components that worked with lesser, unaccelerated platforms and were less demanding.  SimCity 2000 which had FAR more complicated graphics and simulation code isn't remotely as needy as DF. 

I, honestly, think the presence of an OpenGL code base is addressing the symptoms rather than the cause.  Also the fact that the PARTIAL_PRINT option make such a difference is a good clue to the source of the problem.  There's some serious inefficiencies in the rendering system that need to be fixed.  Also, the CPU usage of DF when paused is extremely strange.  It uses close to a 1/3 of a core on my box when paused on an empty underground region.  At this point most functions of the game should be halted and in a wait state...  why is it using so much power of a modern CPU when paused?

Blaming the hardware isn't appropriate.  DF shouldn't remotely bother the fill rate of most graphics chipsets.  This doesn't include the possibilities of bad practices in graphical calls, as there's plenty of ways to do DirectX, Windows/Linux API, and OpenGL code where the simplest tasks can bring down a modern system.  There's serious issues in the rendering system that people keep on stepping over and ignoring that need to be addressed.  I'm getting a little tired of people blaming hardware that can run some of the more demanding games on the market, adequately enough, being blamed for being "too little" to run DF properly.  It's not a 3D game with a full fledged physics engine, advanced AI, environmental sound system, a network subsystem, and operating on fine granularity time scale....  It's a 2D Sprite/Tile game with simplified physics, rudimentary AI, simplistic sound, with no multiplayer component, and coarse (almost turn based) time scale.

Everything from training and experience points to something wrong in the code.  I don't have access to the code, but something just doesn't add up and people seem to give DF a free pass when it comes to these types of problems.  So, I'm not "surprised".  The hardware isn't such a limitation that poorly implemented feature is going to cause this much trouble that a few thousand textured polygons (80 x 50 x 10 overlapping items or so) is going to draw this badly on hardware capable of rendering a few million texture, bump, light, etc... mapped triangles a second.  I'm surprised that everyone keeps on trying to fix everything else but what needs to.

Pardon the soap box, tis' been bugging me for some time.

[Baughn]

Thank you for that analysis - it was correct in its entirety. 

There are severe inefficiencies in all the old DF code. The display code was particularly old, and particularly bad, but I believe I've got that sorted now. Wait a few more days.. or weeks, whichever... you'll see.

[LeegleechN]

I didn't mean the graphics chip was to blame. Of course DF is doing bad things with its openGL calls, and the problem is compounded on intel chipsets because the drivers aren't as sophisticated as nvidia/ati's. No one is seriously suggesting that you should need a beefy graphics card to play a 2D tileset based game...