|
|
Post by hyperfighting on May 5, 2022 18:21:17 GMT
Frickin MAPeD as concepting tool too! I Exported my base Layout in .png form!  |
|
|
|
Post by 0x8bitdev on May 5, 2022 18:56:29 GMT
Frickin MAPeD as concepting tool too! I Exported my base Layout in .png form! Cool!  Thus, there are two independent game modes, with a totally independent 2 maps for each level: sky (normal mode) and space (expert mode). Each level one-screen height in the normal and in the expert mode. When you fall in the normal mode, your character falls into BLUE pit. When you fall in the expert mode, your character falls into BLACK pit. Is it right? |
|
|
|
Post by hyperfighting on May 5, 2022 20:46:04 GMT
I'm sorry I should have clarified the level is simultaneously both modes so it will be at least two screens high.
It isn't easy to get to the second screen there will only be certain points you have enough momentum to get up there. I think I can be crafty and not have the player enter the second screen on a diagonal but it will still feel diagonal. (If that makes any sense)
From a gameplay perspective if you fall from space you will safely fall to normal mode but if you fall in normal mode you meet the PIT.
|
|
|
|
Post by 0x8bitdev on May 6, 2022 11:13:12 GMT
I'm sorry I should have clarified the level is simultaneously both modes so it will be at least two screens high. It isn't easy to get to the second screen there will only be certain points you have enough momentum to get up there. I think I can be crafty and not have the player enter the second screen on a diagonal but it will still feel diagonal. (If that makes any sense) From a gameplay perspective if you fall from space you will safely fall to normal mode but if you fall in normal mode you meet the PIT. So actually it's the same SMB1, but with your pit logic. Switching from the sky to the space part of a map without scrolling. Now, I hope, we've understood each other!  Welcome to the next level! The HOT question is 'BI-' or 'MULTI-' ?.. I know what you think... But... As usual there are 'pros' and 'cons'. 'MULTI-':'pros':1. A map can be displayed at any free position by X, Y and per screen (by a screen index 0-N). 3. A tile properties detection algorithm is faster than with 'BI-'. 'cons':1. A little bit slower than 'BI-'. 2. ...? 'BI-':
'pros':
1. Respectively a little faster than unified for any map size 'MULTI-'. 2. Exported data size can be reduced with duplicated screens in your map. 'cons':
1. A map can not be displayed at any free position, per screen only (by a screen data pointer). This may be a problem when you want to restore your character on a level. You can't center it on the screen by its last position.2. A more complicated algorithm for detection of a tile property. Click for additional info ( read from 'MAPeD & HuC' to end )Let me know what you think about these 'pros'&'cons'. |
|
|
|
Post by hyperfighting on May 6, 2022 19:54:16 GMT
I think we are on the same page I do think there would be vertical scrolling from the sky to the space part of the screen tho. Would a layout like this work?  Thanks a ton for the updated MAPeD - GL its a great read Click for additional info ( read from 'MAPeD & HuC' to end )Regarding the Pro's and Con's l love the repeat screen optimizations offered by "BI" (Can these savings help me cram more GFX, SOUND etc...I'd have to say yes sir to that one) My thought regarding this comment is we are already breaking the flow action by loading the 'PIT' animation so upon returning to the SKY I believe as long as the screen index matches where the surviving player is standing it should be fine. It boils down to this: How badly will the performance hit of "A more complicated algorithm for detection of a tile property." hurt the projects framerate and sound? If it is negligible then "BI" all the way but if we are in trouble on that front then I guess we will cut like glass with "Multi" and forget about working around coding limitations afforded by "BI" etc. I'm super curious if any 320x224 examples exist because the more I think about it. Its the right fit for this project. |
|
|
|
Post by 0x8bitdev on May 7, 2022 14:31:18 GMT
I think we are on the same page I do think there would be vertical scrolling from the sky to the space part of the screen tho. Would a layout like this work? Vertical scrolling... It seems like we still do not understand each other...  The main purpose of Zuks's gameplay is moving from left to right avoiding pits and sometime at a random place of a map you can jump from sky to space etc. Is it right? As you've read here ( MAPeD & HuC ), bi-directional render scrolls a map from screen to screen ONLY! It's like a train that follows its rails. The train can't move near its rails. Only rails from screen to screen. You can't move at perpendicular direction while you've not reached a screen position. And then if an adjacent screen exist you can scroll a map in its direction, for example, UP. The bi-directional render doesn't allow scrolling at any time at any direction. But the multi-directional allows that! You can use the bi-directional render in your project, if you'll use SWITCHING from the sky to the space, NOT SCROLLING! So the question is still open: the SMB1 scheme with SWITCHING from the sky to the space, or the SMB3 cheme with a smooth scrolling anytime anywhere? You can't answer, I want to use the SMB1 scheme, but with scrolling Because it's the SMB3 scheme! I'm super curious if any 320x224 examples exist because the more I think about it. Its the right fit for this project. You need to set horizontal resolution at startup in your app. I know what VDC registers to use to set the screen resolution, but what values to use for 320x... And I know that, for example, R-Type (J) uses 320pix screen width. But in emulator it doesn't look like 320pix width game. But it uses these values for the screen width: HSR: $0303 HDR: $062B In HuC: vreg( 10, 0x0303 ); vreg( 11, 0x062B ); You better ask someone who knows that. p.s.: BTW, I've added deletion of multiple screens to MAPeD. The changes in the dev build. |
|
|
|
Post by hyperfighting on May 7, 2022 15:26:12 GMT
Yes! This is correct.
The line that got me is "You can't move at perpendicular direction while you've not reached a screen position. And then if an adjacent screen exist you can scroll a map in its direction, for example, UP." I finally now understand that in order to move UP to "SPACE" the Screens must be perfectly aligned although with "BI" this could be achieved with careful placement of triggers that help you catapult vertically. Due to the intended fast pace of the game I think it best to use "MULTI" for smooth scrolling between "SPACE" and "SKY"! I get that this is a design choice that will force alot of additional work if I make an uninformed decision. Thank you for being so patient with me and for walking me through this! "MULTI" it is! SMB3 style! What did the five fingers say to the face! ( "MULTI" in a nutshell - PRO-Smooth Scrolling, PRO-Better Collision Routine! CON-Tile GFX Optimization (Not as good as "BI"))
Thanks for the insight here. I'm happy you didn't say MAPeD natively only support 256x224 on PCE Exports. Does anybody know the codes necessary to to get 320x224 screen resolution working via HuC?
This is awesome thank you!
On the topic of your MAPeD HuC integration, I could be way off side here but I need to ask. Do you intend on possibly adding sudo parallax, animated tiles, or raster effects to the repertoire of MAPeD function calls? I get that this might be over reaching as the intention of MAPeD might just (I do not say just lightly) be to have a cleanly optimized and Maneuverable Map Displayed (STATIC,BI,MULTI as the primary options) Then the programmer relies on their knowledge of ASM and HuC to Manipulate the MAP to cause these types of special effects.
My perspective is "Magical Chase" might as well be called "Magical Trick" as it appears they pulled out all the stops and used every trick in the book when creating that game. I know this is over reaching, greedy and possibly down right wrong but I imagine a world where MAPeD provides function calls to totally trick out the MAPeD exports!
|
|
|
|
Post by 0x8bitdev on May 7, 2022 16:44:31 GMT
The line that got me is "You can't move at perpendicular direction while you've not reached a screen position. And then if an adjacent screen exist you can scroll a map in its direction, for example, UP." I finally now understand that in order to move UP to "SPACE" the Screens must be perfectly aligned although with "BI" this could be achieved with careful placement of triggers that help you catapult vertically. Due to the intended fast pace of the game I think it best to use "MULTI" for smooth scrolling between "SPACE" and "SKY"! I get that this is a design choice that will force alot of additional work if I make an uninformed decision. Thank you for being so patient with me and for walking me through this! "MULTI" it is! SMB3 style! What did the five fingers say to the face! ( "MULTI" in a nutshell - PRO-Smooth Scrolling, PRO-Better Collision Routine! CON-Tile GFX Optimization (Not as good as "BI"))Now we are on the same page! Don't forget to remove all the 'adjacent screen masks' from your maps. The start screen mark is enough. And make all your maps fully filled with screens in vertical or horizontal direction to avoid exporting layouts with empty cells that all will be filled with tiles for multi-directional mode. Especially I mean your main menu map with that 2-screens appendicitis. Thanks for the insight here. I'm happy you didn't say MAPeD natively only support 256x224 on PCE Exports. The maximum screen resolution supported by MAPeD-PCE for sreen data is 320x240. It's value by default. On the topic of your MAPeD HuC integration, I could be way off side here but I need to ask. Do you intend on possibly adding sudo parallax, animated tiles, or raster effects to the repertoire of MAPeD function calls? I get that this might be over reaching as the intention of MAPeD might just (I do not say just lightly) be to have a cleanly optimized and Maneuverable Map Displayed (STATIC,BI,MULTI as the primary options) Then the programmer relies on their knowledge of ASM and HuC to Manipulate the MAP to cause these types of special effects. My perspective is "Magical Chase" might as well be called "Magical Trick" as it appears they pulled out all the stops and used every trick in the book when creating that game. I know this is over reaching, greedy and possibly down right wrong but I imagine a world where MAPeD provides function calls to totally trick out the MAPeD exports! You are right, the intention of MAPeD is to make tilemap data for using in ASM or C. Other things, like parallax, raster effects, animated tiles can be done in a separate library. From this list, only animated tiles are directly related to the editor. But I haven't thought about it yet. |
|
|
|
Post by hyperfighting on May 7, 2022 17:27:45 GMT
In the case of the Title Screen I will scale it back to be a vertical. 1 Screen x 5 Screen Vertical Setup. There will be an additional BANK set up for the PIT with a much smaller tile set. I know PCE supports a 512x512 mode would you consider adding support for that at a later time? Would there be any point? would scrolling a 512x512 image use up all the PCE's resources? Animated Tiles sounds awesome! Looking forward to that one. I also hope on day you drop a bomb and "Magical Trick" one of your Dev builds with an optical treat for the ages! ( A guy can dream...I kid I kid. Do I?) On to export business to get my bearings I feel like I should proceed with what I know "256x224". I can reuse the codes but I'll have to rebuild the Maps if the option to pursue 320x224 presents itself. I'm looking forward to the day Entities a is a discussion! Do these export settings look right to you? Any red flags? 
|
|
|
|
Post by 0x8bitdev on May 7, 2022 18:27:27 GMT
I know PCE supports a 512x512 mode would you consider adding support for that at a later time? Would there be any point? would scrolling a 512x512 image use up all the PCE's resources? As far as I know the max resolution can be 536x240 and more horizontally. As for supporting this resolution in MAPeD-PCE. The resolution in the editor must be a multiple of 16. The editor can support 512x240. But this will greatly stretch the editor. So may be as a custom build. And I've found settings for different resolutions: Horizontal settings:
Width HDS HSW HDE HDW CLK 240 03 02 04 1D 00 256 02 02 04 1F 00 (overscan) 288 00 02 04 23 00 (overscan, max) 320 05 02 04 27 01 336 04 02 04 29 01 (overscan) 376 02 02 04 2E 01 (overscan, max) 480 0C 02 04 3C 02 512 0B 02 04 3F 02 (overscan) 536 07 02 04 46 02 (overscan, max) Vertical settings:
Height VDS VSW VDW VDW VCR 192 25 02 00 BF 0C 224 17 02 00 DF 0C 240 0F 02 00 EF 0C (overscan, max) Overscan - Part of the display may be off-screen on some monitors. Max - This is the largest viewable area possible. CLK - Bits 1-0 of VCE register $0400 But it requires translating in HuC. May be later... [upd]: The 'later' has come 320pix width In HuC: vreg( 10, 0x0502 );
vreg( 11, 0x0427 );
poke( 0x0400, 0x01 );
Tested in the 'Ootake' emulator. Paste this code at the beginning of the 'main' function. The code for the R-Type also works with 'poke( 0x0400, 0x01 )', but with a little offset. I also hope on day you drop a bomb and "Magical Trick" one of your Dev builds with an optical treat for the ages! ( A guy can dream...I kid I kid. Do I?) The life is too short! Do these export settings look right to you? Any red flags? The only red flag is for the 'RLE' option. We talked about it before. It isn't not supported for multi-dir maps in HuC. A little bit about 'Property Id'. Blocks or CHR? It depends on your tiles. If your solid tiles are 16x16 maximum - use ' Block'. If you have detailed graphics and your collidable tiles are multiple to a CHR, then use - ' CHR'. As far as I understand - ' Block' would be enough in your case. [upd]: BTW, getting a tile property per 'Block' is faster than per 'CHR'. And drawing a tilemap exported as 'Blocks 2x2' is faster than 'Tiles 4x4'. |
|
|
|
Post by hyperfighting on May 8, 2022 22:51:06 GMT
BIG LOVE AND SHOUTOUT TO ALL THE MOTHERS THAT ARE OR AREN'T READING THIS POST!  I stand corrected on the max resolution. I knew it was 512 something. Side note its super cool the PCE has so many resolution options!!! Oh Maaaaaaaaaaaan! Remember Bonks Adventure has a character called King Drool. Well that's me right now! I relish the day that the resolutions are easily set via library functions! I just saw the "now" right now I'll get started straight away. Firkin awesome! THANK YOU! Thanks for the clarifications! In my mental rolodex - PRO Tiles 4x4 save space CON - 4x4 Tiles are slower too draw. Never attempt to export with RLE on a 'MULTI' Map. So I dug around in mpd.h and found some cool functions! I assume the ones with _ are internal. I tested "mpd_draw_screen_by_pos( 256, 0);" and it worked great! I'm using some starter functions to jump from map to map. void display_MAP_BANK()
{
/* disable display */
disp_off();
/* init tilemap renderer data */
mpd_init( map_ind, ms_2px );
/* draw start screen */
mpd_draw_screen();
/* enable display */
disp_on();
}
DISP_MAP_TITLE1()
{
map_ind=2;
display_MAP_BANK();
/* init scroll */
scroll(0, 0, 0, 0, 223, 0xC0);
scroll(1, 0, 0, 0, 223, 0xC0);
scroll(2, 0, 0, 0, 223, 0xC0);
scroll(3, 0, 0, 0, 223, 0xC0);
}
DISP_MAP_ATTRACT1()
{
map_ind=0;
display_MAP_BANK();
/* init scroll */
scroll(0, 0, 0, 0, 223, 0xC0);
scroll(1, 0, 0, 0, 223, 0xC0);
scroll(2, 0, 0, 0, 223, 0xC0);
scroll(3, 0, 0, 0, 223, 0xC0);
}
DISP_MAP_ATTRACT2()
{
map_ind=1;
display_MAP_BANK();
//mpd_draw_screen_by_pos( 256, 0);
scroll(0, 0, 0, 0, 56, 0xC0);
scroll(1, 0, 0, 56, 112, 0xC0);
scroll(2, 0, 0, 112, 168, 0xC0);
scroll(3, 0, 0, 168, 223, 0xC0);
}The current allocations are: BANK 0 - Attract Mode BANK 1 - Title Screen / Player Select The Layouts are: 0 - The star the large characters stand on 1 Screen (I believe I have to make this a 3 screen layout because TOY-OTA is supposed to shake the screen. In this case the large star would be screen 2 in a vertical layout of 3 screens) 1 - The Star Field used for the raster effect 2 Horizontal Screens (Currently The trouble is here... I can load the screen using the MAPeD functions then using HuC's scroll function I get 4 windows but incrementing the X co-ordinates seems to fail...I kinda get why as likely MAPeD is not supported by this function. Any advice on restoring this effect would be greatly appreciated. When I call the other layouts I also use HuC's scroll function to restore the window size to 256x224. The code below is how I was previously moving the 4 windows. In the video below it appears to me that the first window remains fixed for some reason. scroll(0, ++test1, 0, 0, 56, 0xC0);
scroll(1, test2+=2, 0, 56, 112, 0xC0);
scroll(2, test3+=3, 0, 112, 168, 0xC0);
scroll(3, test4+=4, 0, 168, 223, 0xC0); 2 - Tiltle Screen/Player Select - 5 Screen Vertical Layout - **Edit The challenge here is the jump from screen index 0 to index 1 produces glitches. I have tried both "mpd_draw_screen_by_pos(0, 224);" and "mpd_draw_screen_by_scr_ind(1);" separately but I get a glitch upon update. I am using "mpd_update_screen(TRUE);" at the bottom of the loop I also tried issuing this command immediately after the call but I'm still seeing a glitch.  **Edit I guess what it boils down to in this case is "Screen Shake" and "Window Scrolling" - The attract mode uses these effects but moving forward they could be useful in the game portion. When attempting screen shake will I always need to have unused screens above and below the Main Maps EX: Level is 2 screens tall but as a provision for shake it needs to be 4 screens tall to buffer the X,Y movement? **Edit the screen jump is also giving me issues |
|
|
|
Post by 0x8bitdev on May 9, 2022 15:36:19 GMT
If you mean these stairs... ![]()  ...When exporting your project, you select the BAT size 64x32. It's Ok for your levels. But... It looks like your effect was developed for the BAT size 32x32 and the stars scrolling is looped like an infinite stars field. But with the BAT size 64x32 you'll not get the infinite stars effect. So, for the main menu scenes you need to use the initial BAT size 32x32. Just insert ' set_screen_size(0);' after ' mpd_init' for that. But for your game levels you need to restore the exported BAT size: set_screen_size( BAT_INDEX );[upd]When attempting screen shake will I always need to have unused screens above and below the Main Maps EX: Level is 2 screens tall but as a provision for shake it needs to be 4 screens tall to buffer the X,Y movement? Having 4 screens tall for your levels is a bad idea... It's a lot of useless screen data. And shaking a level screen by changing the scrolling registers is a bad idea too. Because these registers are used by the tilemap render. In the main menu, you can clear the screen (BAT) before shaking to clear the garbage. |
|
|
|
Post by hyperfighting on May 9, 2022 16:37:29 GMT
Thanks for the tips! I modified my functions but I'm still getting a strange result.
void display_MAP_BANK_1X_32_32()
{
disp_off();
mpd_init( map_ind, ms_1px );
set_screen_size(0);
mpd_draw_screen();
disp_on();
}
void display_MAP_BANK_1X_64_32()
{
disp_off();
mpd_init( map_ind, ms_1px );
set_screen_size(BAT_INDEX);
mpd_draw_screen();
disp_on();
}
**Edit
I am having issues scrolling vertically there is glitch at the point where screen begins to scroll.
mpd_clear_update_flags();
mpd_move_down();
mpd_update_screen(TRUE);
Do you think the code I am using for screen jumps is correct?
disp_off();
vsync();
//mpd_draw_screen_by_pos(0, 224); //Alternative method
mpd_draw_screen_by_scr_ind(1);
disp_on();
|
|
|
|
Post by 0x8bitdev on May 9, 2022 17:03:58 GMT
The problem is how to combine 64x32 data with an old 32x32 effect...
Revert the last changes with the 'set_screen_size'.
There are two ways:
1. You can minimize the glitch by changing the background color to black.
2. Now you can see the left 32x28 side of 64x32 BAT. You need to copy it to the right side of the BAT. This way you can simulate looped scrolling as it was.
|
|
|
|
Post by 0x8bitdev on May 9, 2022 17:18:06 GMT
Do you think the code I am using for screen jumps is correct? disp_off();
vsync();
//mpd_draw_screen_by_pos(0, 224); //Alternative method
mpd_draw_screen_by_scr_ind(1);
disp_on();
I'd move the vsync() before the disp_off() |
|
