We have marveled how doubleres=4 brings renewed hope for hi-resolution sprites; at the same time, hope for scaling all characters running at irregular resolutions into their right proportions.

However, with how we are running mugen, the results have been rather nasty. I have tried this with several of my "children" SDio, Kagami, Setsuna, Moriya, Sakura et al, and proved that dynamic cropping can make eyesore effects when you actually scale their proportions. For those who don't know what I'm talking about, it's the scaling effect in the characters where sometimes, the pixel would scale slightly higer, then shift lower. Inconsistent scaling is what i would refer to this case.

Is there a way around this? You bet!

The first method is that ALL sprites (save the required sprites, they do not need it!) must have the EXACT image size! Every sprite must have the exact size dimensions, in order that the scaling will be always constant, if not, you will see some pixel jittering when your character switches frames. This may mean a massive axis realignment though, it depends on how you built your character.

This however, means a heavy stab, especially if you don't have a power machine (which I doubt these days XD); you will need to tell sprmaker NOT to crop sprites, so that the image sizes for all sprites will remain constant. An exception can be made for sparks and explods.

Then for the cns. First, all of your explods, projectiles, and helpers must have their scale as follows:

scale = const(size.xscale), const(size.yscale)

It's okay if this reflects to the helper's explods too.

However, do not apply scaling to explods sourced from fightfx.air, unless you really intended to.

now that you've scaled the sprites and explods up to size, you'll notice that the alignment has all gone wrong! Okay, read on, there's a fix for this too.

For all your x and y axis of explods, projectiles, and whatnot, add a multiplication formula based on their respective axis, like the example below.

;pos = -5, 23
pos = ceil(-5 * const(size.xscale)), ceil(23 * const(size.yscale))

depending on how it was before being scaled, adjust the formula as necessary, until it looks right.

Now, the following is optional, you can do this, you may also leave this out; it's up to you.

For the complete effect of being scaled to the right proportion, you will need a copy of common1.cns to your folder.

For all x and y axis, except the hurt states, multiply all velocities by their respective axis scales. This will speed/slow their movement in tune to the original feel.

And why did we all base the scaling to the cns instead of making a var? This will simplify all scaling formulas, and it will make the character backward compatible to mugen engines running at 320x240.

If you use this for your character. all I ask is a mention in your docs and readmes. Also, don't copy this faq elsewhere; if you want to show it to other people, let them come to dev, and post reactions too, if they want.

This method seems to take way too much time (replacing all frames, editing positions ...). Anyway I'll give it a try someday. Any screenshots ?

I'm researching of a simpler way, the scaling method may only depend on basic txt sff positioning, and if so, I'll just do that, and won't require a full axis and sff recompile. I don't know, but I feel the first method is a sure-fire way to get the perfect scaling effect.

The first method sounds like an awful lot of work just for the perfect hi-res...

If you can't do it for all graphics, do it at least for the animations where the movement is nil. Especially on ground-based animations. This is where the inconsistent scaling syndrome is most obvious, but not on animations with lots of transitions of vastly dissimilar frames.

UPDATE: It seems that on P1 side, the scaling is done consistently fine. BUT...
when it comes to P2 side, the scaling screws up! The inconsistent scaling syndrome appears!

85% of the time, the scaling on p2 side becomes mangled, especially when turning. But upon returning to p1 side, the scaling is fine again!

I will need to try other scaling decimal factors. They might be the ones causing it.

EDIT #2: And it seems that it is. If it does, round off the scaling number to the closest decimal.

Maybe Elecbyte has delayed WinMugen/LinMugen new version releases cause that... they are building a new axis management routine for High-Res mode... that's my hope...

Bored, and keptopther findings to myself, but I'llgive them out now.

1. All characters will need to add a formula to all their headpos and midpos values as attacker states to evaluate the enemy's scaling too. This will practically have no effect on people scaled as 1:1, but will adjust scaled people correctly.

Here's what i mean:

state haha
type = bindtotarget
trigger1 = time = 0
value = (target, const(size.head.pos.x)) * (target, const(size.x.scale)), (target, size(head.pos.y)) * (target, const(size.y.scale))

2. Remaking your palletes via adobe photoshop's massive repallating tool can affect how the sprites are scaled.

3. inconsistent scaling occurs mostly on sprites whose axis is not 0,0 on the air side. So you'll need to make sure that all body sprites axis are adjusted on the sff.

THANK YOU!!!!! This is the info that I really needed to know. Honestly, I would have never found this because it's such an old post. The info is very detailed and lets me know EXACTLY what I will need to do. Thank you very much for reviving this topic.

Heh.

Well, there are times where an exception to the rule can be made.

If you have a problem about doubleres, post about it.

Thanx. One more thing that I need to know involves double res background images. Is this possible? The doubleres characters didn't quite look right on a normal backgrounds. I will need to do the stages just like the characters even if I will have to sacrifice certain parallax elements (I hope I won't have to). Do you have any info on backgrounds using double res sprites?

As stated in another thread, no, doubleres stages are not currently possible. Not unless they're actually part of a character, anyway.

Dangit, this really sucks. The high-res characters look way too different from the low-res background. I just wish that there was a way to scale background images just like the characters. I know it is possible to add background images in the character file, because I intended to do this with my mini-boss characters (one is a fire elemental that sets the ground ablaze and damage is inflicted as long as the fighter's feet touch the ground), but is it possible to add complete backgrounds to all the characters? I can't even imagine how to have have the correct stage (in the character file) activate. Are there triggers that specify if a player is p1 and only p1? I'd also have to have another trigger that activates from the stagename.

This just really sucks. Any suggestions on how to go about doing this? I really don't think I'm interested in going back to using single-res images for the characters just for the sake of the backgrounds, and it's almost impossible to have the overall game look good if the graphic style of the characters and stages are completely different. I know the backgrounds will need to be in the characters' cns (the pcx files for the stages will all need to be in the fight.sff file) and the coding for the stage in every characters' folder, but how can I make it react like normal stages? On a side note, if this can work, than interactivity can and will be utilized. I always wanted to see a statue or something get destroyed in a mugen fight.

Sorry if I seem to be bothing a lot of people with all my questions. But seriously, double-res has given a major graphical boost to mugen characters. It would be awesome if backgrounds can have this same blessing. I will admit that the files for everything will be rediculously huge, but the graphics and animation are so amazing that it's worth the trouble. I'm sure most of us would have a good enough computer to run it anyway. Also, I'm hoping that my project would bring new flavor and interest to the mugen community.

and unless your game is linearly-driven, the fact that there are no stage-based triggers are terrible either.

If only parallax scaling works...

[quote author=Ayu Tsukimiya link=board=4;threadid=1216;start=0#msg16485 date=1057841505]
and unless your game is linearly-driven, the fact that there are no stage-based triggers are terrible either.

If only parallax scaling works...
[/quote]

Ok, I can't tell if you're being sarcastic or not. Perhaps it's too early for me, but I was about to take a nap anyway. Anyway, what do you mean by "linearly-driven"?

Well, I'm not sure if I'd be able to do what I'd like to do, but I'm not going to cancel my project because of it either. I'll just go on ahead and make high-res character sprites and program the characters, but I'll worry about background stuff later on. Maybe in the next release of mugen (if there ever will be another release) there will be more options for backgrounds. If not, or if Elecbyte never again releases mugen (for Windows), then I may be forced to find a different platform to work with.

On a side note, I tried 24 bit pcx sprites for the background with high-res character sprites. It looked better than the low-res 8 bit bg, but not by much. The pixellation is still big and visible, I don't want this. Unfortunately, I don't think there's anything I can do. I don't intend to wreck my computer with Windows and Linux either.

No no.

What I meant by linearly driven is that the stages are used by specific people in story mode. No one can use the other, and can't use a random MUGEN stage. If so, then you can have stages generated as helpers and explods from common1.cns

The only thing is, there's no such trigger as stagename.