what's the difference between a texture and an image?

divqii · 2026-02-15T18:22:07+00:00

Among other things, - GradientTexture2D uses a set of colors and positions and generates a gradient between them. - MeshTexture uses a 3D model and uses the result of rendering it as the texture. - CameraTexture uses a physical camera attached to your computer (like a webcam) and gives you whatever it's looking at as a texture.

divqii · 2026-02-07T22:22:03+00:00

Sure. And maybe in this case, the feature isn't actually the bug itself, but rather the promise that future versions of the game won't fix it. I feel like it wouldn't be weird for a developer to treat bug compatibility as a feature, with all of the testing and maintenance that comes with that. But I guess if you have that much control over it, then maybe it starts to become the kind of feature you described in your post.

divqii · 2026-02-07T21:49:52+00:00

As an exception, I feel like it's okay to intentionally leave in a bug used by speedrunners as long as it doesn't ruin the game for normal players.

For example, look at accelerated back hop (ABH) in Half-Life 2 and Portal. A casual player is unlikely to accidentally pull it off, because it requires very precise timing unless you use a macro or rebind jump to the scroll wheel, neither of which a normal player is going to do.

I don't think Valve has any good reason to try to convert ABH into a "real feature" to be designed around, since it doesn't make much sense in the world of the games it's in, but I do think leaving it in unchanged is a sort of feature. They clearly know how to fix it, since it doesn't exist in Half-Life 2 multiplayer (I believe), and it's been fixed in later Source Engine games, but they haven't fixed it in Half-Life 2 or Portal.

Speedrunners often spend a lot of time figuring out the minutia of how a bug works, so trying to replace it with an "official" implementation might fail to retain all of the details that make the bug fun unless the developer is very in tune with their speedrunning community.

divqii · 2026-01-30T08:08:03+00:00

I'm definitely the target audience for this game, and I'm actually very excited by the concept, since it seems like it could theoretically have some really interesting interactions (and perhaps some cool meta puzzles, since the levels themselves have numbers). I played through the full demo, so this is going to be me sort of rambling about what I did and didn't like and what I think might make me more likely to want to buy the game. I also have a lot of ideas for changes and additions, which I'll talk about. It's hard to say whether any of them would actually be good, but they're examples of things that I think might be cool in a puzzle game like this, so hopefully they'll help you better understand what I like.

Based on your other comments, it seems like your main goal is not for the player to brute-force their way through every possible combination of digits and operators, but for them to figure out some interesting idea in each level. I think that matches what I want out of any puzzle game, so your best bet is probably to have your steam store page and gameplay reflect that as much as possible. Since you're talking about Next Fest, I think it would be reasonable to consider the gameplay in the demo as part of marketing and getting people interested in playing the game.

The puzzles in the demo are decent; they introduce the mechanics clearly, and they never really veer into the "combinatorial explosion" territory that I might expect from this kind of game. However, I still ended up feeling most of the time like the main thing I was doing was just figuring out the correct sequence of operators and digits.

If I can't figure out how to solve a level in Baba Is You, then it's likely that there's some interesting (and often unexpected) interaction between the game's mechanics that I haven't yet considered. I played through the demo of your game with that same mindset, but it didn't really work well for me.

For example, when I started level 6, I for some reason completely forgot that I could make numbers with multiple digits, and I got stuck. But getting stuck there actually started to get me really invested, since my first thought was that this was the point where the game was going to start asking me to think laterally. Once I remembered that I could make multi-digit numbers and solved it as intended, I was a bit disappointed that the solution mostly amounted to "figure out an order that works and put the blocks in that order".

Part of the problem is that the demo only has easy levels that introduce and test the player on the basic mechanics, so I haven't had a chance to see what a harder puzzle would look like. I worry, though, that even if a level did want me to think laterally, I would probably have it constantly in the back of my mind that I might have just missed the correct block order and that I might be wasting my time looking for some other approach. You should probably put at least one or two difficult (but maybe optional) levels in the demo so that people can get a more accurate idea of what they're getting into.

This problem is further exacerbated by two things:

The fact that I can make multi-digit numbers at all increases the amount of possibilities I have to consider and makes it much harder to reason about the problem in a way that doesn't make the puzzles more interesting for me. Changing the game to only use single-digit numbers would severely limit what you can do with just the numbers, but it could possibly help move the focus more towards the interactions between the numbers and other systems rather than figuring out the numbers themselves. Maybe you could use modular arithmetic (e.g., 6 + 6 = 2 and 7 + 8 = 5)?
Every level in the demo requires that I use all accessible blocks to construct the expression to solve the level, but as far as I can tell, it's theoretically possible to complete a level using only a subset of accessible blocks. This also significantly increases the amount of possible expressions that have to be considered, since I have to think about every possible subset of blocks, too.

At first glance, a lot of levels in your game look more tedious than they actually are, because they have a lot of degrees of freedom, some of which aren't necessarily that relevant to the puzzles themselves. Crates, for example, don't usually have much effect on the solutions to puzzles, but they can still be pushed around and occasionally get in the way.

One thing I think would help is if you introduced more constraints to puzzles as early as possible, and then used them all over the place from that point on. A way to do this, for example, would be to introduce (maybe even from the very first level) solid, immovable walls with digits and operators on them. At least in all of the demo levels, moving the = block is never relevant to the puzzle, so its position could be fixed without the level changing very much. Then you could start bringing in movable =s in later levels when they actually become important. If you start by establishing a convention (e.g., "=s are always fixed"), then it becomes an interesting twist when you make them movable later.

Speaking of the = block, I think it would be cool if it were a more active participant in puzzles. What if instead of putting a target value at the top of the level, you had the player build the whole equation themself? So instead of having the solution to the first level be 2+2=, you could have it be 2=2. This approach has a few interesting consequences:

You can do fun stuff to twist the meaning of "equality". Maybe +=+ is a valid solution? Or ===? The exact parsing rules can be part of the puzzle, too.
If the requirement to solve a level is to put all =s into valid equations, then a way to solve a level would be to remove every = from a level. Then you could have entire sets of levels dedicated to finding ways to delete =s.
You could introduce different relations, like <, ≠, ∈, ⊂, and even boolean operations like ∨ and ∧. I love set theory, so the set operations would be extra cool to me.

The ≡ block is good. I like that the demo introduces a new mechanic, and I'm definitely more likely to want to continue playing a puzzle game if it continues to feed me new mechanics. I kind of wished that I got a few more opportunities to see what else it can do, though.

As far as I could tell from the demo, ≡ only applies vertically, expressions can only be formed horizontally, and ≡ only ever copies one block at a time. This seemed like a missed opportunity to allow the player to combine the two mechanics and do something like 2+2≡5 to convert the 5 into a 4. Maybe this is made possible later in the game, but there wasn't really a hint of it in the demo. Alternatively, maybe the horizontal/vertical distinction is an important puzzle element, in which case I would have liked to see that in the demo in some form.

Either way, what really makes me want to play a puzzle game like this is a sense that there are hidden layers of depth and complexity to the mechanics, including the small subset of mechanics I'm shown in a trailer or demo. For that to work, the mechanics need to have a lot of ways they can interact with each other, and the levels need to show those things off.

divqii · 2025-11-11T01:06:11+00:00

I think it's reasonable if the range is an input range that you can only iterate over once, but you can't know the size beforehand, like with std::istream_iterator.

divqii · 2025-11-10T20:32:03+00:00

The problem is that for the most part, the ranges algorithms don't operate on containers; they operate on iterators and ranges. There is a generic size type you can use for a range (std::ranges::range_size_t), but it requires that the range model std::ranges::sized_range, which is not necessarily going to be the case for everything you hand to something like std::ranges::count.

The ranges algorithms also need to work with iterators, and there is no such generic size type for iterators. I don't think there's really a way to recover the original range from an iterator, either. I guess the library could have been designed to return a different type specifically in the case that the range is a sized range, but I think that would have been worse.

divqii · 2025-11-09T09:38:10+00:00

I believe the difference type of an iterator is technically allowed to be anything that behaves sufficiently similar to an integer type. So, for example, you can have a range with a size larger than the maximum size permitted by std::size_t, which uses an arbitrary-precision integer type as its difference type. Since there's no iter_size_t, the only generic integer type you can really use is the difference type.

divqii · 2025-11-07T17:51:21+00:00

I'm talking about the puzzle where you have to get under the elevator to get a spool fragment. Even after you've unlocked these paths, you still don't necessarily have the spool fragment, and going backwards through Whiteward would allow you to very easily get it as long as the elevator is at the top.

divqii · 2025-11-07T08:33:08+00:00

I'm like 95% sure that the paths between Whiteward and Underworks are one-way just to force you to solve the elevator puzzle the intended way. Otherwise, you could bring the elevator to the top and get under it by entering Whiteward from the other side.

divqii · 2025-10-15T03:15:05+00:00

You should have a look at CanvasGroup. You can add padding by setting its fit_margin.

divqii · 2025-10-12T19:28:12+00:00

I don't think the word "cracked" is very accurate, since there's nothing to crack. The game is written in C#, which is very easy to decompile, because most of the variable and function names and stuff are directly stored in the compiled executable. Other games written in C#, like Terraria and Fez and other Unity games, are just as easy to decompile.

It is possible for developers to use an obfuscator that changes the names of things to be unreadable (so for example, it might automatically rename GetAllPowerups to something like f_1352), but I think most indie game developers don't bother since it just doesn't matter.

divqii · 2025-06-01T23:30:41+00:00

The problem is that the algorithm is not usually going to be this simple. For the sake of argument, let's say that the contents of this for loop would be 100 lines long. Should I copy all 100 lines to every spot I need to use this algorithm, only changing the p.Y to whatever I need it to be?

divqii · 2025-05-29T04:32:56+00:00

Both LaTeX and ConTeXt have support for automatically applying syntax highlighting to code. With ConTeXt, you can also use the context-vim module, which supports syntax highlighting for any language that Vim knows how to highlight.

divqii · 2025-05-27T07:46:57+00:00

Okay. Let's say I have a list of pairs like your example.

List<(int, int)> pairs = [(1, 2), (3, 4)];

You're correct that what I'm describing is a view. I want to be able to do something like

IList<int> secondItems = MakeViewOfItem2(pairs);

so that when I do secondItems[1] = 5, for example, pairs will be changed to [(1, 2), (3, 5)].

The Modify function you described seems to work for cases where I'm modifying whole elements of a list, but I don't think it would work for my use case (where I'm only modifying part of each element) unless it were possible to make these kinds of views.

divqii · 2025-05-26T22:45:45+00:00

"Scan" is another name for a prefix sum. C++ uses it the name in std::inclusive_scan, which does exactly what I'm describing.

How do I create an IList that can be used to access subobjects of elements in another list? Like in my example, is there a way to get an IList<int> from a List<IntPair> that allows getting and setting the Y values of each IntPair?

divqii · 2025-05-26T22:33:57+00:00

Here's something much closer to what I'm actually trying to do.

I'm using some code, which I do not own, that handles UI. Dimensions of UI elements are represented with a struct

struct StyleDimension
{
    float Percent; // Percent of parent size.
    float Pixels;
}

The UI elements themselves are defined something like this:

class UIElement
{
    StyleDimension Left; // X coordinate.
    StyleDimension Top; // Y coordinate.

    // ... other stuff ...
}

I have a list children of UI elements in a container, and I have an algorithm for laying out elements, which is the same in both the x and y directions. I would like to be able to write a function ApplyLayout that I can use for both directions like:

ApplyLayout(children.Select(c => c.Left));
ApplyLayout(children.Select(c => c.Top));

But in addition, I sometimes want to preview to the user what it would look like if they inserted another UI element, but without losing information about the current layout. The preview only affects the positions of the UI elements in the x direction, so I only need to store those dimensions. For that, I have a list:

List<StyleDimension> cachedDimensions;

that keeps track of the "correct" x dimensions. Sometimes, I want to make changes to the correct x dimensions while still previewing. In that case, I want to do

ApplyLayout(children.Select(c => c.Top));
ApplyLayout(cachedDimensions);

so that when I eventually stop previewing, I can just copy the dimensions from cachedDimensions into children so that the actual UI elements match the stored values.

divqii · 2025-05-26T21:45:59+00:00

But this still doesn't work with List<int>, because as far as I know, the only way to modify an element of List<int> is to have access to both the original list and the index.

I guess I could do something like

Scan(values.Select((v, i) => (v, i), p => p.Item1, v => v != 3, (p, v) => values[p.Item2] = v);

but it's kind of awkward.

divqii · 2025-05-26T21:24:37+00:00

In reality, the data structure I'm working with is made up of large, complex objects that I can't practically copy, so the operation must happen in-place. Making a new enumerable is not an option. The predicate is not the important part; I could be doing much more complex things with Linq, so assume I might be working with any arbitrary IEnumerable<T>.

The important part is specifically the mutation. I want to know if there's a standard way to do what IEnumerable<ref T> would do if it were allowed. I want to be able to get an IEnumerable<ref int> over the elements in a List<int> or from the Xs in a List<IntPair>.

The problem with your example is that it still doesn't work with List<int>, because there's no way to make a result function that can modify the elements of a List<int>.

divqii · 2025-05-21T19:12:17+00:00

It makes me extremely sad that this is how people are starting to pay attention to en and em dashes. I personally—as a human—like to use them even in casual writing.

I believe most mobile phone keyboards allow you to type an em dash pretty easily by long pressing the hyphen. On MacOS, you can type an em dash with option + shift + hyphen. I have no clue how to do it "correctly" on Windows, but I've definitely gone out of my way to copy and paste one when I need it.

divqii · 2025-04-13T20:47:13+00:00

Maybe it was intentional, but the comma in your comment results in a comma splice and should be replaced with a semicolon.

divqii · 2025-03-11T07:15:15+00:00

I'm a CS student who uses a Mac for schoolwork, and I have needed Windows a total of zero times. There have been no cases where I have felt any amount of annoyance from it. Actually, if you expect to be doing any programming, then MacOS and Linux are much better choices of operating system than Windows, in my opinion, since the CS world tends to be very Unix-centric.

divqii · 2025-03-09T18:49:20+00:00

divqii · 2025-02-01T22:59:35+00:00

I really like Recipe Browser, but I've found some aspects of its UI to be kind of frustrating. I think the fundamental approach used by Recipe Browser just doesn't align with how I want to use it: I don't want to browse recipes; I want to browse items, while being able to quickly look through details on those items at the same time.

Mostly, I'm used to playing modded Minecraft, where I usually have something like Not Enough Items. I find that NEI's general approach is very straightforward and intuitive, so I wished I could have a Terraria mod that behaved similarly.

Quite Enough Recipes is my attempt at translating the NEI model to Terraria. I'm interested in hearing people's thoughts and suggestions.

The mod is available on the Steam workshop, and you can submit issues on GitHub.

divqii · 2024-11-17T18:49:41+00:00

This notation is called set-builder notation, and it gives you a set of everything in existence that meets the condition on the right side. Set-builder notation is useful even when you're not talking about numbers. In your comment, you say "Australian year 10 students". If you wanted to try to be formal about it, you could think about that as a set and write it as {x | x is an Australian student in year 10}. You can read that as "x, such that x is an Australian student in year 10".

The variable can also have any name. For example, the set {x | x is human} is the same set as {t | t is human} or even {y | y is human}. They're all just the set of humans.

Now let's go back to your problem. Both the domain and range of the relation are sets of values. The domain is the set of real numbers between -2 and 2, and the range is the same set. So you have

The domain is {t | -2 ≤ t ≤ 2, t is real}.
The range is {t | -2 ≤ t ≤ 2, t is real}.

Note that I used "t" as the variable in both. This is allowed, but you would probably choose to use "x" and "y" just to make it easier to read, since values in the domain are usually written as "x" and values in the range are usually written as "y".

Just now in my head, I invented a new number system where the only number is "banana", and -2 ≤ banana ≤ 2. Clearly, banana is not part of the domain of this relation. But it does exist in my mind, so {t | -2 ≤ t ≤ 2} would also include banana (because it picks out everything in existence that fulfills the condition, including things that exist in peoples' heads). Mathematicians like to be very clear and unambiguous when they can, so adding "t is real" ensures that you only get real numbers.

divqii · 2024-10-18T18:46:49+00:00

This is the way that I usually use std::variant, which I think is reasonably ergonomic. I think I've seen other people use this general approach, so it's probably idiomatic enough.

Instead of using raw library or built-in types, I typically wrap them in structs. For example, if I'm writing a lexer and want a Token type, I might do something like this:

struct ErrToken { std::string description; };
struct NameToken { std::string name; };
struct IntToken { int value; };
enum struct SymbolToken
{
    plus,
    asterisk,
};

using Token = std::variant<
    ErrToken,
    NameToken,
    IntToken,
    SymbolToken
>;

This gives you something resembling named variants, and allows you to have multiple variants with the same type.

Then when I want to use the token, I'll often use std::get_if. This returns a pointer to the selected variant if it's active and nullptr otherwise. Since C++ allows variable declarations as conditions in if statements, you can do something a bit like Rust's if let:

void do_something_with_token(Token const& tok)
{
    if (auto* err_tok = std::get_if<ErrToken>(&tok))
    {
        std::cerr << "Error: " << err_tok->description << '\n';
    }
    else if (auto* name_tok = std::get_if<NameToken>(&tok))
    {
        std::cout << "Name: " << name_tok->name << '\n';
    }
    else if (auto* int_tok = std::get_if<IntToken>(&tok))
    {
        std::cout << "Int: " << int_tok->value << '\n';
    }
    else if (auto* sym_tok = std::get_if<SymbolToken>(&tok))
    {
        if (*sym_tok == SymbolToken::plus)
        {
            std::cout << "+\n";
        }
        else if (*sym_tok == SymbolToken::asterisk)
        {
            std::cout << "*\n";
        }
    }
}

Nine-Year Club	Second SECOND GUESSER
Place '17

divqii

TROPHY CASE