I resized my sprites again. To 16 px (from 24 px). This time, it took way less time, because I had it all parametrized. And my sprite resize tool helped a lot. My new sprites are this big:

This means I can scale it up a lot and preserve that pixelness (the screenshot is from the future, since I still needed to fix things before this):

On my monitor, this is at 1920×1200:

The game’s “native” resolution is 1280×720. The camera zoom makes sprites appear at about 3x the pixel size. So at x1200, this makes sprites some 4-5x larger, and each sprite pixel is thus 4-5 real pixels, which makes scaling, rotating and filtering much smoother and with less issues. I might even have made the sprites even smaller, if my walls had better logic.

Of course, now all my mobs and other items are sort of mis-sized:

I’ve also messed with the sprites, removing some details and making them generally smaller to see the sizing I need:

I also have to now adjust a bunch of numbers that concern all mobs, such as the collision size:

I am looking at this and I need to change this for every asset, because they all have these. This is unacceptably cumbersome. So I have to modularize this a bit. Firsly, I’ll make a parameter storage asset for these values:

Then link there as the value assets for the individual entities, like weapons:

Now I can change one value and have them all use it. This means all dozens of weapons can share the same:

In fact, this extend to all dropped items, of which there are half a hundred or such. I can do this for mobs too, although they need more granualarity:

Finally, I am keeping the original values, because I don’t always want extra assets for things that are one-off or unique. So I’m letting the parameters be manually filled when there’s no common asset:

I previously fixed my bullet spawn offset, but I have another problem due to the perspective camera. While the mouse position is technically almost exact as to which in-world position it points at, this doesn’t match up visually. The player’s level (orange line) is above the aim reticle cursor line (blue). But the position the cursor hits at an angle ends up above the player’s level (red). The actual firing should happen towards where the reticle is visually, regardless of “exactness” (blue):

I can solve this with a special offset when calculating where the mouse is clicking:

That is, the cursor is “hovering” above the current tile, rather than pointing at the tile hitscan-style.

I also need to fix my lights. First, I can reenable them as is. There are a bunch of issues with this. Firstly, I am not even lighting the new wall sprites, just the bottom one:

Secondly, when they are lit, the tops and void back of walls are being lit based on the tile’s light:

So, those can be fixed to make it look more proper:

I can also tweak my light level and tile visibility levels to look much more gradual/subtle:

There are some issues I can’t really fix, like the very abrupt wall edge:

If I have time, I can fix these with a custom wall shape that has a chamfered corner, so it faces the camera at a reasonable angle.

I also decided that UI will not scale with resolution (I say “decided”, but I need to do this if I am not keeping native resolution if I want to keep sprites crisp). I will keep the UI sprites pixel-perfect at their 2x “zoom”. Larger resolutions will just move and space things around.

I also need to fix UI navigation system. My options menu is broken and the tabbed interface makes it complex to design and implement. For one, I cannot reach the back/reset buttons, so I need a special navigation logic to jump to those:

At which point I ran out of layers, since I need those buttons to be on separate ones. So I added some:

And then things just kept breaking more and more. In short, my system isn’t capable of handling the stuff I need. In theory, it is. But I would need to spend way more time than I have available right now. I might consider it for later work, but not now. So the compromise is to just have a straight-forward button-only options menu:

Now to “just” adjust all the other UIs for it.

Anyway, that’s the big changes that accumulated into almost days of work. I also fixed a bunch of other bugs that I won’t go through individually. Let’s just say, they eat up valuable time and I hate it. I wish I made the project simpler and stopped adding features. My goal is now to “make everything fixed”. I think I am really bad at keeping the build working (although I recognize I probably put way more effort to do so and the project can last way longer). I think I need to simplify things more than I do and make more compromises.

MicroRogue DevDiary #93 – Various fixes
Tagged on:

Leave a Reply

Your email address will not be published. Required fields are marked *