PSX version battle backgrounds

[Cyberman]

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

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.

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

[Anakin]

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

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)

[Micky]

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)

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?

[Anakin]

383 KB

it doesn't make sense

[Micky]

How did you compile it?
I'd guess (from memory):

Code: [Select]

gcc stageview.cpp -o stageview -lgl -lglu -lglut

[halkun]

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.

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.

[Anakin]

The test monter in the original Japanese version was different.

That's true!

=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

[Cyberman]

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]

     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  

[Darkdevil]

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

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

Why have 9 of them?

Theres only five if I recall...

[Micky]

[Micky]

as for the stageview, compiling with -lgl -lglu -lglut makes the cpp search for gl glu and glut... but without success

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]

     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?:

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]

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

I havn't heard that before, but here you go...

[Darkdevil]

Double posting = baaaad!  Edit your last post please

[Anakin]

still too big to fit in memory  

[Micky]

still too big to fit in memory  

I can't do much, then, without access to a windows machine  

halkun, did you have more luck on Linux?

[halkun]

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?

[Cyberman]

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.

This is a very common technique, I've used it in all my embeded system projects greater than a certain size.  Modularity is a must as it saves space and creates fewer errors.

Cyb

[Micky]

A simple Makefile. It should work with minor adjustments on Linux and Cygwin. Not tested, as I don't have Linux or Windows runninig.

Code: [Select]

all: stageview

stageview: stageview.o
gcc $< -o $@ -L/usr/X11R6/lib -lGL -lGLU -lglut -lX11 -lXext -lstdc++

stageview.o: stageview.cpp
gcc $< -c -o $@ -I/usr/X11R6/include

Copy this into a file called "Makefile" and make sure the spaces at the beginning of the lines are converted into one tab or Make complains.

[sfx1999]

Anakin, my instructions were for Halkun, he uses Linux.

In MinGW, the paramaters are -lopengl32 -lglu32 -lglut32. Also, you may have to use -lstdc++.

You need to get the glut library file, also. You can find it here:

http://mywebpage.netscape.com/PtrPck/glut.htm

[Anakin]

thanks, I'll try it

[Cyberman]

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:
((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.

I believe any section of the screen can be used to display an image, Square choose to use the Left side of the display for it.  What I really want to know is what the textures offsets are inside the TIM.  I noticed they used 8 bit TIMS for the background (which makes sense because it has more detail).
I noticed you check for bit 15 to be set for transparency (which I am going to make a note of myself) in the CLUT (I haven't been doing that).

What I've been doing is decoding the TIMs and 'scanning' the references (UV coordinates) to  pick the right palette for the TIM image.  This worked fine for the TIM's for battle models however the TIM for the background is completely different (bleah!)
I guess what I can do is create the OGL textures and generate the bitmap from those, it's still difficult to know what palette to apply unless you go through ALL the UV coordinates to make the texture to begin with.  There seems to be no free lunch!

Darn

Cyb

[halkun]

It's true, bit 15 is the alpha bit. It's nice to see that working. Use my PSX doc for the VRAM format, it helps as I beileve the TIM format follows the same pattern

[Lord_Skylark]

In the original (non-international) japanese version of FF7, all of the Test enemies were regular enemies and not triangles. Additionally, when the US/Int version was released, the Diamond/Ruby/Emerald and their parts replaced some other Test enemies.

~Sky

[sfx1999]

I am going to try to make a build again using Freeglut this time.

Here it is! Go get it!

http://bin.mypage.sk/FILES/stageview.zip