1.9 release checklist

[randomdude999]

i remember p4 mentioning moving some configurations out of individual commands and into some kind of general "config" block. these should be deprecated in 1.9 then imo.

one command that i'd definitely wanna deprecate in 1.9 is freecode $ff, i.e. setting the freespacebyte in the command. this could become a freespacebyte command (or config block entry?) which is used for all freespaces. (also this byte should be used as the fill byte when expanding the rom too) done

also: https://github.com/RPGHacker/asar/issues/224#issuecomment-989433691 maybe we should make optimize dp always and optimize address mirrors the defaults done

[RPGHacker]

One problem I forsee with config blocks is that that they could create a lot of overhead for end users. At least if I grasp the concept behind them correcty. Instead of being able to override just the setting you care about, you'd always have to override the entire block. Or is the intention that you can override singular settings in a block? Though in that case, how'd they be different from just the individual commands we have right now?

I think I need a concrete proposal for what this feature could look like before I can properly picture it.

As for the freecode split, I suppose that's reasonable, since the freespace search algorithm always checks your entire ROM, anyways. It doesn't really make sense for one search to only check $00 bytes, but then another search on the same ROM to also check $FF bytes.

And I guess #224 is a backwards-compatibility thing, so they probably should be the default, yeah.

[randomdude999]

we've traditionally released new asar versions at SMWC3, the next of which starts on 2024-02-23, which i think is a decent time to aim for (gives us about a month to tie up loose ends).

someone (probably jokingly) mentioned adding titles to asar releases. i think it'd be fun, i propose the title "better late than never" for 1.9.

[RPGHacker]

Aiming for a C3 release is also what I was hoping for. Though it's worth noting that I see C3 more so as the absolute deadline. My personal idea is we'll get a stable enough v1.9 built way ahead of C3 and then just keep it ready. I'd avoid making changes until last minute. By now, 1.9 definitely includes more than enough changes. Any more and it'll probably burst.

A different way to look at it: With how much stuff we've already changed in 1.9, I'm pretty confident problems in all kinds of patches and sprites will pop up post release. A version 1.91 will almost certainly be warranted. This means if there's any major stuff we still need to get into Asar before 2.0 (such as more feature deprecations), it doesn't necessarily need to happen in 1.9. There'll be further opportunities down the line.

With that said, here's how I personally view the 1.9 situation: Feature-wise, I'd say we shouldn't add or change anything else (maybe we can still make a decision on the optimize topic mentioned above, but beyond that is where I'd personally draw the line for actual feature stuff). Aside from that, I think we should focus solely on stability - which from my point of view means fixing any problems that break backwards compatibility with 1.81, as well as potential bugs we newly introduced into 1.9.

As far as more personal stakes go, my baseline for 1.9 has always been to make sure VWF Dialogues assembles in it in a way that will keep assembling in 2.0 without any changes. Forward compatibility is the main point of 1.9, after all. This has been working for quite a while, but as mentioned on Discord, some (not so) recent changes to 1.9 broke the patch. Once we get it assembling again, I'll personally be fine with 1.9.

Those may be some rather selfish stakes, but I don't think VWF Dialogues is the worst goal to aim for. For the past few years, it has consistently used features of Asar that weren't very well-known, and many of those have already existed since before 1.9, making the patch a decent test case for changes that break backwards compatibility. So getting it to assemble again will do more good than harm.

[randomdude999]

i agree vwf is a good benchmark, tho i think we should seek out some other ones too. i've tried a few disassemblies, but they're not very interesting, they usually don't use that many features. i think p4 tried every patch on the patches section once, but that's only testing if they still insert i think (or maybe he diffed the output to make sure the output roms are identical too?)

and yeah i've mostly been focusing on bugfixes right now (on asar_19 at least)

[randomdude999]

re: optimize: maybe we should handle that like math pri et al, i.e. make asar 1.9 use the enabled settings by default? also did we ever fix the bug where asar 1.9 doesn't work?

[RPGHacker]

Concering tests, I think testing non-patch stuff (sprites, UberASM, blocks etc.) is actually where it gets interesting, since those often do some special stuff under the hood. More so than patches tend to do. Plus, there's probably way more of them, anyways. The problem is that I don't think there's a straightforward way to test those. The respective tools need to make use of the Asar 1.90 DLL (might require tool rebuilds), and even then correct list files will usually need to be generated. Doesn't seem very automatable.

The "asar 1.9" solution sounds fine to me. And good question, I hink it still needs "1.90" currently.

[randomdude999]

we can't really make asar 1.9 work as it'd still give bad errors in older versions of asar, which defeats the entire point. i'll just make the errors say asar 1.90 instead. the version checker only requires that the version have 1 to 2 dots and consist of only digits. if the major version doesn't match, it exits immediately, so we can change the syntax in 2.0 (i.e., ban asar 2.00 and make both asar 2.0.0 and asar 2.0 work)

[RPGHacker]

You know, maybe a bit of a hack shmeck, but I guess we could also just special-case version numbers < 2.

So we could make 1.90 legal, but 2.00 illegal. Since we probably won't ever have a version 1.10.x, I think we can get away with it, even if it means a special code path that'll be present in Asar 2.x for at least a couple of years probably.

[randomdude999]

well we released 1.90 now