|
|
Post by hyperfighting on Aug 25, 2022 12:39:39 GMT
0x8bitdev - So far so good! I have it plugged in and working! Minor change to my instance of "mpd_set_scroll_step_y(SPEED);" and I'm all set! 
|
|
|
|
Post by hyperfighting on Aug 26, 2022 19:45:09 GMT
0x8bitdev - I'm attempting to get only the center of a MAPeD Map to scroll right. I have the top and bottom fixed but the center portion does not update properly when scrolling. At first glance do you see any red flags? I have tried many combinations but I'm stuck ATM. mpd_clear_update_flags();
mpd_set_scroll_step_x(1);
mpd_move_right();
scroll(0, 0, 0, 0, 32, 0xC0); //Fixed Top of the screen
scroll(1, mpd_scroll_x(), 32, 32, 160, 0xC0); // <- Having an issue scrolling map area (MAP is several screens wide)
scroll(2, 0, 160, 160, 224, 0xC0); //Fixed Bottom of the screen
mpd_update_screen();
pokew( 0x220c, mpd_scroll_x() );
pokew( 0x2210, mpd_scroll_y() );
vsync();
The best I have been able to do is loop the first screen (aka ATTRACT MODES starfield) I can't seem to figure out how to cleanly scroll the center portion so new MAPeD screens appear.
|
|
|
|
Post by spenoza on Aug 26, 2022 20:29:56 GMT
Are you actually making progress on the game or are you stuck retooling the intro every time 0x8bitdev releases a new build (which is pretty often, tbh)?
It might be good at some point to just commit to a version of the tool to make it easier to move forward, if that's the case.
|
|
|
|
Post by hyperfighting on Aug 26, 2022 21:07:01 GMT
spenoza - I am making progress. All of 0x8bitdev 's SPReD/MAPeD iterations are fully in place and working (I am enjoying working with them and testing them). The Attract sequence uses the scroll windows for the star field effectively but in that case there is no need for more than one screen of data because the sequence is so short. In the case I'm speaking of I am programming a "How To Play" screen. "How to play" is my top fixed window and I have a "Controller" in my bottom fixed window. The area in question is the middle window. This is a new topic in that I have never yet seen MAPeD and HuC's scroll function work together from the standpoint of iterating more than one screen in a map. 0x8bitdev mentions it is possible if scrolling LEFT/RIGHT so I am just trying to get the approach correct. Do you happen to know an approach to fixing my "score characters EX: Score:0000000" to the upper left corner of an active map?
|
|
|
|
Post by elmer on Aug 28, 2022 3:08:49 GMT
hyperfighting : Even though I agree with spenoza that choosing to stick to a particular revision is the best way to get *your* own personal project to a stable point, I do have to say that the way that you and 0x8bitdev are going back-n-forth with each other is the PERFECT way to engage a library author, and to improve the library itself for both you, and for everyone that comes after you. Thanks to both of you for everything that you are both doing to improve the capabilities for ALL HuC users, and for making your own creations come to be.  Best wishes, elmer
|
|
|
|
Post by 0x8bitdev on Aug 28, 2022 11:35:06 GMT
0x8bitdev - I'm attempting to get only the center of a MAPeD Map to scroll right. I have the top and bottom fixed but the center portion does not update properly when scrolling. At first glance do you see any red flags? I have tried many combinations but I'm stuck ATM. mpd_clear_update_flags();
mpd_set_scroll_step_x(1);
mpd_move_right();
scroll(0, 0, 0, 0, 32, 0xC0); //Fixed Top of the screen
scroll(1, mpd_scroll_x(), 32, 32, 160, 0xC0); // <- Having an issue scrolling map area (MAP is several screens wide)
scroll(2, 0, 160, 160, 224, 0xC0); //Fixed Bottom of the screen
mpd_update_screen();
pokew( 0x220c, mpd_scroll_x() );
pokew( 0x2210, mpd_scroll_y() );
vsync();
The best I have been able to do is loop the first screen (aka ATTRACT MODES starfield) I can't seem to figure out how to cleanly scroll the center portion so new MAPeD screens appear. For scrolling HuC regions you need to use HuC's scroll functions as described in the MPD doc. And once again, you can't combine MPD's fullscreen scrolling with the HuC's area scrolling. Either MPD or HuC. So, remove this: pokew( 0x220c, mpd_scroll_x() );
pokew( 0x2210, mpd_scroll_y() );
And put the ' mpd_update_screen();' before the HuC's scroll functions. But that won't be enough. HuC's area scrolling works well with MAPeD maps, when the maps designed to be used with a status bar. I mean that your map don't have to be fullscreen by screen height ( map_height = screen_height - status_bar_height). It is obvious. But there is a limitation here - one MAPeD project - one screen size. The only thing you can do is to fill the empty space with empty tiles. In your case I can suggest you to make a separate, a few screen "How to play" map which will take into account your status bar heights. And update your status bar(s) on each frame after the 'mpd_update_screen()' call, because they can be cleared by empty tiles of your map. That isn't the best solution, but that will work. The best solution would be to implement the status bars with scanning line interrupts. I didn't plan this, because it have nothing with the MPD library functionality and can be implemented as separate solution. So maybe later, when I'm free I'll do that. |
|
|
|
Post by hyperfighting on Aug 29, 2022 13:40:33 GMT
elmer - Thank you so much for your message! Also thank you so much for all you do! The information you provide and the accessibility to tools and docs is second to none IMO. I always enjoy reading what the dev's are up to even if it goes way over my head! I have been meaning to ask are you creator of pcengine.proboards.com?0x8bitdev - I love this concept of "empty tiles" it is uncharted territory for me. I performed a few tests and failed miserably lol. My imagination ran wild. The annoying questions With this approach do I still use the HuC "scroll(...)" or abandon it? I'm struggling with the concept of updating status bar(s) on each frame after the 'mpd_update_screen()' call. [upd]
Goal 1. Freeze the top and bottom windows.
Goal 2. Use MAPeD mpd_draw_CHR(...) functions to update frozen windows at trigger pointsIn one reality I'm seeing one map that I jump between screens constantly to get the affect of fixed upper and lower regions? This configuration has one full screen of relevant tiles and the rest of the screens only have relevant tiles in the scrollable middle section. My thought was maybe if I froze the top and bottom scroll area the middle would scroll and due to the empty tiles not affecting the top and bottom regions. The areas marked with x are blank tiles (FF) and 0 is relevant tiles. 000000000000->xxxxxxxxxxxxx 000000000000->xxxxxxxxxxxxx 000000000000->000000000000 000000000000->000000000000 000000000000->xxxxxxxxxxxxx 000000000000->xxxxxxxxxxxxx This configuration is the inverse where the first screen has the fixed status bars but has empty tiles in the scrollable area and every subsequent screen has data in the scrollable area. 000000000000->xxxxxxxxxxxxx 000000000000->xxxxxxxxxxxxx xxxxxxxxxxxxx->000000000000 xxxxxxxxxxxxx->000000000000 000000000000->xxxxxxxxxxxxx 000000000000->xxxxxxxxxxxxx The other thought is instead of jumping screens in a single layout I jump between 2 entirely different layouts. 1 for Status bars 2. for scrollable area Of course I misinterpreted your words and now I'm a mess. 
|
|
|
|
Post by spenoza on Aug 29, 2022 14:33:54 GMT
This is Sunteam Paul's forum, connected to his PC Engine Bible site.
|
|
|
|
Post by hyperfighting on Aug 29, 2022 14:37:42 GMT
spenoza - very cool! I guess the only thing to say is Paul is awesome along with the rest of you! Thanks Paul! This forum rocks!
|
|
|
|
Post by 0x8bitdev on Aug 31, 2022 9:38:00 GMT
hyperfighting , Good news! I will not make my status bar implementation, because the HuC's 'scroll(...)' does everything you need for that. It can point to any visible/invisible BAT area with its X and Y arguments (in pixels). And that is enough to make any status bar you need. So forget everyhting I wrote in my last post. I've tested the HuC's scroll with two status bars at the top and bottom and a horizontal scrolled fullscreen map between them. And it works well with BAT 64x32, screen resolution 256x224, status bar height 32pix. BUT with your screen width - 320pix, you will not have two status bars 32pix height. BAT 64x32 memory is no enough for two 32pix status bars with your screen resolution. And another one thing you have to understand. There is a difference between your "star field" that uses HuC's scroll and the status bars you want to implement. It's almost the same, but NOT the same(!) Making the "star field" effect you just scroll visible screen areas using the HuC scroll functions. But in-game status bars actually outside of the visible BAT area. In short, for example, there are two BAT area: a status bar and a game scene that can be placed anywhere in BAT and with the help of scanning line interrupts these two unlinked memory areas are combined into one image. Thus, a status bar need to be placed anywhere in free BAT memory and can't intersect with a game scene. Otherwise you'll see glitches. To understand better the status bar technique, read the 'HuC62 - Tech Notes.pdf', 'Displaying Status Line' chapter from the official PCE tech doc archive.To implement a status bar with a horizontal scrolled map you need: 1. A fullscreen map for a game scene as before. 2. One-screen map for a status bar graphics. 3. Define scrollable area for the status bar that points to free BAT memory where the status bar graphics will be placed. 4. Init your one-screen map for a status bar and draw graphics into that BAT memory location using the 'mpd_draw_screen_by_ind_offs( _scr_ind, _BAT_offset, _reset_scroll )' / _BAT_offset should point to the status bar memory location, _reset_scroll - FALSE 5. Define scrollable area for a game map. 6. Init the game map. 7. Then in update loop: scroll defined game map area left\right (of course with the HuC scroll! there are no other ways!) and update the status bar info. As the result, the game scene scrolled left/right, the status bar fixed on the screen and points to invisible BAT area. Everyone is happy! p.s.: I fixed a minor issue with an extra tile that is drawn in multidirectional mode. The fix in the dev build.
|
|
|
|
Post by hyperfighting on Aug 31, 2022 15:35:39 GMT
0x8bitdev - Thanks for the info I'm pretty excited! I understand with my 320x224 resolution I can only have 1 status bar so likely I will make "How To Play" a sprite and have the "Controller GFX" as the status bar highlighting various inputs etc. [upd] Now that I understand all I have is 32 pix in height to work with "How To Play" will remain frozen as the top scrollable window. The "controller" is too high at 64 pixels so I will use the various mpd_draw_CHR(..)/mpd_draw_Block (..) functions at various points to display it. Then I will remove it after the brief descriptions take place. [upd] I realize this technique would work for fixing chars to the screen for a score as well. I imagine I will lose a 8x320 row across the area the score is displayed. It would be nice to just fix those chars freeing the rest of the map to move. When you mentioned you might have considered your own custom interrupt my mind went to a place of technical affects galore (The lines they just keep scrolling!!!) I will attempt 'HuC62 - Tech Notes.pdf' At first shot.... Regarding the issue at hand: 1. I have the newest and truest MAPeD (GUI/Library) in place. 2. I have one full screen horizontal map full of tiles top to bottom (Layout A) 3. I have a one screen status bar map full of tiles top to bottom. Only intending to use the bottom tiles on the lower third of the map. (Layout B) 4. This is throwing me through a loop. [upd] I wrote a bunch of junk earlier deleted it all whatever I write seems non-sensical when I read it back. Does this step need HuC functions to be combined with the MAPeD libray functions in order to point to free BAT memory? At this stage I believe the intention is to use 28-31 in the Y axis from the 64x32 BAT size due to the 224 height resolution using only 0-27 and the rest is excess that would be used for diagonal scrolling but we are only moving horizontally in this case. So that space is free.
|
|
|
|
Post by 0x8bitdev on Sept 1, 2022 8:14:47 GMT
[upd] I realize this technique would work for fixing chars to the screen for a score as well. I imagine I will lose a 8x320 row across the area the score is displayed. It would be nice to just fix those chars freeing the rest of the map to move. 8x320 status bar will not work with BAT 64x 32 + scrollable multidirectional 2 screen height map... Guess why? 4. This is throwing me through a loop. [upd] Does this step need HuC functions to be combined with the MAPeD libray functions in order to point to free BAT memory?  I don't know how it's possible... So my answer - No! At this stage I believe the intention is to use 28-31 in the Y axis from the 64x32 BAT size due to the 224 height resolution using only 0-27 and the rest is excess that would be used for diagonal scrolling but we are only moving horizontally in this case. So that space is free. Y-e-s! |
|
|
|
Post by hyperfighting on Sept 1, 2022 12:33:13 GMT
0x8bitdev In the mist of the excitement I neglected to write "8x320 status bar is possible if I only scroll LEFT/RIGHT" I get that it eats into the BAT required for diagonal scrolling and isn't a solution in that case. Appreciate you guiding me away from HuC functions. I was investigating the HuC scroll examples trying to manually load chr0 files manually through HuC's load_bat (...) etc I'm glad I at least I get the concept of understanding where I need to point and store my BAT data. Aiming at row (28-31 Y) in the 64x 32 BAT. I did a search and can only find an example of "mpd_draw_screen_by_ind_offs( map_scr_ind, BAT_offset, FALSE );" in the "Static screens switching demo for multidirectional map" it appears to me that this function accepts columns 0-63 as valid arguments for the "BAT_offset". I can't seem to figure out how to point to row 28 in the BAT. I re-exported my MAP data with the rows radio button selected to see if that changes the behavior of "mpd_draw_screen_by_ind_offs(...); - BAT-offset" but that didn't seem to work. I know this must be obvious and frustrating to you I am sorry for all the questions.
|
|
|
|
Post by 0x8bitdev on Sept 2, 2022 9:54:03 GMT
Appreciate you guiding me away from HuC functions. I was investigating the HuC scroll examples trying to manually load chr0 files manually through HuC's load_bat (...) etc Actually I guiding you away from using MPD library in that step. Re-read carefully all the steps. I don't know another way to define a scrollable region than using HuC's 'scroll' function. Do you? ... 3. HuC's 'scroll'.... 4. MPD's 'mpd_draw_screen_by_ind_offs'... ... I did a search and can only find an example of "mpd_draw_screen_by_ind_offs( map_scr_ind, BAT_offset, FALSE );" in the "Static screens switching demo for multidirectional map" it appears to me that this function accepts columns 0-63 as valid arguments for the "BAT_offset". I can't seem to figure out how to point to row 28 in the BAT. I re-exported my MAP data with the rows radio button selected to see if that changes the behavior of "mpd_draw_screen_by_ind_offs(...); - BAT-offset" but that didn't seem to work. I know this must be obvious and frustrating to you I am sorry for all the questions. ' mpd_draw_screen_by_ind_offs' accepts BAT memory offset as _BAT_offset argument. Since you've read the " HuC6270 - CMOS Video Display Controller Manual.pdf", you know BAT memory structure and how to use the _BAT_offset argument to get the BAT address you need. |
|
|
|
Post by hyperfighting on Sept 3, 2022 14:22:47 GMT
0x8bitdev - I am very close now I managed to merge the status bar map with the horizontal map. The placement of the status bar appears correct but I'm getting a glitch when I scroll. I know I am not supposed to overlap the two BAT locations but I'm not sure where I am off. ////////INIT STATUS BAR AND HORIZONTAL MAP
disp_off();
vsync();
//STATUS BAR aka "How To Play"
scroll(0, 0, 224, 0, 31, 0xC0); // BAT Location (Vertical) 0-224 (BAT Bottom) / Map Window Size (Vertical) 0-31
mpd_init(_map_ind_Status_Map, 0); //STATUS BAR SINGLE SCREEN
mpd_draw_screen_by_ind_offs( 0, 1792, FALSE); // RES BREAKDOWN TO 8x8 tiles (320/8=40 / 224/8=28) 40x28 = 1792 BAT Bottom
//Horizontal Scrollable Area
scroll(1, mpd_scroll_x(), 32, 32, 223, 0xC0); //BAT Location (Vertical) 0-32 (Just after status bar) (BAT Bottom) //Window Size 32-223
mpd_init(_map_ind_Hor_Map, 1);
mpd_draw_screen();
disp_on();
vsync();
////////MAIN LOOP
mpd_update_screen();
scroll(0, 0, 224, 0, 31, 0xC0);
scroll(1, mpd_scroll_x(), 32, 32, 223, 0xC0);
|
|
I don't know how it's possible... So my answer - No!