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

Pages: 1 2 3 [4] 5 6 7 8 9 ... 35
76
Troubleshooting / Re: Bad Animation in Battle Model RSAA
« on: 2012-07-03 12:12:47 »
Yes, seems reasonable NFITC1.

By the way, I got the 15th animation open. Turns out the secondary frame counter is missing for it, which is pretty odd because it forces you to parse the whole animation to compute it. There doesn't seems to be any flag that signals this or anything. The field that should contain the secondary frame counter equals to the animation block length - 5 (which is the maximum length of the animation chunk), but it looks like a very flimsy evidence for such a format change. I'd like to know if there are any other similar animations.

77
Troubleshooting / Re: Bad Animation in Battle Model RSAA
« on: 2012-07-02 22:06:34 »
Yes, something is seriously wrong with that animation. I also found out a few odd animations which didn't fully comply the standard format. Some have wrong chunk lengths and some have different frame count on both counters. This could possibly have some sort of meaning, since I always found pretty absurd they kept this data dulpicated. There is also some apparently unused interlaved data at the end of most animations. I don't know what could this possibly be. Maybe it's just padding?

78
I guess the cost of the resolution was pretty much linear. So it all boils down to how much time they actually could afford to spend rendering (keeping in mind the possible errors and multiple studied possibilities). I think they simply used the bare minimum resolution they found tolerable. And for the DVD versions, when everything was already final, they simply re-rendered the movies once more with a higher resolution.

As for the actual game resolution, who knows. Maybe they had some sort of technical reason for that. I can tell you , for example, early VGA games where rendered at 320x200 8bits because it was a very convenient resolution due to real mode memory mapping. Back on the day DOS programs could access the memory in 64KB chunks called segments. Since 320x200x1bytes = 64KB, one could fill the whole framebuffer without having to deal with costly bank switchings.

79
You shouldn't get stuck, since navigation is performed using walkmeshes which are not releated to the visible backgrounds.

80
FF7 Tools / Re: Kimera: FF7 p model simple editor
« on: 2012-06-10 18:36:28 »
Thank you a lot for your input Obesebear. Kimera failing to interpolate a loaded animation opens a wide range of posible causes for the problems. I'll look into it, but unfortunately won't be able to do so for a while. Our next milestone at the job it's pretty demanding and I'll need to do extra hours.

81
So If I got it right, the only way of finding animation loops is parsing the whole script, finding loops and then seeing if the animations are triggered one time after another. Ugh... that's pretty though.

Well, thank you a lot Akari.

82
Hello everyone.

I was wondering if there is any know way of detecting if an animation is used as loop by the game, both on battles and field. I guess at least there must be some sort of script code that sets the character animation and tells the engine wether they must loop or not. Is this system already known?

Thanks.

83
General Discussion / Re: Ever tried FF7 using Voodoo2?
« on: 2012-05-24 20:43:40 »
I don't think FF7 look as good with a Voodoo as you're picturing it popnlocke. Sure voodoo cards were famous for their diethering on 16 bits graphics which I'm sure made FF7 look great compared to the horrible banding offered by the other cards. But since we're currently playing in 32bit of color, that's no longer an issue. As for the resolution support, are you sure they added support for resolutions higher than 640x480? I think you're wrong. Textures, on the other hand, are the very same regardless of the hardware you're using, so the only way a Voodoo could make them look any better was though bilinear filtering, and that's available on any other card too. Anyway, I think one could play FF7 with full Voodoo 2 support nowadays using DosBox, so maybe I'll try one day.

84
FF7 Tools / Re: Kimera: FF7 p model simple editor
« on: 2012-05-20 22:39:42 »
I uploaded a new version to fix the interpolation issues. Using the interpolate animation button several times doesn't wok to well due to some normalizing that must be done with rotations to fit into the FF7 format. So I added the option to specify the number of frames, which works fine.

As for the problems with the models, I don't know what's going wrong yet. You say those worked fine on 0.93? I don't recall having done any major changes on the animations decoding, but who knows.

85
Actually, I remember seeing that glitch even when I played for the first time around 2000 (obviously with no mods). Maybe it did work correctly with the software renderer?

86
FF7 Tools / Re: Kimera: FF7 p model simple editor
« on: 2012-05-16 21:03:06 »
Damn. You're right Obesebear, there is a big problem here. I think I know where this went wrong. I'll have to do some changes.

Thanks for your input.

87
FF7 Tools / Re: Kimera: FF7 p model simple editor
« on: 2012-05-15 16:52:41 »
I uploaded a new version. Since my other project isn't progressing as I expected, I decided to add animation interpolation in Kimera. It's usage is sort of pointless right now, though, since the framerate of the game should be adjusted for several other things (scripts, cameras, limit breaks...) befor we can dream about having FF7 working a 60 FPS. You can also interpolate individual frames if you are into animation edition.

I also fixed some overflow bugs. It should be working correctly this time.

You can thank sl1982 for waking me up from my slumber. :-P

88
I can add an option to reorder groups in Kimera if you really need it. But I don't think you really need to go that far. As I told earlier, you can open the HRC file, look for the head bone models list and simply add another model at the begining of the list. For example, for Cloud it would look something like this:

head
chest
6.8333898
2 SOME_FILE AAAF

That should prevent any kind of blinking.

89
Well, not exacly. You can add a group compossed by a single very small triangle, though. The idea would be to use the "Add part to the bone" button to add an irrelevant model and the collapse it to a single p file when saving.

There is an easier way of removing blinking, though, that consist simply in adding an irrelevant model at the begining of the models list for the head bone (in the HRC file).

I've seen someone befor use a more elegant method that consisted in adding a pair of poligons right in front of the eyes textured with open version of the eyes and left the inderlying model with the eyes closed. That way blinking actually worked.

It was specualted that one could actually go as far as adding more frames to this blinking animation, but such thing should be done manipulating field scripts.

90
Graphical / Re: Understanding model files
« on: 2012-05-12 10:46:30 »
If you need source code, you can take a look at Kimera's source (in the tools subforum). I also have C code for working with field models if you need it (it's pretty old, though)

91
FF7 Tools / Re: Kimera: FF7 p model simple editor
« on: 2012-04-24 23:47:38 »
Mmm... now that you mention it, this could also happen because the last version was compiled with a diferent version of VB6. Did you try exacly the same executable on both machines?

92
FF7 Tools / Re: Kimera: FF7 p model simple editor
« on: 2012-04-18 20:31:17 »
If Kimera works fine on a machine and fails in another one, my guess is that most likely it's due to different versions of the VBRUN libraries. I also found quiet a few overflow errors when loading 3Ds files recently because the values weren't automatically casted from Integer to Long. VB is sure a strange language...

93
FF7 Tools / Re: Kimera: FF7 p model simple editor
« on: 2012-03-21 22:48:43 »
I was actually planning to reupload this just after I heard about the Megaupload downfall, but then I completly forgot about it. Sorry.

Unfortunately I can't assist you on your quest for an VB6 decompiler sl1982, but I'm afraid you're completly right about the variable names (and also function names). I guess you may finish sooner by redoing it again. If you need help with something, you can count on me.

94
FF7 Tools / Re: Kimera: FF7 p model simple editor
« on: 2012-03-19 10:43:29 »
Reuploaded the source code to rapidshare in case someone wants to mess with it.

95
FF7 Tools / Re: Kimera: FF7 p model simple editor
« on: 2011-12-19 19:14:53 »
So, in playing around with Kimera's animations, and in keeping with your new project concerning COLLADA.  I wanted to suggest implementing a way to move and rotate bones with the mouse instead of clicking left or right arrows.
I assume that won't see the light of day, but just wanted to suggest in on the off chance that someone else picks up the source code to continue improving it.

I thought about that a long time ago and certainly was on my plans. Unfortunately, as you guessed, I'm pretty much done with Kimera. As for the other project (which isn't comming along very nicely), It's aimed to work directly on a real modeling suite.

The link for Kimera V0.93 is down, any upload would be nice (the modified version)

I know this thread is long dead, but the topic seems relevant enough to reply, unless there's a rule against even that, which I don't know of.

Why do you want v0.93 dragicorn? Did any new bugs arise with the lastest version? I thought it was quiet stable this time...

what are the files whit the 3d models???....

Sorry freundwolf, but what 3d files are you talking about?

96
Completely Unrelated / Re: Regarding Emulators
« on: 2011-10-06 19:08:45 »
But using fancy filters to the level of making a cube look like a sphere has it's drawbacks. You end up losing definition and/or detail. If you were to smooth the actual geometry that would certaily look interesting, but would be way too expensive, error prone and in several cases just imposible. I recall seeing some experiments years ago on Project 64, but I guess they didn't get too far.

As for not being able to use AA on a specific applications, there can be several reasons. Some rendering modes and render targets impose several restrictions. For example, you can't enable AA when writting to multiple rendere targets (which is the reason why you can't use driver's antialiasing when using deferred shading). I'm not sure about Antisotropic filtering, but I guess there are cases where you can't use it either.

97
Completely Unrelated / Re: Regarding Emulators
« on: 2011-10-05 23:26:27 »
I guess you're talking abount New Super Mario Bros e1sunz. Well, sure it's a great game, but let's face it, it's no technological wonder. God of War, on the other hand, it's pretty nice for a PS2. PCSX2 has been developed for way longer and allways has led the advances in the exploitation of the newer equipment capabilities. The usage of dual core, specialicez CPU instruction sets, DirectX 10 and now even multicore support (a feature that Dolphin team is still to implement, supossing it's possible to do it at all)...

98
Completely Unrelated / Re: Regarding Emulators
« on: 2011-10-05 20:05:12 »
There is a very good reason to run PCSX2 in software renderer: special GFX effects. The hardware renderer will do a great job most of the time, but sometimes it just fails miserably to do some tricks. Specially when dealing with postprocessing, which can be anoying on some games and completly ruin the experience in others (such as Valkirie Profile 2). And Dolphin is certainly way more demanding than PCSX2 in most cases.

As for the XBox, CXBX can run several games to some degree (see compatibility list here http://shogun3d-cxbx.blogspot.com/2009/11/cxbx-compatibility-list-updated.html). It was also very fast back when it only emulated Turok Evolution since it relied on virtualization instead of emulation. Don't know how it works currently. The project died a month ago, though, as far as I recall. There was that other one called Xenon that could only handle HALO and was very slow several years ago.

Talking about 3D, the Sega Genesis could also handle a bunch of untextured triangles too (without extra hardware). And if we talk about wireframe, hell, even the NES had Elite.

The Saturn is also pretty well emulated too through SSF. No fancy enhacements, though. There were a few atempts at that years ago (Casini and Satorune), but they were cancelled. The PSP emulator (JPCSP) is also surprisingly advanced too.

99
Bolsola, in my opinion in the end what makes a language good for beginers is the lack of details that could turn them off in frustration. Getting simple things running quickly is important to keep peolpe trying. That's why I tend to recomend things such as VB. Pointers arithmetics and manual memory management are powerful tools, but they could easily make many beginers desist early (and I think coding C/C++ can lead you to face them pretty soon, either directly or indirectly). Also in my opinion concepts such as classes, inheritance or polymorfism are too advance and would be best avoided by beginers. Sure Java and C# will make you face classes as soon as you try doing something moderately complex, but for small test programs they should be fine and, in case of errors, they offer a nice amount of information to lead you quickly to the source of them.

As you suggested Python is provably a good starting point too. I haven't presonally used it beyond a small script I had to write some time ago for Blender but I've heard good things about it.

100
FF7 Tools / Re: Kimera: FF7 p model simple editor
« on: 2011-08-29 20:07:37 »
Hey, that sample looks very insteresting ultima espio. Thanks a lot!

Pages: 1 2 3 [4] 5 6 7 8 9 ... 35