PLC how they work?

Hi there, I am having trouble figuring out PLC stuff.... I want to add the knuckles Signpost to sonic 2 plc index, like so

Code:

;---------------------------------------------------------------------------------------

; Pattern load queue

; End of level signpost

;---------------------------------------------------------------------------------------

PLC_3D: plrlistheader

plreq $8680, ArtNem_Knuckles_Signpost

PLC_3D_End

how would I call it? I have tried this....

Code:

moveq #$27,d0 ; <== PLC_1F  load sonic/tails sign post

	    cmpi.w  #$3,($FFFFFF72).w; Check if Player is Knuckles

bne.s   CheckLoadSignpostArt_cont ; if not knuckles jump to LOADPLC2

moveq    #$3D,d0; Knuckles Signpost (3D is the PLC ID)



CheckLoadSignpostArt_cont:	   

	    bra.w LoadPLC2  ; load signpost art

but It dosnt work and I have a feeling its becasue even though its PLC_3D the 3D dosnt relate to its Id?


Plese help I am confused !!!

[/CODE]

 

You'll need to show us the table at the "very beginning" of the PLC lists, the one that points to all PLC lists, i.e. in Sonic 1 Hivebrain 2005 I have:



; ---------------------------------------------------------------------------
; Pattern load cues - index


; ---------------------------------------------------------------------------


dc.w PLC_Main-ArtLoadCues, PLC_Main2-ArtLoadCues


dc.w PLC_Explode-ArtLoadCues, PLC_GameOver-ArtLoadCues


dc.w PLC_GHZ-ArtLoadCues, PLC_GHZ2-ArtLoadCues


dc.w PLC_LZ-ArtLoadCues, PLC_LZ2-ArtLoadCues


dc.w PLC_MZ-ArtLoadCues, PLC_MZ2-ArtLoadCues


dc.w PLC_SLZ-ArtLoadCues, PLC_SLZ2-ArtLoadCues


dc.w PLC_SYZ-ArtLoadCues, PLC_SYZ2-ArtLoadCues


dc.w PLC_SBZ-ArtLoadCues, PLC_SBZ2-ArtLoadCues


dc.w PLC_TitleCard-ArtLoadCues, PLC_Boss-ArtLoadCues


dc.w PLC_Signpost-ArtLoadCues, PLC_Warp-ArtLoadCues


dc.w PLC_SpeStage-ArtLoadCues, PLC_GHZAnimals-ArtLoadCues


dc.w PLC_LZAnimals-ArtLoadCues, PLC_MZAnimals-ArtLoadCues


dc.w PLC_SLZAnimals-ArtLoadCues, PLC_SYZAnimals-ArtLoadCues


dc.w PLC_SBZAnimals-ArtLoadCues, PLC_SpeStResult-ArtLoadCues


dc.w PLC_Ending-ArtLoadCues, PLC_TryAgain-ArtLoadCues


dc.w PLC_EggmanSBZ2-ArtLoadCues, PLC_FZBoss-ArtLoadCues


; ---------------------------------------------------------------------------



By being able to see the main table, we can count down and work out exactly what ID your knuckles signpost PLC is.

 

From what I see in S2's disassembly, there are 66 PLCs in the original PLC index of S2, that's 42 in hex, so that 3D is most likely wrong.


By the way, it looks like you could replace bne.s CheckLoadSignpostArt_cont with bne.w LoadPLC2. Not like it matters much though, it could even make it more annoying if you later have to change the bra.w with a jmp.

 

ok guys I figured it out now but hae another PLC related question...

Code:

;---------------------------------------------------------------------------------------

; Pattern load queue

; End of level signpost

;---------------------------------------------------------------------------------------

PLC_3D: plrlistheader

plreq $8680, ArtNem_Knuckles_Signpost

PLC_3D_End ; ID =45 :)

but how does a PLC with multiple entries work? for example....

Code:

PLC_3A: plrlistheader

plreq $B000, ArtNem_TitleCard

plreq $B600, ArtNem_ResultsText

plreq $BE80, ArtNem_MiniTails

plreq $A800, ArtNem_Perfect

PLC_3A_End

[/CODE]

 

Each PLC list usually contains several entries, for example, the list you shared above:

Code:

plreq $B000, ArtNem_TitleCard

plreq $B600, ArtNem_ResultsText

plreq $BE80, ArtNem_MiniTails

plreq $A800, ArtNem_Perfect

As you can see there are 4 entries, each entry (starting from the top) gets decompressed in sections, during the VDP's display phase, the 68k will decompress a small section of it, and then during the vertical blanking interval when the VDP is no longer busy, the decompressed data gets flushed off to the V-Ram address (the $???? value) specified, and continues in that loop of decompressing, then flushing, once it has finished processing the entry, it moves onto the next one and repeats this process.


The reason for doing it this way rather than loading all of the data directly to begin with is due to the "loading time", decompressing nearly a whole V-Ram space worth of art is going to take quite a while, nothing major but it will be something the player may notice on start up of a game, or even during the game when new graphics need to be loaded (like during a boss loading area), so the data is decompressed in smaller sections each frame, it will take "longer" to decompress the art in total, but the game will not be required to hult and wait for the art to load, it may continue while going through the decompression process.

[/CODE]

 

ahhh most enlightening as alway MarkeyJ... I am having a lot of fun with this stuff at the moment Thank you for the help.