|
|
Post by hyperfighting on May 27, 2022 19:22:22 GMT
gredler I think I screwed the .pcx files up. I tried Gimp / PS CC / ImageMagick / Konverter Back in the day I had a heck of a time getting my .pcx files to display on PCE Eventually I figured some method out. The script I posted reverses all the colour values. I likely mucked up the files with the pcxtool. They always load as all black images in image viewers but they still compile properly.
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on May 27, 2022 20:14:17 GMT
Indexing your pixel art under ---> image --> mode then exporting it as a .pcx doesn't work using GIMP?
|
|
|
|
Post by hyperfighting on May 27, 2022 21:48:20 GMT
@shmglsky not in this case if you download the .pcx files you will see what I mean. I did some sort of post operation on the files back in the day.
|
|
|
|
Post by hyperfighting on May 28, 2022 16:22:26 GMT
So I'm still hung up on trying to reverse whatever weird format I managed to get the Zuk GFX into. I am shocked I never documented my steps to alter these filez. I was able to find what I believe to be an unconverted sprite and the equivalent converted sprite. I also included the .bat that swaps all the palette entries. In PS CC image->mode->color table Shows the normal image with the palette at the top and the converted image with the palette at the bottom of the 16 palette table. Despite running this script again and reversing the values back the image still displays black. A .zip with a file before and after conversion -> Good and Bad FileI got a program called Konvertor that allows me to view the files in HEX. They look familiar but then eventually the values change. This is beyond my depth but this where this research has led me so far. Haven't given up yet. |
|
|
|
Post by 0x8bitdev on May 28, 2022 16:44:23 GMT
Let's start from the basics:1. Simple sprites are sprites: 16x16, 16x32, 16x64, 32x16, 32x32, 32x64... In other words, such sprite uses ONE entry in SATB. 2. Simple sprites are faster than meta-sprites. HuC's sprite functions are the fastest way to work with simple sprites. Because you can reserve ONE SATB entry for one sprite and use it to manipulate a sprite data directly with a simple HuC's functions. So, if your sprites can fit into a simple sprite sizes, use HuC's sprite functions. The less work on the CPU side, the faster your program! But it may be a question of balance between speed and ROM/VRAM usage. 3. Meta-sprites in SPReD-PCE are sprites made up of many 16x16 sprites. At the moment SPReD-PCE doesn't support combination of other simple sprites than 16x16 in exported meta-sprite. BTW, simple sprites 16x32 / 16x64 must be combined with other sprites 16x32 / 16x64 to work correctly (read the Quick Guide for details). 4. SPReD-PCE helps you prepare data for simple sprites and meta-sprites. The SPD library simplifies data initialization for both simple and meta-sprites. You'll replace all your sprites initialization code with a few SPD functions. 5. You can combine simple and meta-sprites in one data set. 6. What does SPD library do with meta-sprites? It copies meta-sprites data into SATB and transforms coordinates. The library was written in assembly and works fast for real meta-sprites not simple sprites. So if you have real meta-sprites, the SPD library will help you. Thus, don't use simple sprites as meta-sprites with the SPD library! This will work slower than HuC's sprite functions! Once more, the less work on the CPU side, the faster your program![upd]:
7. Using HuC's sprite functions resets sprite's offset point that you can configure in SPReD. 1. If so do you think the Zuks are the best sprite to tackle? The Zuks sprite is a real big and angry meta-sprite! If anyone knows how to restore these GFX back to a readable format that would be greatly appreciated. If not I'll start from the drawing board. Even Photoshop CS6 displays black images... 3. I have to re-read the SPReD Docs and experiment but from what I gather you need LEFT/RIGHT duplicates...This is curious to me because in HUC "spr_ctrl(FLIP_MAS,P1[0].flipState);" but I guess due to the way you place the x,y its is necessary. This is just an option for meta-sprites. Flipping meta-sprites in SPReD is much easier than doing the same manually in HuC. For simple sprites you can use HuC's sprite flipping. 4. I really see the value of SPReD because my frame sizes are 32x32 but in most cases my frames should be a META sprite (16x16 + 16x32) which eliminates a whole tile! Regarding animations all the .pcx images have the Zuks centered in a 32x32 frame. This is very handy for animating the Zuks because they always have the same center point. - Will SPReD be able to load my 32x32 GFX and eliminate the transparency. Basically can SPReD take a 32x32 sprite and optimize it to be (16x16+16x32) by factoring out the transparency? OR - Will all 32x32 sprites need to be tightly aligned to the left/bottom corner so SPReD can cleanly eliminate the unused 16x16 transparent tile? In either case it needs to be done. In the case by some stroke of major luck SPReD can optimize my 32x32 frames then I will be in luck for minimal work aligning my animations.
I hope you already have an answer to this question. It's simple sprites...
|
|
|
|
Post by hyperfighting on May 28, 2022 21:33:05 GMT
0x8bitdev thanks so much for starting this party off right! This is very insightful stuff! I'll aim at doing the zuks! Logo in SPReD as my first attempt at SPReD. I should be able to eliminate lots of x,y vars I'm using to piece together the various sprites! Yes even CS6 shows them as black images. No idea how to restore them. This is good news! I'm comfortable with the current setup. Do you recommend converting my simple sprites to SPReD or do you think it is ok to leave them in their current format?
|
|
|
|
Post by 0x8bitdev on May 29, 2022 6:18:03 GMT
This is good news! I'm comfortable with the current setup. Do you recommend converting my simple sprites to SPReD or do you think it is ok to leave them in their current format? Once more... Let's start from the basics:... 4. SPReD-PCE helps you prepare data for simple sprites and meta-sprites. The SPD library simplifies data initialization for both simple and meta-sprites. You'll replace all your sprites initialization code with a few SPD functions. 1. Import your sprite(s) to your SPReD-PCE project. 2. Export your sprites data set. 3. Insert exported data into your project. 4. Remove your old sprite(s) initialization code. 5. Test your program. 6. Go to (1) ...and so on until the last sprite or animation sequence. |
|
|
|
Post by hyperfighting on May 29, 2022 14:07:24 GMT
0x8bitdev sorry for being thick I will load my sprites into SPReD. It looks like the gain here is "The SPD library simplifies data initialization" So far here are my observations please correct me if I'm wrong. I think I'm starting to better understand how SPReD works. 1. I use 32x32 simple sprites for the Zuks (The main characters). This is the fastest way to process frames with HuC (Simple Sprites). When SPReD emerged my thought was to save tiles. Several 32x32 frames are only "16x16+16x32" (Allow a saving of 1 tile per frame in many cases). SPReD currently does not support this configuration and if it did loading the routine would be slower than loading the 32x32 simple frame. In it's current state a Zuks frame that is "16x16+16x32" would break into 3 16x16 sprites if it were to be converted to a Meta Sprite using 3- of the 64 sprites opposed to using 1- as 32x32 simple sprite. 2. By the same token the Zuks! Logo is broken down into 20 sprites - 32x32 sprites pieced together using 6 X variables and 3 Y variables. Another configuration would be to break the logo into 7 - 32x64 simple sprites and 6 32x32 simple sprites creating a total of 14 sprites (The later case seems to make the most sense as the variables could be reduced to 2 Y variables in that case...I think I tried this in the past had challenges and reverted to 32x32). I mention this because I was hoping to load the logo into SPReD as one large image and have SPReD break into 32x32 or a combination of both 32x64 and 32x32 Mega-Meta-sprite for the purpose of reducing my variables to a simple 1 X, 1 Y As fate would have it SPReD does not support the ideas above primarily due to the 16x16 Meta Sprite configuration it currently has. However just because you could...imagine a world SPRed supports "16x16 + 16x32" doesn't mean you should because as 0x8bitdev explains the routine is faster handling a 32x32 sprite and that info he provides is a major take away for someone building a project in HuC! You may sacrifice a blank tile or two for speed. However in the case of the giant logo maybe loading it as Meta-Sprite (If it were supported) would be a good idea due to it's small role in the program code. 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
|
|
|
|
Post by gredler on May 29, 2022 19:47:49 GMT
I haven't been at a machine that I can open thr pcx files with, so I apologize for the dumb questions I could check from a box, but what do the palettes look like? You aren't loading them from a seperate file are you? In huc you can load a image that looks black in an editor that loads correctly in game if the palette is different in a separately loaded image associated with the image you're loading in an editor
|
|
|
|
Post by hyperfighting on May 29, 2022 20:27:46 GMT
gredler you can't have dumb questions when I am the king lol. Thanks very much for taking the time to look into this with me. The palettes are part of the images. The are in some sort of weird format. The worst part is I know I processed the images and created this problem but I can't recall what I did to lock them up so bad. As memory serves me.... 1. Getting my own PCX files into a HuC project was very though (Not displaying etc)...eventually I found this weird method that I am trying to reverse now. 2. A version of HuC came out that allowed me to load .png files and thus .pcx debockle was over.
|
|
|
|
Post by hyperfighting on May 29, 2022 21:37:15 GMT
0x8bitdev I finally broke ground on getting the Zuks! Logo in SPReD format. 1. I had a index color .png that is 32x640 - I broke this down into 20 32x32 .png files (No Alpha just a Pink Background) 2. Upon loading the files in SPReD they were rejected. I resaved the 20 files as .bmp via PS CC and they were accepted! 3. I pressed the optimization button and I was told there were 8 Blank tiles! Yes! Saving 8 redundant tiles. 4. The last two 32x32 Tiles were automatically converted to 16x32 tiles....I followed the instructions renamed created reference copies etc.. 5. I then selected 32KB from the drop down beside the optimization button. 6. I ctrl+a all the frames and pressed the packing button. 7. I proceeded to export using HuC as the export option. I was able to display the First 32x32 tile no problem but the second tile is reversed? I am wondering if I messed up a step? Test Project -> Zuks! SPReD Test
|
|
|
|
Post by 0x8bitdev on May 30, 2022 9:59:48 GMT
0x8bitdev sorry for being thick I will load my sprites into SPReD. It looks like the gain here is "The SPD library simplifies data initialization" Yes! It also makes it easy to switch between different sets of sprites. 1. I use 32x32 simple sprites for the Zuks (The main characters). This is the fastest way to process frames with HuC (Simple Sprites). When SPReD emerged my thought was to save tiles. Several 32x32 frames are only "16x16+16x32" (Allow a saving of 1 tile per frame in many cases). SPReD currently does not support this configuration and if it did loading the routine would be slower than loading the 32x32 simple frame. In it's current state a Zuks frame that is "16x16+16x32" would break into 3 16x16 sprites if it were to be converted to a Meta Sprite using 3- of the 64 sprites opposed to using 1- as 32x32 simple sprite. And yes and no... "Yes": In it's current state a Zuks frame that is "16x16+16x32" would break into 3 16x16 sprites if it were to be converted to a Meta Sprite using 3- of the 64 sprites opposed to using 1- as 32x32 simple sprite. "No": Let's start from the basics:BTW, simple sprites 16x32 / 16x64 must be combined with other sprites 16x32 / 16x64 to work correctly (read the Quick Guide for details). The PCE hardware doesn't support sprites 16x32 and 16x64 the way you imagine them. But PCE hardware supports one could say a memory space for 32x32/32x64 sprites aligned accordingly, where you can place TWO 16x32/16x64 sprites in sequence. Thus, your 16x16 + 16x32 = 5 sprites 16x16, not 3! 2. By the same token the Zuks! Logo is broken down into 20 sprites - 32x32 sprites pieced together using 6 X variables and 3 Y variables. Another configuration would be to break the logo into 7 - 32x64 simple sprites and 6 32x32 simple sprites creating a total of 14 sprites (The later case seems to make the most sense as the variables could be reduced to 2 Y variables in that case...I think I tried this in the past had challenges and reverted to 32x32). I mention this because I was hoping to load the logo into SPReD as one large image and have SPReD break into 32x32 or a combination of both 32x64 and 32x32 Mega-Meta-sprite for the purpose of reducing my variables to a simple 1 X, 1 Y What's a problem and what's going on? 32x32... 32x64...  Just import your Zuks! logo in SPReD as one sprite. As output data you'll get ONE META-SPRITE. And you can position it by X,Y using SPD library. Try to import the image with alpha and cropping: ON/OFF. Which settings will give you fewer sprites. As fate would have it SPReD does not support the ideas above primarily due to the 16x16 Meta Sprite configuration it currently has. However just because you could...imagine a world SPRed supports "16x16 + 16x32" doesn't mean you should because as 0x8bitdev explains the routine is faster handling a 32x32 sprite and that info he provides is a major take away for someone building a project in HuC! You may sacrifice a blank tile or two for speed. However in the case of the giant logo maybe loading it as Meta-Sprite (If it were supported) would be a good idea due to it's small role in the program code. As fate would have it, PCE has hardware limitations... I hope you've understood what are sprites 16x32 and 16x64 on the PCE. There are hardware limitations that don't allow you using the simple things the way you want. But better read PCE tech doc. Another puzzle you have to solve working with sprites on PCE is a memory alignment for sprite data. This is another PCE hardware limitation. SPReD-PCE doesn't sort sprites for you when importing. This has pros and cons. Pros: you always know sprite data order and you can manipulate with sprites in your program like with CHRs using MAPeD. Cons: you can make mistakes... just forgot to sort them. But in both cases you MUST use correct VRAM addresses for your sprite data (see below ). Sort your sprites in SPReD this way to avoid glitches with displaying your sprites:1 - Simple sprites 32x64 or 16x64 must be aligned to an address multiple of 0x0200 in VRAM <-- most biggest simple sprites first 2 - Simple sprites 32x32 or 16x32 must be aligned to an address multiple of 0x0100 in VRAM 3 - Simple sprites 32x16 must be aligned to an address multiple of 0x0080 in VRAM 4 - Simple or any custom sprites with pieces 16x16 must be aligned to an address multiple of 0x0040 in VRAM <-- all meta-sprites and simple 16x16 sprites at the end of list 0x8bitdev I finally broke ground on getting the Zuks! Logo in SPReD format. 1. I had a index color .png that is 32x640 - I broke this down into 20 32x32 .png files (No Alpha just a Pink Background) ... 7. I proceeded to export using HuC as the export option. I was able to display the First 32x32 tile no problem but the second tile is reversed? I am wondering if I messed up a step? As I said above, just import your Zuks! logo in SPReD as one sprite and relax. Tons of imported sprites will give you the same tons of sprites as output data. Which is better, working with one sprite or with 22 (why?)! Simple sprites are simple sprites. Meta-sprites are meta-sprites. Just open any SPReD-PCE example project and take a look at the project data structure.... .. . .. . . |
|
|
|
Post by hyperfighting on May 30, 2022 13:43:45 GMT
0x8bitdev Haaaaaapy Monday! I want to respond to everything you just said especially for on lookers the table breaking down the memory allocations for the sprite sizes are extremely useful! I know I should have never said "As fate may have it" lol Thank you for clarifying the sprite consumption is 5 in the case of a Meta (16x16 + 16x32)! I now get that I should not be breaking down the Zuks logo to 32x32 tiles but the test project still displays a reversed tile and I have no idea why that happened? [upd] I tried changing the "CHR's Offset" to 100 to try and follow your VRAM alignment structure.I'm really really, happy that the Zuks logo can be exported as 1 easy to manage Meta-Sprite! I was confused and believed that it wasn't possible due to the explanation that Meta-Sprites are collection of 16x16 tiles. ( I believed exporting the large logo would overflow the sprite limit) Every way I import the large image the smallest sprite set is 67! I can't seem to get past this issue. When I export I always get the message that I am surpassing the hardware limit.  This is the .png I was loading into HuC the only reason I post this image is to show the alignment of the two images should be identical. Just one is assembled for SPReD and one is assembled for HuC 
|
|
|
|
Post by 0x8bitdev on May 30, 2022 15:25:10 GMT
I now get that I should not be breaking down the Zuks logo to 32x32 tiles but the test project still displays a reversed tile and I have no idea why that happened? You broke the sprites alignment. Your Z1 isn't a simple 32x32 sprite. That is just a meta-sprite with 3 pieces of 16x16. A sprite 32x32 is made up of 4 sprites 16x16. Isn't it? [upd]: And please RTFM on how to make sprites 16x32 / 16x64. And take a look at the example project './data/sprites_TEST_UNPACKED.spredpce'[upd] I tried changing the "CHR's Offset" to 100 to try and follow your VRAM alignment structure. Default ' CHR's Offset = 128 VADDR: #2000' already aligned to 0x0100 and to 0x0200, and to 0x0080 and even to 0x0040. [upd]: VADDR -> VRAM ADDRESSDo you know what is alignment to an address multiple of 0x0200, 0x0100, 0x0080, 0x0040 ?... I'm really really, happy that the Zuks logo can be exported as 1 easy to manage Meta-Sprite! I was confused and believed that it wasn't possible due to the explanation that Meta-Sprites are collection of 16x16 tiles. ( I believed exporting the large logo would overflow the sprite limit) Every way I import the large image the smallest sprite set is 67! I can't seem to get past this issue. When I export I always get the message that I am surpassing the hardware limit. Now you have described a problem... 67 sprites are too many. This is the reason to break the logo into pieces of simple sprites. |
|
|
|
Post by hyperfighting on May 30, 2022 15:57:04 GMT
Now you understand when I was saying the Zuks logo cannot be a Meta-Sprite.
I had attempted to load the logo as a large image initially and the failure to export combined with your explanation of Meta-Sprites taking 16x16 tiles led me to that statement.
So we go back to my initial method of loading 20- 32x32 sprites which boils down to the same style of sprite management found in the initial project before the introduction of SPReD.
I was really happy you could "optimize" as I thought that the individually loaded "32x32" sprites would shave tiles here and there and maintain their simple 32x32 shape. However I was wrong.
It appears when you optimize you are creating Meta-Sprites so for the simple sprite approach you must not do this.
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.
|
|
