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

Pages: [1] 2
Gaming Discussion / Re: Games you want to love but can't
« on: September 27, 2016, 06:47:18 am »
Final Fantasy 1, 3 and 5. Guess I do not like the job/profession system.

Are you saying that each frame of animation is a cloud of verts that show where each vert should be during that keyframe?
No, vertices are still transformed by joints (rotation and translation).  You know in blender this is called vertex group, a vertex can belong to two groups and thus can be affected by two bones. In the game, it also works like this, just the vertex has two different values for corresponding groups. Don't know why though.

so I don't know why it is dynamically combined at runtime
That I don't know. It is just how the model works. Maybe the game converts the models and animations into more GPU friendly format. But that is a blackbox irrevelent to current topic.

Nice that array is so small ;*) 
Ha, again it is just the model format, I believe the game will also convert them into whatever it can use to calculate the matrices.

I guess, this is how different parts are splitted (sorry I'm bad at drawing, the left part is a limb and the right part is the body, the green part is the vertices affected by two bones):

The game just transforms the two parts, then merges the green parts together using the weight values on the vertices.

Ha, thanks. Yeah, I know the basis.

Now you seem to be saying that the vertices are all duplicated?
Well, I mean there are two sets of position values for those vertices that are influenced by two joints. And no,  they are not identical, the two values are different.
For example, those vertices on the shoulder are influenced both by upper arm and upper body.  You can say one set of values are for the arm and the other for the body, after the game done calculating them, use their weight values to combine the two and you get the final positions of the verts.

Not sharing verts for different faces?
I don't think so. They have plenty of faces that share verts, for example, two sides of a robe. This can't be done in blender, but in game, it is accepted.

Thanks for telling me the informations.

Actually I don't know how the game deals with it after the model is loaded, but the transform values in the model are like arrays of 6 fixed point values in the order of rotationx, rotationy, rotationz, translationx, translationy, translationz. It is more like what you see in a blender transform editor, other than matrices.

I don' t how other psx games do with their models, is it common to have a mesh splitted into parts then "weld" the vertcies that belongs to two groups? It sounds so strange to me.

Though I don't know what a matrix stack means, but I think it is the latter, each joint can have its parent joint and the transforms are all relatvie to its parent.
Edit* As for the animations, each frame is relative to the "skeleton" (aka the T pose,

I don't know why there are two positions for a vertex, perhaps it has something to do with whatever develop tools they were using.


I already managed to create animations using the joints:
However, to reverse the process I need to break down the vertices back into their original two-value format.

Without the joints forming a skeleton, the mesh roughly looks like this(no, that is not how I do in the final product):
And this is how the skeleton looks like (blender doesn't have joints, so I use small bones instead):

Programming / [math]Trying to convert 3d models to certain format, possible?
« on: September 05, 2016, 09:47:05 pm »
Recently I have been fiddling with Chrono Cross models and trying to find if it is possible to convert a normal 3d model into the game's native model format.

I will not go into details, let's say the game uses similar structures to current 3d softwares, that is vertices, faces, vertex groups and bones(or joints, whatever you name them). Each vertex can be connect to up to two joints, and the final position of the transformed vertex is decided by interpolating using the weights of the two. The only big difference is, the game uses two position values for those vertices that are connected to two joints.

The logic is like this (V = finaly vertex position, Vo = original vertex position):

Code: [Select]
V = Transform1(Vo1)*Weight1 + Transform2(Vo2)*(1-Weight1)
But in other 3d softwares, it is like this:

Code: [Select]
V = Transform1(Vo)*Weight1 + Transform2(Vo)*(1-Weight1)
So if I understand correctly, if there's only one Vo, it is not possible to calculate Vo1 and Vo2, or do I need extra informations to do that?

Gaming Discussion / Re: Not a rom hack, but side product of a rom hack
« on: August 27, 2016, 08:36:58 am »
Ah, thanks for trying it out. I guess newer webkit browser should be fine.

A while ago, I ported Radical Dreamers as a web game using Demiforce's script dump and translations on sourceforge.

The scripts are almost unchanged, except some opcode corrections because the sourceforge files are not quite up to date.
The graphics were ripped using vSNES and emulator screenshots.
The background music and sound effects were convertd using spc files or recorded using emulators (not perfect but most of them work).
The animations were recreated using javascript, but you need at least a webkit based browser(I only tested on google chrome, both desktop and android version) to see all the features, mostly because some color blending effects need it.

Direct link to the game:  JapaneseEnglish

Known issues:

1. The opening scene bgm and text not synchronized. Currently it is hard to correct it. Maybe the internet speed is a factor too. Another reason is the English text and Japanese text are not of the same length. And Javascript's timer isn't that accurate either.
2. English text wrapping problem. Because the javascript version doesn't add line breaks so the last word of a line may "jump" to the next line when more characters are being appended to the end of that line.
3. Sound effect missing/glitching. To be expected.
4. Slow down in the ending staff roll. Well, it depends on how good your cpu is. My years old PC is not too happy when too many pink birds appear on the screen.

Not a problem.

Well maybe you can try a handwriting inputing method, for example mazec for android (if there's a better one, please let me know).
I wrote these on my phone. Not a pleasant thing to to though, because the touch screen is too small for my like. :banghead:

協怖急解住惑   保



ROM Hacking Discussion / Re: PSX sound problem
« on: April 11, 2011, 09:17:25 pm »
So I need to watch SPU upload? Will check that, thanks.

ROM Hacking Discussion / PSX sound problem
« on: April 10, 2011, 11:06:37 pm »
The game is Culdcept, psx version.
After I moved the card packages to other places, something odd happened to the sound effects. That is, before a card battle, the names of the two cards will be read. But after the edit, the voice is gone, instead, a random beep or trumpet is played. :o

Thing is, I don't know how to debug sound related stuff. Any ideas on how to find the problem?

Oh, the track played during battle is called 'Guardian', isn't it?

Just took a glance at the samples you provided, and recalled I saw some similar compression before.
I'll PM you the link since it is not publicly accessable.

And what's more, the compression is byte based instead of bit if I'm not mistaken...

Many people who translate literally often lose sight of this because they've already seen the image being conveyed through kanji or whatever and don't seem to understand that for someone who's about to try to get that same image for the first time, the literal translation is going to look ridiculous.
:-\  Yeah, that is exactly what I'm worrying about.  And the literal translation from me always tends to be garrulous. Sometimes I think I have to cut extra adjuncts and add comments beside them.
I tried to written summary for each chapter so those who do the localization job (e.g., Faust) can catch the story better. It seems that is not enough at all.

but characters are still concerned with establishing their relationships to one another as they were in the original script (the "Big Bro," "Little Bro" thing in the translation demo).
I always suspect that is a wise choice. LOL
Actually the Chinese words for them are extremely short, just like a simple Mr or Ms prefix. But when it comes to literal translation, they sound as if the characters are playing house. I do hope there's a better way to express (for example, a nickname or something like that), but my skill is limited to reading forum topics and news.

Hmm, I took a look at those help text in game just to find they have to be decoded using mdec after being decompressed.

So is there any tool that can decode/encode individual such pictures?

Hmm, I converted the asm code into ugly c code, so now I can decompress things without copying them out of RAM dump.

The decompressing process is strange.

1. calculate total decompressed buffer length

2. read from the compressed buffer, set up large look-up table(s).

3. read from the compressed buffer, jump here and there in the look-up table(s) to fetch something, write the results to the decompressed  buffer.
  In step 3, it sometimes copies bytes already decoded, so I wonder whether it is some kind of lz compression.

4. check the length from step 1, if it is not done, then repeat step 2 and 3.

You can still do that with all the values stored in ra and Program Counter breakpoints.
Yeah, I figured that out though it was too late.  :P

BTW, actually, direct CD-reading was faster than decompressing the data on an emulator. The data block was 85kb in length after processed and it took a lot of time to be decompressed. That is not really an excuse though, I'm still researching the decompression routines hoping I can eventually understand it.

Yeah, I'm kinda slow to get things done. :-\

I used IDA (though I was new to it). But the game also created its own CD reading function which used DsGetSector and its own sector seeking function. So though I found the function that used DsGetSector pretty soon, I had to find its callers and figure out the parameters.

Hehe, guess I will be more skillful next time.

Check the official SDK instead (it floats around the net, very easy to find nowadays).
Hmm, I will try.
Thank you.

Yeah, finally found the cd reading function after 10+ hours of tracing and testing.
The function itself is neat. It has 4 parameters, a0: the sector number of the package file, a1: buffer address, a2: offset in the package file, a3: length

Pages: [1] 2