tenshou / rcomage Goto Github PK

Rcomage v1.1.1 readme
written by ZiNgA BuRgA

URL: http://endlessparadigm.com/forum/showthread.php?tid=19501


 Introduction
 ------------
Rcomage is a general purpose RCO creation/manipulation tool.  It is designed to allow RCOs to be modified in almost any way, and intended to replace my previous application, RCO Editor.  Rcomage should also generate almost fully "compliant" resource files (very similar to original Sony RCOs).
RCO files are resource files that can be found in the PSP's flash0:/vsh/resource directory which contain stuff like icon data and various other resource components.  RCOs can also be found on UMD Video/Audio discs, where they are used to supply resources to the menus.
Currently, it only has two primary features - RCO dumping and RCO compiling.

Unfortunately, I've released this in a bit of a rush, so haven't really checked many things and haven't added many features I intended to put in.


 Using
 -----
I've included a very basic GUI to save you learning the commands.  For normal operation, for editing an RCO file, you'd open the RCO in the Dump tab, select where to export the structure and resources to, then click Dump.
You may then proceed to edit the dump of the RCO (eg, replace images or modify the structure by editing the XML dump).
To compile an RCO, go to the Compile tab, select a valid XML structure file, select where to save the new RCO and click Compile.

For using the CLI, use the command 'rcomage help' for details.


 General RCOXML structure
 ------------------------
The following should give you a general idea of the general structure for an RCO file.  Not all nodes below are required, and various object/anim entries are omitted.

RcoFile - XML root element; generally does not need to be modified
	MainTree - root RCO node from which everything must descend from
		VSMXFile - attached UMD virtual machine instruction code, for UMD and some LFTV RCOs.  Only one may exist in an RCO file
		ImageTree - parent node from which all image resources descend from
			Image
			Image
			...
		ModelTree - parent node from which all model resources descend from
			Model
			Model
			...
		SoundTree - parent node from which all sound resources descend from
			Sound
			Sound
			...
		ObjectTree - parent node from which all object pages descend from
			<Page>
				page objects go here
			<Page>
				page objects go here
			...
		AnimTree - parent node from which all animation sequences descend from
			<Animation>
				animation entries go here
			<Animation>
				animation entries go here
			...



 Planned Features
 ----------------
- better sanity checks and error handling
- giant cleanup of code (so I can release it later and allow Linux users to compile it)
- RLZ compression/decompression
- better information displays
- internal BMP <-> GIM converter
- documentation of RCOXML format as well as the RCO file format
- more functions (rather than just "dump" and "compile" etc)
- discovery of various "unknown" values
- anything not on my mind right now


 Notes
 -----
- RCO Editor doesn't write adler32 checksums when compressing images (yes, stupid stupid me) so anything edited with RCOEdit will generate a warning when you try to dump it; use --no-decomp-warn flag to suppress warnings (the GUI automatically does this)
- Sony's Gimconv is a little slow, so if you're dumping and converting GIMs, be a little patient (yes, I really did not write gimconv)
- what was referred to as "page" in RCOEdit is now called "object"
- conversions (such as WAV<->VAG or PNG<->GIM) may be lossy!
- a recent update_plugin.rco decompressed with Resurssiklunssi will generate a warning due to Sony deciding not to compress a particular icon in it, in turn, changing the structure a bit, which Resurssiklunssi wasn't designed to handle, so generates a "bad" RCO; recompiling the RCO with Rcomage will fix this issue however
- if zlib level 9 compression is used (specify '--zlib-method default --zlib-level 9' when compiling), RCOs recompiled with Rcomage should either be the same size as the original (decompressed with Resurssiklunssi), or 4 bytes smaller.  This 4 byte difference is due to some weird padding found in the EventData segment of some RCOs, which don't seem to really make any sense to me.  However, these 4 bytes don't seem to be necessary.
- other differences which may occur when recompiling are reordering of names/events and how null text data is represented


 Credits
 -------
- highboy for his WAV <-> VAG conversion sample code
- Z33 for sample GIM handling code and his various RCO tools as well as guides/investigations on various file formats
- creators of 7-zip for their awesome implementation of deflate
- supporting libraries: libxml2, iconv and zlib
- geohot for help with PS3 RCO support
- alpha testers, for discovering some issues and supporting theme development
- everyone else supporting PSP customisation and homebrew scene (too numerous to name)
- anyone I forgot to mention