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

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

Pages: [1] 2 3 4 5 6 ... 11
Personal Projects / Re: PS1 tools
« on: March 12, 2018, 05:58:02 pm »
I have never tested it for that use, but it should work. The tool reads a TXT document with time range(s) which are to be spliced into the STR. You would simply use a single entry which covered the entire length.

The audio in STR files is interlaced with video. Most games I've looked at use the same interlacing pattern, but the STR format supports many patterns. This tool only works with the type I've needed to edit. If you want to try it, I can prepare a little 'how to' and upload the tool.

Personal Projects / Re: [New Tool] Visual SAK - Visual Swiss Army Knife
« on: February 28, 2018, 10:11:29 pm »
BTW what platform/game is your major knowledge on? What do you dig atm?
I've done most of my work on the PC and PS1. I'm not infatuated with those systems; it's just that people haven't done much with the Sony systems compared to mow many games were released for them, so there are a massive number of great PS1 titles ripe for the picking.

The big problem is that yes, I found the character names, but they are fixed length (for example 31x74) and if you try to fit a larger size, you'll obv mess up all the offsets that the game loads.
You're talking about the text-graphics which hold the names that you mentioned earlier, right?

Answering your question depends on how the name-graphics are stored so I dug into it a little. On my copy, the names aren't standard TIMs so they don't show up in a TIMviewer scan. They are 16 tall by varying length. The header is non-standard and missing some info such as the palette, but I think I recognize the 'image header' block which contains 'image data+header size', 'VRAM load coordinates' and 'width/height" For example, the name PAUL (16x32) in TEKKEN3.BNS at 0x86CE4C has 0C010000 50000000 08001000.
0C010000 = 0x100 image data size + 0xC image header size
5000 0000 = image load coordinates
0800 = width, in 4BPP TIMs multiply this by 4 to get pixels-per-row = 8x4 = 32 pixels
1000 = height 16 pixels

None of that information is likely to be of much help. There is room in VRAM for longer name-images, but if the game is using a custom loader, there's no telling how it handles the data. It's not just a matter of making room for more image data, you also have to see that the data is loaded and displayed properly.

Personal Projects / Re: [New Tool] Visual SAK - Visual Swiss Army Knife
« on: February 28, 2018, 01:25:29 am »
It's working nicely!

As far as "display cut off behind controls." and "White border palette", I did some testing and it's caused by Window's 'icon size' setting under 'Personalize > Display". It resizes SAK's frame, but not the image/palette display. I wouldn't worry about it, if there is no easy fix. Maybe just add a note in the readme.

Increasing PalNum beyond allowable range(access violation). The range is 1-256, how much did you enter?
Yes, higher than 256. I was emulating 'dumb guy' who mashes buttons till something glitches, grunts "This program stinks", and writes a nasty message to the developer. :P The 'up button' is properly capped at 256 now, but I can still type large numbers which cause a crash on 'Load Palette".

Do you think I should make a 'New Document' when new ROM is loaded?
No, I would not do that, for the reason you mention. I tried the same thing in the latest version (expanding the expected dimensions beyond actual file size),  and it no longer crashes- just an error message. That is fine in my opinion. Users have to exercise some common sense!

*No way to edit "Tile Address" for existing List-Entry?
Like you say, preserving the old settings when making a new entry is enough in my opinion.

I have never dug into GBA images so I can't help with finding samples. Hopefully someone will speak up.  :thumbsup:

ROM Hacking Discussion / Re: PSX - Relocating pointer table
« on: February 27, 2018, 05:23:14 pm »
What you're wanting to do is move the pointer-table further away from the text in order to expand the text. Can you instead move some of the the text further away from the pointer table? Then you would probably just have to edit the individual pointer entries for the moved text. You have the last-op-listed labeled as 'pointer', but it doesn't appear to be an actual memory address. What does the game do with the 0xffffff6f value to get the actual text start address?

So if I alter that value so that it points to pointer table, won't that mess up all the other operations it's used in? Shouldn't I be altering the value added to the base address, rather than the base address itself?
I think what he was describing is moving the entire text-block (pointers + text). You still have to edit the individual text-pointer entries to move the text further away from the pointer+table, thus making more room.

Personal Projects / Re: [New Tool] Visual SAK - Visual Swiss Army Knife
« on: February 26, 2018, 05:47:51 pm »
It working, nice! Here is some test feedback.

Access violations:
Enter name before selecting Template
Load new ROM with old values still in place (memory reads greater than new file size)

Increasing width or height excessively. Maybe happens when input dimensions exceed open-file's size.
Increasing PalNum beyond allowable range

Displayed palette colors go up with PalNum+load palette, but not down.
Loading new ROM does not clear old image.
"Add Address to list" blanks all settings; better to keep them.
No way to edit "Tile Address" for existing List-Entry?
Displayed image disappears if it goes behind another window, or off screen.
Image display starts with left and top cut off behind controls.
White border at palette right and bottom.

Maybe set starting Tile/Palette Address to 0, width/height to common size.
Maybe change PalNum to 'Colors'
Think 'make palette' buttons better docked next to 'load palette'

Programming / Re: Monochrome Palette
« on: February 23, 2018, 08:27:58 pm »
Yeah, very similar.  8) I suppose that's to be expected given the criteria.

A lot of PS1 graphics have a palette with black as 00 and white as 01. The greyscale method above usually makes these graphics render almost solid black. It's especially notable with text-graphics which are 16 color, but often only use the first 2 or 4 colors of the palette.

To account for this, I was going to try to use XOR bit flipping to calculate every other palette entry. In other words, pal[odd] = XOR of pal[even] and 0xFF etc.
If the above method would generate:
00 11 22 33 44 55 66 77 88 99 AA BB CC DD EE FF
It would instead become:
00 FF 22 DD 44 BB 66 99 88 77 AA 55 CC 33 EE 11

I haven't gotten around to testing if this actually produces any benefit, but it might be worth trying.  :thumbsup:

ROM Hacking Discussion / Re: ROM Hacks to Disable Dithering in PS1 Games
« on: February 23, 2018, 06:46:35 pm »
Interesting information to have. I would think dithering has become more of an issue since the rise of pixel-perfect LCDs.

Personal Projects / Re: Visual Swiss Army Knife (Visual SAK)
« on: February 23, 2018, 06:10:45 pm »
I thought of a feature that might be handy. If this tool is designed to map the graphics in a game and save the map to share with other modders, an option to assign graphics to a sub-group which the user could 'show' or 'hide' would be nice. For games that have hundreds or thousands of sprites, being able to thin the pool down categorically could be handy.

I tried the tool and I'm not really sure how to use it. The interface seems self explanatory, but I don't get the expected results. Maybe it would be good to include a basic VSK file to get people started?

1) I get a 'S:\...FFV advance.gba not found' message at start up.

2) I loaded a FFV USA.gba file, but I'm not sure where graphics are in the ROM for testing. I enter the address shown in the tool's screen-shot and get an 'Access violation: write of address' message. I get a similar message when I adjust zoom, width, height, offset, or name.

3) There seems to be an anchoring issue for the controls on my PC: the 'load Palette, add/remove address' buttons are anchored in place, but the address inputs and palette view are anchored right. Also, if I resize the window enough to remove the lower scroll-bar, the palette-view is cut off. I think I have my PC's view-settings tweaked, so that may be causing the issues.     

Gaming Discussion / Re: Everything happening IRL is Ocelot's doing.
« on: February 21, 2018, 10:10:24 pm »
LoL  :crazy: Too bad, I was hoping the voice actor for Roger Rabbit would do this!
It reminds me of how Charley McCarthy shook his list of supposed communist infiltrators - grandstanding to sway the ignorant masses. Sometimes I'm ashamed to be an American... Or maybe I Russian spy try influence silly capitalist pigs so plot is being not uncovered. Come Natasha, now we give stick of dynamite to squirrel an moose!

Programming / Re: Any good editors that save 16bit BMPs?
« on: February 21, 2018, 07:45:23 pm »
Imagemagick has quite a lot of features - nice!
On a related note, I was recently reminded that TIMviewer includes a 16 <> 24 bit converter for TIMs.

Programming / Re: Monochrome Palette
« on: February 21, 2018, 06:33:43 pm »
Is this to produce a surrogate palette for image data without a palette? I worked on something similar for that TIM tool and was never happy with the results. The problem being that the image data values in an indexed image have no relation to an 'appropriate' greyscale value.

In other words, in a 16 color image, a value of 0x01 in the image data could have originally represented black, white or any lightness/darkness of color. When I tried to generate a generic grayscale palette, things usually turned out very low-contrast compared to their original. I finally opted for a wildly-colored random palette which overall seemed to make the image more recognizable.

There are probably much better ways of doing it, but this was roughly what my attempt looked like, though I used a structure instead of an array. Also, note that the "step" variable does require floating point values for some color-counts:

Code: [Select]
Func _makePal ($pal, $num)

;calcualte distance between palette values, generates FloatingPoint
$step = 0xFF / ($num-1) ;example FF/4-1 color = 0x55 per step

;calculate additive value for stepping 3byte RGB channels: 0x55 to 0x555555
$step = $step * 0x10101

;set initial palette entry to black
$pal[0] = 0

;fill 1 palette entry per loop
For $i = 1 To $num-1

;Palette entry = previous palette entry plus 'step'
$pal[$i] = $pal[$i - 1] + $step
Return $pal

Personal Projects / Re: PS1 tools
« on: February 20, 2018, 02:12:36 pm »
Thank you for clarifying that NERV Agent. I think I'll call it unINTELligible byte order from now on  :P

Mugi, that was quite a find! It looks like they stopped selling the PS2 version a few years back, but the ARCHIVED site shows it was quite expensive. 

Personal Projects / Re: PS1 tools
« on: February 19, 2018, 05:47:51 pm »
Those options look similar to what the plugin has. The problem is that the vRAM coordinates are not retained when you open a TIM. In other words, when you go to save, they set to a default rather than keeping the original values. Even if you knew what coordinates to enter, who wants to enter them manually every time you save?
Does imagestudio retain the coordinates? What about multi-CLUT; does it have an easy way to switch between CLUTs?

It appears that this game shipped with an aggressive anti-Mod detection routine. My BIN/CUE, that was dumped from an original CD, locks up on pSX 1.13. There is, however, a pirated version floating around which loads normally. Comparing the two, the pirate copy appears to have been patched to bypass anti-mod. If you complete this translation, you'll probably want to factor in people using the original version. To that end, HERE is a set of patches to convert the pirate version into the original, in case it helps for comparisons.

Just make sure you don't make a fake compressor that actually inserts literal data with flags set to 0 or you will end up having making the game load quite slowly (i.e. compression is used to really decrease load time, not as an anti modification protection like many usually point out).
I know that's certainly true with large data chunks like images, but is it really significant for text? I mean 1x CD speed is something like 100,000 letters per second isn't it?

Personal Projects / Re: PS1 tools
« on: February 19, 2018, 03:30:30 am »
it's not a big deal for me though since i have the ps2 edition of imagestudio with actual tim/tm2 support
Oh sure, show of with your fancy-schmancy new PS2 generation tools! ;D

And how did you find out that there are 104 of them, each 32 bytes? I mean, there must of been some logic behind finding this specific info.
Other than 24bit, all TIMs use 16bit color. Indexed images still use 16bit color in their palettes.

That means each color entry in a palette is 2bytes long (aka 16bits). So a 16 color TIM has 32 bytes per CLUT (aka 0x20). For 256 colors, that's 512 bytes per CLUT (aka 0x100). In Tomb Raider, the block of CLUTs is separated from other stuff by a field of 00s, so it's easy to measure its total size of 0x2080. Divide that by 0x20 per CLUT = 0x104. Incidentally, there was a typo earlier. The block of CLUTs actually begins at 0xC44b8.

As far as knowing that CLUT1 went with texture1, that was an educated guess. Games are assembled by computers and computers usually do things in a patterned way.

As far as how to find the CLUT block to begin with, I looked a the VRAM and saw what looked like the CLUT block. They're almost always stored near the image data in a file, so I just scanned before and after the image data using nana, and saw the same 'shape' as in VRAM.

How do you inject new CLUTs into a TIM?
A 16 color TIM header looks like the picture below. I just copied the entire chunk of CLUTs from Level1 and inserted it over the original single CLUT. Then edited the other values to match the new CLUT size and count.
You may know the PS1 is 'little endian' meaning the byte order is reversed, so 0x104 CLUTs x 0x20 bytes each = 0x2080. Reversed and +0xC = 0x208C. Number of CLUTs = 0x104, reversed is 0x0401.

Another useful trick, since indexed palettes are identical in format to a 16bit TIM, you can extract/insert them with RAWtoTIM as a 16bit TIM. The 'number of colors' becomes width, and 'number of CLUTs' becomes height. Because the tool wasn't specifically designed for this, you may lose the 'transparency', but most TIMs don't use this feature anyways.

Also, how do you cycle through all the different CLUTs in Jasc Paint Shop Pro 9 (if it is even possible)?
Unfortunately the plugin doesn't support cycling through CLUTs. You also have to be careful about preserving the VRAM coordinates. One way to simplify this is to use RAWtoTIM to extract a TIM from the TIM. It sounds silly, but will leave all the header data intact since it only inserts the image data.

I was searching for the reason my copy won't load (anti-mod) and ran into what looks like the same compression you've been describing. If this is compression, it's just about the crummiest scheme I've ever seen. There seems to be a pattern where 00 means the next 8 letters are to be copied as is. Have you tried adding that code to your text? When the 00 is replaced with 80 (aka  1000 0000), it causes a fluctuation 8 letters later. Just like you said, a bitwise 'countdown'.

F8 0F 20 20 20 20 20 53 00
?--?-- -- -- -- -- --S

4F 46 54 57 41 52 45 20 00

54 45 52 4D 49 4E 41 54 00

45 44 0A 43 4F 4E 53 4F 00
E--D-- --C--O--N--S--O 

4C 45 20 4D 41 59 20 48 00
L--E-- --M--A--Y-- --H

41 56 45 20 42 45 45 4E 80
A--V--E-- --B--E--E--N

20 4D 4F 44 49 46 49 E1 0F 01 C8

2F 43 41 4C 4C 20 31 2D 00
/--C--A--L--L-- --1- -

38 38 38 2D 37 38 30 2D 00
8--8--8- - --7--8--0- -

37 36 39 30 00 00 00 00 00 

Personal Projects / Re: PS1 tools
« on: February 18, 2018, 11:17:37 pm »
WHaAAAaaaAAAaaaaTTTTTtttt!!!!! :D Jasc made very good software. If it aint broke, don't fix it!
I assume you tried the TIMFMTE.8BI plugin file for older versions?

Personal Projects / Re: PS1 tools
« on: February 18, 2018, 11:00:34 pm »
Yep, the ".TIMproject" file is just a TXT document which saves the settings for the given file.

HERE is a copy of the tool with the width/height limits removed. I tested it on the full-length span from Level1, and it seems to work. But keep in mind, the TIM format wasn't necessarily designed for such large sizes so quirks may show up.

So I loaded LEVEL1.PSX and it loads. However, only one 16 color CLUT was extracted, not all 11.
Unfortunately that's all the tool was designed to do since text-graphics rarely have more that one CLUT. Also note that the tool does not re-insert CLUTs so any edits to the palette will not be transfered back into the file.

Also, how did you figure out how to find where the CLUT starts? This is something I could never figure out.
I didn't really, :P The CLUTs are in a big block starting at 0x44b8 which holds 104 CLUTs at 0x20 bytes each. They are listed in the same sequence as used in the textures. In other words, CLUT1 is used for texture1 on sheet1, CLUT2 for texture2 on sheet1. The pattern begins to break down when you come to textures which reuse previous CLUTs (such as the wolf tracks) so matching a texture in the middle would be pretty hard. I'm sure the information linking texture to palette is somewhere in the file, but I don't know where.

Oh, and the plugin you linked to is for Adobe Photoshop, not Jasc Paint Shop Pro 9.
PSP is compatible with Photoshop plugins. If you go to 'Help > Help Topics' and search for "setting plug-in locations" you should see directions for installation.

Just for the fun of it, I injected all the CLUTs into the Level1 texture TIM HERE. TimViewer opens it, but I think official TIMs were capped at 16 CLUTs max.

Mugi, what version of PSP are you using?

Pages: [1] 2 3 4 5 6 ... 11