Dev tools: MAPeD-SPReD (win/linux)

[0x8bitdev]

May 25, 2022 13:03:45 GMT hyperfighting said:

Last few days have been awful. Slowdown and replicating in a test project proved to be frustrating and uneventful.

As per usual it was user error. It is very important that new users of MAPeD place MAPeD calls in the right area's of their loop or else you become me two days ago (frustrated and lost).
I can not take any credit for what I am showing here but I can say my slowdown issues are gone and if you are following this thread and adjusting your project please ensure the MAPeD calls are respectively located at the top and bottom of your loop!

Fighting with yourself is a programmer job. Winner gets everything! 

[hyperfighting]

0x8bitdev someone told me to remove all the junk vsync(); / Scroll code lingering in the project. 

In the case of "TOY-OTA" when he stomps his feet the screen shakes vertically. My question is if you have a 1 screen MAP aka the giant star backdrop how can you make it shake?
In my experience so far MAPeD does not let you surpass a Maps boundaries. All I can think of is using 3 screens... A starfield on top, Giant Star in the middle, Star Field on the bottom.
I figured I would ask opposed to potentially using 3 screens to get the job done.
The code below just shows where I am trying to remove Huc's scroll code but ultimately I am curious if there is a trick to wrap a MAPeD Map vertically if that makes any sense?



if (TaskManager(SINGLE_TASK)==ON)
{
if ((Enemy[0].frameIndex[Enemy[0].frame]==1) && (Enemy[0].spriteChunkFlag==4))
{
scriptActionFlag[1]=1;
}

if (scriptActionFlag[1]==1)
{
if (scriptActionFlag[0]==0)
{
scriptActionFlag[0]=1;
meta[1].y+=2;
mpd_move_down();
//scroll(0, mpd_scroll_x(), scroll_y1+=2,  0, 248,   0xC0);
//vsync();
}
else if (scriptActionFlag[0]==1)
{
scriptActionFlag[0]=2;
if (waitCounter[0]!=10)
{
++waitCounter[0];
scriptActionFlag[0]=0;
}
meta[1].y-=2;
mpd_move_up();
//scroll(0, mpd_scroll_x(), scroll_y1-=2,  0, 248,   0xC0);
//vsync();
}
else if ((waitCounter[0]==10) && (scriptActionFlag[0]==2))
{
scriptActionFlag[0]=0;
scriptActionFlag[1]=0;
waitCounter[0]=0;
scriptKey[KeyValue]=FINISH;
}
}
}

[0x8bitdev]

May 25, 2022 13:54:00 GMT hyperfighting said:

0x8bitdev someone told me to remove all the junk vsync(); / Scroll code lingering in the project. 

I just insist on it and for a long time. But your enduring love for them does not allow you to do this.

May 25, 2022 13:54:00 GMT hyperfighting said:

In the case of "TOY-OTA" when he stomps his feet the screen shakes vertically. My question is if you have a 1 screen MAP aka the giant star backdrop how can you make it shake?
In my experience so far MAPeD does not let you surpass a Maps boundaries. All I can think of is using 3 screens... A starfield on top, Giant Star in the middle, Star Field on the bottom.
I figured I would ask opposed to potentially using 3 screens to get the job done.
The code below just shows where I am trying to remove Huc's scroll code but ultimately I am curious if there is a trick to wrap a MAPeD Map vertically if that makes any sense?

Don't complicate, use the screen you have. You can make the shake the same way you apply scroll values:

pokew( 0x2210, your_vertical_scroll_value_for_shaking );
vsync();

But don't forget to reset the value to zero after shaking!

[hyperfighting]

0x8bitdev Well as per usual thanks again! Screen Shake is working great!

I set my render method to 
trig.render=VSYNC_ONLY;//So at the bottom of the loop we only do vsync(); -- No MAPeD "mpd_update_screen(); + poke"
During Attract I do this += / -= respectively

pokew( 0x2210, scroll_y1+=2);  
The "TOY-OTA" sequence ends or the user does a quick out by pushing run I ensure to do this.

pokew( 0x220c, 0 ); //reset bgx1
pokew( 0x2210, 0 ); //reset bgy1


[hyperfighting]

So I have been working on "Quick Outs" and I am perplexed ATM.
EX: Quickly Jump out of Attract "Done"
EX: Quickly Jump out of StarFall "Done"
EX: Quickly Jump to another position in the LEVEL intro   

I used your export .png and marked it up! 

By my calculation 286 Y is where the guide is and the marching ant's show the screen I am aiming to display.



For some reason the image I am seeing in the program, displays the sky gradient. (Above where I am aiming)
I know I am likely about to get scolded for missing an obvious detail but I am confused at this point.

My test program looks like this...
Note: I now add a DISP_ON_OFF flag in all my MAPeD functions this is helpful for when I am jumping Screens/Maps and also hiding sprites using the call of "disp_off" and re-enabling "disp_on();vsync();" when all sprites are hidden/loaded in the appropriate position. This is beside the question but I'm just mentioning I find this flag useful.

Test Project -> POS JUMP

void SWITCH_MAP_TO_POS( u8 _map_ind, u16 _x, u16 _y, char DISP_ON_OFF )
{
   disp_off();
   vsync();
   mpd_init(_map_ind, 1);
   mpd_draw_screen_by_pos( _x, _y);
   if (DISP_ON_OFF==1)
   {
disp_on();
vsync();
    }
}

main()
{
char RENDER=1;
//320x224 resolution
vreg( 10, 0x0502 );
vreg( 11, 0x0427 );
poke( 0x0400, 0x01 );

SWITCH_MAP_TO_POS( 2, 0, 286, 1 );

/*  demo main loop */
for (;;)
{
//It is Important that this call is at the top of the code  
mpd_clear_update_flags();

//It is Important that this block is at the bottom of the code
switch (RENDER)
{
case 0://No Scroll
vsync();
break;

case 1:
mpd_update_screen();
pokew( 0x220c, mpd_scroll_x() );
pokew( 0x2210, mpd_scroll_y() );
vsync();
break;
}
}
}

[0x8bitdev]

hyperfighting It's a bug. I'll fix it.

[0x8bitdev]

Fixed! The changes in the dev build.
I've removed the 'mpd_draw_screen_by_pos_offs' function as unsafe and useless.

Check the whole project with the latest library.

[hyperfighting]

0x8bitdev This is amazing! Thanks for getting the update out! I'll plug it in right away and report back!

I am just about ready to make the "final" video and get your thoughts.

Beside the position jump. I have one final outstanding issue I am hoping to get your thoughts on.

It's our boy "TOY-OTA" he's up to no good.

So the screen shake works perfectly the way you described it.
However on the second cycle of the attract mode the screen shake reveals "Blue" likely the "Blue" from the sky in the title screen.

I attempt to reset scroll values but that doesn't seem to help.

pokew( 0x220c, mpd_scroll_x() );

pokew( 0x2210, mpd_scroll_y() );
I believe this is due to:

A: The first "Attract" sequence is launched after title times out. (No scrolling has happened)
B: The second "Attract" sequence is launched after the player select cycles and the zuks are killed by the bonebat. (Scrolling has happened...so I am guessing their must be "Blue" BAT data loaded below the screen?)

[0x8bitdev]

I don't quite understand... On the second cycle of the attract mode the screen with TOY-OTA displays, but once shaking starts, you see the blue screen? or blue lines at the bottom/top of the screen?

[hyperfighting]

0x8bitdev Blue lines at the bottom only on shake. Only on the second cycle if you let game loop through its scrolling segments.

[0x8bitdev]

May 27, 2022 14:40:32 GMT hyperfighting said:

0x8bitdev Blue lines at the bottom only on shake. Only on the second cycle if you let game loop through its scrolling segments.

Just fill the bottom line (28 !) with a black CHR using 'mpd_draw_CHR'.

[hyperfighting]

Happy Friday!

Here is the current state of affairs.

- 256x224 Prototype upgraded to 320x224
- The project now uses MAPeD to handle all Mapping.
- All Sprite Positioning has been corrected.
- Several redundant/unnecessary functions were removed.
- Zuks! Title Map is optimized (Large Full Colour Logo is removed to save space)
- Star Fall adjusted to accommodate live "Zuks! Title sprites" during the sequence (Too many horizontal sprites is the challenge in this case)
(Title Star Fall may be kinda weak but it can be tweaked later on)
A keen eye will notice clipping when all the stars line up but I don't believe it to be the case when the stars are converted to 16x16 SPReD sprites!  
- Title Text is converted from Sprites to CHR Data stored in the MAP GFX. 
- Fall Blocks uses MAPeD function calls to get around the (Horizontal Line Limit!)
- Care was given to ensure jumps had no garbage 1 frame of data.
EX: Background appearing 1 frame before sprites.
EX: Sprites hide 1 frame before background.
EX: One frame of garbage due to reallocation of sprite memory addresses
- Clean Outs with "Run"
EX: Cancel Demo
EX: Cancel Star Fall to Player Select
EX: Expedite Parents speaking to Zuks
EX: Jump screen position during level Intro
EX: Cancel Level intro to World 1

The video uses the new MAPeD build released earlier today.



0x8bitdev as always huge thanks for this incredible toolset and for all the help along the way!  
The question now is do we shift gears? Take the blue pill or the red pill?
 

[0x8bitdev]

I've noticed two moments that break the smoothness of the action:

- 00:47-00:48 - the stars twitch a bit before the screen scrolls down
- 02:46 - weird scroll up; it's may be due to lags during recording the video

May 27, 2022 15:17:14 GMT hyperfighting said:

0x8bitdev as always huge thanks for this incredible toolset and for all the help along the way!  
The question now is do we shift gears? Take the blue pill or the red pill?
 

Also thanks! You also help me improve the tools/libs.

The blue pill or the red pill? It's all up to you. 

[hyperfighting]

0x8bitdev regarding "TOY-OTA" he is fixed on the second attract cycle now.

I used this during "disp_off();"

for (waitCounter[0]=0;waitCounter[0]<=39;++waitCounter[0])
{
  mpd_draw_CHR( CHRpos, 224, 0X01, 0x00);
  CHRpos+=8;
}

0x8bitdev Also thanks! You also help me improve the tools/libs.

I am so happy I can at least be of some use  

0x8bitdev
- 00:47-00:48 - the stars twitch a bit before the screen scrolls down

You have a very keen eye this is where we see clipping (I think will be resolved when sprites are 16x16) but I also adjust the Y pos when they line up! You must have caught this adjustment! I need to remove it. Thanks for pointing it out. It has to do with when they land on the ground but it's a hack at best you caught me!

0x8bitdev
- 02:46 - weird scroll up; it's may be due to lags during recording the video

Luckily this is a video issue. The Mountain jitters but it doesn't show well.
Same with "TOY-OTA" some of his screen shake is absent in the video.

-------------------------------------------
Am I feeling SPReD? in the air!?

1. If so do you think the Zuks are the best sprite to tackle?
2. Regarding Zuks the .pcx files I have are "twidled" or something I think it's done with the .pcx tool but I can't figure out how to make them readable?
Early on you mention some methods I tried but no dice.

Encrypted Zuks -> Zuks PCX Graphics

If anyone knows how to restore these GFX back to a readable format that would be greatly appreciated. If not I'll start from the drawing board.

3. I have to re-read the SPReD Docs and experiment but from what I gather you need LEFT/RIGHT duplicates...This is curious to me because in HUC "spr_ctrl(FLIP_MAS,P1[0].flipState);" but I guess due to the way you place the x,y its is necessary.

4. I really see the value of SPReD because my frame sizes are 32x32 but in most cases my frames should be a META sprite (16x16 + 16x32) which eliminates a whole tile!
Regarding animations all the .pcx images have the Zuks centered in a 32x32 frame. This is very handy for animating the Zuks because they always have the same center point. 
- Will SPReD be able to load my 32x32 GFX and eliminate the transparency. Basically can SPReD take a 32x32 sprite and optimize it to be (16x16+16x32) by factoring out the transparency?
 OR
- Will all 32x32 sprites need to be tightly aligned to the left/bottom corner so SPReD can cleanly eliminate the unused 16x16 transparent tile?

In either case it needs to be done. In the case by some stroke of major luck SPReD can optimize my 32x32 frames then I will be in luck for minimal work aligning my animations.

Here is a picture depicting what I am referring to:

  

[upd] I am seeing the documentation clearly describes this very import question.

[upd] regarding the .pcx files I can't access...

I am confident I did this script to them and I can reverse it but I likely did "-pcepal : truncate palette to 3-bits (ie. $00,$20,...,$E0)" or something not quite sure still having issues restoring them back.

pcxtool -swap $F0 $00 NewGraphic.pcx NewGraphic1.pcx
pcxtool -swap $F1 $01 NewGraphic1.pcx NewGraphic2.pcx
pcxtool -swap $F2 $02 NewGraphic2.pcx NewGraphic3.pcx
pcxtool -swap $F3 $03 NewGraphic3.pcx NewGraphic4.pcx
pcxtool -swap $F4 $04 NewGraphic4.pcx NewGraphic5.pcx
pcxtool -swap $F5 $05 NewGraphic5.pcx NewGraphic6.pcx
pcxtool -swap $F6 $06 NewGraphic6.pcx NewGraphic7.pcx
pcxtool -swap $F7 $07 NewGraphic7.pcx NewGraphic8.pcx
pcxtool -swap $F8 $08 NewGraphic8.pcx NewGraphic9.pcx
pcxtool -swap $F9 $09 NewGraphic9.pcx NewGraphic10.pcx
pcxtool -swap $FA $0A NewGraphic10.pcx NewGraphic11.pcx
pcxtool -swap $FB $0B NewGraphic11.pcx NewGraphic12.pcx
pcxtool -swap $FC $0C NewGraphic12.pcx NewGraphic13.pcx
pcxtool -swap $FD $0D NewGraphic13.pcx NewGraphic14.pcx
pcxtool -swap $FE $0E NewGraphic14.pcx NewGraphic15.pcx
pcxtool -swap $FF $0F NewGraphic15.pcx PceFormattedGraphic.pcx

[gredler]

What are you trying to open the pcx in? Some of the low bit rate index pcx files become incompatible with modern packages but photoshop cc and gimp should open any pcx without issue