PLCs, Objects, and an Invisible Sonic

Before I get chewed up and spit out, I'd like to mention that I've researched this extensively before posting but I just can't seem to find what I'm looking for... SonicRetro's Q&A thread is way too overflown to find anything and searching (whether it be here, SonicRetro, or Google) never seems to point me in the right direction.


Question: If I plan to use an object outside of it's native level (ie. a 'Coconuts' in DEZ) how would I go about getting the art to load correctly? in ASM (Sonic2 Xenowhirl 2007)? I mention PLC's in the Topic title 'cause I just know they'll play a part in all this.


Also: I've been getting either a shitty (shitty meaning garbled) or completely invisible Sonic after the EHZ's title card dissapear either at the start of an act or when reviving at a starpost, but once I start moving or his 'waiting' animation starts, everythings fine... I'd be glad to post more info on this for anyone willing to help me tackle this.


Thanks in advance and I'm sorry if these questions are endlessly annoying or don't warrant a dedicated topic... Double sorry if the answers were right under my nose

 

Well I don't use sonic 2 that much, I use sonic 1. But i'm sure they are simular. If i'm not mistaken, enemies are indeed loaded in the "Pattern Load Cues" (PLCs). Some things are loaded specifically for that level, like coconuts for EHZ. Enemies art use vram locations which are needed so that art can be loaded to that location if its free. So, lets say Coconuts has a vram location of "9000" in the plc. So what we want to do is find the DEZ list of the PLC and then see what enemies are loaded/art is loaded and see if "9000" is free for that level. If not, the idea is to find a free vram location you can use. And then do something like this:



PLC_GHZ: dc.w $B
dc.l Nem_GHZ2


dc.w 0 ; GHZ secondary patterns


dc.l Nem_Stalk; flower stalk


dc.w $6B00


dc.l Nem_PplRock; purple rock


dc.w $7A00


dc.l Nem_Crabmeat; crabmeat enemy


dc.w $8000


dc.l Nem_Buzz; buzz bomber enemy


dc.w $8880


dc.l Nem_Coconuts; new enemy


dc.w $F400



dc.l Nem_Coconuts; new enemy


dc.w $F400


Now of course its not exact because this is Sonic 1, and Coconuts isn't in the game, but this is an example. dc.w $F400 is the free vram location, tend to be used to fix the lamppost problem with the spindash guide. Also at the top we have "dc.w $B" and this is the amount that is to be loaded for that level. There are 11 here, but in asm its refered as $B. So if you have $A amount of items, when you add the new item to the list you have to update the amount is loaded.


Not only that, you will need to add a compare to load the object art location for ehz. If say an enemy is to be loaded in 3 levels but have to have 3 different art locations, there will be compares to check what level is to branch to the right code. So you will most likely need to add a check in sonic2.asm where the coconuts object is being loaded, so that you can check if its DEZ and load the art there instead of EHZ with out affecting EHZ.


As for your invisible problem, it could a mappings problem, an art problem. We need a bit more info, the only I can say is check the sonic file using sonMAPED.


I hope this helped a bit, I'll read up on how it's done in Sonic 2, to try and make it easier with examples from the game and get some more example codes.

 

Thanks for the help... I understand everything you've and nothing got lost in translation between s1 and s2.... BUT:


So far: -I found the pattern load 'requests' (same as PLC's right?) for EHZ.


-Grabbed the 'Coconut's data and put it in the DEZ PLC list.


-Gave it a fresh vram location ($6600 to be exact)


I test the rom to make sure everything is in tact but that monkey is a total son-of-a-glitch when in DEZ... this is to be expected because I left out the most important step:

While this makes complete sense to me, I'm not exactly sure where to add the check. I know a few objects that play different roles in different levels, so I'll study them in the asm and until something clicks.

 

^ I'm not sure if I'm reading your problem correctly, but it sounds to me like you just need to conditionally edit the value of the art_tile word in the Coconuts code. You can derive the proper value by dividing the hex VRAM location by hex 20 (so for you, $6600/$20 = $330). Note that in binary, the result of the division for any VRAM location will never take more than 11 bits to express: you can play with the most significant five bits of the art_tile value (i.e. stick a hex digit in front and/or add $800 to that $330) to tell the game other properties of the sprite, such as which palette line to use and whether to draw in front of or behind high plane level art.