[TehKaker]

Hello.
I've been trying to implement act-transitions on mine hack, and for that reason, to avoid lags, I thought that I should require certain edits to the levels formats and such.
I thought on re-compressing the 16x16 blocks into "Kosinski" format, and porting the Kosinski's queuing method used in S3k.

This is how the calls are done on V_Int: http://pastebin.com/wxtL93cM
How the code is ported: http://pastebin.com/Qakzk9U7
How is used from the level's main loop:

		move.b	#8,($FFFFF62A).w
		bsr.w	Process_Kos_Queue
		bsr.w	DelayProgram

Due to the way the Work-RAM is distributed in my hack, I had to reassign certain RAM definitions.
The subroutine "Set_Kos_Bookmark" checks if from stack there's a pointer between Process_Kos_Queue_Main and Process_Kos_Queue_Done (perhaps to interrupt it?); more specifically at this location: $42 + SP. On mine's case, this pointer is done at $FDF4 from Work-RAM, and as SP is at $FDF8 during the call, I changed it to -$4 + SP.

By analyzing the code, I guess this decompression method is done to be interrupted by each V_Int, and be resumed on each next loop, in order to avoid lag.

What's the problem here? The interruption doesn't seem to happen, since the the whole kosinski files are being decompressed in a single time, thus freezing the game for some seconds.

Any thoughts about what causes this problem?
Thanks for your answers!

[flamewing]

The bookmark is set so that V-Int may interrupt the queue and stop it, allowing the game code to run on the next frame. In order to allow V-Int to happen, you need to move the code that sets V-Int routine to before the "Process_Kos_Queue" call.

Moreover, you do NOT want to mess with the location it checks -- $42 + SP -- unless you changed the stack depth at which it is checked. Changing that means that the bookmark will be checking the wrong address, and will not interrupt the queue function.