Dev tools: MAPeD-SPReD (win/linux)

[hyperfighting]

Test Project -> BAD SCROLL

0x8bitdev  please let me know if you can download the test project above.

The first scene demonstrates your new method for "clean scrolling"

The second scene demonstrates HUC's multi scrollable windows.

Upon the first loop back to scene 1 from scene 2 we see the "clean scrolling" breaks. 

I'm not sure how to get around this?

[upd] A little video to aid the description above

[0x8bitdev]

You just need to disable HuC's scroll windows after the 'star field' effect.
Use the following code for that:

scroll_disable( 0 );
scroll_disable( 1 );
scroll_disable( 2 );
scroll_disable( 3 );
scroll_disable( 4 );
scroll_disable( 5 );
scroll_disable( 6 );

A few notes on your code:

1. The 'LAYOUT_WORLD_1()' function you recently posted here. Why don't you use a map switching to a start screen marked in MAPeD ? But instead you are using a screen index... When you will expand your game level, you will change the screen index in your project and rebuild it? Write data-driven code and don't complicate your life.

2. Map/screen switching code is everywhere... Don't duplicate code that does the same job! Just be lazy, don't write the same code twice! 
You need to implement several functions for map/screen switching and use them everywhere!

    For example, you need the following functions:

// switching to a new map
void SWITCH_MAP_TO_START_SCR( u8 _map_ind );
void SWITCH_MAP_TO_SCR( u8 _map_ind, u8 _scr_ind );
void SWITCH_MAP_TO_POS( u8 _map_ind, u16 _x, u16 _y );    <-- this function you will use to restore a game map after the pit one

// switching within a current map
void SWITCH_TO_SCR( u8 _scr_ind );

the body of these functions:
{
disp_off();
       vsync();

       // map/screen switching code
//...

       disp_on();
       vsync();
}
    Save memory and your time, when you'll find bugs or make changes. It's better when there is a one place to find bugs or make changes than... you don't even know how many...

void LAYOUT_WORLD_1()
{
disp_off();
vsync();

mpd_init(map_ind=3, 1); // map_ind=3 <-- This piece of .hit doesn't allow you to write a compact minimalistic code!
mpd_draw_screen_by_ind(2); // .._ind(2) <-- And this too!

disp_on();
vsync();
}
    Do you feel the chaos in these lines? I do! 

[hyperfighting]

0x8bitdev Thanks for getting me on the right track!

My MAPeD function list now looks like this and all chaotic old instances have been replaced.

void border_white()
{
pokew( 0x0402, 0x0100 );
pokew( 0x0404, 511 );
}
void border_black()
{
pokew( 0x0402, 0x0100 );
pokew( 0x0404, 0 );
}
void SWITCH_MAP_TO_START_SCR( u8 _map_ind )
{
   disp_off();
   vsync();
   mpd_init(_map_ind, 1);
   mpd_draw_screen();
   disp_on();
   vsync();
}
void SWITCH_MAP_TO_SCR( u8 _map_ind, u8 _scr_ind )
{
   disp_off();
   vsync();
   mpd_init(_map_ind, 1);
   mpd_draw_screen_by_ind(_scr_ind);
   mpd_draw_screen();
   disp_on();
   vsync();
}
void SWITCH_MAP_TO_POS( u8 _map_ind, u16 _x, u16 _y )
{
   disp_off();
   vsync();
   mpd_init(_map_ind, 1);
   mpd_draw_screen_by_pos( _x, _y);
   disp_on();
   vsync();
}
//THIS IS A WEIRD ONE I NEED TO RETURN TO THE TITLE SCREEN AND LARGE ATTTRACT STAR
//THE ISSUE IS LIKELY DUE TO 320x224 RES
//WITHOUT THIS FUNCTION THE MAP WAS OFF CENTER (256x224) STYLE...THERE WAS A VISIBLE "SNAP" INTO PLACE SO I HID THE "SNAP"
void SWITCH_MAP_TO_START_SCR_RECENTER(u8 _map_ind)
{
   disp_off();
   vsync();
   mpd_init(_map_ind, 1);
   mpd_draw_screen();
   mpd_update_screen();
   pokew( 0x220c, mpd_scroll_x() );
   pokew( 0x2210, mpd_scroll_y() );
   disp_on();
   vsync();
}
//USED FOR THE "STAR FIELD" IT APPEARED "OFF" SO INCLUDED THE "mpd_draw_screen_by_ind_offs( _scr_ind, 23, FALSE );"
void SWITCH_MAP_TO_SCR_COPY_SCR( u8 _map_ind, u8 _scr_ind )
{
   disp_off();
   vsync();
   mpd_init(_map_ind, 1);
   mpd_draw_screen_by_ind(_scr_ind);
   mpd_draw_screen_by_ind_offs( _scr_ind, 23, FALSE );// I believe due to 320x224 res I am not copying the whole screen but the sequence is so brief this seems to get the job done.
   disp_on();
   vsync();
}
//HERE I AM DISABLING HUC'S SCROLL
//WITHOUT "disp_off();" there is one frame of pause.
//I rely on the next map loaded to trigger "disp_on();"
void disable_HUC_scroll (char win_total)
{
char win=0;
disp_off();
vsync();
for (;win<=win_total;++win)
{
scroll_disable(win);
}
}
Things are on the up and up! The next phase which is a WIP is the star fall and adjusting the routines to accommodate a shorter MAP HEIGHT and TRANSLATING LOGO GFX as the screen scrolls!
Currently the base project only has these two calls for scrolling and static screens.

switch (map.render)
{
case VSYNC_ONLY: //No Scroll
vsync();
break;

case MAPED_SCROLL:
mpd_update_screen();
pokew( 0x220c, mpd_scroll_x() );
pokew( 0x2210, mpd_scroll_y() );
vsync();
break;
}
Next post will be the new "Star Fall" sequence tied into the rest of the project etc.

[0x8bitdev]

Small corrections:

void SWITCH_MAP_TO_SCR( u8 _map_ind, u8 _scr_ind )
{
   disp_off();
   vsync();
   mpd_init(_map_ind, 1);
   mpd_draw_screen_by_ind(_scr_ind);
   mpd_draw_screen(); <-- ??? screen already has been drawn by the previous function, try to remove this
   disp_on();
   vsync();
}

//THIS IS A WEIRD ONE I NEED TO RETURN TO THE TITLE SCREEN AND LARGE ATTTRACT STAR
//THE ISSUE IS LIKELY DUE TO 320x224 RES
//WITHOUT THIS FUNCTION THE MAP WAS OFF CENTER (256x224) STYLE...THERE WAS A VISIBLE "SNAP" INTO PLACE SO I HID THE "SNAP"
void SWITCH_MAP_TO_START_SCR_RECENTER(u8 _map_ind)
{
   disp_off();
   vsync();
   mpd_init(_map_ind, 1);
   mpd_draw_screen();
   mpd_update_screen(); <-- this
   pokew( 0x220c, mpd_scroll_x() ); <-- is a
   pokew( 0x2210, mpd_scroll_y() ); <-- really weird... :( something is wrong here!
   disp_on();
   vsync();
}

The project screen resolution is 320x224, the map resolution is 320x224 too and the map's screen doesn't fit perfectly on the screen?   Looks like a bug.

[hyperfighting]

0x8bitdev - Thanks for reviewing the codez!

I made the adjustment and a little test program with some updated functions.

Test Project -> BAD OFFSET

I have a damn Tornado warning so I might be out until tomorrow hopefully nothing major!

Its a very quick one frame pop when the star field shifts back to the big star.....

[0x8bitdev]

The issue is that disabling HuC's scroll windows by calling the 'scroll_disable()' isn't enough. The scroll windows are disabled, but... a scroll value is stored in the system variable bgx1. And this value is applied on the next 'vsync'. So you need to reset the bgx1 manually to avoid one-screen shifted image. Add - 'pokew( 0x220c, 0 );' to the end of the 'disable_HUC_scroll' function.

void disable_HUC_scroll (char win_total)
{
char win=0;
disp_off();
vsync();

for (;win<=win_total;++win)
{
scroll_disable(win);
}

pokew( 0x220c, 0 ); <--- !!! reset bgx1
pokew( 0x2210, 0 ); <--- reset bgy1, just in case :)
}

Remove the 'SWITCH_MAP_TO_START_SCR_RECENTER' function and use the 'SWITCH_MAP_TO_START_SCR' instead.

May 21, 2022 17:46:58 GMT hyperfighting said:

I have a damn Tornado warning so I might be out until tomorrow hopefully nothing major!

I hope you are well.

[hyperfighting]

0x8bitdev Thanks very much for straightening out the OFFSET! I have updated the "void disable_HUC_scroll (char win_total)" and removed "SWITCH_MAP_TO_START_SCR_RECENTER" function!

I have stumbled upon another OFFSET Issue when jumping screens.
The project below inserts a bad frame upon jumping to a screen within a map.
My use case is I have quick outs so the user can skip various scenes.

EX:

User presses run during the ATTRACT -> Warp to "TITLE SCREEN" map
User presses run during the STAR FALL -> Warp to "PLAYER SELECT SCR IN THE SAME MAP" map

Test Project ->BAD SCREEN SWITCH


In addition I am curious if there is a clean way to delete sprites loaded into memory?
I am currently refactoring the code based on the new MAP HEIGHT and I have a common slow down occurring only after a particular scene is loaded.

Currently I am using Hide codes when I am entering a new scene such as hiding the "word bubble" and "Zupapa" and "Zupipi" but I believe they are still taking processing power in that they are still loaded into VRAM
I have also tried reset_satb(); but regardless of what I try if I allow  the PARENTS and WORD BUBBLE to load the next time I scroll the screen I get slow down. I know I am not updating their X,Y co-ordinates after they are hidden so I don't believe this is a case I have code that is purposely updating the sprites after they have been hidden. 

Before I whip up a sample program my question is...is hiding the best way to "delete" sprites? 

void Hide_Zupapa_Zumama()

{
spr_hide(Zupapa);
spr_hide(Zumama);
}

void HideWordBubble()

{
spr_hide(TopLeftBubble);
spr_hide(BottomLeftBubble);
spr_hide(TopRightBubble);
spr_hide(BottomRightBubble);
spr_hide(TopBubble);
spr_hide(BottomBubble);
spr_hide(LeftBubble);
spr_hide(RightBubble);
spr_hide(VoiceSourceRight);
spr_hide(VoiceSourceLeft);
spr_hide(TopBubble1);
spr_hide(TopBubble2);
spr_hide(TopBubble3);
spr_hide(TopBubble4);
spr_hide(TopBubble5);
spr_hide(TopBubble6);
spr_hide(TopBubble7);
spr_hide(TopBubble8);
spr_hide(TopBubble9);
spr_hide(TopBubble10);
spr_hide(TopBubble11);
spr_hide(TopBubble12);

spr_hide(BottomBubble1);
spr_hide(BottomBubble2);
spr_hide(BottomBubble3);
spr_hide(BottomBubble4);
spr_hide(BottomBubble5);
spr_hide(BottomBubble6);
spr_hide(BottomBubble7);
spr_hide(BottomBubble8);
spr_hide(BottomBubble9);
spr_hide(BottomBubble10);
spr_hide(BottomBubble11);
spr_hide(BottomBubble12);
}
Thanks very much for checking in regarding yesterday...I was a bit freaked out. It isn't often my cell and televison send emergency warnings of high winds, hail and threat of tornado.
I was very fortunate in my location. However falling trees caused some damage and sadly three fatalities were reported.

[0x8bitdev]

To fix the offset issue with the 'SWITCH_MAP_TO_SCR' you need update scroll values. Why? 

The 'mpd_draw_screen_by_ind' function changes scroll values, so that you could make scrolling from any screen in multi-dir map. Once again, you can jump to any screen in multi-dir map and continue scrolling.
So the final code will look like:

void SWITCH_MAP_TO_SCR( u8 _map_ind, u8 _scr_ind )
{
disp_off();
  vsync();
mpd_init(_map_ind, 1);
mpd_draw_screen_by_ind(_scr_ind);

// scroll values have been changed and now we need update them to be able to scroll from this screen
pokew( 0x220c, mpd_scroll_x() );
pokew( 0x2210, mpd_scroll_y() );

disp_on();
vsync();
}


But there is another option. You can use the 'mpd_draw_screen_by_ind_offs' function like this:
    
    mpd_draw_screen_by_ind_offs( _scr_ind, 0, TRUE ); <-- TRUE - reset scroll values to zero

This also works and without 'pokew( 0x220c, mpd_scroll_x() ); pokew( 0x2210, mpd_scroll_y() );'. But this doesn't guarantee scrolling from drawn screen.

May 22, 2022 15:24:51 GMT hyperfighting said:

In addition I am curious if there is a clean way to delete sprites loaded into memory?
I am currently refactoring the code based on the new MAP HEIGHT and I have a common slow down occurring only after a particular scene is loaded.

Currently I am using Hide codes when I am entering a new scene such as hiding the "word bubble" and "Zupapa" and "Zupipi" but I believe they are still taking processing power in that they are still loaded into VRAM
I have also tried reset_satb(); but regardless of what I try if I allow  the PARENTS and WORD BUBBLE to load the next time I scroll the screen I get slow down. I know I am not updating their X,Y co-ordinates after they are hidden so I don't believe this is a case I have code that is purposely updating the sprites after they have been hidden. 

Before I whip up a sample program my question is...is hiding the best way to "delete" sprites? 

Once, sprites drawing is enabled, the VDC processes all data in the inner SATB, all 64 sprites. And it works without drop down FPS.

The 'spr_hide' just hides a sprite out of the screen. It's usefull when you need to reuse your sprites. For example, when you make sprites cache.

But you can use 'spr_hide' for your purposes. If you want to be sure that VDC is not trying to draw sprites, you can try: reset_satb() + update_satb(64). This fills whole SATB with zeros and respectively resets SPBG bit for each sprite (0-draw background, 1-draw sprite).

What is the reason of slow down in your case...? I don't know. Try to simplify the program as much as possible and reproduce the slow down in a test project.

[hyperfighting]

0x8bitdev many thanks for the updated scroll values and the info on sprites!

I have been battling with the "slow down" issue I described and I don't believe it is sprites.

I can eliminate my slow down if I do this....

SWITCH_MAP_TO_START_SCR(0); //SWITCH TO A RANDOM MAP
SWITCH_MAP_TO_SCR( 2, 3 ); //SWITCH BACK TO THE MAP I WANT
The two functions I'm using are:

void SWITCH_MAP_TO_START_SCR( u8 _map_ind )
{
   disp_off();
   vsync();
   mpd_init(_map_ind, 1);
   mpd_draw_screen();
   disp_on();
   vsync();
}

void SWITCH_MAP_TO_SCR( u8 _map_ind, u8 _scr_ind )
{
   disp_off();
   vsync();
   mpd_init(_map_ind, 1);
   mpd_draw_screen_by_ind(_scr_ind);
   pokew( 0x220c, mpd_scroll_x() );
   pokew( 0x2210, mpd_scroll_y() );
   disp_on();
   vsync();
}
I am convinced there is something being reset when I briefly reset maps that clears up the slowdown issue....I will make two short videos to demonstrate...
In both cases the SLOWDOWN or Lack there of is on the way up... The only difference between these two videos is the first lacks "SWITCH_MAP_TO_START_SCR(0); //SWITCH TO A RANDOM MAP"
The scroll speed "UP" is the proper speed in the second video.

SLOWDOWN VIDEO (roughly 30 seconds in)



SLOWDOWN HACK VIDEO (again roughly 30 seconds in to see the proper scroll speed)
(When the Parents leave you will see the ficker of the maps swapping briefly roughly 22 seconds)


 

[0x8bitdev]

I don't see a test project. 

The speed of scrolling up and down in the first video is the same!

1. If you think that the problem in MPD library ( the MAPeD is an editor, and can't slow down a HuC program  ), it simplifies everything. Just reproduce a simple logic in a test project: switching to the main menu screen, scrolling down to the ground and then scrolling back up to the main menu screen. And we will see the same slow down. Isn't it?

2. The sprites by themselves can't slow down your program, but the way you work with the sprites can. Just try to look for the redundant 'vsync' in update loop that slows down your program.

[hyperfighting]

0x8bitdev I checked for redundant vsync's via searching my entire project and I can't seem to find any.

I know a test project is ideal but I'm having challenges recreating one and I'm time limited today. I will keep attempting to get one made.

I want to show you a couple more examples where the only line of code between the two examples is "SWITCH_MAP_TO_START_SCR(2);"

1. I use the quick out after I press run on the title screen to warp to player select.
2. Player select is modified so the bonebat kills the Zuks and the scroll up code is executed to cycle back to the tile screen. (scroll up is full speed in both cases)
3. Upon pushing run a second time we see major slowdown in the first video but in the second because I triggered "SWITCH_MAP_TO_START_SCR(2);" we have virtually no slowdown.

What I can say is the code that is bypassed when I push run at the start of the video calls mpd_scroll_y() 8x per cycle....this is bypassed though

The code that executes for scrolling up to the title.... calls mpd_scroll_y() 12x per cycle (I am using this function to check y coordinates to trigger various events.)

I am sorry if what I am showing is not useful I will try to do better. I feel these videos show much better than the previous 2 and it is very odd I can eliminate slowdown with the one line of code variant.

1. Slowdown on second Star Fall (roughly 32 seconds in)



2. No Slowdown on second Star Fall (roughly 32 seconds in) (roughly 25 seconds you can set the "disp_off/on" from the function call)

[0x8bitdev]

Scroll up is faster than scroll down on the same map... This is something new.  I need a test project... 

[hyperfighting]

I purposely change the scroll y.

On scroll down. I set the scroll to 1.
On scroll up the scroll is set to 2 because I'm trying to reset to the title screen quickly.

I will work at getting a test project going at the next opportunity. The main thing is the stars really show the slow down.

I wonder why re-initalizing the map solves it?

ATM the only other clue is that static screens are set to vsync only but of course scrolling uses your 'fast scroll' method.

I can also recreate the videos with a scroll speed of 1 for both up and down maybe the variation in scroll speed is the culprit.

[upd] I set scroll speed using this "mpd_scroll_step_y(2);"

[0x8bitdev]

May 23, 2022 13:51:37 GMT hyperfighting said:

I wonder why re-initalizing the map solves it?

I also wonder. 

May 23, 2022 13:51:37 GMT hyperfighting said:

I can also recreate the videos with a scroll speed of 1 for both up and down maybe the variation in scroll speed is the culprit.

[upd] I set scroll speed using this "mpd_scroll_step_y(2);"

I've just tested scroll down with 'mpd_scroll_step_y(1)' and scroll up with 'mpd_scroll_step_y(2)' in a sample project. It works...

[hyperfighting]

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!

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

//Load Map
SWITCH_MAP_TO_START_SCR(2);
mpd_draw_CHR( 266, 192, 0X02, 0x01);


       //INIT SPRITES
init_satb();

//Triggers  
trig.render=VSYNC_ONLY;
trig.mode=M_TITLE_SCREEN;
trig.subMode=TITLESCREEN_LOAD_GFX;
trig.scriptPhase=0;


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

switch (trig.mode)
{
case M_DEMO:
Demo();
break;

case M_TITLE_SCREEN:
TitleScreen();
break;

case M_PLAYER_SELECT:
PlayerSelect();
break;

case M_WORLD_1_INTRO:
LevelSelect();
break;

case M_WORLD_1: //<---This will have a unique infinite loop just for handling "GAMEPLAY"
World1();
break;

case M_BOSS_SELECT:
BossSelect();
break;
}
/*Animate Zuks!*/
if (pauseflag==OFF)
{
Zuk_State_Machine();
}

satb_update();

//It is Important that this block is at the bottom of the loop
switch (trig.render)
{
case VSYNC_ONLY: //No Scroll
vsync();
break;

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

}