News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - PhOeNiX

Pages: [1] 2 3 4
Newcomer's Board / Re: .tim pixel editor
« on: July 11, 2019, 05:32:35 am »
Use TIMViewer:

Convert to BMP, edit and convert back to TIM.

ROM Hacking Discussion / Re: Something like xdelta that can stack patches?
« on: February 07, 2019, 03:52:38 am »
If checksum validation is your only problem, xdelta allows you to disable it completely.

Gaming Discussion / Re: De-patching?
« on: September 22, 2018, 04:25:47 pm »
xdelta and the size of it's patches really largely depends on how it has been used, if you use the commandline "-B ****" (***being the scan block size here) that defines the maximum block size to be the same size as the image file itself, it will compare differendials between the whole image as opposed to the default setting which to my knowledge is not very large.

for example, my translation patch for evangelion: girlfriend of steel for psp, with default settings of xdelta, produced a patch of the size of 220MB
and by using the switch "-B 536870912" (536870912 meaning 536,8MB, the size of the .iso file) reduced the patch from 220MB to 40MB

I agree, indeed Delta Patcher was designed exactly for this reason, to have a more fine grained control on the patching process, without relying on the command line. You can choose the Source Window Size in Delta Patcher as big as 1 GB.

In my experience, BPS patches (at least the ones generated with current encoders) are always bigger than properly tweaked xdelta3 patches.

Newcomer's Board / Re: xdelta patched roms with genplus gx
« on: January 11, 2018, 11:14:52 am »
The patched ROM might have not a right checksum. You can try fixing the checksum of the ROM with this.

You might want to have a look at this.

Newcomer's Board / Re: Reduce data size of a graphic?
« on: June 06, 2016, 02:41:42 am »
If your image has the same resolution, there is no way your new image will get bigger, unless the game uses some kind of lossless compression like LZSS. In that case the real problem is to write an optimized compressor and not reduce image quality.

Newcomer's Board / Re: How to create a .TIM image? (PSX)
« on: May 24, 2016, 05:35:59 am »
In my experience, the easiest way of dealing with paletted TIMs is to convert the TIM to BMP with TIMViewer. Then the critical part is to edit and save the bmp by preserving the color depth (4bpp, 8bpp etc.), for this I find very useful with its LowColor FileType plugin. This allows you to save low color bmp by choosing the right maximum amount of colors you need in your bmp.

Newcomer's Board / Re: Tim and clut
« on: March 30, 2016, 12:45:06 pm »
Tim2View does not properly support some TIM files. The only tool I am aware of it is fully capable of handling TIM files is TIMViewer by rveach.

The only tool out there which is really able to properly recreate PSX ISO images, including XA streams is PIxel's cd-tool. Albeit complex to use and to find on the web.

Just run your PSX BIOS without inserting the disk. Once the first boot audio finishes, insert your disk without turning off your PSX and wait for the black logo to show up.

Programming / Re: Half-assed disc image input and output
« on: September 01, 2015, 05:02:06 am »
This is what you need

The most important one would be the "rebuildErrorCorrection" method.

Programming / Re: Half-assed disc image input and output
« on: August 30, 2015, 04:58:14 am »
This pretty much depends on the kind of data you are dealing with. Mind that sharing data between classes like the GUI one and another one is not circular dependency.

Circular dependency happens when a class holds a reference to another class and vice versa. That is, the GUI class holds a reference of class A and class A holds a reference of the GUI class.

Programming / Re: Half-assed disc image input and output
« on: August 29, 2015, 02:54:24 pm »
A lot of method parameters is usually a sign that some refactoring of your code will be needed. One solution would be to gather most of the parameters that you need in a separate class representing something meaningful like a file entry.
The class Entry might have a "name",  a "data struct" and a "length" for example.

Code: [Select]
public class Entry{
  private String name;
  private int length;
  private byte[] data;
  public Entry(String name, int length, byte[] data){;
  public String getName(){ return name; }
  public int getLength(){ return length; }
  public byte[] getDataStruct(){ return data; }

The you would pass a list of entries to your method.

Regarding the rest of data in the sectors. If you are dealing with MODE2 images, you will need at least to recalculate ECC/EDC integrity codes for each sector, in order for the iso image to work on hardware.

Newcomer's Board / Re: PSX Imager
« on: August 29, 2015, 08:09:42 am »
In the meanwhile you can try this

It allows you to change the LBA offset of the file you want to replace with another one. This way when replacing the file with cdmage, it will write the file to the new location.

You can also specify the new size of your file. You should find some free location in your iso file and change your file's LBA to that location.

Newcomer's Board / Re: PSX Imager
« on: August 28, 2015, 11:27:01 am »
You can use to extract and replace files in a psx cd image
and as a command line tool for replacing files.

Rebuilding the ISO image is needed only when files change their original size.  Since many games use an internal file table that 99% of the time has to be modified to account for file sizes changes,
just rebuild the ISO image is not enough.

Anyway, it seems this tool is linux only. Unfortunatelly, I have not a linux environment settled up at the moment.

Hi, sorry for necroposting, but I though you were interested on this:

I have been working on NUT files these days and all nut files I tried so far can now be viewed and exported to png with rainbow.
As for now, only "Open" and "Export" features are implemented: it remains to understand one last palette format and "Save" and "Import" features will be added as well.

The current development build can be downloaded at

The main problem I see in your code is this:
Code: [Select]
if (zipEntry.getName() == "tempItemData")
Java's "==" operator performs a "pointer" equality check. In order to correctly compare two strings, you must use the "equals" method instead.
Code: [Select]
I did not check the rest of the code, but as Kaioshin already said: everything you need to known is in the official javadoc. Just read it.

How big depends on your ram size. Otherwise, you don't need to divide it evenly, just construct a fixed size byte array. The method "read" of zis will return the number of bytes read.

You can iterate by calling "read" until it returns a negative number. There are plenty of tutorials about this online.

Check this for example:

You need to iterate over the ZipEntries of the ZipInputStream.

Something like this:
Code: [Select]
ZipEntry entry;
//if we could gather the next zip entry, now, the zip input stream will allow reading the data associated to the current entry (i.e. the current file)...
// so just call
// you may call entry.getName() and entry.getSize() to get the file name of the current file and its size.

So, you should iterate the zip entries, check with getName() whether it is the entry you want to read. Then, (assuming the file is not too big), create a byte array of length equal to entry.getSize(),
read with the file content to the byte array, and finally write it to the output stream.

Pages: [1] 2 3 4