Yet another OHRRPGCE dev blog

[TMC]

Actually, I think my last post demonstrated how jumping between a dozen different things resulted in little more than two bugfixes.

I've finished implementing 24-bit colour mode. You can find the Color Depth option in the General Game Settings menu in nightlies. Right now, the only advantage to turning it on is smooooth transparency effects.

It took a lot of work to make screen fades work in 24-bit mode, which is why we didn't add it at the same time as sprite transparency. Really, it's a miraculous how compatible 24-bit mode is with 8-bit mode; I had thought it would be impossible to achieve, and it took some [s]trickery[/s] software engineering. However, it's not 100% compatible. For technical reasons, switching a game to 24-bit mode causes the "fade screen in" command to behave slightly differently when used after modifying the master palette ("tweak palette", "load palette", etc): it will do an implicit wait(1).

I also spent a lot of time looking into how to do better lossless compression than embedding .pngs in .rpgs. That can be done, but it's kind of pointless since high quality jpgs blow png out of the water for compression. I give up, I'm just using png for now.

Fine, fine, but what about 24-bit sprites?!

Oh you want crisp?

Before:


After:


Can even use the smoothing filter if you want:


Why no, that's not a 960x600 backdrop. Actually it's originally 640x400 scaled up to 960x600 and sharpened.

Do you want to break all limits?
That really starting to use a lot of CPU, though.

Amazing what you can do in a day after spending years laying groundwork.

Not in SVN, not in today's or tomorrow's nightlies. (No, you can not import 24-bit images yet). In fact I have to take a break for a couple days. Enjoy!

[TMC]

(A couple days later? Been putting this off for years)

Time I kept a dev blog again... umm... just ignore all the stuff up the thread that still isn't available in nightlies (which is most of it ), because I don't finish things!

If we write nothing and delay releases by years (it's been over 19 months since hróðvitnir was released), people get the wrong impression that engine development has stalled. Admittedly I didn't do much for the last half year, but I've been busy for a few weeks, and there have been 832 commits (source code changesets) since hróðvitnir. I'm not going to overview what's new (we'll do that when ichorescent releases soon), only what I'm currently doing.

Bena's complaining prodded me to add better mouse support in the slice editor. You can now move and resize slices with the mouse (and also keyboard), and also pan the slice collection, though I still have more big improvements for mouse controls planned. The are icons (slice types, fill parent, clip children, opacity, protected slices and extra data) and less text. Kiefkrack drew the slice type icons quite a while ago. Also a bunch of other UI improvements, such as better controls for collapsing/expanding subtrees (not in the gif).

39_sliceedit.gif (773.03 KiB) Viewed 1629 times

One of my biggest projects since hróðvitnir is the new internal EditorKit system to make as easy as possible for us to add new editors/menus (I wrote it to create the Achievements editor), and I've converted a few editors to it so far. Typically the rewrites are half the code of the original (I've cut about 500 lines so far), far easier to modify, and give consistent a UI across editors instead of each being unique. I've reorganised some menus in the process, eg: recently the map editor:

39_maped_old1.png (2.74 KiB) Viewed 1629 times

39_maped_new1.png (2.95 KiB) Viewed 1629 times

I also just converted the Distribute Game menu, and reworked a huge part of the packaging code too. Together with a new packaging system for the engine itself (ohrpackage.py), that's probably been my biggest project since hróðvitnir. I know noone else cares, but the old package code and scripts were a nightmare to maintain, so I'm working on what bothers me.

Anyway, two new features: exporting game for Steam, and a submenu where you can add or remove files to a package:

39_distrib_contents.png (2.67 KiB) Viewed 1629 times

Finally, I just went through almost all the menus in Custom and added some padding so the text isn't flush against the screen edge. I thought that was ugly. It's part of the process of moving away from 320x200 (you can still run Custom at that but I'll increasingly assume nobody does).

[Feenicks]

Going to greatly appreciate not having to drag the various steam files into the zip every time I make a new update. Great to see.

[The Wobbler]

Steam export will be very very useful especially in games that include more than one .RPG file! Thanks for all the hard work

[TMC]

Oh, I completely forgot about multiple .rpg files. That's still not handled correctly on Mac, where the extra .rpgs ought to get put inside the .app. Hmm, I guess it can just assume that you want all extra .rpg files to be treated that way. (If you add a directory containing .rpgs, they won't be.)

[TMC]

Lately I've mostly been working on slice transforms (more on that next time), rather than release blockers as I should have, but also made some improvements to integer and floating point (fractional) number editing. I finally fixed the awful behaviour of left/right when inputting a float. (There are only a few values in the engine that are floating point, it's not obvious which. Currently just elemental resists and slice opacity. There will be more soon. Press . to enter a fraction).

I also made Left/Right keys accelerate the longer you hold them down, and spent a long time tweaking it until I was very pleased with it.

40_acceleration.gif (47.65 KiB) Viewed 1578 times

It's also more precise for small changes than before, because the initial repeat rate is less than before.
The trick to hitting some value is to briefly release the key, which both slows down the speed and the acceleration.

[TMC]

unexplained.png (91.05 KiB) Viewed 1569 times

[Bob the Hamster]

I don't know what that is but it looks cool!

[TMC]

(Disclaimer: None of this is in nightlies)

I've posted teases of sprite rotozooming in the past, but let's skip that this time because nothing became of it.

In fact last year I threw away most of the code for that and started over, because the rotozooming library I'd used was buggy, and other issues. Instead I switched to the unused software (drawn on the CPU, not graphics card) triangle/quadrilateral rasterizer we already had in the codebase. Huh?

(Aside)

Let's revisit 2011. Jay Tennant, the capable programmer and pianist who wrote gfx_directx, wanted to rewrite the rest of the engine's graphics handling too, to allow hardware acceleration, true color, blending, shader effects, and transforming (rotating/scaling/shearing) any slice with view matrices. I didn't want to drop gfx_sdl or "2D-only graphics libraries", and James didn't want to do all those things at once. The way I remember it, I was trying to talk Jay into focusing on adding OpenGL support to gfx_sdl (and gfx_fb?) instead of starting with gfx_directx, but instead I accidentally talked him into writing a software rasterizer so OpenGL/Direct3D would be optional.

Why isn't [transformed sprite rendering] at least implemented in SDL? Oh well... we'll have to implement our own.

Because it's very difficult to write such an (efficient) general purpose polygon rendering in software, and anyway it's way outside of SDL's purpose of providing the highest-common-denominator. If you want to attempt an implementation, best of luck.

Heh, it is challenging, [...] Actually, I'm quite intrigued in doing this.... dang it Ralph! Enticing me! :P

I've always wanted to code such a thing myself -- so I can't help but become totally distracted by this discussion. :)

Unfortunately Jay's grand plan wasn't realised despite all the work he did, for which I feel a lot of guilt for not lending more assistance: it required probably as much or more work to convert the engine to the new system, and is still only half done. I've been slowly chipping away ever since. The rasterizer was never used because it wasn't really finished (it had tricky unsolved graphical glitches and was slow -- apparently I volunteered to optimise it). We couldn't even use it because it only supported 24-bit color mode, but the OHR remained 8-bit until... Hróðvitnir. I wrote about that project just up this page.

Yikes, looking back, it turns out Jay did implement 8-bit support, but the last thing he did was to delete it after I remarked I'd assumed that he wouldn't... so he figured it wasn't needed. We didn't know the engine conversion to 24-bit color wouldn't happen.

In February 2022 I finally revived the rasterizer. Unexpectedly it was a lot of work to get it complete, bugfree (?) and relatively fast (more can be done). I even added 32-bit texture to 8-bit display rendering.

(End aside)

So then I immediately rewrote sprite slice rotozooming using the rasterizer and... did too much at once. You could scale or rotate (around an origin or not) *or* do any other transform (shear, etc) by setting vertex positions manually, but if you scale a rotation you get a shear, and many other complications I'll gloss over, and the code became so complex that I was defeated. I had another go earlier this year and got much of it working, but I had to find a better solution.

Finally, attempt three: a lot more deleted code. Now Sprite slices can be rotated or scaled only. Everything else the rasterizer can do is done by the new Polygon slice. Polygons will do everything Sprites can including dissolves, and in future, animations.

Polygons can be textured, have a gradient between the vertices, or both (per-vertex color modulation, including opacity). Plus shared opacity/blending/modulation settings.

41_polygon_vertex_colors.png (76.54 KiB) Viewed 1542 times

You can set position and texture coords of each vertex, but the easiest way to set up a polygon is to convert a sprite slice into one. However, they should generally either be parallelograms or else treat the image as a texture UV-mapped in the right way, or you get distortions because they're split into two or four triangles:

41_polygon_uv.gif (281.01 KiB) Viewed 1542 times

Here's a nice article showing you can't stretch a sprite across a non-parallelogram quad well using 2D transforms. Despite knowing that I wasted time trying different triangulations, it didn't help:

(Image created by screenshotting a grid, importing as a backdrop, rotating 45° and scaling 141.4%, overlaying and screenshotting again).

0 & 1: two triangles. 2-5: four triangles, 6 & 7: three triangles

41_polygon_triangulation.gif (158.35 KiB) Viewed 1542 times

What's surprising is that it's possible to always make all the diagonal lines straight and parallel, as I managed here, but not horizontal or vertical lines: they shouldn't stay parallel between opposing sides of different lengths, but any affine transformation keeps them parallel locally, always forcing a seam:

41_polygon_diagonals.png (11.15 KiB) Viewed 1542 times

"Triangulation:" was mostly for testing, but I'll probably allow some control over it. For textured parallelograms two triangles is fine, but for gradients you need four to look correct:

41_polygon_color_interpolation.gif (89.58 KiB) Viewed 1542 times

Not done yet: polygons with 3 or 5+ sides.

A lot else isn't done either, I'm still far from getting either polygons or sprite transforms into nightly builds. I want rotozooming of sprites, polygons, lines, ellipses and ultimately rectangles and text to be consistent, but I already told you you can't scale a rotated sprite. I need to clean up the code and add script commands. Are sprite rotozooming and polygons going to make it into ichorescent? Are they stable enough, and how much would it delay release? Maybe just rotozooming? I don't know yet. Waiting until afterwards may be better.


Footnote: I was reminded that recorded .gifs looked really bad in 24-bit color mode:

41_flickering_32bit.gif (108.39 KiB) Viewed 1542 times

Fixed, and they're now much smaller too.

[Bob the Hamster]

Wow to all of that!

So you have sprite scaling and zooming working, but they are still mutually exclusive?

I would say that merging that now, even with the known limitation would still be useful to a lot of people.

[Bob the Hamster]

Thinking about this more, as long as attempts to set zoom and rotation simultaneously produce a script error, that would make sure nobody writes any scripts that will break later when the limitation is removed

[TMC]

You can both rotate and scale sprite slices. However, although you can convert a Sprite to a Polygon that looks identical*, if you try to apply the same transform to the two they'll react differently, as this gif shows. That's because in order to simplify things sprites have angle and scale parameters, and applying a further rotation or scaling to them adds to those parameters rather than rotating/scaling the vertices of the image on the screen (as Jay would have wanted it). Sprites are first scaled, then rotated, so it makes no difference for further rotations, just for scaling. I think that's fine. We can still add view matrices in future for transforming whole slice trees (e.g. to zoom out the map).

42_sprite_vs_poly_transform.gif (719.59 KiB) Viewed 1507 times

But there are lots of other details that are buggy or I haven't worked out or implemented yet, especially the "Rotate bounding box" setting, which does mostly work (it selects whether the sprite slice's size and position change, otherwise the image goes "outside the box"). I'm wondering whether it should make alignment and anchor points and collision hitbox rotate instead, I think it would be better if it did. Then slices would have separate sizes and axis aligned bounding box sizes. The complexity of that setting is the real reason my previous rotozooming attempts failed. But I could just hide it until it's done.

However currently even if "Rotate bounding box" is off, scaling a sprite still changes its size, so scaling and rotating are very different to each other. I'm not sure about it.

*There's one exception: I decided dissolves should intentionally work differently. For a polygon, I think the dissolve should apply first, to modify the texture (not implemented), meaning a number of dissolves such as Puff won't be available. For sprites, the dissolve happens last, after transforms. This allows you to make an enemy's sprite first fall onto its side and then dissolve.

[TMC]

Another sad story with a happy ending...
I finally resumed work on script debug info, which I started on back in 2014. I also made a bunch of script debugger improvements. You can now see exactly where in your scripts that an error occurred and that each script is currently at. You can also see real names of local variables, and the script debugger runs at higher resolutions and is much much friendlier. Also, script and menu handles are recognised and described.

Not in nightlies yet, but I'll probably be done in a day or two. I'll post more details then.

43_error_line.png (4.06 KiB) Viewed 1446 times

43_debugger_locals.png (4.82 KiB) Viewed 1446 times

"Cont 328:pinpoint" means Container slice 328 (shown in the slice editor as "Script handle: 1612710211 (slice 328)") with lookup code "pinpoint". (I should add a setting to show that number in the slice list.)

Writing some scripts, I was annoyed that the script debugger's current script position display (which possibly noone else knows how to decipher anyway) seems broken. I spent a couple minutes trying to fix it, and I regret them. That stack unwinding logic is possibly the darkest corner of the source. On a whim I decided to waste time more productively and work on merging this huge feature branch from 2014 that I've been too intimidated to finish. This is my second biggest unmerged branch after sprite transforms/polygons, and it's daunting to review. However, any bugs it adds are almost certainly going to be in either the script debugger or compiler error messages, so it's not too dangerous to merge. Thankfully I did a lot more work on it in 2017, so I only had to fix six years of conflicts and incompatibilities, not nine. After some hours of that I was surprised it was in already working order. It also made some UI changes to the script debugger, which I've avoided because that's possibly the worse code in the engine (I wrote most of it). I had planned to start over. So that got me to spend a couple days making a lot more improvements to the debugger, and now the code is only half bad!

There's a number of other debugger improvements I'd like to make some other time: add global variable names, make it run in a separate window, mouse support, and letting you jump to the slice editor from a variable containing a handle, and editing handles.

I've got an insane number of unmerged changes (git branches) which I want to work through, so I thought I'd start a running tally to show progress. I wrote a script to tally the non-"junk" ones showing I have approximately (can't do this accurately, and you can't see the difference between code moved between files vs actually changed):

Code: Select all

433 commits on 205 unmerged branches: 23360 lines added, 10523 lines removed

[Bob the Hamster]

The script debugging improvements look great!

And that is a lot of branches! I'm glad you are merging things