Dev tools: MAPeD-SPReD (win/linux)

[0x8bitdev]

May 30, 2022 15:57:04 GMT hyperfighting said:

You are right I am very limited and handicapped when referring to address multiples etc. I am probably told to go read some documentation. I'm sorry I got where I am from examples and lots of trial and error.
My takeaway is I can leave the export setting at 128 for my simple sprite exports.

You can use default settings. But when you'll stack different sets of sprites in VRAM you will need to take alignment into account.

An address multiple of 0x0200, 0x0100, 0x0080, 0x0040 - this is when the address is divided without a remainder by 0x0200, 0x0100, 0x0080, 0x0040.

[hyperfighting]

0x8bitdev SPReD is super cool! I'm getting my bearings and I have an observation I was wondering if you could clear up.

I believe you classify 16x32 sprites as 32 pixels tall and 16 pixels wide. Please see the image below.



I think I have the process down to create your 16x32 sprites

1. Start with a 32x32 sprite.
2. Create a reference sprite.
3. Ensure both sprites have the correct naming for export.

My observation is that in HuC I believe a 16x32 sprite is 32 pixels long and 16 pixels high.

I am in the process of converting all sprites to SPReD and my original code appears like this for the cloud images...

My source file is 32 pixels long by 16 pixels tall.

spr_make(Cloud1Front1,block[17].x,block[17].y,spritepattern1,FLIP_MAS|SIZE_MAS,NO_FLIP|SZ_32x16,27,1);
In your documentation you refer to LEFT and RIGHT but is there a provision for TOP and BOTTOM assuming 32 pixels is the width?

[upd] Please don't kill me examples clearly show 32x16 this was a useless post. With the exception of the steps to create a 16x32 sprite. Sorry! doh!

[0x8bitdev]

hyperfighting

1. Your cloud sprite is 64x16. So why don't you create your cloud sprite as two 32x16 sprites ? 
2. Are you going to make a separate SPReD project for each of your sprites ?

[hyperfighting]

1. 110% clouds will be 2 - 32x16 sprites.

Totally missed the broom stick in the examples!
I stupidly believed if a sprite was 16x anything other than 16 I need to do a special operation but I now realize I am ok to simply create 32x16 sprite with no hassel.

2. It is my plan to have a separate SPReD.h per sprite set many sprites per set packed. This is easier for me to manage. Does this hurt performance for me in anyway?

[0x8bitdev]

Jun 2, 2022 14:37:49 GMT hyperfighting said:

110% clouds will be 2 - 32x16 sprites.

I stupidly believed if a sprite was 16x anything other than 16 I need to do a special operation...

You are right, if a simple sprite is 16x anything other than 16, it is a sprite 16x32 or 16x64 and you need to do a special operation on it. But your cloud sprite isn't 16x something. 

Jun 2, 2022 14:37:49 GMT hyperfighting said:

It is my plan to have a separate SPReD.h per sprite. This is easier for me to manage. Does this hurt performance for me in anyway?

This just negates the whole point of using SPReD. With the same success you can leave PCX images in your project.

The main goal of using SPReD is that you can group you sprite graphics which helps you quickly switch between sprite data in your project. For example, you can move all your main menu or in-game sprite graphics to VRAM by calling a few SPD functions.

But when you are using 101 SPReD projects for all your 101 sprites... What is the benefit of such use? It is the same as what you did before with PCX sprites.

[gredler]

May 29, 2022 14:07:24 GMT hyperfighting said:

All that said I am still screwed, nude and tattooed with the Zuks.pcx files I keep mentioning like a broken record. I feel like the OG devs on this forum have seen this phenomena before when preparing sprites for older versions of HuC if anyone can help it would be greatly appreciated again here is a tiny before and after (I'm trying to convert the After to the Before) to date PS CS 6, PS CC, Gimp 2.10.22, Image Magick, Konvertor etc loads black images and yet they build in my HuC project.

PCX -> Zuk Sprites Before and After

OK I figured out why your sprites are showing up black in editor, and it's a super simple fix.

Your palette was reversed by your batch, but the actual color index assignments to pixels was not. Your palette in the converted image is colors 0-16, but the pixels are still looking for the colors from 239-255. If you move the colors from 0-16 to 239-255 the image displays correctly, no problem. This can be done in gimp or promotion, possibly other editors, but not photoshop as far as I know you can't reorder indexed color pallettes in photoshop.

[elmer]

Jun 2, 2022 17:53:55 GMT gredler said:

This can be done in gimp or promotion, possibly other editors, but not photoshop as far as I know you can't reorder indexed color pallettes in photoshop.

Absolutely!

Folks ... please do NOT use Photshop to work on color-paletted files, Photoshop has a really nasty habit of rearranging the palette whenever it feels in the mood to do so, and that can make your artwork unusable in a retro-game project without a lot of re-working.

This is NOT a bug or problem with Photoshop itself, it is a consequence of how it was designed ... it was NEVER meant to be used in reto-game projects for developing art.

[0x8bitdev]

Jun 2, 2022 18:28:35 GMT elmer said:

Absolutely!

Folks ... please do NOT use Photshop to work on color-paletted files, Photoshop has a really nasty habit of rearranging the palette whenever it feels in the mood to do so, and that can make your artwork unusable in a retro-game project without a lot of re-working.

This is NOT a bug or problem with Photoshop itself, it is a consequence of how it was designed ... it was NEVER meant to be used in reto-game projects for developing art.

This is more related to the PCX format.

If you need an indexed PNG/BMP to import into MAPeD/SPReD, you can use Photoshop for that. I have not found any issues working in Photoshop with PNG/BMP images.

And, of course, if you know how to work with an indexed PNG/BMP in Photoshop. 

[gredler]

Are there any resources you can point to with working with color tables in photoshop? I've found pixel color assignment and table index order to be a chore in photoshop. The only method I am aware of is the image > mode > color table... window. With that you can change each index value individually but not which pixel is assigned to that index from a similar window. Changeing/swapping order is a real pita with this window.

I love photoshop and have about 25 years more experience with it than promotion and would love to have the option to use both if possible, but the palette managed stuff is such a burden I almost entirely stopped using photoshop

What does the output file have to do with it btw? PSD, PNG, BMP, PCX all behave identically for me in photoshop - the differentiating factor is the color mode that the currently opened image is in (indexed vs rgb, cmyk, etc)



Edit: actually it's not a method of working with it directly but the save for web feature is something I just remembered using years ago to automatically truncate colors to 16 and remove duplicates/similar colors which was helpful. I believe you get similar options when converting to indexed from rgb but I haven't worked in rgb tehn converted to indexed in years so my memory is foggy

[elmer]

Jun 2, 2022 18:59:08 GMT 0x8bitdev said:

I have not found any issues working in Photoshop with PNG/BMP images.

Lucky you!

While it is possible that something has *dramatically* changed in Photoshop in recent years, I have known enough professional video-game artists who have had a problem, that I kinda trust their opinion on this.

[turboxray]

Jun 2, 2022 17:53:55 GMT gredler said:

Your palette was reversed by your batch, but the actual color index assignments to pixels was not. Your palette in the converted image is colors 0-16, but the pixels are still looking for the colors from 239-255. If you move the colors from 0-16 to 239-255 the image displays correctly, no problem. This can be done in gimp or promotion, possibly other editors, but not photoshop as far as I know you can't reorder indexed color pallettes in photoshop.

There are ways to do it. But I wrote a utility for ACT and PAL files. You just export the pal file in photoshop, give it to this util, and then convert image to RGB, then index and say use this custom PAL and it will snap all the colors for you.

[hyperfighting]

gredler - You are the man son! Thank you so much for solving this mystery!! I busted out my promotion and sure enough your method works! Thanks again! I thought these filez were lost to the abyss!

I'm with you Photoshop all day. It's where my comfort level is. The trade off it index's colours how it wants. I find more times than not if 255, 0 255 magenta is used as the knockout colour then it will be the first in the palette when photoshop indexes the image.
Prior to MAPeD and SPReD, in the case the "knockout" colour was misplaced in the wrong order Gimp's colour re-arrange tool is gold. 
Now that we are in the area of the MAPeD and SPReD tools 0x8bitdev allows great control over palettes so using PS is a great viable option as palette adjustments can be made via his packages.

The one thing I will comment on is PS CS 6 and CC sometimes give me grief regarding saving a .bmp as 4bit.
I know my image is indexed and has 16 total colours but in some cases the 4bit option will not light up when I save!? So to get around it I unindex (rgb) and reindex and that solves it.  

0x8bitdev - doh you are right my cloud sprite isn't 16 x something...lame on my behalf.

This just negates the whole point of using SPReD. With the same success you can leave PCX images in your project.

To this point I agree.  

The main goal of using SPReD is that you can group you sprite graphics which helps you quickly switch between sprite data in your project. For example, you can move all your main menu or in-game sprite graphics to VRAM by calling a few SPD functions.

As per usual I am behind on the tech and application. I will push all my sprites through in one SPReD project and see if I can make heads or tails of it.
So far things are pretty good TITLE, CLOUDS and 16x16 Stars are all in.
I was so nervous of the 16x16 stars because they will no longer line up cleanly with the 32x32 Zuk Frames but your offset feature in SPReD made that a breeze!

[0x8bitdev]

Jun 2, 2022 20:05:50 GMT elmer said:

While it is possible that something has *dramatically* changed in Photoshop in recent years, I have known enough professional video-game artists who have had a problem, that I kinda trust their opinion on this.

Did they break Photoshop?!   Where is this world going?.. If even Photoshop can't be used for drawing and saving images! 

Jun 2, 2022 19:13:35 GMT gredler said:

I love photoshop and have about 25 years more experience with it than promotion and would love to have the option to use both if possible, but the palette managed stuff is such a burden I almost entirely stopped using photoshop

You are right, working with color tables is missing in Photoshop. But in a context of this thread, even poor Photoshop can be used. Because MAPeD supports import images with ordered and unordered palettes. In the last case the resulting palette will be packed optimally to reduce the number of active palettes. And a color swapping option is available in both MAPeD/SPReD. So all these little things expand the palette of possible external tools.

Jun 2, 2022 22:54:50 GMT hyperfighting said:

I will push all my sprites through in one SPReD project and see if I can make heads or tails of it.
So far things are pretty good TITLE, CLOUDS and 16x16 Stars are all in.

Since your title sprite has many parts, you can leave it in a separate project. Be flexible.

Put away your keyboard, take your pen and notepad, re-read this, then think and try to figure out what sprites are in your project, where and how in your project you are using them, how to group them, and is it really necessary...

[hyperfighting]

0x8bitdev - Dually noted on analyzing the needs per scene and carefully reviewing the documentation.
I will definitely take your advice on leaving the ZuksLogo as a seperate SPReD project.

I have a hypothetical question assuming the logo and star sprites are in the same file.
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)
I am struggling with memory assignment, effectively loading GFX, handling alternate palettes.

I want to do something like this...I know I'm dead wrong but I would love some pointers.

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?

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
  //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 );
  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 );
  spd_SATB_set_pos( 17 );
  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 );
  spd_SATB_set_pos( 18 );
  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 );
  spd_SATB_set_pos( 19 );
  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  
 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 );

 spd_SATB_push_sprite( SPReD_Zuks_frames_data, SPR_Z1, block[0].x, block[0].y );
 spd_SATB_push_sprite( SPReD_Zuks_frames_data, SPR_Z2, block[0].x, block[1].y );
 spd_SATB_push_sprite( SPReD_Zuks_frames_data, SPR_Z3, block[0].x, block[2].y );

 spd_SATB_push_sprite( SPReD_Zuks_frames_data, SPR_Z4, block[1].x, block[0].y );
 spd_SATB_push_sprite( SPReD_Zuks_frames_data, SPR_Z5, block[1].x, block[1].y );
 spd_SATB_push_sprite( SPReD_Zuks_frames_data, SPR_Z6, block[1].x, block[2].y );

 spd_SATB_push_sprite( SPReD_Zuks_frames_data, SPR_Z7, block[2].x, block[0].y );
 spd_SATB_push_sprite( SPReD_Zuks_frames_data, SPR_Z8, block[2].x, block[1].y );
 spd_SATB_push_sprite( SPReD_Zuks_frames_data, SPR_Z9, block[2].x, block[2].y );

 spd_SATB_push_sprite( SPReD_Zuks_frames_data, SPR_Z10, block[3].x, block[0].y );
 spd_SATB_push_sprite( SPReD_Zuks_frames_data, SPR_Z11, block[3].x, block[1].y );
 spd_SATB_push_sprite( SPReD_Zuks_frames_data, SPR_Z12, block[3].x, block[2].y );

 spd_SATB_push_sprite( SPReD_Zuks_frames_data, SPR_Z13, block[4].x, block[0].y );
 spd_SATB_push_sprite( SPReD_Zuks_frames_data, SPR_Z14, block[4].x, block[1].y );
 spd_SATB_push_sprite( SPReD_Zuks_frames_data, SPR_Z15, block[4].x, block[2].y );

 spd_SATB_push_sprite( SPReD_Zuks_frames_data, SPR_Z16, block[5].x, block[0].y );
 spd_SATB_push_sprite( SPReD_Zuks_frames_data, SPR_Z17, block[5].x, block[1].y );
 spd_SATB_push_sprite( SPReD_Zuks_frames_data, SPR_Z18, block[5].x, block[2].y );

 spd_SATB_push_sprite( SPReD_Zuks_frames_data, SPR_Z19, block[6].x, block[0].y );
 spd_SATB_push_sprite( SPReD_Zuks_frames_data, SPR_Z20, block[6].x, block[1].y );
 //-BLOCK 2 END-

}

[hyperfighting]

Here is what I've been up to...

Curious if this seems logical.

1. 1-SPReD project for the Logo.
2. 1-SPReD project for the Zuk

IDLE_PAL1,2,3 - Are 32x32 frames for the purpose of generating palette swaps.

Every Animation with a unique name is packed with 32KB

All frames are 32x32 with the exception of the Star Sprites being 16x16.

Star animation to the bottom of the list share the same Palette.

Based on the question above the Zuks need separate memory slots and separate palettes  when they are in PLAYER SELECT MODE they are doing unique animations.

This example serves better than the previous in that at this point I believe my structure is getting closer to final.

My intention is to only add 1 packed set of animation frames per memory slot and swap them out as needed.

0-Pal Zuk Colour 1
1-Pal Zuk Colour 2
2-Pal Zuk Colour 3
3-Pal Zuk Colour 4 - All Sprites use this pal

Allowing 8 unique 32x32 frames per slot

EX: Memory Slot 1 0x5000 - CRY
EX: Memory Slot 2 0x5800- CHARGE
EX: Memory Slot 3 0x6000- CHEER
EX: Memory Slot 4 0x6800- IDLE



[upd] I am hoping not duplicate the frames and add LEFT/RIGHT - I would use the HuC's "spr_ctrl(FLIP_MAS, flipState);"