FOSS gamedev and creative worlds

The recent uptick in RAM and CPU requirements by Minetest seems to be related to graphics. When I look down at the ground or up into the sky, my computer gets quieter. However, when I look at a bunch of buildings, my computer gets louder. There must be a way to alleviate stress on the CPU and RAM (I am currently running Minetest at low graphics settings due to the increased RAM and CPU usage, but even then my computer is worked much harder than it used to be.)

Below is the Wikipedia article on graphics cards.
http://us.yhs4.search.yahoo.com/r/_ylt=A0oG7qPZElJR0k4AbTVjmolQ;_ylu=X3oDMTByMDhrMzdqBHNlYwNzcgRwb3MDNQRjb2xvA2FjMgR2dGlkAw--/SIG=11rqjv47v/EXP=1364362073/**http%3a//en.wikipedia.org/wiki/Video_card

Does anybody have any helpful information to share here? If you do, please post the information in this topic.

Minetest is a game where all cubes are rendered individually (eg. a large flat surface of grass won't just be made of two triangles) and where your computer generates the world. On top of that, it saves the world often; so it is quite resource-demanding.

jordan4ibanez said reducing save frequency increased performance, try setting "server_map_save_interval" to a value like 300).

Minetest should save the game every minute but also save when you press the X button or press the menu button.

The save interval may not be the primary problem. I have experienced the CPU and RAM issues on servers as well. What is odd is that I am experiencing these problems with a Direct X build of Minetest (and a 64-bit build at that.) Until a couple of builds before 0.4.5 (though things didn't really get too bad until after 0.4.5,) Direct X always made Minetest much easier on my computer.

I even asked Sokomine about this once. Even Sokomine has noticed a significant increase in CPU and RAM usage.

Calinou wrote:Minetest is a game where all cubes are rendered individually (eg. a large flat surface of grass won't just be made of two triangles) and where your computer generates the world. On top of that, it saves the world often; so it is quite resource-demanding.

jordan4ibanez said reducing save frequency increased performance, try setting "server_map_save_interval" to a value like 300).

No, cubes are combined into meshes.

Whether cube nodes (depending on what they are of course) are combined into meshes or rendered individually, there must be a way for graphics cards to take a greater load off of the CPU and RAM. Even VanessaE sometimes experiences drops in her frame rate, and her graphics card is very powerful.

Inocudom wrote:Even VanessaE sometimes experiences drops in her frame rate, and her graphics card is very powerful.

Doesn't VenessaE's server have the moretrees mod installed? That mod gives me a severe drop in performance, enough that I chose not to use it simply because of that (specifically, it causes map generation to take a lot longer).

onpon4 wrote:Doesn't VenessaE's server have the moretrees mod installed? That mod gives me a severe drop in performance, enough that I chose not to use it simply because of that (specifically, it causes map generation to take a lot longer).

It does, I hardly get more than 30 FPS on VanessaE's server when I'm not in a cave.

I don't really know why VanessaE's moretrees mod causes such a slow-down. Maybe it is for the same reason that the water pyramid in Redcrab's main server does? I do notice frame reduction from structures that have a lot of windows too. Surely, there must be a way to remedy this.

Manic Digger uses blocks just like Minetest does, so Manic Digger has just about the same amount of polygons to render. However, the rendering of blocks in Manic Digger isn't as hard on CPU and RAM as Minetest is. Considering this, there must be a way to enhance the efficiency of block rendering in Minetest.

I think a lot of it has to do with texture size.

I found a good trick is to reduce the size of the less detailed textures - stone, grass...

Here's the textures I've been using - http://wikisend.com/download/136936/hybrid.zip

It's mostly VanessaE's HDX 32px with many of the less detailed textured batch-resized down to 16x16 or even 8x8.

I tried even smaller 6x6, but while digging, I noticed the ores / minerals didn't line up right on stone.
So 8x8 is the smallest that seemed to fit consistently.

Perhaps some can be shrunk down more. I've seen some 1x1 texture packs, so maybe some are possible that way.
This seemed to do OK on my PC tho. Hope it helps.

doyousketch2 wrote:I think a lot of it has to do with texture size.

I found a good trick is to reduce the size of the less detailed textures - stone, grass...

Here's the textures I've been using - http://wikisend.com/download/136936/hybrid.zip

It's mostly VanessaE's HDX 32px with many of the less detailed textured batch-resized down to 16x16 or even 8x8.

I tried even smaller 6x6, but while digging, I noticed the ores / minerals didn't line up right on stone.
So 8x8 is the smallest that seemed to fit consistently.

Perhaps some can be shrunk down more. I've seen some 1x1 texture packs, so maybe some are possible that way.
This seemed to do OK on my PC tho. Hope it helps.

I stick to using 16 x 16 textures when I can. Even then, I think it would help if somebody gave Minetest and its engine better compatibility with Direct X. This feat would have to be done by a member of the community that uses Windows and Direct X.

OpenGL can often be optimized to be faster than DirectX. During the Linux port of Steam, they published an article stating that their OpenGL-optimized code ran faster than the DirectX-optimized code, even in Windows. So enhancing performance for DirectX is probably a waste of time.

I think one of the reasons OpenGL demands more than Direct X does when it is used in Minetest is because Windows is probably still using Direct X while Minetest is using OpenGL (even when Minetest is in the full-screen mode.) This means that two video modes are running at once.

Inocudom wrote:I think one of the reasons OpenGL demands more than Direct X does when it is used in Minetest is because Windows is probably still using Direct X while Minetest is using OpenGL (even when Minetest is in the full-screen mode.) This means that two video modes are running at once.

... it could also be that OpenGL commands are getting routed _through_ DirectX in Windows. I did do a direct comparison, though, and on the same hardware, DirectX outscored OpenGL for framerate- even when I tried OpenGL in Linux. The issue could also be that drivers for Linux aren't given the same level of optimization, though.

tinoesroho wrote:

Inocudom wrote:I think one of the reasons OpenGL demands more than Direct X does when it is used in Minetest is because Windows is probably still using Direct X while Minetest is using OpenGL (even when Minetest is in the full-screen mode.) This means that two video modes are running at once.

... it could also be that OpenGL commands are getting routed _through_ DirectX in Windows. I did do a direct comparison, though, and on the same hardware, DirectX outscored OpenGL for framerate- even when I tried OpenGL in Linux. The issue could also be that drivers for Linux aren't given the same level of optimization, though.

I didn't know that OpenGL could be routed through Direct X like that. I guess that explains why OpenGL can use more RAM and CPU than Direct X does.

It seems like the difference in speed between the two video modes depends on what computer they are on. If that is the case, then Direct X isn't as useless as some people might think it to be.

Inocudom wrote:

tinoesroho wrote:

Inocudom wrote:I think one of the reasons OpenGL demands more than Direct X does when it is used in Minetest is because Windows is probably still using Direct X while Minetest is using OpenGL (even when Minetest is in the full-screen mode.) This means that two video modes are running at once.

... it could also be that OpenGL commands are getting routed _through_ DirectX in Windows. I did do a direct comparison, though, and on the same hardware, DirectX outscored OpenGL for framerate- even when I tried OpenGL in Linux. The issue could also be that drivers for Linux aren't given the same level of optimization, though.

I didn't know that OpenGL could be routed through Direct X like that. I guess that explains why OpenGL can use more RAM and CPU than Direct X does.

It seems like the difference in speed between the two video modes depends on what computer they are on. If that is the case, then Direct X isn't as useless as some people might think it to be.

Nor did I. I assume routing through is what happens, though.