|
|
Post by 0x8bitdev on May 9, 2022 17:24:41 GMT
Its' better if you'll create a test application that you can share and where you'll implement these maps switching/scrolling logic. This way we can easy resolve issues.
|
|
|
|
Post by hyperfighting on May 9, 2022 17:49:09 GMT
I can do that forsure! I need a little to get it rolling.
I was brainstorming so I thought why not try to attempt to keep my promotion starfield map for the attract mode sequence since it already works etc..
//LOOP START
if (map.MAPeD_Render==1)
{
mpd_clear_update_flags();
}
//BODY
if (map.MAPeD_Render==1)
{
mpd_update_screen(TRUE);
}
//LOOP END
//BODY
DISP_MAP_NO_MAP();//Sets map_ind = -1;
LoadGFX_Demo_StarField(); //Loads Promotion Map for Starfield
I was shocked! I was able to get it working but the speed of disabling the MAPeD calls enhanced the speed of the Attract Mode....The 4 Ninjas struggled in previous builds but now they fly through the air as intended!!!!
I am happy to entirely convert the project to MAPeD but maybe I should leave it alone in the case of the scrolling?
I'm also really curious if I can easily do screen shake on a single screen? "TOY-OTA" needs help next if you think I am on the right track with this hybrid method....
|
|
|
|
Post by 0x8bitdev on May 9, 2022 19:06:28 GMT
Why, not?.. Since the star field was designed for BAT 32x32, you can switch back to BAT 32x32 and use your worked star field. And then switch back BAT to exported value. Don't forget to remove the star field from a MAPeD map. I was shocked! I was able to get it working but the speed of disabling the MAPeD calls enhanced the speed of the Attract Mode....The 4 Ninjas struggled in previous builds but now they fly through the air as intended!!!! It looks like you use vsync() several times in your update loop. 'mpd_update_screen(TRUE);' - uses 'vsync()' before applying VDC's scroll registers. So when you have disabled the 'mpd_update_screen(TRUE);', the ninjas move faster than before. Actually you must use the 'mpd_update_screen(TRUE);' only for a map scrolling, not for static screens. As for 'TOY-OTA'... It requires clearing of whole BAT before shaking. |
|
|
|
Post by hyperfighting on May 10, 2022 13:24:17 GMT
Sounds great! I will leave the Attract sequence as is but the TITLE, PLAYER SELECT AND LEVELS will be using MAPeD! This has lead me to a few possible suggestions that might or might not be useful. Different BAT sizes per Layout1. On Export give the option to Export each "Layout" with a specific BAT configuration. EX: Layout 1 = 32x32 EX: Layout 2 = 64x32 2. Instead of this method if the user was allowed to: A. User can define any bank at any time. A dropdown list of BANKS opposed to the BANK+, BANK- buttons. Only Used Banks are Exported. Blank Banks are ignored. B. User selects BAT size on export as per usual. C. MAPeD exports can be combined in HuC as some exports might be EX: 32x32 BAT BANK 0 and another export may be 64x32 BAT export for BANK 1 etc Found a little bug (v.0.70b)When exporting 256x224 Layouts as .png they are perfect. When exporting 320x224 Layouts as .png there is degradation in quality. I used one of your examples to create a little project.
Multi Function TestCurrently the Demo uses the UP/DOWN Keys We have 320x224 resolution, Map and MAPeD file. We have my attempt at a half decent screen jump function. (Please let me know if I missed the mark here.) We have what I believe is sufficient for automatically scrolling the map. Pretty Bare Bones and it works great which leads me to dig into my filez and see why I get a glitch when I attempt the same auto scroll method. Hope fully we can add useful functions and modify the file with examples etc. |
|
|
|
Post by 0x8bitdev on May 10, 2022 15:19:26 GMT
This has lead me to a few possible suggestions that might or might not be useful. Different BAT sizes per Layout1. On Export give the option to Export each "Layout" with a specific BAT configuration. EX: Layout 1 = 32x32 EX: Layout 2 = 64x32 2. Instead of this method if the user was allowed to: A. User can define any bank at any time. A dropdown list of BANKS opposed to the BANK+, BANK- buttons. Only Used Banks are Exported. Blank Banks are ignored. B. User selects BAT size on export as per usual. C. MAPeD exports can be combined in HuC as some exports might be EX: 32x32 BAT BANK 0 and another export may be 64x32 BAT export for BANK 1 etc 1. This will make data export harder, for example, when you'll have more than 10 layouts... You need to control a lot of options when exporting your data. 2A. Banks are secondary to maps. Different maps can share different banks. But if your maps do not use one of the bank(s), that bank(s) will not be exported. 2C. ... In short, the main things are maps. As rule, a game has the same level structure for all maps. And BAT 64x32 is the best choice for scrollable maps. So why complicate the things?  Actually, your issue with the BAT size on the star field effect can be resolved by copying the left side of the BAT to the right one. And you will have the same looped star field with the BAT 64x32. Found a little bug (v.0.70b)When exporting 256x224 Layouts as .png they are perfect. When exporting 320x224 Layouts as .png there is degradation in quality. Thanks for the bug! I'll take a look. I used one of your examples to create a little project.
Multi Function TestCurrently the Demo uses the UP/DOWN Keys We have 320x224 resolution, Map and MAPeD file. We have my attempt at a half decent screen jump function. (Please let me know if I missed the mark here.) We have what I believe is sufficient for automatically scrolling the map. Pretty Bare Bones and it works great which leads me to dig into my filez and see why I get a glitch when I attempt the same auto scroll method. Hope fully we can add useful functions and modify the file with examples etc. I suggest you to create a new project and move&test step by step your working code there. [upd] try to use ' mpd_update_screen( TRUE )' after ' mpd_draw_screen_by...' and before ' disp_on()' to avoid shifted image. [upd] maps/screens switching through white flash. it's just an experiment, but looks not bad... void border_white()
{
pokew( 0x0402, 0x0100 );
pokew( 0x0404, 511 );
}
void border_black()
{
pokew( 0x0402, 0x0100 );
pokew( 0x0404, 0 );
}
char screen_index=0;
JUMP_SCREEN_INDEX ()
{
disp_off();
vsync();
border_white();
//mpd_draw_screen_by_pos(0, 224);
mpd_draw_screen_by_scr_ind(screen_index);
mpd_update_screen( TRUE ); // TRUE - vsync on, FALSE - vsync off
border_black();
disp_on();
}
|
|
|
|
Post by hyperfighting on May 11, 2022 10:58:03 GMT
Ok so I spent the better part of yesterday working at integrating the MAPeD export into the Zuks! project. Here are my notes: - The project is now officially 320x224 resolution. Big thanks again 0x8bitdev ! - Due to the 32x32 BAT tricks we discussed the Atrract Sequence uses a Promotion Export. As a side note elmer mentions here Split Screen Discussion that turboxray has codes that enhance the number of screen scrolls. TX if you are willing to share I would love to upgrade the 4 scrolls in this sequence to as many as I possibly can. The scene would feature both 2x sprites and several scrollers! - The first effect on the title a is "Screen Jump". If you watch the prototype video the transition is pretty seamless. However if you load the MAPeD test project from yesterday there is a noticeable "flash" when jumping screens. Ideally I would like to keep this transition as smooth as possible so in the end the MAPeD export might not be ideal for the title screen sequence and I may need to stick with Promotion export on that front as a last resort. That said I am not giving up on the Title sequence yet. First off the title screen in the prototype is 256x224 and if the same code were to be converted to 320x224 there might be a noticeable flash when the screen jump occur's due to the processing required to draw the additional data. In addition my MAPeD export uses 4x4 tiles which I am told is slower than 2x2 tiles so today I am going to attempt to export the Map with 2x2 tiles and see if the there is any noticeable improvements. - In the MAPeD test project there is seamless vertical scrolling when the down arrow is pressed. In my project there was a "glitch" seen in one of previous posts. This "glitch" is due loading the "cloud" sprites at the same time as issuing the "mpd_move_down()" command. As soon as I adjusted the code to first load the cloud GFX then wait until the next cycle to issue the "mpd_move_down()" I was able to achieve seamless scrolling. - The next glitch happens when the Map is at the very bottom and the Zuks hit the ground and we are introduced to Zupapa and Zupipi. I have a dormant "for" loop that is set to "3" at this point. The loop is responsible for rendering the Zuks, Zupapa and Zupipi. If the loop isn't initialized the there is no "glitch" but if it is enabled I get a glitch. I have attempted to "disable mpd_update_screen( TRUE );" at this point and yes that fixes the glitch but for a reason unbeknownst to me the MAPeD Export loses it's index and shifts. I have also tried moving the "mpd_update_screen( TRUE )" and my sprite rendering logic to in different orders but I still seem to get either a glitch or the MAPed Export loses it's index. I am going to post a video of the Map losing its index ASAP if there is a way to mitigate this then problem solved. In addition I need to attempt an export with 2x2 tiles to see if that helps things. - What I am noticing with the glitches described above it seems MAPeD rendering can be disrupted when large chunks of data are loaded. I am hoping moving the sprite rendering to SPReD may mitigate this issue. -Shoot I missed this! I'll test!!!! - The sprites are now shifted due to being programmed for 256x224 resolution. Instead of fixing the sprites X positions I believe it is time to embark on the process of moving the sprite processing to SPReD who knows this might greatly improve the "glitches" mentioned above as I am hoping processing SPRed Meta Sprites is faster than what I have currently. EX: The clouds are two sprites each and each sprite has two x co-ordinates and one y co-ordinate. So each of the clouds has 3 variables used to position them. One goal will be to completely convert the inanimate objects to SPReD. I will start with the clouds and hopefully optimize the number of variables used to control their position. Static objects Zuks Logo! (A series of if I remember correctly 32x64 sprites) Clouds Word Bubble Falling Brick I will consult the general ledger, read the help and get started with SPReD Scroll Up To SPReD info (I really need to figure out how to create a proper scroll to link) - As of right now the right aligned "Title Text" and "Push Run" are directly integrated into the MAPeD Export. Previous to this they were sprites. "Push Run" is still a sprite for the time being until I code a routine to flash the text via manually placing the tiles on the screen and manually replacing the tiles. I do not think building a screen in MAPeD with the only difference being "Push Run" is a good idea due to addition data being stored and the "flash" that is currently happening during screen jumps etc. - I tried out 0x8bitdev's white border flash! It's a really cool technique that will definitely be useful! - I am happy with the current structure of the underlying code things are managed by a series of switch statements relatively easy to identify bottle necks etc. - 0x8bitdev Sorry for making Bad suggestions regarding the BAT export |
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on May 11, 2022 15:04:51 GMT
Hi all! I'd like to share with you the new PCE development tools I developed for myself, but maybe they will be useful to someone... Thank you so much for this! When I first started doing the obey tutorials my expectation was exactly this on what game development looked like. I can only think about the kind of game I want to make atm, but I look forward to trying it out in the future, going through some of the examples in the quick guide and maybe plotting some maps onto paper. |
|
|
|
Post by hyperfighting on May 11, 2022 15:27:33 GMT
This is a test performed on a 2x2 MAPeD export.
- The Map Jump is noticeable is there any clean fast way to potentially mitigate this?
- I have a smooth vertical scroll on initialization due to reordering some code on my end.
- Once the map reaches the bottom. I am disabling the "mpd_update_screen(TRUE);" by setting the variable "map.MAPeD_Render=0"
if (map.MAPeD_Render==1)
{
mpd_update_screen(TRUE);
}
The same video but without disabling the map update...It's very quick but you can see the alignment shift.
|
|
|
|
Post by 0x8bitdev on May 11, 2022 15:52:17 GMT
In addition my MAPeD export uses 4x4 tiles which I am told is slower than 2x2 tiles so today I am going to attempt to export the Map with 2x2 tiles and see if the there is any noticeable improvements. You will not see ANY improvements on empty scene. Such things need to be tested under load with game logic, enemies, effects, sound, etc. - The sprites are now shifted due to being programmed for 256x224 resolution. Instead of fixing the sprites X positions I believe it is time to embark on the process of moving the sprite processing to SPReD who knows this might greatly improve the "glitches" mentioned above as I am hoping processing SPRed Meta Sprites is faster than what I have currently. EX: The clouds are two sprites each and each sprite has two x co-ordinates and one y co-ordinate. So each of the clouds has 3 variables used to position them. One goal will be to completely convert the inanimate objects to SPReD. I will start with the clouds and hopefully optimize the number of variables used to control their position. What I saw in your project are simple sprites 32x32, 16x16 etc. The SPD library allows to simplify data initialization, preloading. But the main work with simple sprites is the same. - As of right now the right aligned "Title Text" and "Push Run" are directly integrated into the MAPeD Export. Previous to this they were sprites. "Push Run" is still a sprite for the time being until I code a routine to flash the text via manually placing the tiles on the screen and manually replacing the tiles. I do not think building a screen in MAPeD with the only difference being "Push Run" is a good idea due to addition data being stored and the "flash" that is currently happening during screen jumps etc. The whole screen for one message... The 'PUSH RUN' message MUST be a sprite! I kept thinking when to write this to you. And the time has come.  Making a BIG changes in old complex project is a REALLY-REALLY-REALLY BAD idea! You'll get a tons of bugs and glitches! And I strongly recommend you:1. Make a backup of your old project. 2. Create a new project for your game. 3. Create a test project with all your game structure (may be simplified): menu->intro->level maps->pit logic->etc... for testing/prototyping/learning/sharing. And move working code from the test project to the new one step by step. This way you can avoid even more mistakes! When something works in a test project, but don't work in your main project. It's a question to your main project: what's going on there?  It should not be. But when you move a working code step by step, you clearly understand what's going on. |
|
|
|
Post by hyperfighting on May 11, 2022 16:35:49 GMT
0x8bitdev I hear what you are saying. I am currently very happy with the structure of the current code I have. That's not to say I won't whip something up for testing but in my case the little project from yesterday shows exactly what I am aiming to do and off the bat (no pun intended) I see screen flicker on the screen swap in that basic test project. Do you think you can mitigate it? In addition file shows me smooth scrolling and I achieved it by identifying the logic in my first glitch and reordering when the "loading of the clouds occures" The second glitch I know exactly the logic that causes the "studder" but that doesn't happen with my previous PROMOTION method. So I know exactly where on my end to investigate. I'm not overly worried about stepping through my code. The biggest reservation comes from this statement: The final trick to the "Level" introduction is the falling bricks. I believe as the bricks fall I am using "put_tile();" to replace the sprites with background images because I will overflow the number of sprites per the horizontal limit if I do not strategically replace the falling blocks. I was going to employ the same method for the "Push Run" Text but if I am unable to place tiles via a MAPeD export I might be SOL on the replacing title Portion. Do you think it best I aim to use MAPeD for Level portion only and retain what is currently there from the prototype? If this is the case I would focus on reformatting the Zuks to SPReD format to optimize there 32x32 tile sets to 16x16 + 16x32 META Sprites I can see a great savings here. Please let me know what you think considering the challenges.
|
|
|
|
Post by 0x8bitdev on May 11, 2022 16:36:04 GMT
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.
|
|
|
|
Post by hyperfighting on May 11, 2022 16:43:48 GMT
0x8bitdevThis is wicked (good and bad I guess!) Thanks for looking into the HuC scroll! Also please see the post above I think we posted at the exact same time lol
|
|
|
|
Post by elmer on May 11, 2022 17:07:47 GMT
Making a BIG changes in old complex project is a REALLY-REALLY-REALLY BAD idea! You'll get a tons of bugs and glitches! And I strongly recommend you:1. Make a backup of your old project. 2. Create a new project for your game. 3. Create a test project with all your game structure (may be simplified): menu->intro->level maps->pit logic->etc... for testing/prototyping/learning/sharing. And move working code from the test project to the new one step by step. This way you can avoid even more mistakes! I completely agree with this!  Thanks for providing such great support for your library code, it's really getting a work-out.  |
|
|
|
Post by 0x8bitdev on May 11, 2022 17:12:45 GMT
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?  The final trick to the "Level" introduction is the falling bricks. I believe as the bricks fall I am using "put_tile();" to replace the sprites with background images because I will overflow the number of sprites per the horizontal limit if I do not strategically replace the falling blocks. I was going to employ the same method for the "Push Run" Text but if I am unable to place tiles vis a MAPeD export I might be SOL on the replacing title Portion. It requires testing, how the 'put_tile()' works on scrolled screen. Do you think it best I aim to use MAPeD for Level portion only and retain what is currently there from the prototype? If this is the case I would focus on reformatting the Zuks to SPReD format to optimize there 32x32 tile sets to 16x16 + 16x32 META Sprites I can see a great savings here. Please let me know what you think considering the challenges. Actually, I've prepared a quality update for the tilemap library and wanted to post it today. But, as always "but"... With that update you can insert back your star field screen to the MAPeD project and easy use it in your code with full screen of looped stars in 320x224 etc. I don't see any obstacles to fully use the MAPeD and tilemap library for the main menu scenes etc... But as you may see it requires testing the library on real data and polishing all the roughness. So don't rush with sprites. Let's figure it out with the tilemap library. |
|
|
|
Post by hyperfighting on May 11, 2022 17:16:56 GMT
I love it! I'm so down! I'm really excited to see if we can make MAPeD the one stop shop! As per elmer  "You are the man son!" [upd] Tested the "put_Tile ()" function tiles display but I don't recognize their design or palette. |
|
It should not be.
"You are the man son!"
