|
|
Post by hyperfighting on Jul 31, 2022 16:38:36 GMT
0x8bitdev - Many Thanks for helping work the Meta-Sprites out! Big code savings! Many lines removed trying to manually piece those Meta-Sprites together! I'm calling the render "loops" at different points so I'm still setting the positions manually at present...It has to do with the "clouds" only loading if the screen scrolls. The stars that overlap the logo are using sprites "16-19" so they can overlap the logo...so if I'm thinking about this correctly there isn't Clouds/Logo butted up to each other its more like a sandwich with Stars in the middle position wise. Clouds (Pos 0)/Stars (Pos 16)/Logo (Pos 20) Logo Loop (loads first): spd_sprite_params( SPReD_STATIC_SG_arr, 0x6000, SPD_FLAG_IGNORE_SG, 0xff);
spd_SATB_set_pos( 20 ); <--- This position is set first
spd_SATB_push_sprite( ZUKS_TITLE, block.x[0], block.y[0]); Cloud Loop (Only loads if the title screen scrolls) spd_sprite_params( SPReD_STATIC_SG_arr, 0x6000, SPD_FLAG_IGNORE_SG, 0xff);
spd_alt_VRAM_addr(0x5500);
spd_SATB_set_pos( 0 ); <--- This position is set second only if scrolling executes
//Top 3 Mountain Clouds
spd_SATB_push_sprite( CLOUD, block.x[17], block.y[17]);
spd_SATB_push_sprite( CLOUD, block.x[18], block.y[18]);
spd_SATB_push_sprite( CLOUD, block.x[19], block.y[18]);
//Bottom 5 Barrier Clouds
spd_SATB_push_sprite( CLOUD, block.x[7], block.y[7]);
spd_SATB_push_sprite( CLOUD, block.x[9], block.y[7]);
spd_SATB_push_sprite( CLOUD, block.x[11], block.y[7]);
spd_SATB_push_sprite( CLOUD, block.x[13], block.y[8]);
spd_SATB_push_sprite( CLOUD, block.x[15], block.y[8]);My status update is I'm on the tail end of SPReD integration and code refactoring. I'm working on the "LEVEL INTRO" portion - DEMO, TITLE, PLAYER SELECT (Are all completed at this point) I'm still using HuC render calls...I tried inserting the new calls as soon as you released them but broke my code. As soon as I have the "LEVEL INTRO" functional again I will do the final touch of integrating the SPReD library calls to handle the sprite rendering. Thanks again!
|
|
|
|
Post by hyperfighting on Aug 4, 2022 19:25:31 GMT
0x8bitdev - Today is finally the day MAPeD meets SPReD in Zuks! It took me a while due to code refactoring. I'm pretty happy with the result. I have the "SPD_DEBUG" turned on so you can see VRAM usage. "Attract Mode" uses an alternate method for loading VRAM so the pink borders aren't seen there. I'm still using HuC calls for the sprites with the exception of the meta-sprites and spd_SATB_to_VRAM() I tried implementing the LT calls but from my POV I think it will require more logic than what I already have to implement. I'll send you my "animation engine" to see what you think. If you feel there will be significant gains I will change it up.
|
|
|
|
Post by 0x8bitdev on Aug 8, 2022 13:15:08 GMT
hyperfighting , I've taken a look at your 'Animation.h'. IMO at the first sight it looks TOO HEAVY for PCE project and HuC with its awful not so good code generation. Such unified approach can be useful for PC project, where you are not limited in megabyteZ and megahertZ. If you were an experienced game developer, I'd thought that you know what and where you are doing. It's Ok, if you are going to use all that in the Main Menu and it works well on simple scenes. But I wouldn't use such approach in a game session. I'd tried to simplify and may be hardcoded many things to speed up it as possible. Just wanted to be sure that you are not missing one significant moment, you write your game for limited platform and you need to fight for performance. Try to avoid endless switches in your program. Your entity structure size is 2KB... Does it really have to be that fat? BTW, using the entity fields directly without 'struct' definition works faster. Especially since you are using the only one instance of the entity structure. Writing platformer game for PC and for a retro platform like PCE are two different styles of programming. And the last case is the case when knowledge of hardware and low-level programming experience comes in handy to save more memory and CPU time to make your game fast and smooth. p.s.: Implementing the LT calls for simple sprites don't require additional logic. Because they have the same logic as HuC functions, but a bit optimized. The only thing you need to track is a SATB position to write data to. And there is no LT function that works with a pattern code.
|
|
|
|
Post by hyperfighting on Aug 8, 2022 16:37:56 GMT
0x8bitdev - Thank you so much for your analysis! and the terrific SPReD and MAPeD tools! It has been a wild ride and the roller coaster hasn't hit a stop yet! This has and continues to be awesome!! I guess objective A) is to remove the "struct actor" and just reference the members individually. Hoping there is small a boost there =) Regarding the LT function. I just want to clarify regarding I believe to do this effectively you need to do something like this before the SATB position statement spd_sprite_params( <EXPORTED_SG_arr>, 0x6000, SPD_FLAG_IGNORE_SG, 0xff);
spd_alt_VRAM_addr(0x5500);
spd_SATB_set_pos( 0 );
spd_SATB_set_sprite_LT( <exported_name>_frames_arr, spr_ind, X, Y )The issue is, if I I'm thinking about this correctly the "spd_sprite_params (...)" and "spd_SATB_set_sprite_LT" and would need to be referenced by another switch statement so the one size fits all model (animation.h) is integrated into calling the LT functions. In this case I might just keep things the way they are. As you suggest use hard coded LT functions for the game portion for speed purposes and use animation.h for the "menu" system. Regarding Entity structure size.... If it just means reducing the the array size from 50 to another lower number I can do with less. The members themselves were carefully considered during the creation. I know it could always be better fewer members etc Final thoughts on "animation.h" while I wish you thought it was great or goodish...I totally get why you don't think it is an ideal solution for the entire game structure. From where I stand I reduced the original lines of code from the original BETA. Previously every scene had a hardcoded animation system I saw this as redundant so I wanted to make the code footprint smaller in that way. At the least it helped simplify the existing code base. Took away some redundant functions etc... so I think it is good from the perspective of a lighter overall footprint. Again thanks very much for taking the time to review. Now I'm anxious to remove "struct actor"  and get some solid new content created!
|
|
|
|
Post by 0x8bitdev on Aug 8, 2022 19:14:37 GMT
I believe to do this effectively you need to do something like this before the SATB position statement Nevermind. I meant the HuC analogues like 'spd_set_x_LT', 'spd_set_pri_LT' etc... Final thoughts on "animation.h" while I wish you thought it was great or goodish...I totally get why you don't think it is an ideal solution for the entire game structure. From where I stand I reduced the original lines of code from the original BETA. Previously every scene had a hardcoded animation system I saw this as redundant so I wanted to make the code footprint smaller in that way. At the least it helped simplify the existing code base. Took away some redundant functions etc... so I think it is good from the perspective of a lighter overall footprint. When you have limited hardware, hardcoded and fast things are better than universal solutions that take up excess CPU time. |
|
|
|
Post by hyperfighting on Aug 16, 2022 15:09:57 GMT
0x8bitdev - As per your suggestion I have successfully eliminated the use of all structs and significantly reduced the number of declared variables. I also unrolled an unnecessary inner loop and saw some nice speed improvements on the ATTRACT code. Today I am bugging you with two things on my mind. 1. Regarding a High Score. Ideally I would like to use the background map to display the high score so I am not wasting any sprites on it: EX: "SCORE:000000000" does MAPeD have a way to lock in a few chars so that they don't move when the MAP scrolls? I know it is possible to freeze an entire horizontal portion of the screen in the same way the ATTRACT mode has 4 speeds the star field moves at but in my case I just want to freeze the score and only the score. Do you know a way using background tiles? 2. Regarding "Zuks" characters I have "_SPReD_ZUK_chr 0-17" in the past the animations seemed perfectly sequential. EX: IF SPReD has 1.STAR, 2.IDLE, 2.RUN, etc... Then _SPReD_ZUK_chr0=STAR, _SPReD_ZUK_chr1=IDLE, _SPReD_ZUK_chr3=RUN It seemed previously the _SPReD_ZUK_chr# corresponded to the animation in the list but now the order of the CHR files seems off. Not a huge deal through trial and error I can find the animation I am looking for but I am curious regarding this. I will PM you the file in question.
|
|
|
|
Post by 0x8bitdev on Aug 18, 2022 7:42:45 GMT
0x8bitdev - As per your suggestion I have successfully eliminated the use of all structs and significantly reduced the number of declared variables. I also unrolled an unnecessary inner loop and saw some nice speed improvements on the ATTRACT code. Congrats! 1. Regarding a High Score. Ideally I would like to use the background map to display the high score so I am not wasting any sprites on it: EX: "SCORE:000000000" does MAPeD have a way to lock in a few chars so that they don't move when the MAP scrolls? I know it is possible to freeze an entire horizontal portion of the screen in the same way the ATTRACT mode has 4 speeds the star field moves at but in my case I just want to freeze the score and only the score. Do you know a way using background tiles? Neither MAPeD nor MPD library supports fixed HUD area for multidirectional maps. This requires scanline interrupts handling. The MPD library doesn't use its own interrupt handler. Fixing a few chars on the screen is a more complex and strange task than fixed HUD area by scanline interrupts. I wonder if anyone knows any games that use such trick? Most games use scanline interrupts for a fixed HUD. But some games use simple sprites for a HUD area. For example, "The Legendary Axe" uses 8 sprites 32x32 for its HUD and prints score values directly into sprite regions. So this trick can be used as option. But the second part uses scanline interrupts for HUD. You know that you can use the HuC scroll regions for a fixed HUD. But this will limit your game map scrolling to left/right directions only. 2. Regarding "Zuks" characters I have "_SPReD_ZUK_chr 0-17" in the past the animations seemed perfectly sequential. EX: IF SPReD has 1.STAR, 2.IDLE, 2.RUN, etc... Then _SPReD_ZUK_chr0=STAR, _SPReD_ZUK_chr1=IDLE, _SPReD_ZUK_chr3=RUN It seemed previously the _SPReD_ZUK_chr# corresponded to the animation in the list but now the order of the CHR files seems off. Not a huge deal through trial and error I can find the animation I am looking for but I am curious regarding this. I will PM you the file in question. Each exported .bin file is a CHR bank in terms of SPReD. Each CHR bank contains packed (several sprites) or upacked (one sprite) data. SPReD uses one-based CHR bank indexes. Exported data - zero-based indexes. I don't understand why you're concerned about what these files contain? |
|
|
|
Post by hyperfighting on Aug 18, 2022 14:05:49 GMT
0x8bitdev - Thanks for the tips regarding the HUD! I had to ask to see if there was something I was missing here. It looks like sprites might end up being the best way to display a score. Regarding my interest in the .bin CHR bank files. I am declaring all the files per exported SPReD project. EX: My Zuk declaration looks like this.. #include "SPReD_ZUK.h"
extern char* SPReD_ZUK_chr0;
extern char* SPReD_ZUK_chr1;
extern char* SPReD_ZUK_chr2;
extern char* SPReD_ZUK_chr3;
extern char* SPReD_ZUK_chr4;
extern char* SPReD_ZUK_chr5;
extern char* SPReD_ZUK_chr6;
extern char* SPReD_ZUK_chr7;
extern char* SPReD_ZUK_chr8;
extern char* SPReD_ZUK_chr9;
extern char* SPReD_ZUK_chr10;
extern char* SPReD_ZUK_chr11;
extern char* SPReD_ZUK_chr12;
extern char* SPReD_ZUK_chr13;
extern char* SPReD_ZUK_chr14;
extern char* SPReD_ZUK_chr15;
extern char* SPReD_ZUK_chr16;I am doing this so I can use this data in conjunction with the "scale2x" function. I noticed that the stored frames chr0...16 shifted after a recent export so I had to rediscover which CHR Bank correlated to which animation when before I thought it was sequential to the list in SPReD. EX: SPReD GUI has 3 animations (Packed/Unpacked (static)) then those three animations/static sprites would correspond to CHR Bank0, CHR Bank1, CHR Bank2 etc... Am I using the right approach by declaring each CHR Bank, if I intend on enlarging the sprite? This is what I believed I need to do in order to reference each individual 16x16 tile contained within the CHR Banks. If there is a better way I am game! I just need to be pointed in the right direction and I will get to work.
|
|
|
|
Post by 0x8bitdev on Aug 18, 2022 16:04:13 GMT
hyperfighting The problem is that you are using data that is not intended to be used directly by user. It is just a hack. A CHR bank number depends on a sprite creation order. Also the packing/unpacking operation affects a bank index. So while you are working on your sprite set, you are working with floating banks. Alternatively, you could make a separate sprite set for scaled sprites...
|
|
|
|
Post by hyperfighting on Aug 18, 2022 17:55:24 GMT
0x8bitdev - Got it! The method I am using is working fine. I can dig a bit and locate the 16x16 blocks in the existing CHR banks. I am curious and I admit this may sound dumb of me to ask as I believe the answer points to yes... Is declaring CHR Banks expensive? Like declaring the same information twice? EX: #include "SPReD_ZUK.h" //I know "SPReD_ZUK.asm" is declared here...and typically this is all you need to get SPReD exported GFX to display.
extern char* SPReD_ZUK_chr0; //Is declaring each of these bins essentially doubling the size of SPReD exported GFX?
extern char* SPReD_ZUK_chr1;
extern char* SPReD_ZUK_chr2;
extern char* SPReD_ZUK_chr3;
extern char* SPReD_ZUK_chr4;
extern char* SPReD_ZUK_chr5;
extern char* SPReD_ZUK_chr6;
extern char* SPReD_ZUK_chr7;
extern char* SPReD_ZUK_chr8;
extern char* SPReD_ZUK_chr9;
extern char* SPReD_ZUK_chr10;
extern char* SPReD_ZUK_chr11;
extern char* SPReD_ZUK_chr12;
extern char* SPReD_ZUK_chr13;
extern char* SPReD_ZUK_chr14;
extern char* SPReD_ZUK_chr15;
extern char* SPReD_ZUK_chr16;I am asking because if the answer is "yes" then potentially my previous method of declaring GFX via HuC has a smaller footprint. I hope I am wrong and I am overthinking this... At this point I am fully invested in SPReD would there be a way to somehow provide functionality to give access to the 16x16 blocks without having to declare the CHR Blocks individually?
|
|
|
|
Post by 0x8bitdev on Aug 18, 2022 18:15:59 GMT
Is declaring CHR Banks expensive? No, you are declaring far pointers which cost 3 bytes per declaration: bank - byte and address - word At this point I am fully invested in SPReD would there be a way to somehow provide functionality to give access to the 16x16 blocks without having to declare the CHR Blocks individually? Only via your 'scale2x.asm', because there is no way to re-assign far pointers in HuC. |
|
|
|
Post by hyperfighting on Aug 18, 2022 18:40:32 GMT
0x8bitdev - Very much appreciate the explanations! Thank you for putting my mind at ease!  I'll get back to it and let you know when I have something substantial to discuss! Thanks again!
|
|
|
|
Post by 0x8bitdev on Aug 24, 2022 17:08:21 GMT
A little update to MPD library v0.7
Optimized screen scrolling, re-written in assembler. Now it is 3x faster than before.
As usual the changes in the dev build.
|
|
|
|
Post by hyperfighting on Aug 24, 2022 20:45:46 GMT
 0x8bitdev - I can't wait to give this a test drive! I'll plug in the new MPD library v0.7 ASAP! |
|
|
|
Post by 0x8bitdev on Aug 25, 2022 8:27:51 GMT
0x8bitdev - I can't wait to give this a test drive! I'll plug in the new MPD library v0.7 ASAP! Just in case... If you have stable 60 fps in your project, you will not get 180 with the 0.7 You'll not notice any difference in performance. That ' 3x' means that you have a little more frame time for your game logic. But any testing is certainly welcome!  |
|
and get some solid new content created!
