Sonic and Sega Retro Message Board: Hanoch - Viewing Profile - Sonic and Sega Retro Message Board

Is there a real reason why most huge ass games fill all the space with junk (a bunch of $FF bytes in a genesis ROM, for example).

I also read somewhere here that xbox 360 and ps games are almost the same, only difference is PS games have a lot of padding for the blue ray disks (and also changing text strings to load the right buttons that vary from each console).

Is it really necessary to fill the emptiness in the games, to match the cartridge/disk size?

Also, why when adding new art to a sonic game, sometimes the new DAC samples I add become noisy, but after resizing the padding file, its all better?

What I don't understand is, how can different emulators produce different effects. Are they like how operation systems vary from each other (how Linux is different than microsoft, gens is different than kega etc) or maybe there's something else im missing?

Pattern load cues are how sonic loads his art. He loads for each sprite a specific amount of tiles, leaving all other vram space free to manipulate untill that exact sprite loads and overwrites that vram space. What I want to know is, has anyone tried to do that thing with palettes?

Each sprite is using a specific amount of colours from that same line, and when that sprite is shown all unused colours are free to manipulate. I have a feeling sonic 3 and knuckles uses that kind of method to handle things easily, because of how well done most of the engines are there. Also, the red 3D test spheres overwrite the ring's colours and when they are gone, its all back to normal.

...

I am just sick of figuring how to code loops using the method the original uses, I thought that maybe a special object which changes Sonic's collision would work better.

Sub IDs:

Bit 0 - tells if vertical or horizontal
Bits 1-2 - tells the size (00 is 64, 01 is 128, 10 is 256, 11 is 512)
Bit 3 - tells what is the flag to set (changes bit 6 of sonic's status from clear/set respectivley)
Bit 4 - this one tells if the object should also draw sonic behind/above art.
Bits 5-7 all unused.

Now, when bit 6 of Sonic's bitfield is changed, Floor_ChkTile checks it and loads a completely different chunk, even though the graphics looks the same as always. The only thing that it loads is the collision.
What I had in mind is to create a special file with the alternate collisions for every chunk in each level. This offest is loaded into RAM and there is possibly a special alogrithm to locate the appropriate collision for each chunk.

What else I noticed, is that in SonEd2's sonic 1 mode, there is an unused byte with extra 4 bits to change, which could be used for the alternate collision. Downside is it wont store inside the zone mapping file (so I could possibly edit SonEd2 to actually do that, but I'll be raped if I do)

Each chunk has $10 coloumns of blocks times $10 rows of blocks times 2 for the details = $200 (1st byte is the draw direction, 2nd byte is for the collision) While the alogrithm could work with only a $10x$10 times 1 ($100) since it only needs 1 byte for the alternate collision.

It reads the size of the index and divides by $100 to get to the number of how much chunks it has.

AFAIK, d1 is the chunk number Sonic is standing on, when it comes to both Sonic_Loops AND Floor_Chktile.
d1 occupies $100 bytes somewhere in the alternate collision file and to locate it by multiplying $100 with d1 to get to the offest of alternate collision. I haven't thought of how to code it in ASM yet but I'm counting on it.

Comments on the theory would be welcome.

Edit: Grammar.