logo
 drop

Main

Community

Submissions

Help

56326329 visitors

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 - CUE

Pages: [1] 2
1
???

Why do I have to offer something not tested?

I'm searching for a tester (TESTER is not a TRANSLATOR). When I release a tool, I go directly to the web, as anyone can see, but it makes no sense to release tools that have not been tested. First a tester to find bugs, then, "possibly", a translation, because i saw the name of the games in some lists ("most wanted translations").

If I have explained wrong (english isn't my native language), I apologize for that.
If this is not the correct web to find a tester, I apologize for that, this not happen again, I can look in other websites, I searched a tester on many websites, and RHDN was the last. First in spanish webs, it is easier for me.

Again:
* I have no interest in these games, I was only interested in the compression method used.
* I've never talked to translate the game, only on a possible translation, and I never said I was to take part.
* I asked for a tester, first a tester to find bugs, then, "possibly", a translation.

I no need waste my time with these discussions.

Huei-, you are free to release yout own tools, tested or not tested.

2
@BRPXQZME, I have no interest in this game (I never played PS), and the final language dont interest me (english/french/spanish/aramaic ...)
If I release the tools, you'll be the first to know  ;)

@Hiei-, the first post says: "So its looking for someknow that know japanese interested for try the tools and possibly make a translation". I no need post a screen/video to show my work, and I'm not interested in a possible translation.

3
Quote from: Hiei-
I'm sure a few translators would be interested, so why not release the tools if they are done ?

Why? I have not seen any english/spanish translator interested in a few forums, and no one has contacted me, so why do they need the tools?

But... maybe this year, cleaning a bit the code :-\

4
Ooppps, I'm sorry, I left this project because nobody has interested. I have more projects and I can't wait for a translator.  :(

Packer/Dumper/Compressor/CD injector for Scripts/Graphics/Fonts (extract/insert), all are finished some months ago.


5
Newcomer's Board / Re: Edited Overlay Too Big - NDS TL
« on: April 07, 2012, 11:07:45 am »
This image is from Okamiden, the overlay table, file Y9.BIN:


The "yellow" part is the decompressed size, bytes 0x08-0x0B ('bss_size' in your info)
The "green" part is the compressed size, bytes 0x1C-0x1E ('unknown' in your info)
The "magenta" byte is the flag for compressed file, byte 0x1F ('unknown' in your info, normally 0x01)

Do you update correctly both sizes and the flag? (surely the compressed value is outdated)

You can use too BLZ to compress/decompress overlay files: http://www.romhacking.net/utilities/826/
(but you always have to update the overlay table, Y9,BIN, by hand)

6
Newcomer's Board / Re: Edited Overlay Too Big - NDS TL
« on: April 07, 2012, 05:05:38 am »
If I remember correctly, the overlays files in RE:OSS are compressed. Do you update both filesizes (compressed/decompressed)? The new overlay file is compressed? The text needs pointers (same as Okamiden)?

Too many questions with so few data.

7
Personal Projects / Re: Digimon World [PSX] Hacking Project
« on: April 05, 2012, 04:56:22 am »
Quote from: gledson999
OK thanks CUE, you jukebox Bug fix are awesome
Thanks, but I'm not the author, is Romsstar :)

8
Personal Projects / Re: Digimon World [PSX] Hacking Project
« on: April 02, 2012, 08:04:40 am »
@gledson999: Digimon World uses codes based in SJIS (2 bytes/character). You can't use 1-byte codes.

9
Quote from: Auryn
If you are using a program somebody made for you, you should give him credits everytime you mention him.
This would be a good motive to not help you and show that you just reached this point by good luck.
Anyway, I believe the guy that made the program was Pleonex and because he is a good friend, take my help as a birthday present (was last wednesday).

Took me longer to make the screenshots as to find those pointers!
PS: I was wondering why you can't edit the graphics.
I'm the guy, not Pleonex.
I have the structure of the 5 files ('sysmes.dat' too), in spanish (see below). The "hard" part is updating the control bytes if you do not know how they are organized​. The rest is very simple and easy.

Quote from: mister seta 123
CUE: Okay, I'm  a idiot.  :( Take my virginity if you want.
Ok, I'll remember. Tonight, for example? ;D >:D ;D

I have no time now, you should wait until summer. I'm busy with some tools/translations (as you know, as always). I'm updatin RHDN with some of these old tools (and more soon).

File structure:
Spoiler:
--------------------------------------------------------------------------------
cabecera + datos + punteros + bytes de control

cabecera (4x4)
- SIR0
- offset1
- offset2
- 0

los datos van seguidos, con un 0-byte como terminador, sin alinear
el final del bloque se alinea a 4 bytes, rellenando con 0xAA

los punteros van seguidos, con un 0-int como terminador, sin alinear
el final del bloque se alinea a 16 bytes, rellenando con 0xAA

en offset2 están los datos de control, de la forma usual, dependiendo de cómo estén los datos anteriores
--------------------------------------------------------------------------------
camera.dat

en offset1, por cada entrada:
- offset a los datos, hasta que sea 0
- offset a los punteros
después del cero final:
- offset 1
--------------------------------------------------------------------------------
chara.dat

en offset1, por cada entrada:
- offset a los datos, hasta que sea 0
(si el offset es menor que el anterior es un ID)
después del cero final:
- offset 1
- 0
--------------------------------------------------------------------------------
file.dat

en offset 1:
- offset a "$nombre", hasta que sea 0
- offset a "dato"
- offset a "nombre"
- offset a los punteros
después del cero final:
- offset 1
--------------------------------------------------------------------------------
staff.dat

como camera.dat
--------------------------------------------------------------------------------
sysmes.dat

en offset 1:
- offset a "nombre", hasta que sea 0
- offset a ?1 ¿coordenadas de algo?
- offset a ?2
- offset a ?3
- offset a ?4
- offset a los punteros
después del cero final:
- offset 1
--------------------------------------------------------------------------------

10
Newcomer's Board / Re: Finding kanji hex values for psx games
« on: March 27, 2012, 01:12:40 pm »
The text starts at an odd offset and Windhex needs an even offset to display correctly all. I think that's the problem.

11
Newcomer's Board / Re: Finding kanji hex values for psx games
« on: March 24, 2012, 04:58:52 am »
Using my ASCII table, NOT THE UTF8 TABLE, 99% similar as other sjis tables, and using the same offset in the ISO (*) ---> no problems found:


(*) Bad idea. It's better to work with the extracted files.

12
Newcomer's Board / Re: Finding kanji hex values for psx games
« on: March 23, 2012, 12:01:34 pm »
Please show your table. And post an offset with japanese texts.

ぁ=9F ---> or 829F?
あ=A0 ---> or 82A0?

Try with "cp932-ascii.tbl" from this package: http://www.fileden.com/files/2010/5/7/2851431/CUE.rar

The game font:
Code: [Select]
file .......... SYSTEM.DAT
offset ........ 0x00083C
tile width .... 8 (found in 0x000834, 2 bytes low endian)
tile heigth ... 14 (found in 0x000836, 2 bytes low endian)
bpp ........... 2
tiles ......... 1872
size .......... 0xCCC0 (found in 0x000838, 4 bytes low endian)
                (tiles * width * heigth * 8 / bpp)

13
Newcomer's Board / Re: Finding kanji hex values for psx games
« on: March 23, 2012, 05:14:26 am »
Tha game uses Shift-JIS codes? Are you sure?
Find the font to know what characters are used.

14
But ECCRegen only recalculate the EDC/ECC, and not update the TOC when the modified file has a different number of sectors. It's the same problem with CD-Mage.

15
These games use MODE2/FORM2 tracks, same as PSX. I can't replace the files because I don't know how to assign values  to the byte CODING_INFO (sector byte 0x013) without check the MPEG/AUDIO file. The tool never checks the files, just replace.

16
No, sorry. I'm full with other projects.  :(

What system uses CD games with 2 data tracks?

17
CUE, did you get my PMs? I sent 2 but they're not showing up in my sent box.
Yes.

I'm working in a tool to replace files in a MODE0/MODE1 CD image, similar as PSX-MODE2:


MODE0 is finished. I think the next week will be totally finished.

March 17, 2012, 04:50:55 am - (Auto Merged - Double Posts are not allowed before 7 days.)
Tool added: http://www.romhacking.net/utilities/852/

To change the cuesheet file:
- get the file LBA (file "CDDA1" in Grandia Digital Museum)
- convert to minutes/seconds/fractions
- change the values in the file (".cue" extension)

Example:
Code: [Select]
CDDA1 LBA = 193769
min = lba / (60 * 75) = 43;  // integer division
mod = lba % (60 * 75) = 269; // remainder division
sec = mod / 75 = 3;          // integer division
fra = mod % 75 = 44;         // remainder division

Edit the cuesheet file and change INDEX 01 with the new min/sec/fra values ("isoname" is the cd image name):
Code: [Select]
FILE "isoname" BINARY
  TRACK 01 MODE1/2352
    INDEX 01 00:00:00
  TRACK 02 AUDIO
    INDEX 01 43:03:44

18
Hmmmm, I have the game in ISO/MP3 format (ISO for the data track, MP3 for the music track) and  I expanded FIELD\TEXT2.BIN from 26192 bytes (0x6650) to 26624 bytes (0x6800) to fill the latest sector with random data. I replaced the file into the ISO and the game run fine in SSF Ver0.12 beta R3. Now I need finish the tool to allow replace a file with other of any size.

The EDC (Error Detection Code) is a sector CRC checksum to check if the sector data is corrupt. The ECC( Error Correction Code) is used to correct the corrupt data.

19
Quote from: MrFwibbles
How do you conclude that KERNEL.BIN is the next file? ...
YAMADA.BIN - Start at sector 614, size=80 -> 80 / 2048 = 0.04 -> rounded = 1 sector -> 614 + 1 = 615 is the next sector (LBA)
WINDOW.BIN - Start at sector 615, size=13900 -> 13900/2048=6.78 -> rounded = 7 sectors -> 615 + 7 = 622 is the next sector (LBA)
...

Max filesize in the same "space": round(SIZE/2048) * 2048 ('2048' is the sector size, 0x800):
- for YAMAHA.BIN -> round(80//2048) * 2048 = 1 * 2048 = 2048 bytes
- for WINDOW.BIN -> round(13900//2048) * 2048 = 7 * 2048 = 14336 bytes

Quote from: MrFwibbles
...After saving, recompiling and mounting the ISO, ...
How do you do?
All others files are in the same position (LBA)? Check the file "CDDA1" in the root, a CD DA file pointing to the music track. The game can crash if this LBA is modified.

Can you convert your MODE1 ISO in a MODE0 ISO with the music track in another file (MP3/WAV format)? I have a tool to modify a MODE0 image with modified files, even changing the number of sectors occupied.


~~~ ADDED ~~~
- for E800.MDT -> round(0x7B000/2048) * 2048 = 246 * 2048 = 0x7B000 bytes, the file has the max space allowed, you can't add more bytes !!!

20
ROM Hacking Discussion / Re: Densetsu no Stafi - Font Question
« on: March 08, 2012, 07:45:02 am »
I used an old (and unfinished) tool to convert a binary file into a graphic file (only 1-2-4-8 bpp) with a monochrome palette.

Pages: [1] 2