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

Pages: 1 [2] 3 4 5 6 7 ... 31
ROM Hacking Discussion / Re: Landstalker sprites unpack [Genesis]
« on: June 29, 2016, 04:13:01 am »
OK, I had a look at the game.

The sprites are "dynamic" : that means that only the current frame is loaded in VRAM (opposed to static sprites : all frames are loaded at the beginning of the scene). That supposes that it's quite fast to load them, since you have only a 1/60th of second to load the frame. Usually, that means that frames are not compressed in the ROM. So I'd suggest you look carefully into the ROM, using Tile Molester or anthing related with proper config (4bpp).

It can also means that they are first decompressed in RAM, then loaded from the RAM, so you can try to make a RAM dump and look into the dump file (there are things that could be gfx around pos FF2E00, for example). If you find gfx there, it'll be easy to find the part of the code that decompress gfx there.

A good thing to know : frames are usually made of several sprites (from what I've seen plaing the game with Gens, they are made of 2 32x32 sprites). A 32x32 sprites is made of 4x4 = 16 tiles, ordered from top to bottom then left to right (whereas map tiles are raster order : left to right then top to bottom), so they are not always easy to track. If you don't succeed, you can make a dump of the VRAM : the chars tiles are tiles from 3A0 to 4FF (multiply by 32 to have the VRAM offset), then do a search in the ROM for some bytes you picked in the VRAM (be careful : some emulators don't have the wrong endianness when they dump the VRAM).

For the record, what I did :

I read into the LTT that there were compressed gfx at position 0x3986C, 0x398A0 and 0x398D4, so I launched gens-r57shell mod and made a breakpoint for reads in the ROM at these pos.

I saw that these addresses were read by the program at offset 4AB6. By studying the stack I came to the conclusion that the decompression routine starts at 2F0. The source offset is in register a0

I made a breakpoint for execution at address 2F0 and noted all the values of the register a0. Here's the list up to the first game screen. Here are the pos : 3861E (SEGA logo, it's not the offset in the doc of LTT weirdly), 3DF3C, 3986C, 398A0, 398D4 (title screen), F654 and
F668. The last twoaren't listed in the LTT doc, so they are worth a try with their tool. But it's quite unlikely : I played some time after that (up to the appearance of Friday) and no other call was made, so it'd mean these address contains all of the NPC frames. But I didn't see large portions of gfx in RAM.

So my bet is that sprites are uncompressed.

edit : there is uncompressed NPC (old man) gfx in ROM at 17E600. Nigel is around 123850.

ROM Hacking Discussion / Re: Landstalker sprites unpack [Genesis]
« on: June 28, 2016, 05:23:36 pm »
You're right ! Isn't it stupid to upload a sprite sheet in jpeg  ::)

There's a "Landstalker Translation Tool" on this site, that decompresses some stuff. have you checked whether it decompress your sprites ?

ROM Hacking Discussion / Re: Landstalker sprites unpack [Genesis]
« on: June 28, 2016, 10:02:10 am »
Tcrf already lists some. What make you think there are more ?

ROM Hacking Discussion / Re: Landstalker sprites unpack [Genesis]
« on: June 28, 2016, 08:57:28 am »
Why do you need to unpack them from the ROM ?

If you just want sprites, it's easier to rip them. If you want to make a hack, you'll probablyy need to repack your edited sprites. If they are compressed, it'll likely be quite difficult.

Personal Projects / Re: Nick + Andy Love Story (Binary Land hack)
« on: June 28, 2016, 03:44:14 am »
I don't know much about video game music, but I've been told that many music makers for MD games use Deflemask. There are several modes in it, the default is, I think, MD.

Concerning BL, those are good ideas. When i'll stick back to this project, I'll certainly implement them.

I was also thinking about a malus item that would reverse controls for only one penguin (the one who picked it), that'd make the game quite hard to play because most levels aren't designed for it. Same thing for vertical moves.

Personal Projects / Re: Nick + Andy Love Story (Binary Land hack)
« on: June 27, 2016, 09:43:49 am »
I have started a port of this game on Megadrive. It's quite advanced. Music is among the things that still need to be implemented. If you can convert them to some format MD can handle, like Deflemask in MD mode, I'm definitely interested. If you have ideas for improvement, that could make the game interesting for a longer period, I'm interested too.

Programming / Re: Optimizations that LA,OOS,OOA used?
« on: June 25, 2016, 07:26:07 pm »
I was trying to learn python and pygame however I need constant help since I have no idea where to start
I was trying to make a tile and palette system however I couldn't figure it out

You don't need to make a palette system if you program it in Python. Try to find a project on that looks like what you want to achieve, understand the source and modify it. I'd say it's the easiest way.

Personal Projects / Re: Nick + Andy Love Story (Binary Land hack)
« on: June 25, 2016, 07:23:11 pm »
Nice little forgotten game. You control two penguins : one normally while the other is mirrored. The goal is to reach the top of the screen while avoiding / killing all ennemies, and enter the exit at the same time.

The thing is there was a love story between 2 members of the staff, and they were personified in the pinguins (crying each other's names in Love Story mode).

The level music was Erik Satie's "Je te veux", ("I want you" in French), which was likely on purpose :)

Programming / Re: Optimizations that LA,OOS,OOA used?
« on: June 25, 2016, 06:14:07 pm »
That's a fallacious well-known argument : well-written Python can be faster than bad-written C.

The thing is it's much easier to write good Python than good C.

That said, I'm a huge Python fan (C too, tbh) and Python is fast enough to handle a Zelda game. You could even use pygame for it (just avoid 32 bits surfaces, stay with 24 bits + a transparent color). And if pygame isn't enough, you can always try PyOpenGL.

But even with an easy language like Python, it'll be much more work than with GameMaker (but much more rewarding, and as already said, you'll have complete control).

ROM Hacking Discussion / Re: What are you looking for in a ROM hack?
« on: June 22, 2016, 10:17:55 am »
Mainly translations. But I really like improvements when a game is notouriously bad in this aspect. For example, Stef's hack of Street Fighter 2 SCE (fixing the sound driver), or some better palette hacks (some by Pyron's or Maxfarras' Super SF2).

One day, I'll hack Rastan Saga 2 to death and make it the best arcade game of the 16-bits area  ;D

Programming / Re: Final fantasy (NES) torus map algorithm
« on: June 16, 2016, 12:33:28 pm »
What's the difficulty exactly ?

Really interesting. An intro article about how to code for PSX (compiler needed ? configuration ? How to test ? With emu ? Real hw ?) would be awesome. Just give some links towards articles you like if you don't want to lose the time to write it.

Wake up guys! This thread is one year old. If the op hasn't made his mind yet it's likely he won't translate anything at all...

Also the sms version is better looking than this mockup, and contains two extra worlds compared to the arcade.

Tons of games on the PS2 used sequenced music, and PS2G's music always sounded like low grade on board sequenced stuff to me anyway.

I think it was made on purpose : the original game already sounded 80s synthetizers and it was perfect with the overall old-school SciFi thema.

What this means is replacing it with streaming sound would require hacking the game too, or is impossible.

Or he could replace it with sequenced music too...

Cool. I don't know if this is the player, my ear, my memory or if it's intented, but it seems 2 notes are missing (around 0:17 and 0:38, the first note of the chord section).

Your link doesn't work  :)

From CUE's notes (sorry, I uploaded only the binaries) :

Sega Ages Volume 01/17 - Phantasy Star Generation: 1/2         (c) CUE 2010-2012
DAT file structure: (PSG?\*.DAT & PSG1\@EVG.DAT\0002.dat)
 - header
   + 4 bytes: number of files, low endian
   + for each file
     - 4 bytes: LBA, low endian (first LBA = 0x00000001)
   + fill
     - aligned to 0x800 bytes, padded with 0x00
 - for each file
   + X bytes: data file
   + fill
     - aligned to 0x800 bytes, padded with 0x00
PAK file structure: (PSG?\@SOUND.DAT\*.pak, some LZR decoded files)
 - header
   + for each file
     - 4 bytes: offset, low endian (first offset = 0x00000400)
     - 4 bytes: length, low endian
   + fill
     - aligned to 0x400 bytes, padded with 0x00
 - for each file
   + X bytes: data file
   + fill
     - aligned to 0x10 bytes, padded with:
       + 0x00 (only if needed)
       + file size, low endian (4 bytes) (only the needed bytes)
       + file number, low endian (4 bytes) (only the needed bytes)
       + zeros (only if needed)
PCK file structure: (PSG2\@MAPDATA.DAT\0310.pck, PSG2\@MAPDATA.DAT\0001.raw)
 - header
   + for each file
     - 4 bytes: offset, low endian
   + fill
     - aligned to 0x10 bytes, padded with 0x00
 - for each file
   + X bytes: data file
   + fill
     - aligned to 0x04 bytes, padded with 0x00
 - fill
   + aligned to 0x800 bytes, padded with 0x00
LZR file structure: (LZR encoded files)
 - header
   + 2 bytes: signature, always "CM"
   + 4 bytes: decoded data length, low endian
   + 4 bytes: encoded data length, low endian
 - data
   + X bytes: encoded data
   + Y bytes: flags
 - fill
   + aligned to 0x800 bytes, padded with 0x00

 'flag' data, 8 bits, right to left:
 - 0: uncompressed data, copy 1 byte from encoded data to 'target'
 - 1: compressed data, copy 'length+3' bytes from 'target-offset-1' to 'target'
      + 12-bits offset, bits 0-11 from encoded data
      + 4-bits length, bits 12-15 from encoded data
SGGG file structure: (some LZR decoded files)
 - header
   + 4 bytes: signature, always "SGGG"
   + 4 bytes: version?, always 0x00000001
   + 2 bytes: width, low endian
   + 2 bytes: height, low endian
   + 4 bytes: junk
 - palette, twiddled
   + for each color (256 colors)
     - 4: bytes: ABGR color, low endian
 - raw, width*height bytes
   + X: raw image
PSG1 EVENTS: (PSG1\@EVENT.DAT\*.lzr decoded)
 - event block
   + 4 bytes/code, low endian
     - code 0x0001000B + code + code + addr (address pointer)
     - code 0x0002000B + code + code + addr (address pointer)
     - code 0x00010035 + addr + code (address pointer)
     - code 0x00010036 + addr + code (address pointer)
     - code 0x00100041 + addr (address pointer)
     - code 0x0070003B + addr (address pointer)
     - code 0x0072003B + addr (address pointer)
     - code 0x00000031 + addr (text pointer)
     - code 0x0000003C + addr (text pointer)
     - code 0x0001003C + addr (text pointer)
     - ???
     - all other codes do not have addr
 - text block
   + aligned to 0x04 bytes, padded with 0x00
   + one or more text lines
   + up to 40 Shift-JIS characters per row
   + ASCII control codes
     - % ....... <PUSH>
     - \ ....... <END>
     - ? ....... <MORE>
     - * ....... <SELECT>
     - @ ....... <NEWLINE>
     - cN ...... <COLOR=N>
     - #N[N] ... <PORTRAIT=N[N]>
     - {NN} .... <WAIT=NN>
  - more blocks
Sega Ages Volume 01/17 - Phantasy Star Generation: 1/2         (c) CUE 2010-2012

So .pak files are made of several other files. Maybe some of them are not samples but tunes ?

Are there other file than *pak in SOUND.DAT ?

While the rest of your post seems valuable information, the beginning is false : CUES tools are SPECIFICALLY made for these games, and most of the resources are compressed. If it appears that sound isn't, all the better.

I just figured out how to do that, thank you tryphon.

So I've got a folder full of 0001.pak-0026.pak files, I wonder if I can use another program to replace the tracks, if I can convert them from .WAV (or .MP3) to .BIN format somehow??

Open them in a hex editor, if they start by LZ they are compressed (use CUE's psg-lzr to decompress them, it can also compress). But you'll have to figure out the format by yourself. You can try to load them as raw wav files, playing with settings to see if something recognizable can be heard. Also, look the first bytes in a hex editor, there are often clues about the format used.

Hehe thanks man! Yeah I do it by ear so it takes a while, but I'll usually load a .vgm in winamp so I can listen to each individual channel. If the music is really complex I'll also record and slow it down to hear what's being played, or make it mono if there's a lot of stereo panning effects. In special cases I've also used the debug in Regen to check the frequency of notes, which I've translated to notes on a scale. That way it's near impossible to get the notes wrong, leaving only stuff like slides, SSG-EG and vibrato that can go wrong. Which it often does, but I can at least get it close enough so that most non-musicians wouldn't notice the difference.

PS2 doesn't have too many difficult melodies or riffs and most of the songs are pretty short. It does use SSG-EG at times though, which I can't quite replicate with YM2151 because it's not a feature of that chip. For example the high pitched fade in bell notes at the beginning of Prologue with an echo effect on them, where I had to shape the instrument to simulate the SSG-EG effect.

I made some attempts to import .vgm files in the VGM MM tracker before, but it didn't quite work. Converting to midi is also only about 80% accurate, often with weird tempo changes and some wrong notes.

I see. You record from a keyboard or by directly entering notes ?
Also, why don't you use YM2612 ? Deflemask doesn't handle it ?

Pages: 1 [2] 3 4 5 6 7 ... 31