Can you just check which direction the player is facing at the very beginning of the round, and then use that character's stage if they're facing to the left? Or is that not exactly what you're trying to do?

Also, I have my doubts about your claim that most of us would have a good enough computer to run it. Maybe in a couple years, though.

Doubleres'ed MUGENs runs decently even on a p1 233. Proven by my friend who I asked to try it out.

It may not be the same story for windows XP users though.

WInane: Or the ishometeam trigger, right? Well that can work also, but that will make stage randomizations with doubleres graphics aesthetically impossible for obvious reasons.

Amazingly enough, doubleres=4 makes MUGEN run at its usual 60+ fps on my machine... something I had started to miss after upgrading to XP.

It also made Warakia shrink. Oh well, details, details...

Well, I have Windows XP, so if I can't even make it work, then I'll have to alter the project. As for using the player facing trigger, I thought about that. It can work with a player2 name trigger but.... It would have really bad effects in versus and team modes. In vs mode, the stage would ALWAYS be player2's stage and in team mode, since 2 characters will be facing right, two copies of the stage will be displayed at once (not sure what would happen graphically or technically though). What I need is a trigger that can activate based on the stagename and/or triggers that only activate only to player 1 in combination with the p2name triggers. It's all so confusing and it seems impossible for now. I really hope this changes in a future release of mugen.

I have a question regarding this.

This inconsistent scaling problem mentioned here... I have not encountered it using a scaling of 0.5 for x and y values. Am I correct to say that the scaling problems are caused because any other value besides 0.5 or 1 would not result in a perfect number, hence, the engine, due to rounding off will produce different scaling points along the sprite.

Hence, doubleres = 4 and using a scaling value of 0.5 for x and y values will give perfect results, would it not?

I am pretty sure that round up causes some small problems with sprites that are unevenly sized, though it would be really easy to code a tool that makes them even.

I know that, at least for the last DOS version of Mugen, the scaling engine has some issues; for example, some scaled sprites will look good when the player is facing the right, but the sprites will be teared when facing the left...
Example? M. Bison (the last one by The Necromancer)'s taunt.

Edit: oh, I just forgot: topic reviving is bad, mm'kay? ;)

This post has been edited by BlackJack on Dec 6 2003, 01:16 AM

In the cases of the other sections of this form, either the topic become out-dated or the users might consider a older release to be a new one. I don't see why the dead-topic rule should apply to threads in the Development Discussion section.

The universal exception to reviving dead topics rule is if the content of your message is worthwhile.

And in the case of Dev Discussion, additions and ideas are more than welcome.

Back to my topic...

In most cases it should. Even now, I am still finding out the true reason why some sprites are scaled differently. My hypothesis for this matter would be that the size of the image itself is different, and when you crop images, the size becomes really dynamic.

This can be influenced by a lot of things...
1. The initial dimensions of the image prior to encoding
2. SFF positioning
3. AIR positioning
4. SPRMAKER cropping

To cut down the suspects by at least 1, we choose not to adjust our images via the AIR file, so it stays 0,0. This somehow helps in the consistency issue, but it still produces problems on P2 side.

Eliminating another cause can be done by a STANDARD axis size starting from the image itself, prior to encoding.

A last resort would be encoding the images together in a common image size.

I believe there is a way to make the MUGEN engine scale everything perfectly.

Oh, and an update for Doubleres=4 junkies.

Capcom screen size and SNK screen size has been recalculated. Reason? when compared to an actual scaled screenshot ingame, MUGEN sprites encoded in the proportion I issued makes the character sprites appear taller than they should!

Here are the new scaling values.

CAPCOM-based games

x = 0.83
y = 1.07

Previously, it was 0.87:1.17

SNK-based games except Garou MOTW

x = 1.05
y = 1.07

For the SNK side, I already got the X proportion right from the beginning. It was in the height where it is wrong.

Now for Garou scaling.

Theoretically, Garou MOTW sprites were rendered for 320x240. But the sprites, for some reason, was scaled down further to 304x224, resulting in the shrinking of sprites. I know some of you will argue that Garou sprites were not rendered in 3d, but I dunno, anything could be possible.

*taking notes* mmm very interesting. I was very excited when I first tried out bridget to see what the fuss was about. I think this will be very good for creators that are doing characters with original sprites, when I did the mugena sprites back in the day I lost a great amount of detail when I had to shrink them down to mugen size... since they were hand drawn and colored in high resolutions. Hmmm here comes some inspiration... if I wanted to do a new Mugena I could use this technique to upscale her "transformation" sprites. Thanks for the info.

I stumbled over this and was left confused. The difference with CPS2 is kinda obvious to see when everyone becomes fat in MUGEN without scaling, but I thought NeoGeo sprites come out with the correct proportions in MUGEN without a need to scale them.

Sure, 320 / 304 = 1.0526315 and 240 / 224 = 1.0714285 but . . . well, I can't tell much difference nor if the proportions are correct with or without such scaling. :(

Furthermore, wouldn't Capcom sprites look a tad less fugly if you scaled only one of the dimensions to achieve the desired proportions? I mean, even then, it's too fugly to be worth it in my opinion (double-res or not), but why make it even more so than necessary? Shouldn't make a very significant difference in gameplay I would think, and I doubt many people care if the sprites take up the exact same proportion of the screen as they did in the games they originated from.


Also, I don't understand this at all:

Nor do I understand how this would have any effect:

If you're really truly sure about that one, could you post a before PCX file and an after PCX file to be compared?

I notice it, but moreso that backgrounds aren't scaled than characters. And more particularly that the screen dimensions are missing 64 pixels(1/6 :o).

Scaling *up* the Y component of CPS-2 sprites then redrawing the sprites seems much more useful and without detail loss.

Scaling up the X and Y components of the sprites to 400% x 500%, then scaling both axis down by 50% *seems* to be producing good double res sprites as far as CPS-2 goes that are in right proportions...

And yeah, it actually is noticable :(

EDIT: Attaching an image to better illustrate my point.

This post has been edited by Kung Fu Man on Sep 26 2004, 07:00 PM

Attached Image

So what scale values would you use in the cns? I'm lost :wacko: