Dev tools: MAPeD-SPReD (win/linux)

[elmer]

May 11, 2022 16:36:04 GMT 0x8bitdev said:

I've found a conflict with using the VDC's scroll registers directly ( vreg( 7, ... ) and HuC which tried to set its scroll values each time. As a result, sometimes, when you skip the MPD's update, you may see jumping image. I hope this issue can be solved through the HuC's 'scroll' function.

Are you talking about the split-screen stuff, i.e. scroll(), or just the regular vblank processing which sets the X and Y scroll from bgx1 and bgy1 ... which is standard behavior on the PCE coming from the System Card.

Either way ... yes, MagicKit's "scroll" library code is baked into HuC, and startup.asm, and it's not easy to replace. Ignoring it and using vreg() to set the scroll is definitely a path that is likely to cause some problems for your users.

[0x8bitdev]

May 11, 2022 17:18:17 GMT elmer said:

May 11, 2022 16:36:04 GMT 0x8bitdev said:

I've found a conflict with using the VDC's scroll registers directly ( vreg( 7, ... ) and HuC which tried to set its scroll values each time. As a result, sometimes, when you skip the MPD's update, you may see jumping image. I hope this issue can be solved through the HuC's 'scroll' function.

Are you talking about the split-screen stuff, i.e. scroll(), or just the regular vblank processing which sets the X and Y scroll from bgx1 and bgy1 ... which is standard behavior on the PCE coming from the System Card.

Either way ... yes, MagicKit's "scroll" library code is baked into HuC, and startup.asm, and it's not easy to replace. Ignoring it and using vreg() to set the scroll is definitely a path that is likely to cause some problems for your users.

When I was trying to make static screens switching with double buffering, I've found that something switches scroll position back to (0, 0) from (256, 0). I was setting a scroll position via 'vreg( 7, ... )' But when I use the 'scroll()' for the same purposes, everything works without glitches as it should be.

[upd]: What is the bgx1 and bgy1 ?

[elmer]

May 11, 2022 17:32:31 GMT 0x8bitdev said:

[upd]: What is the bgx1 and bgy1 ?

First of all ... whoops, I renamed them to bg_x1 and bg_y1, which will annoy some old PCE assembly-language developers!

They're the X and Y scroll variables that the CD-ROM System Card uses to set the VDC's X and Y scroll registers every VBLANK.

Since HuC is written to be compatible with the System Card's behavior, so that you can use it to develop CD games and well as HuCARD games, it follows the same conventions.


I recommend that you take a look at the BIOS Manual in the PCE documents to get some idea of the behavior that is being copied.

If you want to dig deeper, there is a disassembly of the System Card's small VBLANK and HBLANK IRQ handler in "huc\examples\asm\elmer\doc\syscard_irq1.txt"

Once you understand that, you will be in a position to look at HuC's similar-but-more-complicated interrupt handling in "huc\include\startup.asm"


<EDIT>

And then, after you've gone to all of the effort to get your library working properly with HuC ... you'll find that KickC setup that I'm using does NOT follow HuC's (IMHO incorrect) design-choice, and that the option of when/how to change the VDC's scroll registers is delivered back to the game developer (and the individual libraries that the game developer chooses to use).

[0x8bitdev]

elmer  Thanks! I'll let users decide, which method to use to set scroll values: HuC's 'scroll(...)' or direct writing to registers. Under certain conditions, writting directly to registers works well. And it's faster than using the HuC's scroll library.

[dshadoff]

This is a standard, "help the entry level developers" versus "give all the complexity to the experienced developers" design decision.
You can probably guess which one HuC was originally created for.

[0x8bitdev]

May 11, 2022 17:12:45 GMT 0x8bitdev said:

May 11, 2022 16:35:49 GMT hyperfighting said:

I see screen flicker on the screen swap in that basic test project. Do you think you can mitigate it?

Bugs like that have no place in the library!   No any jumping! I'll try to delegate the main 'scrolling job' to HuC.
Hmm... Flickering in a test project? (sniffing) Can I touch it? 

Sorry, if that wasn't clear... I meant, could you share the test project with that glitch, so that I could understand the problem. 

A common action plan, when you've found a bug/glitch:

1. Reproduce the problem in your test project. If you can't, and everything is Ok! in a test project -> most probably the problem in your main project.
2. Try to minimize a test project. Remove everything unnecessary, so that one problem remains. The less code the better!
3. Once you've reproduced the problem in a test project -> make a post with a video and share the test project.

Otherwise I can't say anything specific about your problem.

[hyperfighting]

I'm sorry for the confusion. What I was referring to is. If you fast forward to roughly 40 seconds in the prototype YouTube video.
You will see the jump to the full colour Zuks logo is pretty much seamless if you load the test program I made you will notice the screen jump has a noticeable delay.
Its coded so all you do is just press the down/up arrow to see the screen jump effect.

 link to test project




[upd] Side Note: As of yesterday I upgraded my HuC to Elmers latest build.

- As mentioned previously it appears the "scroll" commands have a negative effect on the MULTI map index. I am sure I can replicate and add to the project.



- I can say I have tested "Tileput()" (sorry if syntax is incorrect I don't have a proper reference ATM) and it doesn't seem to work as expected. I will get that in the test project as well. 

[0x8bitdev]

A new update for the tilemap library MPD v0.4

Changes:

1. Added support for free step scrolling (1-7 pixels per step). It can be used for inertial scrolling.

    Removed 'mpd_scroll_step' enum, now 'mpd_init( u8 _map_ind, u8 _step )' as scroll step value receives numbers 1-7 pix.
    Added 'mpd_scroll_step_x( u8 _step_pix )/mpd_scroll_step_y( u8 _step_pix )' for scrollable maps.

mpd_scroll_step_x( calced_positive_move_step );
mpd_move_left();

2. 'mpd_draw_screen_by_scr_ind' renamed to 'mpd_draw_screen_by_ind'.
'mpd_draw_screen_by_scr_data' renamed to 'mpd_draw_screen_by_data'.

3. Added 'mpd_draw_screen_by_ind_offs( u16 _scr_ind, u16 _BAT_offset, bool _reset_scroll )' and 'mpd_draw_screen_by_pos_offs( u16 _scr_ind, u16 _BAT_offset, bool _reset_scroll )' for multi-directional mode.
Added 'mpd_draw_screen_by_data_offs( mpd_SCREEN* _scr_data, u16 _BAT_offset )' for bi-directional maps.

This allows to draw screens at any place in BAT and can be used for various purposes:

    a. For double-buffered screen switching without black screen ( disp_off()/disp_on() ) within one map.
    Added a new sample that shows double-buffered screen switching for multi-directional maps: './samples/pce/tilemap_render/multidir_stat_scr_multimap'

    b. For custom scrolling between screens out of the tilemap library. The same technique as (a), but you can make your custom scrolling between screens.

    c. If your game map fits into any BAT size, you can fill the BAT with a map screens and make a map scrolling using the way described in point 4 (see below).
    It's faster than using the tilemap library for scrolling!
    So, the rule is as follows: if each of your game maps fits into BAT, DON'T USE the MPD library for scrolling! It doesn't make any sense! Use it for filling BAT with screens and getting a tile property!

4. Removed VDC's scroll registers update on 'mpd_init' and 'mpd_update_screen'.
'mpd_update_screen( bool _vsync )' changed to 'mpd_update_screen()'.

    Since v0.4 the library doesn`t interact with VDC`s scroll registers in any way! It just provides scroll values X/Y: mpd_scroll_x(), mpd_scroll_y().
    Thus, user must set scroll values in his program using these functions. This is for scrollable maps only!

    There are two ways:

    1. Fullscreen scrolling. Write directly to the bgx1(0x220c)/bgy1(0x2210) system variables:

for(;;)
{
...your code here...

// update VDC's scroll registers on VBLANK via bgx1/bgy1 variables
pokew( 0x220c, mpd_scroll_x() );
pokew( 0x2210, mpd_scroll_y() );
vsync();
}

    2. Area scrolling. If you need to combine a static HUD and the scrollable area for your map, you can do this using the HuC's scroll library - 'scroll(...)':

    NOTE: This will work for linear horizontal bi-directional maps!

// init map area
scroll( 0, 0, 0, 0, region_bottom, 0xC0 );
// init HUD area
scroll( 1, 0, region_bottom + 1, region_bottom + 1, scr_height - 1, 0x80 );

for(;;)
{
...your code here...

// scrollable region update
scroll( 0, mpd_scroll_x(), 0, 0, region_bottom, 0xC0 );
vsync();
}

    Thus, the main option is (1). But if you need to limit the scrollable area you need to use the (2) option.

    NOTE: To avoid conflicts, these options can not be used together. You must use either (1) or (2).

That's it!

P.S.: All the changes and updated samples you can find in the dev build archive.
-----------------------
hyperfighting now you can make the star field effect without glitches.

Code:
// draw the original screen
mpd_draw_screen_by_ind( screen_index );

// draw the same screen with an offset
mpd_draw_screen_by_ind_offs( screen_index, 23, FALSE );

This fills BAT area 64x28 with screen data and you'll have fullscreen inifinite looped star field.

Just in case... With the resolution 320x... you can't make double buffered screen switching with BAT 64x32. But with resolution 256x224 you can.

[hyperfighting]

KING DROOL!!!!!!!

[0x8bitdev]

May 12, 2022 11:38:08 GMT hyperfighting said:

KING DROOL!!!!!!!

Now you have a lot of work! 

[upd]: About the platform blocks we'll talk later...

[0x8bitdev]

May 12, 2022 11:14:29 GMT hyperfighting said:

You will see the jump to the full colour Zuks logo is pretty much seamless if you load the test program I made you will notice the screen jump has a noticeable delay.
Its coded so all you do is just press the down/up arrow to see the screen jump effect.

In your original project the 'Zuks!' logo is a sprite. Is it correct?

If yes, why did you decide to make it as a SCREEN 320x224?
Leave it as sprite and you'll have the same result as in original project.

Filling the screen area in BAT takes time. But setting coordinates to a sprite is incomparably faster!

[hyperfighting]

0x8bitdev

In your original project the 'Zuks!' logo is a sprite. Is it correct?



If yes, why did you decide to make it as a SCREEN 320x224?

Leave it as sprite and you'll have the same result as in original project.



Filling the screen area in BAT takes time. But setting coordinates to a sprite is incomparably faster!

Zuks Logo appears as Sprites in two places on the Title Screen and on the Attract Mode.

1. When the Title Screen times out the text offsets. The idea is a "jingle" will play at the end of the jingle the text will offset.
2. When the Title Screen times out a second time the stars fall to the ground. As the stars fall there was flicker due to the horizontal sprite limit when the stars overlapped the Zuks! logo.
I mentioned before that the stars are 32x32 sprites when infact they should be 16x16 sprites (Thanks to turboxray for pointing this out) so it is possible maybe there won't be flicker in the future if by chance changing the stars to 16x16 does not overflow the line limit.

3. In the prototype I quickly hide the Zuks! Logo and show the embedded title screen.

So the GFX are not wasted on animating the small offset they are reused in the Attract Sequence.

I know have my coffee in hand and am at my work station I'm ready to go!
  

[hyperfighting]

I modified your  "multidir_stat_scr_multimap" sample Static Screen Multi 320x224

The only changes I made were the Zuks Map exported from MAPeD at 320x224 and the resolution code is added.
The issue is the the Static Screens are misaligned.

[0x8bitdev]

May 12, 2022 11:25:57 GMT 0x8bitdev said:

Just in case... With the resolution 320x... you can't make double buffered screen switching with BAT 64x32. But with resolution 256x224 you can.

Have you read that?

256/8 = 32*2 = 64 (BAT 64x32)
320/8 = 40*2 = 80 ....

[hyperfighting]

Sorry for this! This means all screen jumps in 320x224 mode will have a flash/delay?
I need to test my Prototype with a 320x224 Promotion export to see if this is the case there too.

[upd] I revisited the prototype and added 320x224 codez and maps via ProMotion.

Do you think we can employ a trick to get this sort of performance out of MAPeD?
Its kinda hard to tell the whole screen is refreshing but focus on the embedded "Press Run" text and block in the left corner.




[upd] A way better example.