I'm not 100% sure where to put this, but it is minor and not a hack.
I played the hack Mario Gives Up by cyphermur9t and I enjoyed it, but there were some bugs I noticed (that were also pointed out by OmegaYoshi). I decided to fix them myself (since cyphermur9t hasn't) and made this. It must be patched onto a ROM that already has Mario Gives Up as this patch only contains my own changes.
I was coding all this stuff because I planned to make a RPG battle system for SMW but let's say I discovered my classes start tomorrow and I don't think I'll have any time to work on that anymore, so I'm releasing this here.
Just store values to $00-$0F, use invoke_sa1 to some label with PHB PHK PLB and JSL to any of the labels in this file. Remember to write windowing_ before, so if you want to call CircleWindow, you write JSL windowing_CircleWindow. Read the stuff before each effect so you know what to store to $00-$0F
Those who know ASM will probably see how everything is a complete mess and probably super inefficient. Well, that's why I'm not releasing this on the UberASM section, but if anyone want to give it a try, feel free, I don't mind. Do note that, of all of them, the rectangle window is the only which can do weird stuff to your game. Just make sure all the rectangle fits in a 768x512 screen, only the centered 256x224 portion of it will appear on screen.
EDIT: Forgot to explain how the scaling works.
The windowing table with the data you want to scale must be stored at !tempTable before you call this code, so make sure you set it at the initialization for example. The information here remains untouched and can be changed anytime if you want to scale a different window. The scaled version is updated by the code to smw's windowing table ($04A0) whenever the scaling factor changes.
SMAS Super Mario Brothers 3 (plus custom SMAS SMB3 Mario Maker tile) toolbars for Lunar Magic. Thanks to Spriters Resource and also KingGeoshiKoopshi64, Neweegie, Carbongolem and Qwerty Triple6 of MFGG.
I can see a slightly more obvious way to fix that than making a new tool for it...
Actually, I think that it shouldn't be heavily used.
It should only be used as an analysis of the cause of the issue of the tool using the old asar.dll.
(Indeed, I made this for that purpose.)
I think that this utility should not be created. ---
Also known as signature. This will be appended to your posts. HTML is allowed.
I didn't even know DLLs could include resource files as well. Should probably add that to my CMake script for the Asar DLL. In the current version, I left it out on purpose, thinking that only executables could make use of resource files. Thinking about it, that never really made any sense.
I'm the one working on doing that. I focused on other projects for a couple of weeks, which is why I haven't done that many, but the Angry Sun, the Fire Bro, and the Hammer Bro are all done and submitted to the sprites section. By the end of this week I should have managed to convert the rest of the sprites in it.
After those are done, we have also gathered a lot of Sonikku's other C3 sprites, which will all be converted and submitted.
I'm not sure which thread I should put this in, but I figure here is as good as any.
This is a VRAM DMA queue system. It was originally created for a homebrew project, but I decided to port it to SMW as well, mainly for use with the second thing that I'll explain. This adds two tables of data to transfer to VRAM, one smaller one and one larger one. This can simply be added to UberASM's NMI code.
; Small-scale upload table: $7FB700
; Index at $06F9
; Up to 64 4-byte entries
; Format: 2 bytes specifying a VRAM address followed by 2 bytes specifying data to write
; Large-scale upload table: $7FB800
; Index at $06FB
; Up to 85 12-byte entries ($7FBBFC-FF are unused - could be used for something;
; I could even have put the indexes here, or put them at $7FB800-03
; and the table at $7FB804, but having them in shadow RAM is easier)
; - Byte 1: DMA settings (value of $4300).
; - Byte 2: Register to affect (value of $4301).
; - Bytes 3-5: DMA source address (values of $4302-$4304).
; - Bytes 6-7: Size of data (values of $4305-$4306).
; - Byte 8: VRAM settings (value of $2115).
; - Bytes 9-10: Destination VRAM address (values of $2116-$2117).
; - Bytes 11-12: Delay timer. If this is set, the DMA will be delayed by this many frames.
; In addition, the data will be shunted to the beginning of the buffer, and the index to it will end up being
; a value other than 0 after all the other DMAs finish.
As you can see, the small table, which I put at $7FB700-B7FF by default, is mainly for writing individual byte pairs. Each entry is 4 bytes long and specifies just a VRAM address and data to write. The large table, which I put at $7FB800-BBFF, is for writing larger chunks of data. Each entry in this is 12 bytes long and specifies various DMA settings, as well as a timer that can be used to delay uploads. To use these, load the 16-bit index to the table, which I have at $06F9 for the small table and $06FB for the large, store your data to the table indexed by X (you'll probably need a secondary address as a source for the large table), then increment the index by either 4 or 12 (or a multiple of 4 or 12 if you're writing more than one entry).
Now, as for the immediate reason why I wanted to implement this system in SMW in the first place...anyone who's worked with SMW's Map16 tile-changing routine or the various custom variants thereof might know how slow it is. It depends on stripe image data, which takes a lot of NMI time to process compared to DMA. As a result, I've often found myself getting screen flicker and lag very frequently in hacks that use things that change multiple blocks at once (such as the YI number platforms, or ? blocks larger than 16x16). This patch changes that so that the routine at $00C0FB, which is used to change a block's graphics in VRAM when the tile number changes, uses the DMA queue (specifically, the table at $7FB700) instead of stripe image, making it significantly faster. It doesn't require freespace, and it is compatible with all current Map16 changing routines (or at least, it should be).
; VRAM base address = $3000
; small-scale upload table = $7FB700 (index at $06F9)
; large-scale upload table = $7FB800 (index at $06FB)
;$00C17A - Lunar Magic hijack!
I've tested the code with both normal and custom blocks, though not extensively. This might be worth inclusion in Lunar Magic, or it might not? I could maybe submit it to the patches section? In any case, if anyone else would like to try it out, I'd welcome further testing and suggestions. I'd also be curious exactly how it compares to stripe image in number of cycles used.
I tried out your code and it seems to work without issues. Flickers with map 16 changes bigger than 16x16 like you said are completely gone. 1 thing your code doesn't seem to account for is Layer 2 map 16 changes. The actual change of the block will occur like normal but the GFX/image won't change, and it also remains at its original position if the layer is moving. Don't know if this matters as well but I converted it to SA-1 since that's what I'm using.
Hm, you're right. It looks like while the Layer 1 address changed from $2800 to $3000, the Layer 2 address is still $3800, but the code only uses $3000. Does it work if you replace the top part with this instead?