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
News Submissions / Re: Utilities: Rainbow: texture format converter
« on: July 13, 2014, 10:03:59 pm »
You mentioned "Wii": does that mean you intend to add support to "tpl" graphics and other GC/Wii-specific formats (like you intend to for PSP with GIM support)?
Yes, the roadmap for future versions of the tool would be to add support for mipmap TIM2 images and GIM files. Then, adding support to tpl images found in GC/Wii games.

Any way to include tree support and TOS rebuilding support for PS2 (maybe PS1 and PSP if possible) to the limited extent possible, even just as a GUI for other existing tools for practical reasons?
I am not sure I got what you mean. You mean ISO rebuilding?

Also, is there any possibility to include (already-made) TIM support within this tool for completeness sake?
This is not considered a main feature right now, but it is not excluded. As for now, there are many good tools that can deal with TIM images.

Any chance -and that's a *big* stretch- to make the tool as comprehensive as Tinke or CT2 by including compression/decompression support for known formats like slz (tri-ace stuff), cpk, pkg (whatever Square Enix is using for PSP releases) and the like, instead of resorting to command line? A GUI would be really nice.
It is very unlikely. The main goal of Rainbow is to manage specific graphics formats. Compression and archive formats go out of this scope.
Even if a GUI would be nicer for many people, I still think that for such kind of files, a command line tool would be more suitable (since they can be used inside scripts to rebuild the whole structure of the game disc).

What do you think about the feasibility of including Saturn graphics support (attempts were going underways back in the late nineties for a graphical editor but fizzled out due to a complete lack of interest)?
I did not dig too much into such formats. But if I manage to find enough documentation and good debuggers for such a platform, then yes, it is definitely possible that Saturn graphics support wiil be added.
Or making something like Tilemolester but with more options, better coding, and much more flexible clipboard handling (like with CT2), included within the tool? (one of the aspects I wish Tinke included. It does have a hex editor that's awesome to use on the fly for any file under the arborescence)
As I said for the previous quotes, this would go out of the main goal of this tool. So, no there is no plan, right now, to extend the program with such features.

P.S. It seems to be something wrong with the image link on this news. May some staff member fix it?

Personal Projects / Re: Parasite Eve - Translation Project
« on: July 13, 2014, 08:31:01 am »
Glad to see this translation is now finished :). Congrats!

Newcomer's Board / Re: Xdelta Gui
« on: April 16, 2013, 09:49:48 am »
Indeed, Delta Patcher is english by default, if you want to change the languag, you must ship the "resource" directory along with the executable file.

Newcomer's Board / Re: PSX VRAM
« on: April 06, 2013, 10:37:22 am »
How could this be done, for people who don't know MIPS?

Newcomer's Board / Re: PSX VRAM
« on: April 06, 2013, 06:30:10 am »
For his needings, i think copying only a bunch of hex values of any row would suffice.

Newcomer's Board / Re: PSX VRAM
« on: April 06, 2013, 04:15:12 am »
If they are not compressed, it is simply a matter of copying a portion of hex bytes of your texture (either 4bpp or 8bpp) from VRAM and serching for it over the whole ISO. Let's say you fnd a match at offset
0xA456FE5 of your ISO. Since a PSX ISO is segmented in sectors of 2352 bytes in size, simply convert 0xA456FE5 in decimal and divide by 2352 -> 172322789 / 2352 = 73266: this is the LBA (logical block address) in which a part of one and only one file of your iso is stored. In other words, open up your iso with cdmage and search for a file whose starting LBA is less or equal to 73266 and its ending LBA is greater or equal to 73266. This is the file you are searching for.

Newcomer's Board / Re: PSX VRAM
« on: April 05, 2013, 06:31:48 pm »
PSX VRAM is a 1MB 1024x512 raw image at BGR555 (16 bit). You can just dump the VRAM with pSX and then view it with psxvram by agemo or tile molester. The right-hand side of the VRAM is used to store textures to be loaded in the screen buffer on the left. Such textures can be either in 4bpp or 8bbp format, so you should change encoding for a correct visualization. At the bottom left side you can see the palettes of every 4bpp/8bpp texture stored on the right side. Such palettes are in BGR555 format too.

To get the offset of a particular coordinate in VRAM, let's say x,y, it is just y*2048 +x*2 (2 bytes per pixel, 1024 pixels per row). Note that PSX does not store images by tiles.

Unless you are expanding almost EVERY file in the game, you don't really need to rebuild your ISO image. Just extract files that need editing and then reinsert them back with CDMage.
For XA/STR editing use to extract and reinsert your movie+audio/audio files.

Programming / Re: [rusty asm] Call a routine from a routine
« on: December 06, 2012, 06:49:44 am »
Normally, ra it's stored in the stack together with other needed registers at the start of your routine, e.g.:
Code: [Select]
addi $sp, $sp, -20
sw  $ra, 16($sp)
sw $s3, 12($sp)
sw $s2, 8($sp)
sw $s1, 4($sp)
sw $s0, 0($sp)

ax registers like a0,a1 etc. are usually used for parameters to routines and vx registers like v0 etc. for return values. Temporary registers like t0 etc. are not guaranteed to contain the same value through routine calls, so they not need to be stored in the stack before the routine starts.

There is no point to continue, since seems that you like only trolling people. These were my arguments, go in peace.

You really don't want to undersatand, there could be also 100% of rom hacks out there that are confortable with BPS, but they are all rom hacks that are confortable with any other patching format invented. So BPS is pointless for such hacks, got it?

GPL'd programs, and other open source variants were defined for code reuse and not to reinvent the wheel. IMHO, there is no point to recode something to take control over it, since you have any level of control over open source code. xdelta is awful in its code, but it is still usable as a patching library if you are good enough.  A fantastic contribution to the romhacking community would be an alternative implementation of xdelta or a portable patching library for such a format.

I was agreeing with you. The fact that it works on only 90% of the existing ROM hacks, makes it completely useless.  :thumbsup:

I don't like to repeat myself, this is not true, the 90% of rom hacks out there are not for NES/SNES GBA SMD GENESIS and whatever up to 16bit console you can imagine. The whole set of rom hacks done by SadNES city is prevalently on PSX, Gemini works on PSX, every single human being on GBATemp works on NDS. Are you still sure that the 90% of rom hacks out there will find beat useful? As KaioShin stated, the "90%" of rom hacks that you are claiming to be confortable with BPS are also confortable with UPS and IPS, so, the only advantage of BPS over UPS/IPS etc is delta patching, that is useful for other type gaming console.
I will not repeat myself one more time, I hope you got it.

Even if somebody writes a faster implementation, it is pointless. If you didn't notice from several people in this thread, there is nothing worthwhile about the BPS format. There are no problems that need addressing. Clearly byuu is such an ass, that anything he writes is by extension worthless.

It seems that you can't read what I write: "BPS is a very good specification for a patching standard and I would be very happy to see new hacking projects using BPS". So, no one here is saying that byuu is an ass, don't spread something that no one has said.
Quote from: Tater Bear"
People should always stick to the first implementation and use that to judge a format. I wish everyone was a smart as you KaioShin
As you said earlier, we are not talking about the patch format, we are arguing about patchers, so we are saying that beat is not useful at all at this state, it seems that you want to understand only what it is confortable to you.

Who cares that beat functions fast enough for 90% of the ROM hacking projects out there.

This is not true, ROM hacking cannot stick to NES/SNES hacking forever. Playstation, Playstation 2, Wii, PSP, NDS and many other gaming platforms whose games are more than 300 MB in size need a fast patching tool, regardless of the game size. As I can see, RHDN is a community devoted at very old console hacking like NES/SNES, Genesis etc. but it is slowly moving to 32 bit systems like PSX, as recently opened threads demonstrate. When BPS would become fast enough to produce patches for ISO and NDS cart images, I will definitely drop xdelta.

P.S. By forcing BPS to do checksum verification, many patches obtained from an ISO image would not work in many cases, since ISO images are very dependent on the software you used to make them. This is why the xdelta format is suitable for such tasks, since it can be used to produce checksum-less patches.

A patching format is not user-friendly, it is a patching format, period. The motivation behind the existance of many frontends for xdelta is that the programming API for generating and applying xdelta patches is horribly programmed and not documented at all . Once one will embed the xdelta patching code into a GUI program, xdelta would become the de facto patching standard for the ROM hacking community. This is a problem that I was considering to resolve with Delta Patcher 2.0, that would include the xdelta3 source code inside the executable, reducing the amount of GUI widgets (like the log window).
BPS is a very good specification for a patching standard and I would be very happy to see new hacking projects using BPS but it lacks programmers at implementing a fast and optimal algorithm for generating BPS patches.

Newcomer's Board / Re: Advice for patching CD images?
« on: July 04, 2011, 06:51:36 am »
Just a hint. Try use 0 compression and compress your patch with 7z at maximum level. You archve should be' much much smaller ;).

Newcomer's Board / Re: Advice for patching CD images?
« on: July 04, 2011, 06:06:14 am »
If you guys think a window size option might be useful, It'll be simple adding it to Delta Patcher. Just let me know ;).

P.S. Regarding the new files size growing. Maybe, UltraISO or whatever program you are using, amutomatically moves these filese, changing their LBA. I suggest you changing, wherever possible, the file size only. Often, the last sector of your file stored in the ISO has many free bytes. Try using TOC Changer to calculate the amount of space available, if it suits your needs, just change the file size and reinsert your modified file (the less you move your files, the more your patch becomes small ;)).

ROM Hacking Discussion / Re: Pathcing Program Question
« on: June 12, 2011, 06:41:35 am »
The lite version of Delta Patcher has  two more "check boxes" only. The other buttons are the same of xdeltaGUI (i think the "about" button isn't so problematic :P)

Pages: 1 2 [3] 4