1. Firaxis celebrates the "Asian American and Pacific Islander Heritage Month", and offers a give-away of a Civ6 anthology copy (5 in total)! For all the details, please check the thread here. .
    Dismiss Notice
  2. Old World has finally been released on GOG and Steam, besides also being available in the Epic store . Come to our Old World forum and discuss with us!
    Dismiss Notice

Shaders, Color Palettes, and Unit Animations

Discussion in 'Civ3 Future Development' started by Flintlock, Dec 1, 2021.

  1. Quintillus

    Quintillus Archiving Civ3 Content Supporter

    Joined:
    Mar 17, 2007
    Messages:
    7,166
    Location:
    Ohio
    What makes sense for multi-threading is another area that is interesting. Certainly, trade connections is a huge bottleneck in Civ3. But I am definitely interested in multithreading in general.

    Which probably sounds contradictory given my previous post. In my mind though, there's a distinction between JavaScript-style async/await (where at some unknown point in the future, a result will return), and parallelizing calculations (where you run a bunch of tasks in parallel). The latter is multithreaded, but can effectively be thought of synchronously. Run a bunch of threads on this task, wait for them to finish, go do the next thing.

    I don't know how well parallel calculations will work with mod/Lua interop. But as someone who plays Civ3 over Civ5/Civ6 in no small part for the larger maps (and lack of 1 UPT), being able to scale performance effectively is a significant appeal.

    Although I also wonder if the performance can be improved simply by using better algorithms. In my experience, there are often more significant speedups available via algorithms than via threading, and trade calculations in Civ3 are slow enough that I've long wondered if there is low-hanging fruit in terms of optimization.
     
  2. Puppeteer

    Puppeteer Emperor

    Joined:
    Oct 4, 2003
    Messages:
    1,687
    Location:
    Silverdale, WA, USA
    Way into speculation land here, but I've presumed trade calculation loops adjacent tile comparisons repeatedly. Thats basically a problem for a convolution matrix which should be reasonable to translate into a library of some sort that uses parallel computation. Not necessarily the GPU, but perhaps processor multiprocessing features.

    There should be a number of handy libraries as convolution matrices are used in image processing and convolutional neural networks which are all the rage in recent years.
     
  3. Puppeteer

    Puppeteer Emperor

    Joined:
    Oct 4, 2003
    Messages:
    1,687
    Location:
    Silverdale, WA, USA
    On a completely different project and completely different engine I just got another insight about this. I dug some more to make sure we're not missing a filter clearing (I still can't find one), but I think I have an idea of what the problem is:

    Our scrolling and scaling aligns pixels off of their int-based positions, and OpenGL is sampling the interval between the edge and the transparency.

    Other game engines have some sort of "nearest pixel" filtering for such occasions, but I haven't yet seen that Godot does.

    Huh, I just noticed that OpenGL has a GL_NEAREST filter in its shaders. This is just the beginning of an idea, but maybe we can use a shader to go over the base tiles and apply this filter? I have no idea if what I just said is even a possible thing.

    Alternately I guess our options are to draw an extra solid pixel in each direction or snap the drawn position to integer values. We should only need to do that for base terrain tiles, though, in any case. Well, maybe fog of war, too.

    May or may not be of use: https://learnopengl.com/Getting-started/Textures
     
    Last edited: Dec 29, 2021
  4. Flintlock

    Flintlock King

    Joined:
    Sep 25, 2004
    Messages:
    861
    Using nearest neighbor filtering might fix the seams but if we switch to that we lose bilinear filtering. That's not necessarily a bad thing, the choice between the two is a choice between pixelated/grainy sprites (nearest) and blurry sprites (bilinear). Personally I don't think either one looks good. In fact I think we should ditch the zoom slider and only support zoom levels of 1.0 and 0.5 like the original game. Making 50% zoom look good is a relatively simple matter of averaging four pixels into one, whereas we'll never be able to make sprites look good at f.e. 110% zoom without recreating them.
    My idea for a lazy fix is to scale up the sprites by something like 0.1% as they're drawn so that way, hopefully, the sample locations are nudged off the transparent pixels onto the opaque ones without otherwise changing the appearance noticeably. Drawing an extra opaque pixel around the opaque areas on each texture is another option. I tried quickly rounding off the draw position to integer coords but that didn't make any difference. I suspect that doesn't help since the sprites are still drawn at non-integer locations once the scaling factor is applied. Keep in mind the seams only appear at zoom levels other than 1.0.

    Another way we might be able to fix the seams is by changing the blend mode. It's somewhat strange that the seams are fully transparent instead of something like 1% transparent, which is what I would expect if the texture samples went slightly into the transparent region. It's possible that the blending mode is set to throw away pixels if their opacity is anything less than a full 1.0.
     
    Quintillus and Puppeteer like this.

Share This Page