Flipping Image without manual import, during game?

I'm going to try to have a game where it may consist of multiple sprite frames, so probably 100 something? So I want to condense the amount of sprites/images per character I add into an object.
Instead of manual flipping and adding the same sprites facing in the other direction, I was wondering if I can import all the sprite frames facing one direction only, and then program it to have them flipped, facing the other direction during game play? I tried using scale -1, but that just makes them invisible.

I don't know how I've been using MMF this long and never tried this, but I also ran into the lack of -1.0 scale support this morning. Can this be added to MMF?

A bit of a workaround, but could you use a shader that flips the animation? (I think that there's one available by default.)

The most efficient method in most cases is to simply do exactly what you were trying to avoid- copy the flipped animations for all sprites in an opposite animation. In my own project, for having multiple objects sprites in one object, I use 16 different animation sequences per direction, with a flag controlling if the object is flipped or not, and the objects animation set to "+16*Flag". This doesn't necessarily double the overall memory used for object animations, as they compress down pretty efficiently as mirrors of each other.

As DavidN says, you can use a HWA shader to flip the image as its rendered, but this won't apply to gameplay effects like collision detection. There should be a default shader available for flipping iirc, otherwise its very simple (pixel.x = -1*pixel.x;) But a shader isn't as good a method as just saving a reversed image hardcoded in. Besides not affected collision detection or similar software level concerns, shaders add a somewhat significant GPU burden to a game which would be unnecessary (all MMF2 shaders are pixel shaders, not vertex shaders, so particularly inefficient for large textures) and shaders limit the runtimes you can export to- HWA shaders only work in .exe windows files, other runtimes have specific shader support that is cross-incompatible, and for example anaconda can use OpenGL, while HWA is DX9

In MMF2's animation editor its not very hard to create a flipped animation. Just right click an animation direction, select "create opposite direction", then go into that opposite direction and right click it and flip vertically. So even if you had great sequences of animations it never takes too terribly long to go through and clone them all

I know it's not hard to create a flipped image. Though I was just wondering if possible in terms of memory when exporting. I also wouldn't mind support for -1.0 image flipping. I don't know why they go invisible when you do this.

MMF2 has only positive scaling. A scale of -1 is the same as 0; the object has 0 width, 0 height.

Each method of image flipping has its own drawbacks and advantages. The memory needed for hardcoded sprites is doubled at runtime, but both the uncompiled .mfa and compiled .exe or other export will be compressed and take barely any extra size. So unless you're really worried about RAM footprint, which you really shouldn't be, that's the way to go. Save shaders for more advanced, nonhardcodable effects

The thing about flipping here in MMF2 games is, in old 2D games, there was only one sprite existed in the tile set looking in one direction. It was mirrored by the games code. If this sprite was changed in the games code, it was changed facing the other direction.

In MMF2 Games, if I change a sprite facing right, in order to make the same changes of the same sprite but for facing left, I would need to apply the flip selection every time, thus making more work than necessary.

While having internal sprite flipping in direction left & right to begin with has advantages, sometimes it has disadvantages.
For example, the advantage is different shading on sprite, or holding a weapon in one hand instead of changing hands the weapon is held, depending which game you're trying to simulate.
However, in most common fighting games, the game assumes to have sprite flipping in code form, instead of manual flipping for the other direction, ala graphic importing in MMF2/CTF. So to simulate the effect, every time I import a sprite of a character facing right, then I have to keep flipping the sprite changes for facing left as well.

Importing same sprites, then flipping them is a little more work than necessary, but I guess whatever I can get by to make ti work correctly.

Oh yea, not to mention that I have to do this at least twice in MMF2/CTF2.5. One character object to be controlled by Player 1, and the other same character object, but to be controlled by player 2. Unless there's a way to create the same object but to change its controls to be used by player 2 instead.

I would just like to point out that the methods described here are choosing where to place the burden on the program.
Flipping the images and then importing them takes more memory.
Trying to flip the image at runtime taxes the cpu/gpu more.
It would seem that placing the burden on memory has a signficantly less effect than placing the burden on the CPU, especially on mobiles.

This is a feature we definitely need, most competitor development environments have this feature.

^ This. So much of this. Please! :)

I've done some programming with things like MUGEN, and they even have option to flip images at run time. I would imagine things like VB, and/or C++ have a similar programming method for flipping images.

Clickteam really suprises me with things like this sometimes. They program some absolute genius functions into Fusion....but fall down on the basic fundamentals! :O. Even AMOS programmed by Francois in the early 90s had this feature. Please rectify this Clickteam!:)

+1
object masks (an object that when it overlaps with another objects it turns that object transparent/semi transparent) would also be a great addition and help to create nice looking health bars, destructible environments, etc. Such a simple thing to program with so much potential.

Yes to flip, mask, and also resize an active's dimensions without altering the image, I know you can do it with Active Picture but it's a pain. Useful for custom health bars etc.

What do you mean resize active dimensions? You can already resize object by either scaling up at runtime, or resize manually in frame editor. Or do you mean resize in another way?


Though I still want image flipping. Would save a lot of time on image resourcing.

I think SolarB means resizing the extents of the animation border at runtime, so you can hide/show part of the animation frame. For example, if you wanted to split the character in half during the run-time you'd do active->resize animation width->0.5. If you wanted a health bar that wasn't a gradient, such as maybe a balloon that fills up with water, you could use this to show/hide part of the animation.

1+ to this! other programs this is easily done, ctf 2.5 should have this option.

Yeah, the absence of this option is weird. Forcing the user into manual, repetitive workarounds for a problem that could easily have an elegant, automated solution is rarely a good idea IMO.

Set Effect to: "Flip Horizontally"

Attachment 14336 Attachment 14337

The effect must be at flip horizontal for this to work?

Quote:

---

Originally Posted by SMASHINGmedia

Set Effect to: "Flip Horizontally"

Attachment 14336 Attachment 14337

---

Awesome!!! so it was in there XD that was well hidden lol. Is there a way to flip horizontally & vertically at the same time?
=)

Just noticed that the Hot spot doesn't flip to the reverse side wen flipped horizontally, making this function pretty useless all your characters frames are all the same image size, which is very inefficient :(
=)

+1
ehm, please?

It isn't useless if you require your pivots and action points to remain in the same place regardless of the way the sprite is facing. But if the -1 scale did what we all expect, there wouldn't be much of a need for the automatic directions in MMF anyway. ;)

Good point mobichan. I never thought of that X) I guess we'd need a command to change the hotspots/actionpoints in-game as well as the -1 object scale flip then lol.

I would be really nice if someone from clickteam could clarify how much memory space repeated frames & flipped frames take up.