jbrandwood/liberis

Roadmap : Stuff to fix or to be implemented

Closed this issue · 3 comments

gameblabla commented

Hello,
thought i would write up for future reference what is missing and should be fixed or implemented.
Here's a non exhaustive list :

  • Proper open source tools to convert Huc6272-BG format.
    For Legal and pratical reasons, we should write our own tools to convert them directly.
    I wrote this https://github.com/gameblabla/bmp2huc for converting images for the 8/16bpp color formats.
    24bpp and 4bpp are missing however.

  • Provide higher-level functions for ADPCM and CD-DA and bundle them as part of liberis.
    I'm working on that here : #2 but what i didn't do for ADPCM at least was to provide them as high-level functions within liberis itself. I will do that once i can get it fully cleaned up but obviously i would need some help on that...
    So far, i've only did so for CD-DA.

  • Fix issue with gamepad controls
    Oldrover was complaining about the gamepad code on real hardware not working unless it's called twice and using the high byte instead.

Unlikely to be fixed/implemented anytime soon

  • MJPEG support through RAINBOW chip.
    It seems to be woefully documented sadly. This would also need either a conversion tool or a fork of libjpeg to directly support the RAINBOW variant. (which seems to be very similar)

  • Aurora 3D chip.
    PC-FX GA SDK does support it but it is quite a tall order to support. Maybe we could just disassemble the proprietary libraries or make GCC support them ?

jbrandwood commented

I have already addressed the FX-BMP part of your suggestions on the forum. If you wish to write a development-tool that preserves the FAT12 structure, then that has some valid uses ... but corrupting the FX-BMP as we're doing now only has a temporary purpose for experiments, and it has little long-term value to either liberis or pcfxtools.

As for supporting 0x0000-0x7FFF ... the compiler and linker scripts already does support using that area, excluding 0x7E00-0x7FFF, which is reserved for the firmware, and which needs to stay reserved for the firmware. Examples for using that memory have been in liberis for many years.

Having graphics converters would be nice, and you can read the official SDK's development docs for the formats to support.

gameblabla commented

Yeah we talked about the FX-BMP stuff on the forums. I did think of writing to the FAT12 filesystem as you said but didn't see a point for the kind of testing i wanted to do. That's something i could certainly add to my tool though. (But i'm starting to think it's probably a better idea to just do it from the console itself. Idk to be honest but i think we should probably not write it to FX-BMPs for now indeed and ideally we need to push them on our own.)

Good to know about 0x7E00-0x7FFF, that's why i was confused but seeing the documentation, it seemed to be important enough.

I skimmed through the docs and it seems that 24bpp uses YUV888 pixels. But i'm still unsure as to why the filesize is smaller compared to 16bpp and google translate is sadly not exactly clear on that... :P

dshadoff commented

You've probably all forgotten about this issue (as it's been closed for about 2 years), but:

  1. I created a separate repository for data converters here:
    https://github.com/pcfx-devel/PC-FX_Programming_Tools
    It uses Python, as that's available on virtually every system, plus it can also be considered a way of documenting those data formats. ADPCM would be a natural next step, and one day it would be nice to have MJPEG, if we can get it fully understood.

  2. Gamepad controls were fixed with a PR in 2023 I think.

  3. FX-BMP FAT functions would need to consider FAT16 for larger sizes as well. I think it's a good goal to at least support the internal memory at some point (but not top priority).

As I clean up the current implementation, I will examine the pending Pull Request contents.