[S1] Considerably speeding up level loading
Gotta go fast, right?

So, the other day as I was browsing through my old projects, I found a project that I had been working on but never completed, and since I came up with ways to considerably speed up level loading, I thought I could share with you. Why you'd want to use this? Well, I don't... Gotta go fast, right??!!
Bear in mind I will use Sonic 1 HiveBrain disassembly, so for SVN/Hg/Git, reference only. I am unsure whether or not will it work with Sonic 2 or Sonic 3/Knuckles/3 and Knuckles. Most of these are compatible with each other and can be applied fairly easily, however if its not the case, and is known, will be stated in the description

So, one very long process the game does each time you load up level, is load title card art. This is nemesis compressed tiles, and are compressed without interruptions. If you were playing music before this, it would freeze, which is clearly notable in Selbi's Sonic Erazor hack. As you can hear, it takes actually pretty long time, and for not very huge save of ROM space. If we uncompress the tiles, it will be able to load in only few frames, meaning the music will not be interrupted much at all. So, it obviously is quite a good speed up considering the space usage wont be much bigger, it's good tradeoff for the speed. You will need uncompressed tile-loading code from the misc section.

You can find there ins lables loc_37B6:, loc_47D4:, and Cont_ClrObjRam:. Next, decompress artnem/ttlcards.bin. You can change the filepath of this file, rename, etc., it's up to you. However in this example I am going to keep it as is. Now, go to lable Nem_TitleCard:, and you should see something like this:

Another long process is to load level graphics. While the processor does other things while that, it must wait for it before fading level in because of the PLC queue, and the fact that the graphics would look terrible (glitched graphics, blank space, etc.). However, because of how fast comper is, we can highly optimize the loading even if we reserve the processor completely just to load level graphics. However Comper isn't as compact as Nemesis compression, so extra space usage in inevitable. It'd be almost impossible to calculate exact space usage, so I threw an aproximation. The space usage may vary. It is good to note that currently no level editor supports Comper, so you must recompress if you wish to edit this system. You will need comper compressed tile-loading code from the misc section.

So, what you want to do first, is recompress these files from Nemesis to Comper:

Note how I reduced the value in the first dc.w as well? This is the pointer for the amount of PLC's to load, and since we removed the main art file, that is one less. You want to repeat this for all of the levels.

Note: You are required to have implented Method 2: Comper compressed level graphics in order to make this work correctly.
In the original game, the level loading hangs for few seconds while it loads level graphics, such as badniks and actual level tiles. This is necessary to not make the level look broken. However as we implented level graphics being decompressed with Comper, therefore it is not an issue, and you can load other graphics much faster, for example while the title card sequence is running. This means, we don't have to wait any graphics to load before we can let the player move already, and they will never notice. However, in order to store more PLC's in the queue, you need to allocate more RAM. We will extend the PLC queue from $FFFFF680-$FFFFF6FF to $FFFFF650-$FFFFF6FF. So first of all, we need to move SBZ and LZ palette cycle pointers from $FFFFF650-$FFFFF661 to somewhere else. You need to find $11 bytes of free RAM somewhere, for this example, I will use $FFFFFECA-$FFFFFEDB.
Go to loc_19F0:, loc_1A0A:, and loc_1ADA:, and replace each instance of $FFFFF650 with your desired RAM address. In my case, $FFFFFECA.
Before StartOfROM:, place these equates:

These make sure the lenght of the transfers are correct, and so PLC works as it should. Next up, we should fix the PLC addresses. Replace each instance of ($FFFFF680).w with PLCQueueAdr.w, and each instance of ($FFFFF684).w with PLCQueue.w. Now we have successfully extended PLC queue! Next, we need to make use of this extra space. So, go to Level_TtlCard:, and you should see something like this:

If some of the levels crash, you can adjust the value 3 in the second line to bigger value, until the levels don't crash. However this works completely in vanilla Sonic 1. EHowever, there is still a slight possibility that FZ can cause some issues, so lets quickly fix that. Go to Resize_FZmain:, and change:

bsr.w LoadPLC ; load FZ boss patterns

to

bsr.w LoadPLC2 ; load FZ boss patterns

Never mind the above, doing the change will make the explosion graphics break, and you can not cause any crashes in the origianl game anyway, so there is no good reason to do that chance
And there you have it!

Misc

Spoiler

comper compressed tile-loading

Spoiler

This is the piece of code needed for parts of this tutorial; You will be informed whenever this is necessary.
Right above LoadPLC:, put this piece of code:

I have an idea to speed up reloading the level after dying or loading the next act, based on what I did for level transitions in Sonic 2 Adventure Edition.
Basically, you take a single RAM byte and set it to -1 in before it switches to level mode (like in the title screen and S2 2P level select).
Then you load the level normally, and when it finishes loading, you set the byte to the current zone number. The next time a level loads, it will check the variable and find a match for the current zone number, and skip loading the main art tiles, blocks and chunks.
One could potentially skip reloading the level layout as well after dying, but that would require an extra byte, and anything that alters the layout would be problematic.

I actually was going to do that, but completely forgot. I had done this before, by setting the level restart flag to 2 instead of 1. However I need to check very closely that I don't make the code a bloated mess while doing it, so I'll look into it later. Thanks for the suggestion anyway

Might as well only load the bits of the title card you're actually using.

Suggesting to go the S2/S3K route of different title card art for each title card? or loading only certain tiles out of the whole tileset?

If the latter, is there a way to do that, in a way that won't slow things down at all?

If the art is uncompressed then selectively loading certain letters will speed things up (though perhaps not noticeably).

A negligible speedup perhaps, and I'd say less VRAM usage but not that it matters ALL too much... the title card art usually just gets written to the same place as the explosion and animals anyway and doesn't interfere with anything else... and 9/10 it's gone before you ever see either of the aforementioned sprites in gameplay.

Double post... to report a bug... IDK if its in the clean ROM version, but after applying this fix, my # of lives no longer appears. The hud object with Sonic's name and icon DO appear, but the number itself does not.