|
Post by gredler on Jun 17, 2022 17:07:37 GMT
16 wasn't really enough, we had to compress down. Did you mean, sharing palette slots between different sprites? yeah because of number of enemies on screeen, powerups, and decorative sprites to spruce up the tile map repetitions we had to consider and consolidate our palettes so the above could share palletes. Initially I was so excited by number of palettes available I made too many unique but in practical implementation it had to be optimized for sharing
|
|
|
Post by 0x8bitdev on Jun 18, 2022 16:35:23 GMT
yeah because of number of enemies on screeen, powerups, and decorative sprites to spruce up the tile map repetitions we had to consider and consolidate our palettes so the above could share palletes. Initially I was so excited by number of palettes available I made too many unique but in practical implementation it had to be optimized for sharing Unfortunately, there is no other way to achieve a maximum diversity of sprites in one frame. But may be a palette switching in one frame by a scanline value yet. But that is another story... and definitely not for HuC... hyperfighting , I've added the 'data directory' field to the SPReD data export dialog. .H file will be exported to a selected directory and the rest data to 'selected directory' + 'data directory'. Also now exported palette can be accessed per slot. For exampe, exported palette has four slots. You make 'load_palette' as usual on data init, but you can also manipulate each of 4 slots of the exported palette. The changes in the dev build.
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Jun 18, 2022 17:17:34 GMT
DarkKobold - That's what I'm talking about! Using all the Turbo Grafx! I just got its Cat-astrophy lol I love the Megaman helmet and the Mice have cool moves SF 2 inspired! Love it! I've always thought to myself, because of the Mega Man helmet, the cat should shoot furballs!
|
|
|
Post by spenoza on Jun 18, 2022 20:11:24 GMT
Purrrrdouken!
|
|
|
Post by hyperfighting on Jun 18, 2022 20:56:17 GMT
It's a cool idea I could see a combo finishing with a super charged furball! 0x8bitdev - Thanks very much for making the adjustments in SPReD! At first I tried tucking the .h file somewhere other than the root directory but I now realize .h lives in the root and all the export data can be tucked anywhere! This is great stuff all of my SPReD exports are now organized in SPReD graphics directories! Another huge thanks for the adjustment to manipulate palette slots! I'm excited to see if after a user selects 2 Zuks if those two pals can be aligned to pal 0 / pal 1 freeing the other pals for more GFX etc. Regarding SPReD two minor things are the ability to "delete" and "reorder palettes". I've made mistakes and those two options would be handy but as you point out it doesn't take very long to rebuild SPReD files. Another thing I ran into is making a mistake with "packing sprites" and "re-packing sprites" EX: 1. I have sprites ordered 3,2,1 and I pack them. 2. I then realize the order of the sprites is wrong so I reorder the frames as 1,2,3. 3. I try to repack the sprites by selecting the frames and pressing "Packing" button the frames don't repack with the new sprite order 1,2,3 4. So now I press the "Splitting" button but when I do this 20+ animations are split and need to be individually repacked. It would be great if you reorder frames that are packed then repack then, the packing algorithm will repack based on the new frame order.
|
|
|
Post by 0x8bitdev on Jun 20, 2022 16:11:18 GMT
hyperfighting How to fix your glitch when sprite 16x16 becomes 32x32 ?.. Your first attempt was: spd_sprite_params( ... ); spd_copy_SG_data_to_VRAM( ... );
spd_SATB_push_sprite( ... ); ...
vsync();
Then I said that you need to call the 'spd_copy_SG_data_to_VRAM' after 'vsync'. And your second attempt is: ...
vsync();
spd_sprite_params( ... ); spd_copy_SG_data_to_VRAM( ... );
spd_SATB_push_sprite( ... );
In fact, nothing has changed at all.. It is the same as in the first attempt. Using the 'spd_copy_SG_data_to_VRAM' after 'vsync' means using the 'spd_copy_SG_data_to_VRAM' after 'vsync' and nothing else: spd_sprite_params( ... ); ...
spd_SATB_push_sprite( ... ); ...
vsync();
if( my_super_condition_to_avoid_data_loading_each_frame ) { spd_copy_SG_data_to_VRAM( ... );
// reset my super condition my_super_condition_to_avoid_data_loading_each_frame = 0; }
It would be great if you reorder frames that are packed then repack then, the packing algorithm will repack based on the new frame order. Packed sprites can't be packed again. They need to be splitted to be packed again. The only thing I can try is to make splitting for selected sprites. There was a point with that... I don't remember all the details. I need to take a look...
|
|
|
Post by hyperfighting on Jun 20, 2022 17:51:33 GMT
0x8bitdev - So I'm trying to follow but I'm majorly missing something. This how I've got it setup. if( my_super_condition_to_avoid_data_loading_each_frame) { spd_sprite_params( SPReD_ZUK_SG_arr, vramSlot, SPD_FLAG_PEND_SG_DATA, Zuk_last_SG_bank_ind); spd_SG_data_params( &SG_DATA_SRC_ADDR, &SG_DATA_SRC_BANK, &SG_DATA_DST_ADDR, &SG_DATA_LEN );//Assign Params to pointers
spd_SATB_set_pos(StartSprite); for (; StartSprite<=LastSprite; ++StartSprite) { spd_SATB_push_sprite( SPReD_ZUK_frames_data, Enemy[Index].anim_ins.frameset, Enemy[Index].x, Enemy[Index].y ); ++Index; } }
vsync();
if( my_super_condition_to_avoid_data_loading_each_frame ) { spd_copy_SG_data_to_VRAM( SG_DATA_SRC_ADDR, SG_DATA_SRC_BANK, SG_DATA_DST_ADDR, SG_DATA_LEN );//Use assigned pointer values? // reset my super condition my_super_condition_to_avoid_data_loading_each_frame = 0; }
|
|
|
Post by 0x8bitdev on Jun 21, 2022 16:42:53 GMT
0x8bitdev - So I'm trying to follow but I'm majorly missing something. This how I've got it setup. if( my_super_condition_to_avoid_data_loading_each_frame) { spd_sprite_params( SPReD_ZUK_SG_arr, vramSlot, SPD_FLAG_PEND_SG_DATA, Zuk_last_SG_bank_ind); spd_SG_data_params( &SG_DATA_SRC_ADDR, &SG_DATA_SRC_BANK, &SG_DATA_DST_ADDR, &SG_DATA_LEN );//Assign Params to pointers
spd_SATB_set_pos(StartSprite); for (; StartSprite<=LastSprite; ++StartSprite) { spd_SATB_push_sprite( SPReD_ZUK_frames_data, Enemy[Index].anim_ins.frameset, Enemy[Index].x, Enemy[Index].y ); ++Index; } }
vsync();
if( my_super_condition_to_avoid_data_loading_each_frame ) { spd_copy_SG_data_to_VRAM( SG_DATA_SRC_ADDR, SG_DATA_SRC_BANK, SG_DATA_DST_ADDR, SG_DATA_LEN );//Use assigned pointer values? // reset my super condition my_super_condition_to_avoid_data_loading_each_frame = 0; }
You are right, you are missing something... spd_copy_SG_data_to_VRAM( SG_DATA_SRC_ADDR, SG_DATA_SRC_BANK, SG_DATA_DST_ADDR, SG_DATA_LEN ); - Why ? ...if you are using data copying per sprite ID: spd_copy_SG_data_to_VRAM( SPReD_ZUK_frames_data, FRAMESET );The main logic is: spd_SATB_push_sprite
vsync();
spd_copy_SG_data_to_VRAM <- not every frame, but only as needed
------------------------------------- I've changed the splitting operation in SPReD. Now you can split selected sprites. And then pack them if you need. NOTE: All sprite groups with selected sprites will be splitted.All the changes in the dev build.
|
|
|
Post by hyperfighting on Jun 21, 2022 17:50:40 GMT
0x8bitdev - This is too good regarding the splitting and repacking I'm sure users will run into repacking situations from time to time. Many thanks! I'll give your pointers a shot and see if can get this 16x16 sprite to transform into a 32x32 sprite smoothly!
|
|
|
Post by hyperfighting on Jun 24, 2022 14:45:31 GMT
A quick update! I have the 16x16 Sprite smoothly transitioning to a 32x32 sprite! It has been taking me a while but I figured integrating SPReD I should refactor the code.
EX: Unique "animation" engines were in place for all scenes. Title, Player Select, Level Intro, Attract mode.
I have been working at one 'animation' system to rule them all. So much bulky redundant code is being removed.
My plan is to make a short and documented demo project to showcase the alternate 'slot' method. If anyone is interested they can use the project, modify or suggest an improved way to handle the slotted animation. If 0x8bitdev thinks its worthy it can be included as an example with SPReD package other wise it will still be avaliable via this thread for those interested. More to come later.
|
|
|
Post by hyperfighting on Jun 25, 2022 16:44:15 GMT
[upd1] Demo has been revised. - "Flip_You" function was added to reduce the footprint of animation.h- "ATLAS" parameter is removed from "FrameAnimateActor" this is done so actors can be easily loaded in and out of any allocated VRAM slots - VRAM allocations appear normal now EX: no more 20480 to represent 0x5000 - Glitch is resolved. VRAM allocations are restructured thanks to insight from 0x8bitdev Slotted Animation Demo -> Get the Demo
This is my official attempt at submitting a demo that could possibly be bundled as an example with SPReD. For those following or new to the thread I'm hoping someone may find this useful or possibly share some ways to improve the current system and make the demo better. Please be brutally honest. I did my best to make something useful and because it takes a different direction than a standard SPReD implementation it might be a useful reference to have on file. Description: An alternate approach to animation using data managed with SPReD Purpose: If you cannot load all animations into VRAM you can SLOT them in. EX: Your character is given 8 32x32 slots in VRAM and you load SPReD packed/unpacked animations into those 8 slots as needed. (of course you can mod the 8 slots higher or lower etc) CAUTION: This example complicates the ease of use SPReD provides. One main drawback is SPReD "Offsets" need to be handled manually. Any Sprite Offset in the SPReD application is for reference only in the case you use this method. It is advised to review other SPReD sprite animation examples before pursuing this option as SPReD has some great benefits natively. FEATURES OF THE DEMO: - SPReD and MAPeD data combined in one demo. - SPReD Data is tucked into the GFX directory (A great feature of SPReD on Export. Note all SPReD export .h files must live in the root directory) - 320x224 (res setup) - Managing Large Sprite comprised of 20 - 32x32 Tiles "Zuks Logo" - Smoothly transitioning 16x16 Simple Sprite into a 32x32 Simple Sprite - Custom Animation System (Manages 16x16 and 32x32 Simple Sprites) - 1 VRAM slot controlling 4 Identical Stars - 16x16 Simple Sprites "Stars" - 4 VRAM slots controlling 4 Unique Zuks - 32x32 Simple Sprites "Zuks" - SHOWING/HIDING Sprite - 1 - 32x32 "BoneBat" 0x8bitdev - I hope after some improvements you may consider including this demo. Please review the project when you have a chance.
|
|
|
Post by 0x8bitdev on Jun 27, 2022 16:43:23 GMT
It isn't without one flaw which is overwriting VRAM data with different VRAM data in the second scene. I don't encounter this in my base project as my screen "blanks" when scenes transition. It would be nice to know it can somehow be avoided. Apologies for typos etc. (Glitch does not appear in the video) 1. But another glitch is very clearly visible, when fourth star becomes a magenta zuk. You can see one frame of glitchy title sprite, because you overwrite the title logo. I don't know why... And the problem is that you load 10KB of graphics to VRAM in one frame. The new graphics has not been loaded yet, but the sprite begins to be drawn and you see a piece of old image (title sprite). 2. To avoid the VRAM overwriting, you just need to manage VRAM wisely. If you don't want to overwrite VRAM, just write to another empty memory space. Write at the following VRAM addresses, to get rid of these issues: 0x4000// Zuk 1 0x4800// Zuk 2 0x5000// Zuk 3 0x5800// Zuk 4 0x3b00// BoneBat
...and your title logo located at address 0x6000 will not be overwritten. p.s.: if you don't know how to watch sprite graphics in Mednafen. Alt + D - debug mode, then Alt + 2 and 'Right Arrow' -> sprites viewer, 'Left Arrow' -> tiles viewer, '<', '>' - palettes switching.
[upd]: Why don't you use hex numbers as function arguments? I mean, for example, this: FrameAnimateActor(ZUK_ATLAS, 0, 0, 0, 0, 20480);//0x5000 // Zuk 1 FrameAnimateActor(ZUK_ATLAS, 1, 1, 1, 1, 22784);//0x5900 // Zuk 2 FrameAnimateActor(ZUK_ATLAS, 2, 2, 2, 2, 24576);//0x6000 // Zuk 3 ...
It looks weird...
|
|
|
Post by hyperfighting on Jun 28, 2022 14:42:15 GMT
0x8bitdev Many thanks for the insights! I have revised and uploaded an improved Demo above. Can you tell me how to make a "scroll to link"? I have no clue... EX: I want the to say get the revised demo here and it jumps to the previous post. 1. Because SPReD was exporting numeric values for memory addresses I believed I had to use them but I have that changed now. 2. Thank you for pointing out my poor VRAM allocations! The glitch is solved! This leads me to ask how much VRAM does MAPeD use for a Multi Scroll Map? I'm wondering how low can I go? 0x3B00 or even lower? 3. Thanks for Mednafen sprite watching tricks! I never knew that! What do you think? Is the demo half way decent? Do you think you would consider adding the demo to SPReD? I have an idea regarding MAPeD I want to run by you.... Lets say I have the same screen 10 times...then the same screen 5 times etc... Instead of taking up 15 screens it would be great if I could take up 2 screens and put a loop value on each screen. I have a special effect in mind and I'm thinking I might be wasting screens etc so I figured I would ask... Also on the SPReD side of things can I load a palette group into whatever slot I want outside the exported value? EX: I have two SPReD projects and both are have 2 palettes exported to pal 0. This is obviously a problem because the second pal group will overwrite the first. I know the answer is export the second group to pal 2 but I'm curious can I choose the pal slot the group will be loaded to when I load the pals via the code? Another example might be the Attract sequence. Each character is featured individually so it makes sense that their pals groups are loaded to pal 0 because only they are featured in each scene but in the "GAME" the pals will need to be staggered so that they don't constantly overwrite pal 0.
|
|
|
Post by 0x8bitdev on Jun 29, 2022 16:29:31 GMT
Can you tell me how to make a "scroll to link"? I have no clue... EX: I want the to say get the revised demo here and it jumps to the previous post. Maybe a post options? 1. Because SPReD was exporting numeric values for memory addresses I believed I had to use them but I have that changed now. As for exported data, you need to use generated constants, not values. 2. Thank you for pointing out my poor VRAM allocations! The glitch is solved! This leads me to ask how much VRAM does MAPeD use for a Multi Scroll Map? I'm wondering how low can I go? 0x3B00 or even lower? The MAPeD doesn't use PCE VRAM... Because it is a standalone map editor. But the MPD library loads your map data to VRAM. And this is my question to you, how much your map data takes up in VRAM and how low can you go at VRAM addresses? But the problem goes much deeper... If you ask such questions, you do not understand what you are doing. You've been developing your game for years and still don't know the PCE hardware basics... How it is possible? I have a feeling that PCE programming is a kind of magic for you. Something, somewhere, somehow works, and as the result you see something on your screen... And you are happy with all of that. It's a pure magic! But programming and hardware is a pure logic, detailed documented and is available for free to everyone. The first thing you had to do was to study and analyze a new information about platform, its hardware capabilities, RAM/VRAM size and so on. After that, when you know how the platform hardware works, you can make your steps in software development. But you decided to start from the end... It doesn't work this way. This way you will make your game for decades and never finish it. There are basic things that any developer MUST know! Do you prefer programming blindly? I'm not interested in this approach, because it's a waste of my time. If you spend years developing your game and don't want to spend hours, days or maybe weeks (who knows?) on reading "boring" technical documents to understand what you are working with, I don't want to waste my time helping you. This thread isn't called 'PCE hardware for dummies'. And I'm not going to explain the PCE hardware basics here (but you can start a new thread for that). Because there is a lot of official/unofficial documentation available for that. Here we discuss everything related to MAPeD/SPReD and their HuC libraries - MPD/SPD. The only thing I can suggest is just RTFM! I mean read at least everything related to VDC (HuC6270) with its VRAM, registers, DMA, BAT, SAT, SG, CG etc., VCE (HuC6260). Read until you understand what is written there. And how this understanding will help you make your game better. Then read Mednafen Debugger Documentation, run commercial games, take a look at video memory: BAT, CG, SG data... with their addresses, VDC registers and so on. Once you find the answer, how to manage VRAM for your game, we will continue. 3. Thanks for Mednafen sprite watching tricks! I never knew that! That is really bad, when you are developing something and somehow... What do you think? Is the demo half way decent? Do you think you would consider adding the demo to SPReD? I think it will be difficult to understand the logic of your demo with its scenes, sub-scenes etc. I can add a link to the main post. Lets say I have the same screen 10 times...then the same screen 5 times etc... Instead of taking up 15 screens it would be great if I could take up 2 screens and put a loop value on each screen. I have a special effect in mind and I'm thinking I might be wasting screens etc so I figured I would ask... As I wrote here - As exported data, a multi-directional map is a simple MxN row\column ordered array of tile indices. So it doesn't matter what screens and how many times repeat in your map. As exported data it is just a 2D array of tile indices. But in MAPeD you will have 2 screens. Also on the SPReD side of things can I load a palette group into whatever slot I want outside the exported value? EX: I have two SPReD projects and both are have 2 palettes exported to pal 0. This is obviously a problem because the second pal group will overwrite the first. I know the answer is export the second group to pal 2 but I'm curious can I choose the pal slot the group will be loaded to when I load the pals via the code? That's why I wrote here - Take your notepad and write down in it what sets of sprites will be in your project, what palette slots they will use. You need to understand which sprite sets can be combined together, when palette slots can be overwritten by other sprite sets without conflicts.Another example might be the Attract sequence. Each character is featured individually so it makes sense that their pals groups are loaded to pal 0 because only they are featured in each scene but in the "GAME" the pals will need to be staggered so that they don't constantly overwrite pal 0. You just forget that you develop a game, not the main menu. So focus on the "GAME" palette and do not invent problems for yourself!.. ...with zero slots... BUT if you are unable to plan your work and stick to the plan and you want to complicate your life, you can manage palettes as you want... Use HuC's load_palette and work "wonders"!..
|
|
|
Post by hyperfighting on Jun 29, 2022 19:24:57 GMT
0x8bitdev I am a bit of a dummy when it comes to forum posts. Thanks for setting me straight with the options I never realized that you could link to previous posts this way. Apologies for stating MAPeD when in fact I should have referred to the MPD library. I used MAPeD as a blanket statement when in fact it refers to the application that you create and manage maps with and of course the MPD library is what we use when we load exported MAP data via HUC. My question directly applies to the VRAM footprint the MPD library has? The documents you have suggested will never give me that specific info. Granted they will give me a better understanding how the hardware works. In terms of the logic I use while coding this project..... I need a healthy understanding of C (still learning as I go...enjoying it) I need a healthy understanding of MAPeD (Blanket Statement) (still learning as I go...enjoying it) I need a healthy understanding of SPReD (Blanket Statement) (still learning as I go...enjoying it) I need a healthy understanding of HuC (Blanket Statement) (still learning as I go...enjoying it) We came from two vastly different ideologies and we met here. With all the knowledge and insight you have you can never fully anticipate what requirements another user will have. Through this process the tools have been improved. If I hadn't jumped in and took the approach to programming I had then I wouldn't have been able to meet you on this platform and raise questions regarding your SPReD and MAPeD implementations. Some of the questions I have asked are stupid where others are valid. This is an open forum to hopefully give people some good insights and some good reference so hopefully this banter makes for some good reading. Currently when I export from SPReD I don't care what VRAM address I export because I handle that manually in my code. (You saw this as valid and afforded me this opportunity) I am now asking for the opportunity to do the same thing with pal groups. Why not allow the user to load the pal group where they want via their code? [upd] More stupidity on my part it looks like I can load a pal group to any location "load_palette( (value must be 16-30 represents sprite pal 0-15), SPReD_BONEBAT_palette, SPReD_BONEBAT_palette_size);" my bad! I think all things mentioned fall in the guidelines of MAPeD and SPReD territory. I am a huge fan and appreciate all that you have done. The things you say sometimes shake me to my core but I'll survive.
|
|