|
|
Post by 0x8bitdev on Jun 3, 2022 17:30:12 GMT
I have a hypothetical question assuming the logo and star sprites are in the same file. Of course, you can combine the stars with the logo in one SPReD project. I told you, group your sprites! My goal is to mimic my current memory locations in the existing project. (I don't see examples assigning unique addresses to certain sprites in a combined file...I'm likely over looking something) When I had separate files for the stars and the logo I exported each one with the appropriate memory address that mimicked my previous project. (I had pretty good results GFX displayed with their respective palettes...movement glitches with the logo...WIP) In the event gfx are combined in one file can unique memory address be assigned? No! One sprite set -> one VRAM address for all sprites for all data set. You assign it when you export data. Why do you need separate VRAM addresses for all your sprites in one data set? The sprite library wants you to just forget about it. Use the ' set_sprite_params' with <exported_project_name>_SPR_VADDR and forget about VADDR. But keep VADDR in mind every time you export data. SPReD Project Pal 0 - Star GFX (Packed) 16x16 frame size Pal 1 - Pal 2 GFX (Single Idle Frame 32x32 for Pal) Pal 2 - Pal 3 GFX (Single Idle Frame 32x32 for Pal) Pal 3 - Pal 4 GFX (Single Idle Frame 32x32 for Pal) Pal 4 - Logo GFX (Packed) 32x32 frame size void LoadGFX_Title()
{
//-BLOCK 1 START-
//In this block I am attempting to load STAR GFX into 0X5000 <--- ??? NO! ONLY EXPORTED CONSTANT ALWAYS!
//Asumming Zuk pals are located 0-3 we are loading a new pal per sprite
//GFX slots mimic the previous projects layout - we are starting from position 16
load_palette( 16 + SPRED_ZUKS_PALETTE_SLOT, SPReD_Zuks_palette, SPReD_Zuks_palette_size >> 4 ); <--- Ok!
spd_sprite_params( SPReD_Zuks_SG_arr, 20480, 0 );//0X5000 <--- ???
spd_SATB_set_pos( 16 );
spd_SATB_push_sprite( SPReD_Zuks_frames_data, SPR_STAR1, P1[GREEN].x, P1[GREEN].y );
load_palette( 17 + SPRED_ZUKS_PALETTE_SLOT, SPReD_Zuks_palette, SPReD_Zuks_palette_size >> 4 ); <--- palette already loaded!!! ??? 17 + ??? 16
spd_SATB_set_pos( 17 ); <--- ??? delete! spd_SATB_set_pos( 16 ) was enough, after this call every spd_SATB_push_sprite increments SATB pos
spd_SATB_push_sprite( SPReD_Zuks2_frames_data, SPR_STAR1, P1[ORANGE].x, P1[ORANGE].y );
load_palette( 18 + SPRED_ZUKS_PALETTE_SLOT, SPReD_Zuks_palette, SPReD_Zuks_palette_size >> 4 ); <--- palette already loaded!!! ??? 18 + ??? 16
spd_SATB_set_pos( 18 ); <--- ??? delete!
spd_SATB_push_sprite( SPReD_Zuks_frames_data, SPR_STAR1, P1[PURPLE].x, P1[PURPLE].y );
load_palette( 19 + SPRED_ZUKS_PALETTE_SLOT, SPReD_Zuks_palette, SPReD_Zuks_palette_size >> 4 ); <--- palette already loaded!!! ??? 19 + ??? 16
spd_SATB_set_pos( 19 ); <--- ??? delete!
spd_SATB_push_sprite( SPReD_Zuks_frames_data, SPR_STAR1, P1[BLUE].x, P1[BLUE].y );
//-BLOCK 1 END-
//-BLOCK 2 START-
//In this block I am attempting to load LOGO GFX into 0X6000 <--- ??? No any attempts! Exported constants ONLY!
load_palette( 16 + SPRED_ZUKS_PALETTE_SLOT, SPReD_Zuks_palette, SPReD_Zuks_palette_size >> 4 );
spd_sprite_params( SPReD_Zuks_SG_arr, 24576, 0 );//0X6000 <--- ???
spd_SATB_set_pos( 20 );
..........
} 1. 16 - sprite palettes offset ALWAYS AND FOREVER. I already regret that I didn’t sew it into a constant when exporting. Thank you!  Use load_palette with set_sprite_params one time! 2. Just do the same what you see in the sample projects. Don't use your own numbers, addresses... Only exported constants! 3. Too many data initialization calls!... Merge all your stars in one project with the logo. I told you about that, group your sprites! |
|
|
|
Post by hyperfighting on Jun 3, 2022 18:12:49 GMT
[upd] 0x8bitdev Thanks for your input here. Did you see the other post after that on the previous page? Regarding the "Zuk" master file?
I now get you are setting up SPReD so 1 simple VRAM address is all it takes to get several well placed sprites in a "scene". If we look at Zuks! here are the scenes we have: TITLE ATTRACT PLAYER SELECT LEVEL INTRO LEVELS So technically a SPReD project could be each one of these scenes. What I don't get is handling overlapping sprites and palette swaps EX: BLUE, GREEN, PURPLE, ORANGE Zuks.If we look at the TITLE scene there are two sprites LOGO and STAR. Having the LOGO and STARS lumped into one SPReD project does not make sense to me at this point. STARS - This is one of many animation sequences for the main character "Zuk" so from my point of view it does not make sense to have the STAR animation lumped with the TITLE logo because the STARS will appear again in the "LEVEL INTRO" and again in the "LEVELS". I'm imagining the STAR sprites being used in other scenes and I'm worried about wasting space on the same "STAR" sprite being loaded into TITLE, LEVEL INTRO and LEVEL scenes etc What does make sense to me is: TITLE - One SPReD project consisting of the logo's 20 - 32x32. The logo has it's memory location and palette allocation. MAIN CHARACTER - One SPReD project consisting of the "Zuk" main character. This project houses all frames of animation and alternate palettes. One of the animations is the Spinning Star. PRO's - I can use "SPReD_Zuk.h" opposed to loading several ".png filez" to load the Zuk character GFX. - I have one project to neatly review all frames and palettes - I can tweak frames and offsets as needed Where I'm a bit lost... I don't want to load every animation into VRAM when I load the MAIN CHARACTER I only want to load up to 8 frames of animation at any given time per character. EX: The TITLE scene requires all 4 Zuks to have identical animations but the PLAYER SELECT requires all 4 Zuks to have unique animations. In the case of the PLAYER SELECT I give a window of 8 frames per character and swap animations as needed. EX: Bad Example of memory allocations I realize they could be closer together but this is the gist. ZUK 1 - 0x5000 ZUK 2 - 0x5800 ZUK 3 - 0x6000 ZUK 4 - 0x6800 So I'm hoping to use the same SPReD project to accommodate loading Zuk Frames into these various Memory Locations but If I exported 4 separate files with different VRAM offsets would that create alot of unnecessary duplicate GFX data? Just hoping to get a little more clarity here. I'm sorry for being a bother things are still a bit murky but they are starting to get clearer.... P.S - I also see the cloud being used in several "SCENES" so I see the cloud on its own in its own file...I am really hung up on loading the same files multiple times if all I need is one instance loaded into ROM. I am concerned multiple SPReD scenes with the same GFX bloats the ROM...I hope I'm making sense. P.P.S - I have been looking at SPReD as a sprite catalog. Pull whatever sprite you want out of the catalog and load it into VRAM as desired. It is a great way to neatly organize and position sprites, pals - initially I believed it was possible to call and load any GFX to any VRAM location at anytime. I didn't realize the intention is load every single sprite in a SPReD project into VRAM when initialized. Could there be a way to manually load to specific packed sprites into vram locations? [upd] I'm updating my update lol....As mentioned above my perception of SPReD has been a "catalog" it's handy because you can always browse a catalog and see whats what. If I could just load elements of the catalog at will my SPReD projects would look something like this: STATIC - Logo, Cloud, Falling Brick ZUKS - Character Sprite Animations ZUPAPA - All Animations ZUMAMA - All Animations ENEMY 1 - All Animations ENEMY 2 - All Animations ENEMY 3 - All Animations etc... This way I benefit from having a nice SPReD project to view, edit and group sprites. I can mix and match sprites in any combination with no fear of "doubling" GFX data. In my case I might not use the "SCENES" approach EX: worry about whats loaded in each "SCENE" "CATALOG" approach. EX: Mix and match as desired. Need a way to specifically load a packed animation/static sprite in a catalog to VRAM I think there is a use case here. The user can benefit from SPReD and load GFX as desired. More technical with the memory allocations but catalogs are easy to conceptualize and a great organizational tool. Catalogs all the way! Can it work like that? Just make sure the pals allocated in one catalog don't overlap another and you are gold.
|
|
|
|
Post by hyperfighting on Jun 4, 2022 16:09:27 GMT
0x8bitdev Just an FYI I updated the post above earlier this AM ^ (Just in case you didn't see it) I have been experimenting... I am loading my Logo GFX into pal 15 on import. When I export I am selecting slot 15 and I get the error message "the palette data doesn't fit into 16 slots." When I try to compile I get an error. If I export with slot 0 selected I get no error on compile. This is the SPReD file I have been playing with using for export. STATIC.spredpce (24.77 KB)
|
|
|
|
Post by hyperfighting on Jun 4, 2022 17:29:16 GMT
0x8bitdev I did my very best to make a clean test project -> Zuk SPReD TestNote: On compile I get: (Warning. Opcode crossing page boundary $8000, bank $0B)I am combining my STATIC catalog and my MAIN CHARACTER catalog. STATIC catalog (packed 32kb)- currently 20 - 32x32 simple sprites assigned to Pal 15 exported to slot 0 (as mentioned exporting to slot 15 gives an error) exported to 0x6000 MAIN CHARACTER catalog (packed 32kb per animation) - currently all Zuk animations Pal 0-4 exported to slot 0 exported to 0x5000
|
|
|
|
Post by 0x8bitdev on Jun 5, 2022 10:59:51 GMT
hyperfighting First of all, thanks for pointing out my mistake. I've fixed the exported palette data. Now ' load_palette' only accepts exported constants as input! No any '16+' and '>>4' or something else! The ' load_palette' in your HuC project MUST looks like this: load_palette( <EXPORTED_NAME>_PALETTE_SLOT, <exported_name>_palette, <exported_name>_palette_size ); The updated SPReD and the samples you can find in the dev build. So re-export your SPReD projects and fix the ' load_palette' in your HuC project. ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- And you are right. I've missed something... If you will share the same characters in the main menu and in a game session, the logo sprite is unwanted in the characters data set. So you can absolutely legally separate these two sets. But don't forget about simple sprites sorting by size I mentioned before! And as I mentioned just forget about things like this: EX: Memory Slot 1 0x5000 - CRY
EX: Memory Slot 2 0x5800- CHARGE
EX: Memory Slot 3 0x6000- CHEER
EX: Memory Slot 4 0x6800- IDLEYou'll have ONE VRAM address for whole data set. I hope this is clear. In your HuC program you'll operate with sprite index or sprite data pointer. And yes, for simple sprites you can use HuC's spr_ctrl(FLIP_MAS, flipState)If we look at the TITLE scene there are two sprites LOGO and STAR. Having the LOGO and STARS lumped into one SPReD project does not make sense to me at this point. STARS - This is one of many animation sequences for the main character "Zuk" so from my point of view it does not make sense to have the STAR animation lumped with the TITLE logo because the STARS will appear again in the "LEVEL INTRO" and again in the "LEVELS". I'm imagining the STAR sprites being used in other scenes and I'm worried about wasting space on the same "STAR" sprite being loaded into TITLE, LEVEL INTRO and LEVEL scenes etc What does make sense to me is: TITLE - One SPReD project consisting of the logo's 20 - 32x32. The logo has it's memory location and palette allocation. MAIN CHARACTER - One SPReD project consisting of the "Zuk" main character. This project houses all frames of animation and alternate palettes. One of the animations is the Spinning Star. PRO's - I can use "SPReD_Zuk.h" opposed to loading several ".png filez" to load the Zuk character GFX. - I have one project to neatly review all frames and palettes - I can tweak frames and offsets as needed I completely agree. If the stars appear in many scenes without logo it makes sense to store them in a separate data set. The same relates to the main character. Where I'm a bit lost... I don't want to load every animation into VRAM when I load the MAIN CHARACTER I only want to load up to 8 frames of animation at any given time per character. EX: The TITLE scene requires all 4 Zuks to have identical animations but the PLAYER SELECT requires all 4 Zuks to have unique animations. In the case of the PLAYER SELECT I give a window of 8 frames per character and swap animations as needed. EX: Bad Example of memory allocations I realize they could be closer together but this is the gist. ZUK 1 - 0x5000 ZUK 2 - 0x5800 ZUK 3 - 0x6000 ZUK 4 - 0x6800 So I'm hoping to use the same SPReD project to accommodate loading Zuk Frames into these various Memory Locations but If I exported 4 separate files with different VRAM offsets would that create alot of unnecessary duplicate GFX data? Just hoping to get a little more clarity here. I'm sorry for being a bother things are still a bit murky but they are starting to get clearer.... Again that 0x5000, 0x58... Look, one data set of packed sprites means that the whole data you can see in the CHR bank will be loaded to VRAM. So it depends on data amount. If memory allows to load whole data with all animations -> load it and use sprites with all animations. If your PLAYER SELECT mode uses characters with unique animations, just make a separate SPReD project for that. Don't mix unique animations for the PLAYER SELECT mode with the character sprites you will use in a game session. Once more. If the TITLE uses one animations set for characters, the PLAYER SELECT another one, in-game characters the third one -> just make three independent data sets for your characters and use them separately. Ask if something isn't clear. P.S - I also see the cloud being used in several "SCENES" so I see the cloud on its own in its own file...I am really hung up on loading the same files multiple times if all I need is one instance loaded into ROM. I am concerned multiple SPReD scenes with the same GFX bloats the ROM...I hope I'm making sense. If the cloud sprite you will use in the main menu only, you can add it to the logo data set. Such small things that appear in one mode, for example, in the main menu, you can unite together. Otherwise you need a separate data set. P.P.S - I have been looking at SPReD as a sprite catalog. Pull whatever sprite you want out of the catalog and load it into VRAM as desired. It is a great way to neatly organize and position sprites, pals - initially I believed it was possible to call and load any GFX to any VRAM location at anytime. I didn't realize the intention is load every single sprite in a SPReD project into VRAM when initialized. Could there be a way to manually load to specific packed sprites into vram locations? [upd] I'm updating my update lol....As mentioned above my perception of SPReD has been a "catalog" it's handy because you can always browse a catalog and see whats what. Once more: PACKED (sprites were packed in SPReD) sprites help you group data to not to move it ROM->VRAM often. Just load it and use it! UNPACKED (each sprite has its own CHR bank) sprites split your data into pieces - separate sprites that you can load to VRAM separately at the same VADDR. This useful for meta-sprites. So the art of using SPReD is your ability to organize and group data for efficient use. I am loading my Logo GFX into pal 15 on import. When I export I am selecting slot 15 and I get the error message "the palette data doesn't fit into 16 slots." When I try to compile I get an error. If I export with slot 0 selected I get no error on compile. It's Ok! Your project uses 16 palettes. SPReD counts used palettes by the maximum palette used by any sprite. Just don't make data holes in the palettes. Import the logo to #0 palette and export it to #15 if you need that. ----------------------------------- I'll take a look at the test project. [upd]: I need your SPReD projects.
|
|
|
|
Post by hyperfighting on Jun 5, 2022 18:20:16 GMT
0x8bitdev - I got the new dev version and made the adjustment in the base project regarding loading palettes! I've been adjusting my Zuks Main Character File. In case having the pal files at the top was an issue. I adjusted the export to have all the 16x16 files at the top of the list.  I've re-exported the Logo properly using pal 0 to import the 20 .bmp files and using pal 15 to export the logo. I've been playing with the "Player Select" scene trying to get 4 Zuks loading with separate animations etc. I haven't been having much luck there. That's the update so far. I'm gonna work on getting the enemy filez formatted for SPReD. [upd] One thing that is driving me a bit crazy is that SPReD only loads 4-bit images. Google research shows if an image has 15 colours it can be saved as 4-bit. However TG-16 supports 16 colours (15+Knockout)
I need to reduce my palette to (14+Knockout to save my .bmp as 4-bit)
Here is a sample file. That won't load into SPReD but I believe it is legal in the sense that TG-16 supports it based on it having 16 colours (15+Knockout)
BoneBat_LAUGH.bmp (2.05 KB)
|
|
|
|
Post by 0x8bitdev on Jun 6, 2022 13:51:07 GMT
I've been adjusting my Zuks Main Character File. In case having the pal files at the top was an issue. I adjusted the export to have all the 16x16 files at the top of the list. It depends on VRAM address of your data and respectively sprite data alignment. [upd] One thing that is driving me a bit crazy is that SPReD only loads 4-bit images. Google research shows if an image has 15 colours it can be saved as 4-bit. However TG-16 supports 16 colours (15+Knockout)
I need to reduce my palette to (14+Knockout to save my .bmp as 4-bit) 4-bits is the range 0..15 -> 16 colors in total I've seen the same issue with your BMP image like in your logo palette in SPReD - data hole. Your 'BoneBat_LAUGH' uses the last 16 colors in 256 colors palette. So actually you have 256-colors image that uses the last 16-colors. To solve the issue, make your image RGB and then back to the indexed format and save it as 4-bit BMP. This way you'll get a correct 4-bit/16-color image that you can use with SPReD. |
|
|
|
Post by hyperfighting on Jun 6, 2022 14:11:37 GMT
0x8bitdev First thanks for that conversion technique. That was sloppy and totally makes sense. Convert the BoneBat_Laugh to RGB change to index color and BAM you can save as 4 bit! Well here's a fun one! So I make what I call a "FilmStrip" or what others may call a "Sprite Sheet" in any case I have all the frames I want 16 total colours and I want to maintain the palette order for successful import into SPReD. So I use CANVAS SIZE in PS. 1. CANVAS SIZE 32x32, CONSTRAINED TO TOP, save to .bmp 2. (CTRL + Z undo previous action to return filmstrip total height) CANVAS SIZE 32x64, CONSTRAINED TO TOP, CANVAS SIZE 32x32, CONSTRAINED TO BOTTOM, save to .bmp On and on where 64 is adjusted to the next frames position. In this case PS never gives a 4-bit .bmp option on save. (I also convert to a .png using RGB back to index no luck) BoneBat_STRIP.bmp (15.12 KB) I'll keep busy formatting sprites but I would love a clean way to break the strips into 4-bit .bmp or .png images. I was able to achieve the Zuks because I removed one colour out of my "Filmstrip". It seems PS CC/CS6 associates the 4 bit .bmp save option with 15 colours total in some cases. Any feedback on the Test File? Is there a cleaner way to do palette swapping?
|
|
|
|
Post by gredler on Jun 6, 2022 16:53:28 GMT
The process you're describing is inheritently built into promotion to easily save animations into sheets with shared 4 bit palettes, but if you are using photoshop the best example I can suggest is saving the color table out as a pal, then crate an action to batch apply color mode and table choice using that pal. Photoshops algorithm will pick which pixels are which colors though so it's not easily controllable and you may get some unexpected pixel color assignments.
|
|
|
|
Post by 0x8bitdev on Jun 6, 2022 17:29:54 GMT
Houston, we have a problem! You haven't understood a little, but significant thing: One data set -> One SPReD project
You have mixed packed & unpacked sprites in one project... The sprite library doesn't work this way. Either PACKED sprite set, or UNPACKED. BUT you can mix PACKED/UNPACKED sprite sets in your HuC project. Your characters set already takes 28K... Another bad point is that your character takes ~25% of a sprite area... that wastes a lot of memory just on an empty space... It's hard to suggest something, because I don't know how much the gameplay and VRAM during the gameplay will be loaded with other things. So you need to split that 28K into parts for caching in VRAM when needed.
Well here's a fun one! So I make what I call a "FilmStrip" or what others may call a "Sprite Sheet" in any case I have all the frames I want 16 total colours and I want to maintain the palette order for successful import into SPReD. So I use CANVAS SIZE in PS. 1. CANVAS SIZE 32x32, CONSTRAINED TO TOP, save to .bmp 2. (CTRL + Z undo previous action to return filmstrip total height) CANVAS SIZE 32x64, CONSTRAINED TO TOP, CANVAS SIZE 32x32, CONSTRAINED TO BOTTOM, save to .bmp On and on where 64 is adjusted to the next frames position. In this case PS never gives a 4-bit .bmp option on save. (I also convert to a .png using RGB back to index no luck) Any feedback on the Test File? Is there a cleaner way to do palette swapping? Photoshop is too "smart" to do such simple things. You can try the following: save your images as 8-bit and then reload and resave it as 4-bit. Did you try something else, for example Gimp? To be honest, I don't know how it works with such tasks. |
|
|
|
Post by hyperfighting on Jun 6, 2022 17:51:21 GMT
gredler - Thanks a bunch for the input! elmer is going to chime in any second a reiterate not to use PS lol I'll keep playing around and report back thanks for your input as well 0x8bitdev ! 0x8bitdev said: I think the only sprites I didn't pack are the Idle frames because they were only one frame and I imagined they were already packed! Dually noted I will pack all and try again. Regarding using 25% of sprite area did my previous method of loading the sprite into 0x5000-0x5800 use the same percentage? In that case I was swapping sets of animation as needed. EX: Load Run to 0x5000, Player is now standing still Load Idle to 0x5000 etc... The Stars in the "TILE" screen also use the 0x5000 method because all animations mirror each other. In the case of "PLAYER SELECT" we go back to the idea of Zuk 1 - 0x5000 Zuk 2 - 0x5800 Zuk 3 - 0x6000 Zuk 4 - 0x6800 I know you said to forget about this method but if it uses less of the "sprite area" should I stick with it? [upd] I guess the way I was seeing it two slots EX: 0x5000 and 0x5800 are used for the Zuks during gameplay the rest of the slots are used for other things. [upd] How can I tell if all sprites in a set are packed? My process is to individually pack each animation. I still see a render glitch with the spinning stars. My process.... IDLE_PAL1 (32KB packed) .... RUN1-RUN8 (32KB packed) So the Zuks File has several individual packed animations and now I have packed all the individual frames etc... Maybe a warning when things a mismatched? I'm not sure where I have gone wrong?
|
|
|
|
Post by 0x8bitdev on Jun 6, 2022 18:52:14 GMT
regarding using 25% of sprite area did my previous method of loading the sprite into 0x5000-0x5800 use the same percentage? It doesn't depend on the method you use. Take a look at the character sprites. Most of them use ~25% of a sprite area and the rest is an empty space. Click the 'Splitting' button and then 'Packing' with 32KB size. You'll see a lot of empty space in sprite data. You can't do anything with it. It looks like wasting of a memory on NEO-GEO wasn't a problem.  In that case I was swapping sets of animation as needed. EX: Load Run to 0x5000, Player is now standing still Load Idle to 0x5000 etc... The Stars in the "TILE" screen also use the 0x5000 method because all animations mirror each other. In the case of "PLAYER SELECT" we go back to the idea of Zuk 1 - 0x5000 Zuk 2 - 0x5800 Zuk 3 - 0x6000 Zuk 4 - 0x6800 I know you said to forget about this method but if it uses less of the "sprite area" should I stick with it? [upd] I guess the way I was seeing it two slots EX: 0x5000 and 0x5800 are used for the Zuks during gameplay the rest of the slots are used for other things. I said because I didn't know a scale of disaster, how many kilobytes will take you character data. If you would use packed data for all the sprites, you would know how many bytes the sprite data takes up. The info below CHR bank or File->Statistics. Well, then try it with your slot system. |
|
|
|
Post by gredler on Jun 6, 2022 19:27:34 GMT
regarding using 25% of sprite area did my previous method of loading the sprite into 0x5000-0x5800 use the same percentage? It doesn't depend on the method you use. Take a look at the character sprites. Most of them use ~25% of a sprite area and the rest is an empty space. Click the 'Splitting' button and then 'Packing' with 32KB size. You'll see a lot of empty space in sprite data. You can't do anything with it. It looks like wasting of a memory on NEO-GEO wasn't a problem. I was wondering why there was so much empty space on those character sheets I opened up to find the palette issues on. the caracters seem to fit with a 16x16 quadrant but they are centered oddly onto the sheet wasting a lot of pixel space |
|
|
|
Post by hyperfighting on Jun 6, 2022 19:56:40 GMT
gredler - The bad spacing was just an easy way to line up animations but in the vein of optimization all sprites should be left, bottom aligned to optimize as much tile space as possible. So the thing that was so exciting to me was that SPReD supports Meta-Sprites among other cool features. My initial thought was to left,bottom align all frames to remove the weird spacing and optimize the sprites. So in many cases the sprites would be a 32x16 +16x16 Meta Sprite after 1 tile is removed. 0x8bitdev made it clear to me that in it's current state SPReD only supports 16x16 Meta sprites so each frame would take up 3 sprites (16x16+16x16+16x16) in the SATB As I understand it Simple 32x32 sprites are faster to process than Meta-Sprites and they only take up 1 sprite in the SATB so I left the spacing as is. I'm not sure there is a solid way to optimize the sprites at this point? On NeoGeo they would either break a frame to a meta sprite (16x32 + 16x16) and save the one tile or just load a whole 32x32 frame wasting the tile depending on what they felt like doing. There is definitely more wiggle room dealing with variable sized cartridges! In either case they are using 2 sprites of 96 but in the one case they save the 1 tile per frame in ROM. 0x8bitdev were you able to run the test project without glitches? I retried exporting the file with what I think is packed animations but I'm still glitching. [upd] 0x8bitdev is there a way to make the "slot" system work with SPReD?
|
|
|
|
Post by 0x8bitdev on Jun 7, 2022 9:44:13 GMT
0x8bitdev were you able to run the test project without glitches? I retried exporting the file with what I think is packed animations but I'm still glitching. Of course. I'll explain it later. You've done some mistakes when switching between data sets. [upd] 0x8bitdev is there a way to make the "slot" system work with SPReD? I'm trying to make it possible. I'll let you know. |
|
