|
|
Post by 0x8bitdev on Jul 1, 2022 17:27:11 GMT
hyperfighting You are still do not understand what I told you... It's amazing... It does not matter what library you are using for tilemaps, MPD or something else... The answer to the question: how much your map data takes up in VRAM and how low can you go at VRAM addresses, will be the same in any case. If you can't answer, I can suggest the same - RTFM VDC etc.. until you understand the basics in a broad sense, and not in a nutshell in the form of my answer. C knowledge is a good skill, but when you know hardware. Without hardware knowledge, your C knowledge is nothing... If you still have not understood: 1. Hardware2. C/HuC etc... 3. Gamedev In your imagination the order is: 1. Gamedev 2. C/HuC etc... 3. Hardware? No, haven't heard... It is wrong order! So my question to you is still the same: how much your map data takes up in VRAM and how low can you go at VRAM addresses for your sprites?
|
|
|
|
Post by spenoza on Jul 1, 2022 17:57:13 GMT
hyperfighting I think you need a new thread for general programming/development help. For example, the question of how much VRAM is used: it's how much space the graphics themselves take up. That's it. It seems like MAPeD-SPReD is giving you such a shortcut that you're skipping over some of the underlying knowledge necessary. MAPeD-SPReD is a great tool, but trying to use it as a crutch is going to create problems. I think you should do something very simple WITHOUT MAPeD-SPReD first, and then use MAPeD-SPReD for the more complex version, to make sure you understand all the underlying principle. You're jumping a little too far ahead, and what you really want to know is more general programming and hardware information, but you don't seem to know quite how to separate that fully from what the tool is doing.
|
|
|
|
Post by hyperfighting on Jul 2, 2022 14:45:06 GMT
0x8bitdev I'm kinda scared to respond  I would say my map data uses 0x0000-0x2600 Leaving 0x2600-0x8000 for sprite data I will continue to research the hardware as per your instructions. This is my POV on VRAM atm. spenoza thanks for giving me a lifeline to save myself. My initial intention is to get SPReD and MAPeD fully integrated into the original Zuks! prototoype. I am close and will post progress as soon as I am there. Integrating SPReD showed me how bloated the prototype is. The animation system I posted here is my attempt at rectifying the code bloat. I believe it is relative to this thread as it showcases an example of the "slot" system as it relates to a SPReD project.
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Jul 3, 2022 3:57:25 GMT
hyperfightingI don't envy the work you have done so far. Although admittedly I haven't spent the time on it I think is required, I have already learned coding is a tough nut to crack. Ideally, there would be a book of some kind with examples you can flip through, failing that something you can print out for reference.
|
|
|
|
Post by 0x8bitdev on Jul 3, 2022 8:04:18 GMT
hyperfighting Glad you are on the right road! The life is full of magic, if you do not know physics! The same with the PCE programming. The PCE programming is full of magic, if you do not know the hardware. But unlike the life, the PCE programming's magic can make stupid glitches. And you can't fix that stupid glitches, if you do not know the hardware. If you are going to make something simple, like another tetris clone, the snake game etc. It is not necessary to know much about the PCE hardware. But if you respect yourself as a programmer, you will know! If you want to make a super game of your pipedreams, YOU MUST KNOW how the PCE hardware works!Nobody wants you write in assembly. If assembly is just a funny word to you that starts with, sorry, "ass". It's okay! But you need to know how VDC works, what hardware data structures it uses for CG, SG, SAT, BAT... What/where/how/at what addresses is going on in VRAM... To make the "magic" for users, you need dispel that "magic" for yourself! Otherwise you can make something simple... not so ambitious. And it is better when you start from simple projects. Because they help you sharpen your programming skills and hardware knowledge. hyperfighting I don't envy the work you have done so far. Although admittedly I haven't spent the time on it I think is required, I have already learned coding is a tough nut to crack. Ideally, there would be a book of some kind with examples you can flip through, failing that something you can print out for reference. The conclusion of this story is that you have to go from simple to complex step by step in development, and it takes years. But when you jump over the steps, you're doing something that you're not ready for, and that brings problems.
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Jul 3, 2022 17:52:54 GMT
hyperfightingGalahan left me his source code for Speccies. It was a simple game, originally made by a friend for the SMS, but if you think it will help you, I'll give it to you. 0x8bitdevI think the whole subject of programming is utterly fascinating. Plus I am always eager to learn... finally I think I understand pointers... I still have to decide what I want on this, but I could see myself reading techy books instead of fiction novels. Isn't 0x supposed to be the start of hexadecimal numbers?;p
|
|
|
|
Post by 0x8bitdev on Jul 4, 2022 14:35:03 GMT
Some changes to the tools and libs. MAPeD:
- data export: added optional sorting for exported entities: left to right, bottom to top or without sorting MPD v0.6
- screens/entities data moved from H file to ASM to save more memory for user data (that was a bad idea storing data in H file) - added HuC functions to get access to screens/entities data - added description how to work with screens/entities - added MPD_DEBUG flag that shows how long screen drawing/scrolling takes by border colors (use Mednafen); it is disabled by default in all samples, uncomment ' MPD_DEBUG' to enable the debug mode - updated samples Updated info you can find in mpd.h or here* You need to re-export your maps to work with the MPD v0.6
SPReD:
- data import: fixed 8-bit BMP import (Photoshop can exports 8-bit BMP with a palette less than 256 colors, there was a bug related to this issue) - data export: added option for adding an exported filename to sprite names; thus, it is possible to export the same sprite set several times, for example, with different palettes, and all exported data sets can share the same graphics - data export: optimized palette export: min/max slots SPD v0.5
- changes in SPD_DEBUG - now you can see how often and how much data loads ROM->VRAM and how long does ' spd_SATB_push_sprite' take; ' SPD_DEBUG' is enabled in all animated samples by default - added second argument to the ' spd_dbl_buff_VRAM_addr( VADDR_dbl_buff, _dbl_buff_ind )' function and added ' spd_get_dbl_buff_ind()' function to make double-buffered meta-sprites more independent in processing - optimized loading of SG data to VRAM for double-buffered meta-sprites; added ' SPD_DBL_BUFF_INIT_VAL' as initial value for a double-buffer index - added ' spd_alt_VRAM_addr( _alt_VADDR )' function to use VRAM address other than exported one; now it is legal and can be used for sprite instancing - added ' spd_change_palette( _plt_ind )' function to change a sprite palette after the ' spd_SATB_push_sprite' function call - added meta-sprite instancing demo ( .\samples\pce\sprite_render\animation_test\huc3\); each meta-sprite has its own behaviour, palette and share the same graphics data - updated samples Updated info you can find in spd.h or here* There is a little change after exporting your projects with the latest tool:
load_palette( <EXPORTED_NAME>_PALETTE_SLOT, <exported_name>_palette, <exported_name>_PALETTE_SIZE ) - the third argument must now be written in capital letters (I've replaced constants with defines)
TODO:
- SPReD: optimized meta-sprites export with sorted simple sprites e.g. 32x64, 32x32, 32x16, 16x16, i.e. not only 16x16 - SPReD: palettes manager - SPD: lightweight implementation of the push sprite routine for simple sprites, without double-buffering support etc... - MPD: scrolling optimization in assembly As usual the latest changes are available in the dev build.Well, guys and gals... Who will make a beat'em up game? Sounds crazy for HuC. But if you couldn't before, now you can try. |
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Jul 4, 2022 19:36:51 GMT
I've thought Catastrophe was meant to be a beat-em-up, but the footage, I saw, if I remember correctly, the main character was not actually "beating up" the enemies, but just jump swiping them in one hit and knocking them down.
Technically, you can always do that in beat-em-ups, but that's cheating!
|
|
|
|
Post by DarkKobold on Jul 5, 2022 0:29:09 GMT
I've thought Catastrophe was meant to be a beat-em-up, but the footage, I saw, if I remember correctly, the main character was not actually "beating up" the enemies, but just jump swiping them in one hit and knocking them down. Technically, you can always do that in beat-em-ups, but that's cheating! You're not remembering correctly. The combo system has been in the game for ages. This is the video you watched, where you suggest we start from scratch because you personally don't like beat'em ups. www.youtube.com/watch?v=5vWbDovEp4o |
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Jul 5, 2022 1:35:36 GMT
I don't think I meant you start from scratch. I didn't mean to be hurtful by my comment, so if you took it that way, I apologize. I get it, I'm opinionated. I end up not liking a lot of my ideas either.
Anyway, I hope you won't hold a grudge. I'm used critiquing stories on Critters.org; they give you shit there if you said everything was rosy.
I do try to say what I like about something. I think there's a lot to like about Catatrophy, even if I'm not particularly fond of beat-em ups or something.
Also, maybe you think I think your adventure game is a bad game because of something I said? That's not true. I would probably enjoy it, actually. Mostly I just think some of the pixel art looks flat (the tiles--the sprites are fanastic) and the title screen kind of drives me nuts because those pillars aren't holding up the ceiling.
|
|
|
|
Post by 0x8bitdev on Jul 5, 2022 8:51:45 GMT
I've thought Catastrophe was meant to be a beat-em-up, but the footage, I saw, if I remember correctly, the main character was not actually "beating up" the enemies, but just jump swiping them in one hit and knocking them down. Technically, you can always do that in beat-em-ups, but that's cheating! I meant classic beat'em up games with big brutal mans, womens, aliens, like in the SPD sample above with the guy(s) from "Double Dragon". Technically HuC is enough to implement beat'em up mechanics, of course. Cool beat'em up, I like it! |
|
|
|
Post by hyperfighting on Jul 5, 2022 15:36:02 GMT
![]()  Hats off on all the hard work and solid functionality offered by the new build. I have updated MAPeD and SPReD to the recent dev build and replaced all my assets with new exports. The only small complication as you mentioned is the ALL CAPS in the PAL "load_palette( SPRED_ZUK_PALETTE_SLOT, SPReD_ZUK_palette, SPRED_ZUK_PALETTE_SIZE);" Things are smooth going but one thing has broke on my end. My palette initializations no longer work. Previously I was able to do this in SPReD 4.0...but now any pal other than pal the .bmp was imported with isn't accessible just appears black? actor[GREEN].visible = ON;
actor[GREEN].x = 60;
actor[GREEN].y = 28;
actor[GREEN].anim_ins.pal=4; // Recognized as GREEN Pal that the sprites were imported with
actor[GREEN].anim_ins.priority=1;
actor[ORANGE].visible = ON;
actor[ORANGE].x = 220;
actor[ORANGE].y = 46;
actor[ORANGE].anim_ins.pal=1; // Not Recognized all BLACK
actor[ORANGE].anim_ins.priority=1;
actor[BLUE].visible = ON;
actor[BLUE].x = 40;
actor[BLUE].y = 124;
actor[BLUE].anim_ins.pal=0; // Not Recognized all BLACK
actor[BLUE].anim_ins.priority=1;
actor[PURPLE].visible = ON;
actor[PURPLE].x = 250;
actor[PURPLE].y = 168;
actor[PURPLE].anim_ins.pal=2; // Not Recognized all BLACK
actor[PURPLE].anim_ins.priority=1; [upd] I know you provided an example for pal variations with Meta Sprites but I'm not clear if I need to adjust something using basic HuC calls. [upd] Sorry!
|
|
|
|
Post by 0x8bitdev on Jul 6, 2022 14:12:09 GMT
Added optimized meta-sprites export with sorted simple sprites to SPReD-PCE. There is a new option available in the data export dialog - "Non-packed sprites optimization" and it is enabled by default. Now meta-sprites look like they should look. And meta-sprites processing costs less than before as you can see from the images below (white border lines). Before the changes:
![]()  After the changes:
 Zuks logo: hyperfighting You know what to do ...remove a lot of useless logo related code... The latest changes with updated samples in the dev build. |
|
|
|
Post by hyperfighting on Jul 6, 2022 16:13:31 GMT
0x8bitdev This is too good!!!! I have 16x64 clouds that can benefit from this treatment too!
|
|
|
|
Post by turboxray on Jul 10, 2022 21:57:52 GMT
Added optimized meta-sprites export with sorted simple sprites to SPReD-PCE. There is a new option available in the data export dialog - "Non-packed sprites optimization" and it is enabled by default. Now meta-sprites look like they should look. And meta-sprites processing costs less than before as you can see from the images below (white border lines). Before the changes:
![]() View AttachmentAfter the changes:
View AttachmentZuks logo:View Attachmenthyperfighting You know what to do ...remove a lot of useless logo related code... The latest changes with updated samples in the dev build. Is it taking up about ~370 cycles per cell in the meta sprite??? |
|
