PSX version battle backgrounds

  • Thread starter Thread starter Micky
  • Start date Start date
Status
Not open for further replies.
As for compressed... It's possible but why compress something twice?  I can do a second decompression on that data and see if anything interesting comes out I suppose.
Click to expand...
You are right, applying something like LZS twice doesn't make sense. But the animation data could be in a special animation-compression format, that gets read and decompressed while playing the animation. Similar to the ADPCM compression that you can do to audio data.

Does the fixed version of the bg viewer now work for everybody, or are there still problems? I know the first few stages crash, but from then on every stage I tried worked.
 
still no,
and it doesn't run even in Cygwin
Also I tried to compile (making the changes you suggested) with MinGW and with Cygwin without success
But I didn't find the fixed version

As for the pyramid monster, I believe it was not supposed to be animated, since it most probably derives from a boss -RENO- attack which is called 'Pyramid' and it causes the member of the player team to freeze, and the only way to break it is to attack your affected team member with another
 
still no,
and it doesn't run even in Cygwin
Also I tried to compile (making the changes you suggested) with MinGW and with Cygwin without success
But I didn't find the fixed version
Click to expand...
I put the fixes directly into the sourcecode that I posted. Can you show me a stack trace?
 
I used the new source changing only the name of the folder OpenGL to glut
and in Cygwin I get>     stageview.c:7: string No such file or directory
(the same in MinGW)
and if I remove the Code: [Select]
Code: 
#include <string>
I get a series of errors starting with: stageview.c:27: parse error before 'namespace'
 
I get a series of errors starting with: stageview.c:27: parse error before 'namespace'
Click to expand...
It is a C++ program, rename it to "stageview.cpp". That should make it recognise the "string" include header as well.
 
As for the pyramid monster, I believe it was not supposed to be animated, since it most probably derives from a boss -RENO- attack which is called 'Pyramid' and it causes the member of the player team to freeze, and the only way to break it is to attack your affected team member with another
Click to expand...
It's possible by why have 9 of them? ;)
They are all the same color yellow fading to brown at the base. I thought Reno's pyriamid was green (and transparent).  This is one of those scripted battles though. So I guess we might want to find that battle script and oggle it.

You are right, applying something like LZS twice doesn't make sense. But the animation data could be in a special animation-compression format, that gets read and decompressed while playing the animation. Similar to the ADPCM compression that you can do to audio data.
Click to expand...
Still there isn't all that much data to begin with, so I'm a bit baffled.  I'll get my backgrounds working for the battle environment first then worry about it.  Have you compared the scale of the battle scenes to the scale of the battle models by the way?

Cyb
 
It is a C++ program, rename it to "stageview.cpp". That should make it recognise the "string" include header as well.
Click to expand...

compiled it successfully with both Cygwin and MinGW but upon running I get: program too big to fit in memory

(the memory of my system is 512MB)
 
compiled it successfully with both Cygwin and MinGW but upon running I get: program too big to fit in memory
(the memory of my system is 512MB)
Click to expand...
Wow, I've never seen that error before! Of course, I don't have a Windows box around to try it myself.
How big is the .exe file?
 
How did you compile it?
I'd guess (from memory):
Code: [Select]
Code: 
gcc stageview.cpp -o stageview -lgl -lglu -lglut
 
It's possible by why have 9 of them? ;)
They are all the same color yellow fading to brown at the base. I thought Reno's pyriamid was green (and transparent).  This is one of those scripted battles though. So I guess we might want to find that battle script and oggle it.
Click to expand...

The test monter in the original Japanese version was different. I think it was some sort videogame looking thing that when you hit it, the "face" would bounce back. I think it had a hand on it. I remeber it looking different....

Anyway, the pyramid battle formation has a "leader" that, when killed, will kill the children. I always found that intresting.
 
The test monter in the original Japanese version was different.
Click to expand...

That's true!
Iview1.jpg

=ENEMY000.LZS original jap version

as for the stageview, compiling with -lgl -lglu -lglut makes the cpp search for gl glu and glut... but without success
 
Ok I seem to be having a bit of trouble guessing at the Texture Page

Micky's code is (probably hacked together like everything I do):
Code: [Select]
Code: 
      int texture_idx = ((mesh_tri_flags & 0x0E)-6) / 2;

This looks like 'technically' you can have 8 texture pages
So
bits 3-1 are the texture page  index + 3 from what I can acertain from this.
That correct?

I fogot to add that it looks like the packed binary format the Square used is rather anoying  :lol:
 
The test monter in the original Japanese version was different. I think it was some sort videogame looking thing that when you hit it, the "face" would bounce back. I think it had a hand on it. I remeber it looking different....
Click to expand...

You mean like the one in the Shin-Ra building?
It generally has cannons or rockets with it....


Why have 9 of them?
Click to expand...

Theres only five if I recall...
 
as for the stageview, compiling with -lgl -lglu -lglut makes the cpp search for gl glu and glut... but without success
Click to expand...
In which directory do you have libgl.*,  libglu.* and libglut.* ? Add that with -L, so if you have them in /cygwin/lib, add -L/cygwin/lib.

Ok I seem to be having a bit of trouble guessing at the Texture Page

Micky's code is (probably hacked together like everything I do):
Code: [Select]
Code: 
      int texture_idx = ((mesh_tri_flags & 0x0E)-6) / 2;

This looks like 'technically' you can have 8 texture pages
So
bits 3-1 are the texture page  index + 3 from what I can acertain from this.
That correct?:
Click to expand...
Not really... From what I understand this is the VRAM offset used by the PSX hardware for textures for that group of polygons. It is only me that splits it into 256x256 textures. That's mostly because using odd-sized textures is a bit of a pain - not to mention it is only available in extended OpenGL.
It think this could better be written as Code: [Select]
Code: 
((mesh_tri_flags & 0x0E) / 2) - 3
, because the leftmost area in VRAM is used for the screen. But I'd have to reread the PSX documentation to make an exact statement.

Double posting = baaaad!  Edit your last post please :)
Click to expand...
I havn't heard that before, but here you go...
 
still too big to fit in memory  :(
Click to expand...
I can't do much, then, without access to a windows machine  :(

halkun, did you have more luck on Linux?
 
I'm not a programmer. I'm not keen on putzing with the creation of a X11 executable. The linker requires at least 8 libs besides the GL stuff (x11, shim, etc) and I'm not keen on creating a makefile at this very moment.

However your format discription is going to make it's way into Gears. I'm going to hold off proper placement for now, as I seem to have incorrectly placed file formats at the end of my doc when they belong at the beginning under "kernel"

I'm discovering the kernel hooks, which are the hardest to detect. The system is like layers. When the kernel loads a module it's actully on top of the kernel, the user sits on top of of module. The data is "under" the kernel so it's hard to see the kernel as it sandwiched between the user and the data.

User -> Module <-> kernel <- data

I learning how to scub away the module and see the kernel proper. It's like I can see wires going into blackness, but I can at least follow the wires.

Your back end stuff shines a light behind the kernel so I can see it.

What I find so striking is that the basic architecture of Final Fantasy hasn't changed since Final Fantasy 1 (O_o)

That too had a 16k kernel that sat on the bottom of NES memory. It purpose was to manage intrrupts, bank in modules, and keep the overall system running. Of course the original FF1 only had 16 parts that were 16k each, Only six of them were executable (Kernel, menu, battle, world map, field, and minigame.... wow, sounds familliar, huh ^_^) The rest were data resourses.

Pretty neato huh?
 
Status
Not open for further replies.
Back
Top