Sprite glitches on PC team when editing encounters?

[Laggy]

Hi, I'm a relatively new user to the FFTPatcher tool (and have completely fallen in love with it - much kudos to Zodiac and those who developed the thing). I'm playing around with the editor and I mainly want to be able to edit pre-existing encounters under the ENTD tab.

However, whenever I take an preexisting unit (that isn't a monster) and use a new sprite/class for it, it causes sprite glitches on the PC side. When the loading screen for the map appears (i.e. "Cellar of Sand Mouse") right after formation, the background darkens and splotches a little, and in the actual fight one or more PC units are a giant jumble of multicolor pixels. Here's a screenshot:



Does anyone know what causes this and what steps I can take to prevent it? Thanks!

[Lydyn]

There's a limit of 16 units and 9 sprites that can be used per battle. Obviously this battle has hit the 9 sprite limit (5 Player Units + 4 Enemy Classes). You always need to include the 5 player units, meaning there can only be 11 Enemy Units and 4 different sprites on their side.

[Laggy]

A-ha. That explains it nicely, thank you.

Is the sprite limit only applicable to the actual jobs (Squire, Chemist, etc.) or do monster sprites fall under this as well?

[Lydyn]

All sprites fall under this rule.

[Laggy]

And as of right now, is it possible to edit the number of PCs you can have per fight (mainly looking at 4 as opposed to 5)?

[Lydyn]

Not that I know. Maybe we can, and I don't know.. we're getting closer though.

[Xifanie]

The PSX probably can't handle that well.

Even if we able able to do so my guess is that it would at the very least  slow down effects as it did in the PSP version and may make everything else slower too.

[DarthPaul]

Is there any way to speed up the effects in the psp version cause that annoys me.

[Xifanie]

Yeah, play the PSX version on your PSP.

[DarthPaul]

The effects are slow on the psp too


EDIT: misread your post and again great idea......gotta find where i put popsloader

[Gamesoul Master]

The PSP version is not being slowed down by anything happening in the game. Unless you count it being programmed to run at half speed as a "slowdown". If you look at the FPS at given points in the game, you can see it switch between 15, 30, and 60 FPS, depending on the situation. 30 and 60 FPS run at what we'd call "normal speed", but when it drops to 15 FPS (and it's a very solid kind of 15, the kind where you can tell beyond a doubt that it's capped at 15), the speed drops to half. Basically, those 15 FPS spots were programmed in every way to run at 30 FPS, but they're instead being forced to 15. Sucks, eh? No amount of "overclocking" or running from ISO instead of disc will make it go any faster.

As for the sprite limitation... It'd be interesting to find out where this limitation is imposed and play with changing it. I'm willing to bet that unless the game specifically allocates a static amount of memory to loading sprites in battle, 1 or 2 more could probably be done without any slowdowns.

Or I guess the better question is... where is the data for the scrambled sprite coming from? I'd have first guessed that the game is pulling the data from memory that doesn't belong to sprite data (out of range data), but doesn't that scrambled sprite look like a scrambled *sprite*? Meaning... doesn't it seem that it *is* indeed pulling a sprite, but simply isn't displaying it correctly? The shape looks like pieces of a sprite, but the colors look too bright to be from a sprite.

[Archael]

The PSP version is not being slowed down by anything happening in the game. Unless you count it being programmed to run at half speed as a "slowdown". If you look at the FPS at given points in the game, you can see it switch between 15, 30, and 60 FPS, depending on the situation. 30 and 60 FPS run at what we'd call "normal speed", but when it drops to 15 FPS (and it's a very solid kind of 15, the kind where you can tell beyond a doubt that it's capped at 15), the speed drops to half. Basically, those 15 FPS spots were programmed in every way to run at 30 FPS, but they're instead being forced to 15. Sucks, eh? No amount of "overclocking" or running from ISO instead of disc will make it go any faster.

It'd be interesting to find out where this limitation is imposed and play with changing it. I'm willing to bet that unless the game specifically allocates a static amount of memory to loading sprites in battle, 1 or 2 more could probably be done without any slowdowns.

Or I guess the better question is... where is the data for the scrambled sprite coming from? I'd have first guessed that the game is pulling the data from memory that doesn't belong to sprite data (out of range data), but doesn't that scrambled sprite look like a scrambled *sprite*? Meaning... doesn't it seem that it *is* indeed pulling a sprite, but simply isn't displaying it correctly? The shape looks like pieces of a sprite, but the colors look too bright to be from a sprite.

very interesting read

[Gamesoul Master]

From your short reply, I can't tell if you're being serious or messing with me in some way (sarcastic, condescending, etc)... XD.

I am hoping that somebody comes along with more information on this situation (not the PSP issue, no mystery there... I mean the sprite limitation situation). With a hint of where to start, I may even try to help look into this myself. If nothing else gets figured out, it'd be nice if we could rid ourselves of some of the mystery involved with this sprite limitation.

[Archael]

no, I'm not being sarcastic at all

it is very interesting because your read offers some insight in what we can do to implement those 2 features (more sprites, fix PSP slowdown)

[Gamesoul Master]

Well then... perhaps we could first figure out where to start. I do realize that many of you are working on other things (which is impressive, btw... I don't see too many communities full of people working on a bunch of different, related projects at the same time), but maybe a few of us could get the ball rolling on this to the point where people more knowledgable can work from our results and implement something useful from them.

The question to any of the more knowledgable types here would be... *is* there any footwork that can be done on these two issues to shed some light on the problem? Like... maybe figuring out if the glitched sprite is actually pieces of a real sprite? Or trying a bunch of different things with adding extra sprites to see if anything interesting happens? Would any of this be useful in furthering the investigation?

[LastingDawn]

Well SentinalBlade once said that those sprites are "Dami.spr"(Dummy} Though further opened up we see that sprite is a separate one altogether, a beta Iron Giant, but according to SentinalBlade if it's file is removed, the game will freeze when trying to call the above ninth sprite. Of course this is slightly contradictory because at times it calls what looks to be an askewed Other.spr, that's all the info. I know about it.

[Gamesoul Master]

Thank you very much. That is a good starting point to go off of. The first thing to figure out is... are either of these files truly called upon if the sprite limit is exceeded. Simple enough to test...