Language…
18 users online: CroNo, DanMario24YT, Dennsen86, Inflagrandy, KaptainAhab,  MarioFanGamer, Metal-Yoshi94, mikeeeeee83, Nayfal, NewPointless, Rykon-V73,  Segment1Zone2, Serena, signature_steve, snoruntpyro, Sweetdude, TheXander, Tulip Time Scholarship Games - Guests: 308 - Bots: 413
Users: 64,795 (2,371 active)
Latest user: mathew

Posts by Katrina

Katrina's Profile → Posts

Early-stage screenshots from a hack I haven't quite ironed out the idea of, not worth starting a thread for yet.



these are all from the first level, which is way huger than most levels need to be


this is from level 2, a river level


this is from the world 1 castle


this is from the first level of world 2, a desert

There are a few other levels in basically embryonic stages, incl. a forest, a town, a switch palace, and a cave.

These screenshots are all very tentative and the overall character of the hack is likely to change to something I can be more showy with, and with more variety of themes. Current options include something like Paper Mario, but also something completely ridiculous like Super Metal World, like the music.
So, I guess I get to barge in now?

I’ve had a project going I’ve been calling "Daiyousei", which I started for my own hack which, for various reasons, has a need for this kind of thing. Here’s everything interesting I’ve got so far:

https://dl.dropboxusercontent.com/u/12961639/smwc/dys-2015-12-11.zip

If it’s decided Daiyousei is worthwhile, I have a github thanks to my university, so I could set up a proper repo instead of sharing .zip’s or whatever. I haven’t been able to test it on Linux yet because I murdered my Arch install a while ago, but as far as I know as long as you can get Asar to link it doesn’t do any weird platform-specific things that would break it.

Currently:
  • The tool can only insert standard sprites, and the ASM only deals with standard sprites. Shooters and generators should not be hard to add but I want to get the standard sprites up to par first. The load routine doesn’t deal with the koopa shells, etc, so those crash.
  • The tool has absolutely no compatibility with TRASM sprites. It may have incompatibility with a few sprites using weird xkas edge cases. I am not sure how many TRASM sprites there are, so I’m not sure how important that is.
  • A bunch of the original game sprites crash because I haven’t made them rtl yet.
  • It reads the same cfg and sprite list formats as the original sprite tool.
  • It should work with headerless roms. Haven’t tried.
  • It should work with typical Romi’s spritetool sprites. Haven’t tried.
  • The ASM is there to load extra bytes, but there isn’t any way to actually mark sprites as using extra bytes. We’ll need a new cfg or sprite list format for that.
  • Sprites are enumerated 000-1ff, using the extra bit used to mark sprites as custom by sprite tool.
  • A bunch of RAM addresses and a few constants are declared in memory.asm.
  • Everything is really poorly tested.


A bunch of things in the code are meant to make room for things I haven’t written the code for yet. In particular, tables are defined for extra options, which would allow the tool to have a few extra sprite settings (like extra custom states, clipping options, etc.), and clipping tables, although I have not yet written a custom-clipping collision routine.

A lot of things warranting explanation in a readme are currently unexplained, but I am willing to answer questions for now.

A lot of code is kind of weird and I want to fix it. I wasn’t really planning on sharing any of this until I at least had standard sprites working all the way but now this forum has shown up, so here we are.

Also, this isn’t like super important, but I’m gonna be honest: using raw hexadecimal addresses for all the sprite tables, aside from making everything a nuisance to port to the SA-1, is barbaric as a coding standard. Even mikeyk’s sprites were polite enough to write out a couple defines here and there. I still just have to leave the RAM map open in another window when I’m dealing with anybody else’s sprite code, because I honestly just do not care to memorize the fifty-or-so tables by address. And if I find anybody using a new-to-Daiyousei table by its hex address instead of its defined name, I swear to God I will move it simply to break your sprite.

Plans I have for the future:
  • The tool should detect if the original sprite tool has been used, and if so, clear out its patches. This shouldn’t be hard, but it’s enough of a bother that I haven’t done it yet.
  • Disassembling the original game sprites and allowing users to use the disassemblies instead using !opt_reinsertOriginals. Given how many sprites have yet to be disassembled I am unsure how feasible this is.
  • Having the tool actually parse options.asm so that options like !opt_reinsertOriginals will actually bear any meaning.
  • A new cfg format, including things like the new Daiyousei options, and maybe a new sprite list format.
  • I’m doing something wrong when I print out Asar’s errors. I should replace this with something correct.


In particular, for the new cfg format, I was thinking something like:
Code
DYS 1
type: standard
props: aa bb cc dd ee ff
xopts: 00 11
clipping: 08 08 10 10
xbytes: 2
source: myfile.asm

This format would be fairly easy to detect (is the first word "DYS"?), and allows for the addition of new fields without just counting how many bytes are in the file. Given the amount of defines and such Daiyousei generates a version number could help detect a sprite that would cause errors without just launching a wall of Asar errors onto the user.

I have a lot more weird plans and thoughts, but they’re far enough away that any extra promises would probably be vaporware. I feel a little silly leaving this honestly pretty messy stuff here, but it’s what I’ve got.
Originally posted by imamelia
Why only 000-1FF? Surely you can use a different flag and make them 000-3FF?

Because using the existing extra bit for part of the sprite number, like tessera, breaks backward compatibility - all the sprites that use it for something will have to look somewhere else for their settings
Using another byte for sprites 200+ gives us a lot more possible sprites, but Lunar Magic’s table only leaves room for 512 if we want extra bits not to act funny.
I have some ideas for how to do the formats:
Code
Standard sprite encode (for comparison)
        +3       +2       +1       +0
           ----~~~~ ----~~~~ ----~~~~
           nnnnnnnn xxxxssss yyyyeNSY

So: the x, y, s, S, and Y bits are all taken by SMW for format data. We cannot use them for anything extra without kind of ruining everything.
The e bit here is the extra bit for typical custom sprites. We cannot use this for anything extra without sacrificing some support for old sprites.
The N bit is used as the sprite number high bit by Daiyousei. We can use this pretty freely.
Knowing all this, I’ve come up with two possible formats for sprites 200+:
Code
Long encode, proposal 1
        +3       +2       +1       +0
  ----~~~~ ----~~~~ ----~~~~ ----~~~~
  nnnnnnnn 11111bbb xxxxssss yyyyeNSY

In this encoding, long sprites are 200-3ff. "Nnnnnnnnn" is the long sprite number - 200. "bbb", entered by the user as part of the sprite number, is the number of extra bytes, not including the sprite number.
So sprites 0|1f8-0|1fc would be used. _f8 would be for sprites with 0 extra bytes, _f9 would be for sprites with 1, etc. Sprites 0f8-0ff and 1f8-1ff would probably just be left unused, because making them loadable would involve some ugly stuff in the load routine.
This way, the extra bytes can just use Lunar Magic’s table and we don’t have to fight anything or beg FuSoYa to add a feature to Lunar Magic, which I have my doubts about.
These sprites would be kind of awkward to enter in LM, but don’t need any extra features or anything. If this does get used, FuSoYa could add support for it, which would basically amount to a UI convenience.

Code
Long encode, proposal 2
        +3       +2       +1       +0
  ----~~~~ ----~~~~ ----~~~~ ----~~~~
  nnnnnnnn 1111NNNN xxxxssss yyyye1SY

In this encoding, long sprites are 200-11ff. "NNNNnnnnnnnn" is the long sprite number - 200. Sprites 1f0-1ff are unusable. (We could use -1f0 instead of -200, and then they’d be usable, but the long sprites would go from 1f0-11ef.)
We’d be pretty much be depending on either FuSoYa adding support so they could have extra byte sizes.
Or we could make them all leave space for all 4 extra bytes. (This is wasteful, but the easiest way.)
Or maybe something like 200-3ff having 0, 400-5ff having 1, etc., but I would like it a lot better if we didn’t give any weird importance to the sprite number like that.
These sprites would also be very awkward to enter in LM. Not sure if they’d be much more awkward than option 1.

Also, even if we do get an encoding working, we have to decide on how the high byte of the number is stored, and it probably won’t act right with a bunch of old sprites. Like if you have a Birdo sprite and it expects the egg to be in the next sprite slot, and you try to put Birdo in slot 226, odds are it’s going to shoot sprite 127. In general most sprites are going to spawn sprites in 000-0ff, and assume they’re the original game’s, or 100-1ff, and assume they’re custom, regardless of what we try to do with them.

So overall, I feel like this is a lot of complexity for something which I’m not sure will see a lot of use. I don’t know how many sprites a typical hack has nowadays, but I haven’t seen anyone complain about running out and with the option to replace mostly-unused sprites like Peach and the fireworks there should at least be more space than spritetool had.

Originally posted by JackTheSpades
format stuff

I generally don’t like the idea of just reading the file until you run out of stuff. iostream makes it easy to do, but iostream sucks. I’d be perfectly willing to write a couple dozen lines of C++ to make the format a bit friendlier, and it wouldn’t be hard to generate from a cfg editor either.

Also, this way we can get optional fields without having to do a bunch of weird order requirements. Like, if we add spritetip support, and now sprites have an optional description line, how does that do with custom clipping settings? If we make every new field mandatory so that we don’t have weird things like "sprites with a custom clipping setting need a description, but not the other way around", that’ll make it harder to do updates that add fields, and we’ll get a million sprites with a line that’s just like "asfdkljzxlckvj" if we require a spritetip description or anything.

The other option I was thinking of was just throwing YAML at it, and making a big verbose config format with lots of options named in English, with a format something like: https://dl.dropboxusercontent.com/u/12961639/smwc/dys/cfg_template.yml
There’s probably something really broken in that file that makes it a bad example but it gets across the general idea of these files being huge and kind of complicated, but human-readable. The complexity isn’t too worrisome because there’s a few YAML libraries available so we don’t need to actually write a parser.
Drawbacks of this include:
  • YAML is huge, so the library would be huge.
  • a giant list of options named in English might not be super hype for the Japanese community, or any non-English hacking community.
  • It’s really hard to come up with names for these that aren’t a mile long
  • The simple number of fields is kind of intimidating. Not sure if it’s better or worse to a new user than just a bunch of weird meaningless bytes.
  • We’d need to do bit-twiddling inside the tool to combine all the flags into tweaker bytes. This would basically be a move of code from the cfg editor to the tool, not really a huge deal.


Maybe it’d be better off in JSON, ugly though JSON may be, simply because JSON is smaller.

On a related note, does anybody have the source code for the old cfg editor/tweaker? Was source code ever posted to begin with?
Originally posted by imamelia
Didn't Katrina have an idea for something like that?

Actually, I have an implementation.

It doesn’t really seem like anybody had much to say about the code I posted last time, which is inconvenient for me. If y’all could tell me if you’ve got any interest at all in the tool I’ve got going, that would be great.

I’m also not really clear whether y’all are working on the github that was posted a while ago, or if JackTheSpades just has a separate thing going or what.

I’ve just continued work on what I have in the meantime. Currently I have it up to loading generators and shooters successfully, no scroll sprites or run-once sprites yet (although run-once sprites are pretty much only missing tables).

Right now, standard sprites, generators, and shooters are distinguished using a byte in the same table as the extra property bytes and such are stored in. The generator/shooter number is just the sprite number. This will break things that load generators or shooters outside the load routine. I’m not sure if we can avoid breaking it while allowing generators, shooters etc. in arbitrary slots. I don’t know that this will be a huge problem - there’s not a lot of reason to spawn a generator or shooter, and all you have to do to fix it is change the ID and set the extra bits.

Also, in the process of putting all this in, I implemented my cfg format and made a new sprite list format.
Here’s an example cfg I’ve been using:
Code
DYS 1
acts-like: 02
props:     33 04 05 00 06 00
ext-props: 67 00
source:    basic.asm
xbytes:    1

The ‘acts-like’ byte is the $9e setting, ‘props’ are the Tweaker bytes, ‘ext-props’ are the extra properties bytes, ‘source’ is the ASM source file to use, and ‘xbytes’ is the number of extra bytes to use.
The original cfg format had the first byte as the type byte, but Daiyousei gets the type from the sprite list. I will probably try to add support for the type 0 tweaks of the original tool later, which is the only place the type byte in the original cfg was any use.
The only mandatory fields are ‘acts-like’, ‘props’, and ‘source’. It is worth noting that generators and shooters don’t actually have any use for ‘acts-like’ or ‘props’, so I may just reduce that to ‘source’.
‘ext-props’ is optional (setting to 00 00 if absent) because there’s plenty of sprites already which don’t use them for anything. ‘xbytes’ is optional because the vast majority of existing sprites don’t use any extra bytes.

A few other tables exist and are loaded for extra settings and clipping and things, but right now no code actually reads them.

The sprite list I’ve been using is:
Code
DYS 1
@standard
#101 basic.cfg
#102 complex.cfg
#103 basic2.cfg
#104 beezo_rideable.cfg
@generator
#1d0 test-generator.cfg
#0f8 spawning-test.cfg

An @ line sets the type for all the sprites until the next @ or the end of the file. A # line is basically the same as a sprite list line from the original tool, it has a slot number and the cfg file to put in that slot. This doesn’t quite go aesthetically with the CFG format but it’s practical and easy to parse.
Inserting a sprite into a slot 000-0f6 will overwrite an original game sprite.
This format should also comfortably allow overworld sprites, cluster sprites and whatever later on.

If the ‘DYS #’ header is missing, it uses the original sprite list format, inserting everything into slots 100-1df, and inferring the type from the number.

If there’s any interest in my tool, I’ll post code again once I’ve got a few things fixed up (mainly a few places where there’s a jsl to an rts). If not, I’ll try my best to contribute to whatever y’all got running? Again, really not clear how that’s working.

Also, seriously, I think y’all are makin’ the sprite numbers a lot more complicated than they need to be. They’re also hardly urgent. If we decide we need 1,000+ sprite slots we can change up the load and spawn routines later.
Progress report:


I’ve made a substitute for the no more sprite tile limits patch. It keeps a count of tiles known to be used so far, and makes $01b7b3 (FinishOamWrite) update it with the amount of tiles drawn. Not all sprites call $01b7b3, so it also does a scan loop starting from there in case any tiles have been used that weren’t recorded; this loop will exit right away if the sprite recorded all its tiles, or will iterate over as many tiles were drawn otherwise. This *should* perform a lot better than the old way, which was to just run a scan from the start every time, but I haven’t measured.

I haven’t tested the patch with the Koopa Kid fights, with their sprite backgrounds and all, but I’ll almost certainly need to change a bit of it to make it work.

I also have run-once sprites working, which allowed me to fix up shells and the triple spinning platforms, etc.

The last sprite type to deal with is scroll sprites. I’m still kind of figuring out how exactly to deal with these, the original game’s way is really weird. I might recode them entirely, to separate layer 1 and 2 more and maybe add proper layer 3, so that they can be mixed ’n’ matched in exciting new ways. I’m also considering not doing that. If I write an okay generic one that’ll probably more than cover everybody’s scrolling needs.

Also in the works are a few shared graphics subroutines. Those have enough weird little specifics that we could probably argue them for a while. My main goal with them is to have them general enough that I can update at least most of the original spritetool sprites to use them instead of their current routines.

Edit: Also left to be dealt with is custom clipping, which I would very much like to have in here. Imamelia has posted a clip routine and I might end up just modifying that a bit to use the tables I’ve made, etc.
(restricted)
I meant to talk about things at the meeting when that thread came up, but it looks like that’s going to be just a bit yet so I figure I may as well drop in with a progress report.



I ended up putting custom scroll sprites aside and just working the original game’s back into the load routine. At this point the tool is pretty much able to match all spritetool’s features. There’s still a few bugs in SMW’s sprites that I’m trying to work out, which are mostly with the bosses.

I have begun to port over the sprites included with the original spritetool, which all seem to work fine once I’ve de-trasmed them. I’m also hoping to port over Tessera’s included sprites.

Another focus is the shared subroutines, and in particular I’ve created a few shared graphics subroutines. They are:

Code
!ssr_GenericGfx_16x16
!ssr_GenericGfx_16x32
!ssr_GenericGfx_32x16
!ssr_GenericGfx_32x32
!ssr_GenericGfx_FTable16x16
!ssr_GenericGfx_FTableMTS


They are called like:
Code
	ldy <frame>
	rep #$20
	lda.w #<frameTable>
	jsl !ssr_GenericGfx_...


The first four are fixed-size and use the sprite’s tweaker palette settings. The tables only contain the tile numbers to use.

The last two are arbitrary-sized. The tables contain pointers to frame data. For FTable16x16, this is the frame’s width in pixels, followed by tile, properties, x offset, and y offset for each tile. For FTableMTS (‘multiple tile size’) it is size ($00 or $02), tile, props, x, y.
For 16x16, the frame ends with tile $ff, for MTS it ends with size $ff.

The routines handle horizontal flipping (which is why the FTable routines need a width byte) but not vertical flipping.

The only thing I’m really thinking of adding to these right now is some way to get the Tweaker palette into the FTable routines, because right now the only way to do palette swaps with those is to give each palette its own set of frames.

Quote
From the looks of the progress I guess Katrin is already doing most of that herself?

Basically, yeah. Sorry about taking so long to reply - like I said I was hoping to bring this up at the meeting.
(restricted)
Okay, so, being currently working on all the other code and all, I would like to ask some questions here.

Quote
1) autosort by sprite priority (it is not object priority).


I’m not 100% clear what you’re saying here. What do you mean by ‘sprite’ and ‘object priority’? I’m not aware of anything by either of those names, except maybe the p bits in yxppccct, which I sure hope aren’t what you’re talking about (Are they what you mean by object priority?). Maybe these are just names I have’t learned yet, iunno.

When does the sort occur - when a sprite requests its OAM slot, when it’s calling the finish oam write routine, or all at once at the end of each frame? Is the sorting a complete sort of all sprites, or just some, say sprites which overlap each other? Probably most important - do you know how long this sort would take? Normally SMW just lets all its slots fill up however they might, depending on how your sort is done it could take up quite a bit of extra time.

Quote
2) use the complete oam (128 tiles).

Are you planning to keep this compatible with old sprites using $0300-$03ff directly, with 8-bit X/Y? Would you just be able to drop old sprites in there without problems? (If you put them in sorted order at the right times, this might not be a problem).

Quote
3) one hijack for each special original sprite like smoke, yoshi tongue, yoshi, sparkle, etc...

You could probably look at imamelia’s extended NSTL patch. I know it misses at least a few things (e.g. the smile on lakitu’s cloud) but it’s got a hijack in the vast majority of them, as far as I know.
(restricted)
It’s still pretty much the same. One with all the currently-existing fields filled out looks like:
Code
DYS 1
acts-like:   xx
props:       xx xx xx xx xx xx
ext-props:   xx xx
dys-opts:    10 00
ext-clip:    00 f8 10 18
name:        Sprite
description: A can of Sprite to satisfy Mario's thirst.
source:      file.asm
xbytes:      x


Currently the name and description fields aren’t used for anything but I intend for the tool to eventually generate spritetip files. Having a field for them in the cfg editor couldn’t hurt. I hope to add some stuff for the tilemaps, but haven’t yet; I should get on that soon.

The dys-opts fields are for settings used by shared subroutines or whatever. Currently only bit 4 of byte 1 is used, to decide whether to use custom clipping or not. (I said bit 6 in irc yesterday; I was wrong.) The other bits should be left 0 so nothing acts weird if we come up with uses for them later.

The ext-clip values are x offset, y offset, width, and then height.
Setting the dys-opts bit and filling in ext-clip is all it takes to make a sprite use a custom sprite clipping set, no changes to the asm are necessary. The old sprite clipping value is just left unused in this case.

String fields (name, description, source) start from the first non-whitespace character after the colon and continue to the end of the line.

The minimum cfg file right now is:
Code
DYS 1
acts-like: xx
props:     xx xx xx xx xx xx
source:    file.asm


Any bytes (like the extra property bytes) left out are assumed to be 00. The name and description are empty strings if left out.

I am thinking of reducing the required fields to just source because technically generators and stuff don’t actually use any of that data, so having it there is just kind of weird. But that’s hardly like, urgent.

Also there’s nothing actually requiring that you keep the field data aligned or anything but I think it’s nice that way.

Being able to read in old cfgs would be very helpful, and shouldn’t be like super hard to do given how simple they are.
Originally posted by imamelia a few threads over
Also, Katrina, does your custom clipping routine still assume that all position values are within a range of 0x7F? It looks like it does.

Right now, yes. In fact right now it just hijacks the ‘get clipping’ routines and nothing else, which isn’t even enough to get values out to $7f working properly; a few things use SubHorizPos & such before they check the actual clipping.

So we’re going to need to have a moment of discussion on a hot new topic, clipping.

The main concern I have with clipping is that I’m worried about it taking up a billion tables. For one thing, right now the only one even partly implemented is sprite clipping. The ‘obvious’ way to do object clipping would take eight tables, I think, which is quite something to be demanding. I’m thinking of just deriving them from the sprite clipping offsets, which gets to be a bother if you want them separated but I’m hoping that won’t be too common.

16-bit clipping offsets is appealing to me (you could make things like the layer 3 smasher, with layer 2/3 graphics and a huge hitbox), but they would also take up twice as many tables as now (4 -> 8). I’m thinking of using a separate collision routine for them (probably based on imamelia’s), using direct page $0c-$0f as the high bytes or something, so you could use static values for them or keep them in miscellaneous tables and copy them over.

EDIT: just remembered using a separate routine only makes sense for sprite<->mario and sprite<->object clipping but not sprite<->sprite clipping, crying
anonimzwx, you appear to be describing insertion sort, a widely-known O(n²) algorithm. That is... not great. Gonna be real, if you would post whatever code you have for this it would be a great help in making this kind of decision.

p4’s proposal is interesting and seems simple to implement. I have exactly three objections:
  • It seems like priority changes would have to have a 1-frame delay. This is like, slightly inconvenient, but not unmanageable.
  • Each sprite would only be able to draw tiles at one priority. I feel like there would be a good use case for multiple priorities in a single sprite but I cannot think of what it is.
  • It seems like the main trouble that could arise in implementation would be that sprites which iterate over other sprites for whatever reason could be doing it in a different order than they execute in, so if they do that and one dies on the same frame you could get something weird. The main reason to do this is collision, which would only need one routine changed.


None of these are really deal-breakers. It may be the case that none of them turn out to be problems at all. When I have time I will probably give this a test run.
Originally posted by Vitor Vilela
I wish if we could improve actually sprite<->sprite interaction because SMW barely has it at all. You can't put a sprite in a platform, you can't stack sprites, you can't make a sprite mount another sprite, this is just horrible.


I am totally down for this. I’ll start looking into the sprite clipping routines. I’ve honestly been kind of considering a third routine, alongside INIT and MAIN, like COLLIDE or something, to be called when sprites hit each other. But it kind of feels like there has to be something wrong with that idea.

Quote
Also I really want to sprite clipping just be in the RAM, allowing the sprite itself change it at any time. It would just make everything much more flexible.


The current system is it checks an option bit to see if custom clipping is in use, and if it is, it just uses RAM tables instead of the ROM tables SMW uses.

I decided to make them configurable in the cfg file because it seems plausible that there will be a bunch of sprites that don’t want a SMW clipping setting but don’t change size either. But if you do want to change its size while it’s running, those are just initial values, you don’t have to worry about them if you don’t want to.



Also, I’m hoping that with custom clipping and the GenericGfx routines, it will be easier to do things like replacing a sprite with a shrunk/grown version. It’ll probably never to get to like, click-of-the-mouse level intuitive, but...

Aside: sorry for a lack of progress lately! I just plain haven’t gotten lots done since last time I was in IRC other than a few optimizations in the shared subroutines.
I can kind of see jamming sprites and such into a struct, but I feel like having the tables split makes them a weird fit. Is it possible to make their alignment smaller than their actual size, so that e.g. sprite[1] would be offset by one byte instead of however far the last sprite table is from the first? (I think it might be like, $7facff-$9e = $7fac61, or something in that area, which is clearly not useful)
Or we could just tell people not to statically index sprites, which honestly seems like it’s not a super useful thing to do be doing.

Being able to avoid their redefinition is definitely nice though.

While we’re talking about adding things to Asar, might I make a feature request?
The SA-1 patch more sprites thing moves a few variables from the direct page into 16-bit addressed IRAM, which normally isn’t a huge deal but I have some code which has the data bank set to possibly be in $40/$c0+ while it’s dealing with sprites. I have the following macros to deal with ‘Out-of-Bank’ access:
Code
macro OB(opc, addr)
	if <addr> < $100
		<opc>.b <addr>
	else
		<opc>.l <addr>
	endif
endmacro

macro OBX(opc, addr)
	if <addr> < $100
		<opc>.b <addr>,x
	else
		<opc>.l <addr>,x
	endif
endmacro

These noticeably suck compared to being able to write code like a normal human being, e.g.
Code
	lda $0003,y : %OBX(sta, !spr_xByte1)

They also don’t give as many errors as is desirable, e.g. I can write %OB(inc, !thing) and it won’t give me an error if !thing happens to be direct-pageable.

And I was hoping that maybe opcodes with a .b and .l version could have something like a .o psuedo-mode which would just be converted to .b or .l somewhere. I’m assuming, of course, this is a problem people other than me have sometimes; if it’s obscure enough, I do have the macros.
Re: leod, I’m neutral. The platform patch is not really a game-changer in terms of whether to integrate something like that into the tool, because integrating it would allow for a much, like 2x, more efficient way of handling it. It’d be nice to have somebody who releases things seemingly fairly frequently around I guess.

Originally posted by imamelia
Incidentally (*looks at Katrina*), what is the current status of this anyway?


Currently a boring slog of me finding and fixing weird bugs, like if you hit a Buzzy Beetle with a Buzzy Beetle shell they turn into a weird sinking glitch tile and if that hits anything the game crashes, I did something to the NSTL patch that makes the Amazing Flyin’ Hammer Bro flicker, etc. This isn’t like, a quest for me to run through and fix every bug that’s happening so far (I expect that to take a while because some of these are just awful), but I am trying to get it so you can play through every SMW level without crashing.

I’m also working on getting it to work with Vitor’s SA-1 patch, which mostly consists of looking through ASM files checking for raw memory addresses, and checking my hijacks against Vitor’s. This should be done pretty soon, unless I’ve missed something important about the SA-1 patch.

In a couple of days I have spring break, which means staying with my family and not having reliable internet. If anything this will drastically improve my productivity, but I don’t know how much y’all will be able to witness of it.
Quote
This should be done pretty soon, unless I’ve missed something important about the SA-1 patch.



I’ll report back on this again once I’ve got a script worked out to detect hijack collisions.

modedit: stz $ table stretch
(restricted)
(restricted)
(restricted)