|
Post by gredler on Oct 27, 2019 18:53:20 GMT
Thanks for sharing touko!! That is so inspiring, how gorgeous are those black hueys! I want our catastrophy huey to be brown and store it in a little mini faux litter box LOL
|
|
touko
Punkic Cyborg
Posts: 106
|
Post by touko on Oct 27, 2019 18:59:15 GMT
Thanks for sharing touko !! That is so inspiring, how gorgeous are those black hueys! I want our catastrophy huey to be brown and store it in a little mini faux litter box LOL I have some that the author sent me because i helped him,and they are incredible ,and not printed in 3D of course .
|
|
|
Post by elmer on Oct 27, 2019 20:38:40 GMT
We used puCrunch for compressing Rikki & Vikki's graphic data and stage maps, it worked quite well and has a good license. Other algorithms you may want to look into are aPLib or Elmer's SWD4 / SWD5. Both puCrunch and aPLib offer better compression than my SWD4 or SWD5, so they would be preferable choices to build into HuC, IMHO. Heck, even basic 4-bit/12-bit or 4-bit/8-bit LZSS would probably be good enough for most people. If turboxray , or ccovell have their puCrunch decompressors ROMable (i.e. with ring-buffers), then those would be great for HuC. I, personally, refuse to take the performance hit of using ring-buffers, and am only interested in targeting development for SuperCD or better (which includes TurboEverdrive2), so my aPLib code is optimized for decompressing into a block of RAM, even if the data is then going to be copied into VRAM.
|
|
|
Post by turboxray on Oct 27, 2019 20:59:15 GMT
The version of Pucrunch that I made, only used a ring buffer if you specificied VDC, ADPCM, or AC register (you didn't have free ram to use larger than the sliding window size, or a hucard project with only base 8k working ram). Otherwise it assumed the destination was ram based (could also decompress across banks of ram, but only needed two to be mapped in at a time as long as the sliding window size was kept under 8k). But yeah, it wasn't fixed with a ring buffer. It also had an option to take tile or sprites in linear pixel format and convert those to PCE planar in real time (which was also nice if the destination was port based because it did so on those boundary lines). It was slower, obviously for the conversion, but linear pixel really did get some compression savings for larger images.
|
|
|
Post by ccovell on Oct 28, 2019 0:13:59 GMT
If turboxray , or ccovell have their puCrunch decompressors ROMable (i.e. with ring-buffers), then those would be great for HuC. I, personally, refuse to take the performance hit of using ring-buffers, and am only interested in targeting development for SuperCD or better (which includes TurboEverdrive2), so my aPLib code is optimized for decompressing into a block of RAM, even if the data is then going to be copied into VRAM.
In this thread: pcengine.proboards.com/thread/820/old-stuff I posted links to the PuCrunch code that I made ROM-able. I did this back in 2008, so exactly how-to has faded from my memory, but I think I included examples in that archive I posted.
|
|
|
Post by paranoiadragon on Oct 28, 2019 2:42:55 GMT
Some hucards were made for barbarian PCE by a french (ishigobankai ) . What the, when did these come out! We're they up for pre-order, or were only a few made as an experiment?
|
|
|
Post by Arkhan on Oct 28, 2019 6:23:52 GMT
Some hucards were made for barbarian PCE by a french (ishigobankai ) . What the, when did these come out! We're they up for pre-order, or were only a few made as an experiment? LOL how did you guys miss this. It was on PCEFX. I have two. They were for sale IIRC. I did the music for it, lol. This was at least 3 years ago or something. They are just PCBs with chips in them under the labels, I think. Pretty much like the other repros. They look nice and it's all pretty cool, but they feel funny since they aren't plastic.
|
|
touko
Punkic Cyborg
Posts: 106
|
Post by touko on Oct 28, 2019 8:24:07 GMT
no sale, this game was only edited for fun with a limited number of hucards if i remember correctly .
yeah, they are a bit heavy too ,but i think it's the cheapest way to make hucards .
|
|
|
Post by gredler on Oct 28, 2019 18:10:51 GMT
The version of Pucrunch that I made... We used puCrunch for compressing Rikki & Vikki's graphic data and stage maps, it worked quite well and has a good license. Other algorithms you may want to look into are aPLib or Elmer's SWD4 / SWD5. ...would be preferable choices to build into HuC, IMHO. Heck, even basic 4-bit/12-bit or 4-bit/8-bit LZSS would probably be good enough for most people. If turboxray , or ccovell have their puCrunch decompressors ROMable (i.e. with ring-buffers), then those would be great for HuC. I wonder if this is a option for us? Or probably something for a future project, since this one is so near the end of development? We are trying to squeeze by with as little ASM as possible, I can't even help with C very much, and DK seems to be incompatible with ASM for now
|
|
|
Post by turboxray on Oct 28, 2019 20:09:10 GMT
I wonder if this is a option for us? I mean, I'm kind of just mucking around right now trying to figure out what I want to work on. I don't know your guys timeline, but I can get some working library code for handling compressed stuffs fairly quickly in HuC (I imagine it's going to be tiles/sprites/bat that you'll need compressed). I'll put up a working demo so you can see. Both puCrunch and aPLib offer better compression than my SWD4 or SWD5 Yeah but IIRC you said you used it because it was fast to decompress. PuCrunch is slow. So a compress scheme with fast decompression rate is always a good option to have! BTW gredler, what version of HuC are you using?
|
|
|
Post by gredler on Oct 28, 2019 20:19:54 GMT
Thanks so much for considering it sir. We are on 3.99 huc, and load png tilesheets, sprites, and and maybe some bats but I don't think so at this point.
We may still have some pcx files, but I've been trying to go through and convert everything to png every since Elmer added support for it. some day soon I want to batch out the remainder but that's a housekeeping thing for me and probably isn't a technical factor lol
|
|
|
Post by DarkKobold on Oct 30, 2019 19:26:03 GMT
I wonder if this is a option for us? I mean, I'm kind of just mucking around right now trying to figure out what I want to work on. I don't know your guys timeline, but I can get some working library code for handling compressed stuffs fairly quickly in HuC (I imagine it's going to be tiles/sprites/bat that you'll need compressed). I'll put up a working demo so you can see.
This would be great. TBH, we're really trying to wrap this project soon. We're entering the "all assets in game" and just getting to the polish phase. I think we are set on space, but compression would help us add a few final features that would otherwise be left on the cutting room floor.
|
|
|
Post by turboxray on Oct 30, 2019 21:09:51 GMT
This would be great. TBH, we're really trying to wrap this project soon. We're entering the "all assets in game" and just getting to the polish phase. I think we are set on space, but compression would help us add a few final features that would otherwise be left on the cutting room floor.
Cool! I'll get to work on it. Is your project hucard, CD, or both?
|
|
|
Post by gredler on Oct 30, 2019 21:17:09 GMT
HuCard only. We would have to change a lot to make it CD
|
|
|
Post by turboxray on Oct 31, 2019 6:20:47 GMT
;// Pucrunch decompression routine - standalone ver. ;// ;// Modified for use with PCE(CD) system. ;// rev. 1.3 ;// ;// Calling parameters for LZ_decmp: ;// (stream) source address = _bx ;// (stream) source bank = _al ;// (mode) _ah = 0, 1, 2, 3 ;// ;// 0 = decompress directly to VRAM (no conversion) ;// 1 = decompress directly to VRAM (convert linear to planar, per tile) ;// 2 = decompress directly to VRAM (convert linear to planar, per sprite) ;// 3 = decompress directly to CRAM ;// ;// ;// ;// Note: The destination address of the PORT devices, needs to be set first before calling ;// the decompression routine. ;// ;// Note: Function destroys _al,_ah,_bl,_bh,_cl ;// ;// ;// Note: routine uses self modifying code. ;// ;// Header: ;// end compressed addr(word) ;// indentifier 'pu' (word) ;// ending decompressed addr(word) ;// escape char (byte) ;// starting decompressed addr (word) ;// gamma info (4 bytes) ;// exec addr (word) ;// ;// ;// Todo: ;// ;// -Need to include a RAM/Local decompression mode (non port based). ;// -Need to include a ADPCM port write decompression mode. ;// -Need to include a ADPCM port read decompression mode. ;//
I found the last version I worked on. Looks like it uses self modifying code, which is not really ideal for hucard projects. So I'll work on making a more rom friendly version,
|
|