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

Pages: 1 2 [3] 4 5 6
51
Well to answer the connection between scene.out and .x battlefields in game development aspect, if the scene.out file contains camera animations they are probably the winning animations for each character. It is waste of space to include the winning animations to each battlefield so they are in one file and it's in scene.out if there are no other files containing camera animations. This applies of course for every animations that are "global".

52
Oh damn, that's incredible!! :D

I guess I'll have to up the pace with the wmx tool since you are making this much progress with the textues :S

53
I'm sorry to be the party pooper, but I highly doubt that this is real. This is why -> https://www.reddit.com/r/FinalFantasy/comments/3dmhj0/final_fantasy_viii2_fanmade/

I can't be completely sure about this being real but I recommend to not get your hopes up for this unless the OP proves me wrong.

54
While looking in the memory I found out the addresses used for the sections. I'm sure that Maki found them already but something interesting I noticed in that is that the engine adds or subtracts 2 from the value indicated in the wmx.obj for example if U1 = 40 and V1 = 60 the engine does some calculations on them and in the memory they are U1 = 42, V1 = 62 .

Sometimes it subtracts instead of adding. That is the reason why the UV's are misplaced in the PC version and the road does not show the white lines.

55
That's a lot of information! You've been rocking it :D

Why does changing camera logical zoom and flying from esthar to bridge would crash the game?
This is the glitch that is made because of "size exceeding" and static memory "bad sides".

This is more detailed exception with memory addresses and related FF8.EXE opcode (thanks to debugger):
Code: [Select]
First-chance exception at 0x00545F36 in FF8_EN.exe: 0xC0000005: Access violation reading location 0x36382834.

This means, that opcode at 0x00545F36 (FF8_EN.exe+145F36 - mov ax,[edi]) tried to read memory at 36382834, but this memory address didn't exist.
Why this happened? The memory exceed it's size limit (probably engine tried to load another texture, but in fact loading this made the engine to overwrite some sensitive parts of memory and in fact ordered the engine to read 36382834 address (which could be just part of texture bytes, or for example changed header, to read for example 255 vertex instead of 10 and completely make the game go insane).

I understand that the engine overwrites wrong memory addresses if the limit is exceeded, but I don't understand why changing the logical zoom of camera cause this kind of crash? As seen the engine always loads fixed amount of segments depending on the camera rotation so shouldn't all the textures and geometry be pushed on the memory also? So does that mean that it is VRAM related issue?

56
I do think that it is related to the padding which was used in psx. There's probably no reason why it should be exactly 0x9000 amount of bytes, but I think that padding was the only reason it exists. Otherwise they would probably be one after another.

57
Quote
by the way if you are wondering how I got your code changes is because I was too lazy to ask for source and decompiled your code, sorry about that. ;)

That's totally okay, after all I did say that I will publish the source if anyone wants it. Didn't just do it because I thought I would pull out next version out pretty quickly :P. It's in github though so I can just link it if needed https://github.com/Halferi/wmx2obj  Well there you have it :D, that's the same version as the compiled one though.

Quote
it still just sends the last created one, which means all other data stored in faces are of no use. or is this just for debugging code and that code will be changed?

Well you can say that from the whole code. I never intended it to be final yet because I knew that I still have to change things for optimization. That also includes the rearranging of functions to easier upgrades in future once the program is "ready". But don't get me wrong, I do really appreciate that you do these optimization checks, also saves time from me :P.

Quote
also, don't know where I read it, but someone somewhere said there was a limitation to how many faces or vertices can be on each terrain chunk, which I can't really see, a pure water tile uses 512 faces, 400 vertices, but the chunk with balamb town for example uses 790 vertices and 1156 faces, which suggests to me that it should be possible to put more detail onto the FF8 world.

I don't think that there is any limitation to it technically. Problems that may occur though is the performance, but testing that comes later. Each section can hold technically 0x9000 bytes which is 36864 bytes in decimals. The world map currently hardly utilizes this space fully at all, in fact I don't seem to remember any section to take over half of the maximum size.

58
Well it does use 18 texture pages right now but the way the code adds them to ArrayList is that even if the next texture page is the same as last one it adds it to the ArrayList. To minimize the memory usage it should be done that it only adds the next texture page when the value changes. I think this is what you mean right?

Oh and the heightmap looks cool :P

59
I think Maki did that already but didn't make any release yet. I guess he's keeping us waiting on purpose so he can surprise us big time ;). Well anyway, the models have been documented by Vehek so it's only matter of programming.

60
@Mcindus
That is really interesting! I haven't done anything with tonberry, but I would like to know how to take those VRAM snaps. Would help a lot to understand how the game utilizes the memory. Also is it possible to take snap of the whole VRAM with it because at least the psx vram is size of 1MB and it is presented as 1024x512 area. This is probably how it's in the PC also.

@kaspar01
Those castle portals are stored in wmsetXX.obj, I did a lot of studies on that before and I'm 90% sure that it contains the portals because it does contain lunatic pandora and other models used for world map.

61
Well I've been thinking about the subdividing of the existing polygons but there is that performance downside. However once I get the program working I can do some testing with normals affecting the performance. If somehow the game is utilizing gourard shading, then we can maybe limit the usage of normals so it wouldn't look worse but give some performance boost. Also it would save space from already limited segments which could be filled with subdivided blocks for better detail. And yes, Maki's program looked very nice. I'm wondering if you are (MakiPL) focused in the engine side of the game because of the application(s)? If you are then I think it's okay that we don't overlap too much, but of course, I wouldn't mind that.

Speaking of the textures itself. I don't think that texl.obj file leads us to anywhere with higher quality textures since it doesn't contain any header except for the textures itself. That would mean the headers have been written somewhere (maybe to .exe) and that makes it impossible to replace the textures with bigger ones. However wmsetXX.obj contains headers for these textures so utilizing those the texture size can maybe be increased.

While it is pretty interesting and definitely worth of a try, I don't plan to do it myself at least yet. The converter itself gives me some hard times since I've low amount of experience with coding still. However I won't let it stop me from doing the program because how else would I ever learn to code if I never do it. I don't want to make you think that there is a chance that I would drop out of this because I do study information and communication technologies and in fall I attend software engineering studies with main focus of game applications.

62
Oh btw, one thing about high resolution textures occurred to me sometime ago.

If we assume that the engine can handle larger size texture pages like 512x512, since it can manage 256x256 over 128x128, it could be possible to replace these files in wmsetXX.obj (and why not in texl.obj but it's not used in old release). The only thing I can see limiting this is that the headers are pointing to specific location in the file, so by changing those it could be possible to replace the old ones in the file. That will not work on texl.obj however because it doesn't have any headers.

Just a thought but should be worth a try, unless the wmsetXX.obj needs to be certain size.

63
Thanks for this tip! That sure will release a lot of load during exporting. I will rearrange the code that way since I have to do some parts again after all.

64
No no, that's really good that you point these things out :D! Hadn't really thought about that material thing yet but yes, that sounds like the most optimal way to do it, thanks for the tip! :)

Ok so, tested doing blocks outside then it occured to me the way it is built that obviously you can't preloop blocks because a segment has multiple blocks which needs to be written in correct order else the retriangulate of 3ds max will destroy 90% of the vertices. but doing the segment then passing the looped segment into the write functions still works which would cut down the loops from 2 505 to 835 for the outer segment loop alone also it would reduce the complexity of the code allowing compiled code to execute better.

Can you open this up a bit? I have troubles understanding what you are meaning with this.

65
As Zervox said that's not making 1 file for each part but make 1 file containing multiple mesh.

Actually having separated file could be a third option so that we have a choice:

-1 file 1 mesh (current)
-1 file multiple mesh (Zervox's one)
-multiple files

Very nice!
I'd like to test it as soon as possible.


Yeah that's wiser, I'll make that an option.

to save some processing time removing uneeded for loops, I noticed atleast for me that the textured version takes FOREVER to finish, reducing the amount of loops would probably help alot.

Yeah it is taking time to finish right now because it's not really optimized yet, right now it just writes every texture indices to the file which isn't really optimal. However I'll optimize it to only write specific indices only once and make the faces to refer those which will speed up the exporting process and also reduces the lag seen in 3d editing programs.

66
I'll make that happen in new version. However would you really prefer if each segment was separate .obj file? I mean isn't it frustrating to import each file? If not then I can make a setting to change these properties so you can choose if you want it stitched or separated.

67
That's really odd, I don't seem to get the same errors for some reason:


Well anyway, all the texture related problems should be corrected after next update except transparency which has to always be done manually. I'll release the updated version once I get normals working, textures corrected and the segment swapping done, may take a while  :cry:

68
Yeah I'll fix that .mtl file to not be mandatory to export everytime.

About invalid texture index. That's odd, I maybe encountered it once or twice when I first made the code but never after that. Do you know specific sections which launches this bug? Would help me to fix is ASAP. Actually if it's not severe issue I'll fix it with next update since the optimization should fix those kind of problems and also would make much less lag while editing the mesh.

69
Can you post a larger scale image of the above, can't identify the beach. Never mind, found it, I've problems with reading  :-X

The textures not being seamless is probably my calculation error since it's not perfect yet because of the hex values, I'll try to search an answer for it.

About normals. I documented in reverse engineer forums that wmx.obj contains some sort of shadowing values. Well I now know that they are normals and probably used for Gourard shading which PSX GPU can utilize (look it up if interested). For the next version I'll include normals too so the shading is not a problem after it. Though before I put normals in use I want to improve to current algorithm for texture vertexes because right now it's taking too much memory as you can see from the file size. After optimizing the algorithm I would say the file size will drop about 1/4 or 1/3

I had to check the seam thing and it appears in FF8 also:


Sorry for the first picture but I hope you can see it, my FF8 uses 128x128 textures since it's the older release. However these kind of problems occurs all over the map because of the developers. Also the odd stretches like in the kaspar01's picture are misplaced UV's by developers. There's probably nothing that can be done automatically to these unless all the UV's are re-generated.

However it looks better in game because of the renderer which makes it look more seamless, although the problem exists there even if it's harder to notice.

70
it's really low poly and low res but here it is : http://s2.postimg.org/jqe3yenjc/close_up.jpg

Seems like the road now has the white lines like in the PSX version. Show me if you see any UV misplacement's so I can try to fix them :).

71
wmsetXX textures are 128x128 each. texl.obj contains only 256x256 big textures. I think that with the current calculations both works with the geometry, don't know about larger textures.

Quote
Fun fact: most likely road and rail use same textures in same position..or apparently the things which are in the same position in the uv actually have the same texture so..basically they could probably use the same "merged" texture.. i guess..

They may be on the same page with each other, but I don't know how the engine treats it since the texture call from wmx.obj indicates that the page is different. There may be some sort of memory handler in the engine that works with the PSX VRAM to ease the job for GPU. One reason why I believe that is when memory hacking the camera in the game to value of 300 (1024 is normal camera) which zooms out the camera from the player makes the game crash when flying over esthar and FH bridge. It makes the bridge textures disappear before crash. It could also mean that the memory buffer can't keep up with the textures, but it may be too soon to make this kind of conclusions.

Quote
I confirm that road and rail can use the same texture.

fun fact 2: there is a little piece of texture which is apparently not used (not from road or rail at least..)

Nice job! Looking great :P

72
Well the UV's don't depend on the resolution so you can put higher or lower resolution images in blender or 3dsmax. However I'm not sure what happens to UV's when you put for example 1024x1024 texture, it may be messed up a bit, but then it's just a matter of new calculation and that's it. Speaking of it I can make an improvement so that when you export the world map you can choose which resolution textures you want to use so it doesn't mess up the UV's.

The problem with the UV placement is that they are presented in hex values 0-255, so I have to manually do the calculations because for example 0x7f is 127 in decimals and 127/255 = 0.498... while it's supposed to be 0.5 on UV grid.

73
Yeah, I should have probably mentioned that the game engine treats the rail and road textures as an one texture the same way as others. Timviewer shows them sepereated in wmsetXX.obj file but they are loaded to frame buffer in complete texture (128x128 I think). I found a program which can tell the VRAM locations here: http://www.romhacking.net/utilities/799/

74
Well actually it is uint8 for triangles, right? But, I don't know,  that's 256 vertices for 1 block which is pretty small area by itself, but I can see what you mean.

It would be a dream come true if we get to the point where we could edit those restraints like memory caps and so on. Thinking about the PSX memory limitations which are present in the PC version also. If those can be bypassed then the true graphic overhaul can start :P.

I haven't looked at those files, but what about esthar before and after entering the area?

Yes the whole esthar continent is a part of interchangeable sections. That Trabia Garden which kaspar01 mentioned is probably a leftover from early builds replaced with the same section. It probably contained the model and textures before the missiles, but that's never seen in the game so dumping that out seems to be logical answer.

75
wmx2obj version 2!

This program exports the world map as a wavefront .obj and material tempalte library .mtl file.

https://www.dropbox.com/s/dg6su56s5x3dlv5/wmx2obj.jar?dl=0

What's new compared to prior version:

Texture support added with correct material and vertex groups. UV's have been corrected to minimize the UV errors present in the PC version for some reason. Please report any UV calculation errors or improvements if you find the current settings to be a bit off.

Instructions:
  • Import wmx.obj
  • Choose the segments/sections you want to export. (1-768 are sections for the correct map, 768-835 are placeholders which are placed according to story progress in game.
  • Export .obj and .mtl to same directory

Good to know before use:

  • When exporting different segments and importing them to 3d program like blender, they will appear in the place where it would be on a world map instead of origin in 3d space!
  • It may take some time to export the file due to large file size, same goes for importing the exported file to 3d editing program.
  • You have to supply the textures for materials yourself by extracting them from wmsetXX.obj files or texl.obj or by some other way. The problem with extracting these files are that they use CLUT info which isn't automatically applied when exporting them. Timviewer is a good program for extracting these files as a bmp file but it extracts only 1 CLUT info at a time.

Thanks to kaspar01 for his corrected textures that he did. I was able to test my calculations and if the textures worked with these and this is how it looks:


Rails, roads and water have their own texture pages. Sadly the rails and roads are not in one texture page so I didn't spend time to correct this manually. However, you can create your own textures by looking up the UV maps from blender for example.

I purposely didn't put the source code for now, but if you want it I'll publish it!
 
Please report any bugs and wishes for improving the program. I'll start to make the importer once I have set my mind on how to wisely develop it. Also the fact that textures are hard to extract from the files is pretty stupid so maybe I'll look on to it someday.

Pages: 1 2 [3] 4 5 6