Print

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

[pondicherry]

When I use TWBT print mode, things get really slow and then this:
"GPU unable to accommodate texture catalog. Retry without graphical tiles, update your drivers, or better yet update your GPU."

First time I see this and I'm used to TWBT...

[lethosor]

Are you using GemSet or another tileset?

(By the way, this is the issue Toady has mentioned regarding tileset expansion:)

Even a basic addition of another character page is not a rewrite I feel comfortable doing.  The DF part is fine -- it'd take a while, but I could do the DF side of it once I knew what data to push where.  However, I have no idea how to set up additional texture atlases while still keeping the speed up in OpenGL, assuming it wouldn't require a completely different approach, so I can't really start.  It's way on the back burner for this reason.  The game could probably use another thousand characters at this point to remove fundamental overlaps.  That's potentially independent of the item graphics problem, though they both run into the texture atlas issue (if you want more than a few item pictures).

[pondicherry]

Yes, this happens with Spacefox and GemSet the other's I haven't tried ...
Btw this issue stops with 2D print mode, but I miss TWBW

[LeoCean]

Yes, this happens with Spacefox and GemSet the other's I haven't tried ...
Btw this issue stops with 2D print mode, but I miss TWBW

Those are like the only ones that use overrides... Well more than one override tilesheet.

For some reason I'm getting the GL error, is the first time I see this. What can I do?

What error, specifically, are you seeing?

Also (unrelated): Is there a reason why this thread uses "40_24" instead of "0.40.24", or at least "40.24"? I'm not really sure where this came from, but it's not particularly consistent (a search for "40_24" on this forum returns 13 results, nearly all of which refer to this pack, while "0.40.24" returns 340).

Isn't that a good reason to use it then?

[fricy]

When I use TWBT print mode, things get really slow and then this:
"GPU unable to accommodate texture catalog. Retry without graphical tiles, update your drivers, or better yet update your GPU."

[pondicherry]

thanks for the big and bold letters, I've read them. The thing is: I always used spacefox + twbt and none of this happened. What changed from the previous r.?
Edit: Drivers are up to date=updated

[NW_Kohaku]

Are you using GemSet or another tileset?

(By the way, this is the issue Toady has mentioned regarding tileset expansion:)

Even a basic addition of another character page is not a rewrite I feel comfortable doing.  The DF part is fine -- it'd take a while, but I could do the DF side of it once I knew what data to push where.  However, I have no idea how to set up additional texture atlases while still keeping the speed up in OpenGL, assuming it wouldn't require a completely different approach, so I can't really start.  It's way on the back burner for this reason.  The game could probably use another thousand characters at this point to remove fundamental overlaps.  That's potentially independent of the item graphics problem, though they both run into the texture atlas issue (if you want more than a few item pictures).

... What?

With all the pathfinding and brute-force random motion of water, how on Earth is loading a second (or third or fourth) set of images to use as an icon atlas going to in any way noticeably affect the speed of the game?  (In fact, that's what graphics already does, and it's effects are totally negligible...)

[lethosor]

Speed of graphics is not an issue at this point (since the OpenGL/SDL/libgraphics changes between 40d and 0.31), but it used to be a significant bottleneck in earlier versions. DF uses a texture catalog for speed in OpenGL-enabled print modes (STANDARD, VBO, FRAME_BUFFER, etc.), which TwbT also requires - 2D print modes actually cache all combinations of tiles, foreground colors, and background colors as they are used, which can end up requiring more memory but isn't too much slower. When using OpenGL print modes, most GPUs can handle creating textures for 256 tiles, but cannot handle the hundreds (thousands?) of extra tiles that some TwbT-enabled graphics sets use.

[NW_Kohaku]

Speed of graphics is not an issue at this point (since the OpenGL/SDL/libgraphics changes between 40d and 0.31), but it used to be a significant bottleneck in earlier versions. DF uses a texture catalog for speed in OpenGL-enabled print modes (STANDARD, VBO, FRAME_BUFFER, etc.), which TwbT also requires - 2D print modes actually cache all combinations of tiles, foreground colors, and background colors as they are used, which can end up requiring more memory but isn't too much slower. When using OpenGL print modes, most GPUs can handle creating textures for 256 tiles, but cannot handle the hundreds (thousands?) of extra tiles that some TwbT-enabled graphics sets use.

Why not?

I'm not all that familiar with such things, but I have trouble believing a few thousand 16x16 (or even 24x24) images is in any way a burden on any remotely modern GPU, as I've seen graphics mods on games that take up several gigs of RAM.

[Putnam]

16x16x24x16x16x256 bits per 16x16 tileset, I think. 16x16 tiles, 24-bit color depth (unless DF actually loads transparency, in which case add another x1.333333333 to that or replace 24 with 32), 16 foreground colors, 16 background colors, 256 tiles per tileset.

That's 402653184 bits, or 48 megabytes, which isn't that bad at all. 64 MB if 32-bit.

[Pidgeot]

Speed of graphics is not an issue at this point (since the OpenGL/SDL/libgraphics changes between 40d and 0.31), but it used to be a significant bottleneck in earlier versions. DF uses a texture catalog for speed in OpenGL-enabled print modes (STANDARD, VBO, FRAME_BUFFER, etc.), which TwbT also requires - 2D print modes actually cache all combinations of tiles, foreground colors, and background colors as they are used, which can end up requiring more memory but isn't too much slower. When using OpenGL print modes, most GPUs can handle creating textures for 256 tiles, but cannot handle the hundreds (thousands?) of extra tiles that some TwbT-enabled graphics sets use.

Why not?

I'm not all that familiar with such things, but I have trouble believing a few thousand 16x16 (or even 24x24) images is in any way a burden on any remotely modern GPU, as I've seen graphics mods on games that take up several gigs of RAM.

The short, very simplified answer is that there is a lot of overhead involved in telling the GPU to draw something. It takes time to create the data needed and passing it through the driver to the GPU; if you give it too little data at a time, the CPU won't be fast enough to keep the GPU busy, and you end up wasting a lot of time. By combining all the data and sending everything in one go, everything will run much better. There are limits, though; for example, you can't change textures in the middle of a single set of drawing instructions. Hence, the "naive" approach of just uploading 4 separate textures and switching between them won't work; you'll need to switch between them constantly, and that will bring far too much overhead.

As I mentioned in the referenced thread, a 3D texture should actually be able to avoid that issue, since that essentially stacks multiple textures on top of each other in a way that allows you to use each one without texture changes, but it's not a free lunch, so there are some drawbacks as well (more memory usage, rewriting the code to use the proper texture "layer", etc.)

[mifki]

When using OpenGL print modes, most GPUs can handle creating textures for 256 tiles, but cannot handle the hundreds (thousands?) of extra tiles that some TwbT-enabled graphics sets use.

It shouldn't be a problem for modern GPUs. However I'd recommend DragonDePlatino and other tileset authors to optimise their use of additional tilesets, i.e. use all the tiles in a tileset, because the game will load all tiles even if they're empty and unused.

[NW_Kohaku]

The short, very simplified answer is that there is a lot of overhead involved in telling the GPU to draw something. It takes time to create the data needed and passing it through the driver to the GPU; if you give it too little data at a time, the CPU won't be fast enough to keep the GPU busy, and you end up wasting a lot of time. By combining all the data and sending everything in one go, everything will run much better. There are limits, though; for example, you can't change textures in the middle of a single set of drawing instructions. Hence, the "naive" approach of just uploading 4 separate textures and switching between them won't work; you'll need to switch between them constantly, and that will bring far too much overhead.

As I mentioned in the referenced thread, a 3D texture should actually be able to avoid that issue, since that essentially stacks multiple textures on top of each other in a way that allows you to use each one without texture changes, but it's not a free lunch, so there are some drawbacks as well (more memory usage, rewriting the code to use the proper texture "layer", etc.)

Well, even you said in your response on that page that graphics are basically running on the same sort of principle as the already-extant graphics pages.  Even those already have multiple color combinations, (for example, they are shaded blue when underwater,) so you're also already dealing with the same multiple-variations-on-a-single-image issue. 

Ultimately, the issue that seems to be raised here is that having these multiple color-coded tiles will somehow balloon required GPU usage, but since you could easily allow for no overlapping tiles (and have a few extra to spare) by having a relatively mere doubling or tripling in size of the tileset, you are talking about linear growth in an already fairly small data size.  (Only about a hundred MBs at most, well within the capacity of even 5-year-old GPUs.)

I just don't see how the relatively tiny amount of data we're talking about is going to add up to anything that would cause a problem.

[Pidgeot]

Even those already have multiple color combinations, (for example, they are shaded blue when underwater,) so you're also already dealing with the same multiple-variations-on-a-single-image issue. 

No, coloring is a simple mathematical operation that is handled by the GPU as part of that single drawing operation that is responsible for drawing the foreground tiles - it uses only the "regular" texture, switching isn't necessary.

Ultimately, the issue that seems to be raised here is that having these multiple color-coded tiles will somehow balloon required GPU usage, but since you could easily allow for no overlapping tiles (and have a few extra to spare) by having a relatively mere doubling or tripling in size of the tileset, you are talking about linear growth in an already fairly small data size.  (Only about a hundred MBs at most, well within the capacity of even 5-year-old GPUs.)

I just don't see how the relatively tiny amount of data we're talking about is going to add up to anything that would cause a problem.

It isn't a question of memory, but of time. The GPU isn't even the issue at all - it's the CPU, because that's where all the data is being prepared and sent to the GPU for rendering. The CPU can only send sets of drawing operations to the GPU a limited amount of times per frame, because there simply isn't time for more. If you need to switch between textures too much, then you will exceed the number of drawing operations you are allowed to use (because a texture switch requires a new set of operations), and you will end up taking too long to render the scene.

[NW_Kohaku]

It isn't a question of memory, but of time. The GPU isn't even the issue at all - it's the CPU, because that's where all the data is being prepared and sent to the GPU for rendering. The CPU can only send sets of drawing operations to the GPU a limited amount of times per frame, because there simply isn't time for more. If you need to switch between textures too much, then you will exceed the number of drawing operations you are allowed to use (because a texture switch requires a new set of operations), and you will end up taking too long to render the scene.

OK, we're talking about something different than I thought...

But honestly, isn't that more a matter of how many tiles are on the screen than how many different types of tiles there could possibly be?  (More a problem of TWBT's multi-level view than tilesets.) Again, if you allow for creature graphics, that's a totally arbitrary number of graphics tiles, and most graphics sets have more creatures than it would take tiles to prevent overlaps of things like cursor, bin, floodgate, up/down stair, and letter X.