Regarding massively abusive framecounts

Here's the deal. I'm working on a game which is to be the crown jewel of my indie career. (Until I make the next one, obviously.) It is the most ambitious project I have undertaken, and as a grizzled veteran of solo game production, I know I need to watch my step at this high of level--it is easy to crush your own bones to jelly with unrealistic design decisions.

With this in mind, I carefully evaluated numerous development tools for it. In the end I chose MMF because it would cut the development time significantly, leaving more time for the ridiculously elaborate graphics.

Now...that's where the problem is creeping in. Or, rather, has barged in with a keg and a bad stench and taken up what may be permanent residence on my couch.

You see, the main character in the game is modular; he/she is constructed from multiple objects depending on what he/she is equipped with.

The problem is that the character has 850 frames of animation, multiplied by a minimum of 9 bodyparts. As such, the game is already experiencing choking loading times. The frame containing only the main character takes 50 seconds to load.

Second, the intent was to have the armor, clothing, and the characters themselves change color. This also takes for-freaking-ever.

So I have a few questions.

I figure the horrible load time is probably inevitable just because there is so much crap crammed in there. But I thought I'd check to see if there are ways to speed it up. So is there any way to reduce or optimize the load time for a game that has a horrendous number of frames (besides using load on call)?

Will the hardware acceleration release include the ink effects SDK or something similar to it, and if so, would it theoretically be possible to make recoloring of certain types a realtime effect? (i.e. making all pure magenta tones show up as a different hue?)

Are there any other tricks or techniques that will help a game not choke when you cram ten or twenty thousand frames of animation into a single level?

Lastly, if I asked real nice and made Bambi eyes at the developers, do you think you could make a command to reset the colors of an object to their original values? (This is so I can recolor an object to a different color)

Well I've been having the same problems too. My games get really graphically intensive, and MMF2 just currently isn't for that. I've been opting for some 'import compressed animation, AND LEAVE IT COMPRESSED for the love of God!' type of functionality.

It seems everybody is having a very low Framerate due to their projects getting more serious, which is why we all will make love to Yves when the Hardware Acceleration is out. However, it's not guranteed that it will speed up your project, depending on what part of it is causing a slowdown.

Quote:

---

Will the hardware acceleration release include the ink effects SDK or something similar to it

---

shaders might make the ink effects practically obsolete

Good.

The general idea appears to be, if your making something serious, MMF isn't a good solution. Yays..

I'm also not really expecting much from the HWA. MMF's graphics engine doesn't seem to really work well with HWA, eg. we cannot have floating point angles or positions. Well I suppose I'll just wait for the build.

Quote:

---

Originally Posted by The_Alee

eg. we cannot have floating point angles or positions.

---

How the hell do you position an object at position 341½ pixel? I mean, you can't put something between two pixels, so it's obvious that if you need floating positions you need VARIABLES. And with the angles, 360 degrees seem enough for me, but if it isn't for you then you're requiring a process that may take longer to calculate and even slow down the rotating process of standard round values. I see no use in getting to have a 321½ degree angle, but sure, I guess some could use it.

Quote:

---

Originally Posted by The_Alee

The general idea appears to be, if your making something serious, MMF isn't a good solution. Yays..

---

There is no perfect solution. If you develop seriously, you need to consider the strenghts as well as the limitations of your development tools. In MMF it's easy to create scrolling and tons of objects to test the frame rate, before spending months of work...

It is far too early to decide prematurely what HWA will and won't be able to do, or its impact on any project.

I don't see how massive, impressive, choking graphics are a sign of seriousness or MMF2's capability to create serious works.

MMF2 is a 2D creation tool and I am not aware of any tools in this range that can solve the problem of loading huge amounts of graphics into memory without taking up memory or having a corresponding impact on cpu/speed.

In all fairness, it seems that this is an across-the-board problem for anyone creating a game, be it 2D or 3D and might rely on some ingenuity, planning, and understanding of the physical restrictions that are the nature of computer hardware to date. Obviously, intensive, high-quality graphics are going to assure that your system requirements are much higher than average and impact the range of access to your work, regardless of any solutions applied to the problem.

Even 3D game creation has limits and restrictions when it comes to textures. We see video memory increasing exponentially, and there is even a proprietary, built-in compression scheme, (GTX) to allow more detailed textures. The hardware has been evolving along with the software to give more quality, (not to mention polygon count, etc. That not only creates a syndrome where the more they get, the more they want, but it forces users to update their hardware to play the games, or at least enjoy the quality in many cases.

Among the restrictions are the 2x factor for textures in 3D.

MMF2 is a serious tool and is moving forward. It is useful for serious game creation, but fun for frivolous experimentation, and it is affordable and accessible.

Clickteam is open to ideas and improvements. My quesiton is, if anyone has researched the issues involved, then that may be were the answer can be found. Then, this discussion could go from pushing the limits of hardware and software and confabulating glitzy graphics with serious game creation, (both casual and commercial) to something this company can consider implementing in the future.

If anybody has any solutions that are viable, then that is worth considering. Hardware acceleration will certainly have a large impact on MMF2, but as with 3D game creation, that impact will not be limitless and users will still have to apply skills and techniques to get the most from it, I think.

Quote:

---

Originally Posted by MechaBowser

Quote:

---

Originally Posted by The_Alee

eg. we cannot have floating point angles or positions.

---

How the hell do you position an object at position 341½ pixel? I mean, you can't put something between two pixels, so it's obvious that if you need floating positions you need VARIABLES. And with the angles, 360 degrees seem enough for me, but if it isn't for you then you're requiring a process that may take longer to calculate and even slow down the rotating process of standard round values. I see no use in getting to have a 321½ degree angle, but sure, I guess some could use it.

---

It's less for positioning, and more for custom movements. If we could just add 0.2 to an object's X location every frame...
An object's position and angle are only variables anyway, they don't necessarily correspond to the exact location the object is drawn at.

hey maggot

Here is a solution that might improve your game performance:

Instead of putting ALL graphics for the character (of which most of them you might not even use in the level!), put only the most vital parts in the character by default, and then put the rest of the graphics as .png or .tga or something externally in a folder. Then, when the player equips a new item or such, import the frames you need into the active object.

That may help...I'm also not sure why it didn't occur to me to split the animations across multiple objects, since that's what I've done with previous projects for reasons totally unrelated to framecount or loading time. If only key frames were loaded on startup and others were loaded in the background (one frame at a time or somesuch) maybe it could work...

That still leaves the recoloring problem, but if the effects SDK becomes available, it should take care of it. But that's why I want to know beforehand if the SDK is going to be able to do it, or if the SDK is even coming out--I don't want to sink a huge amount of development time into a game that hinges on something that I may never get.

I'd really rather do this project in MMF, because while the game may technically be better in true 3D, I like using MMF a lot better than Gamestudio...(And I'm a lot better at it.)

Thanks for the suggestion, wreckski. It may well end up solving a great deal of other problems...I guess we'll see.

I have another question. Do images with alpha channels take considerably longer to recolor or load?

your just looking for a program to take the work away... mmf will realistically not slow down unless you have many object's. extremely large objects or...... "BAD" work on the developer's part.

suggestions:

*coloring cloths* as for changing color just have all the cloths mono-chrome and a parent cloth object with black and white(NOT just mono-chrome). with ink effect of and/add then use replace color on the parent.

*slow loading* just look for things that stay the same or similar and remove them from large animations, untick create at start on objects you don't need at the start rather then destroying them as soon as the game starts (seems unnecessary say but i see it a lot).


lastly take a step back every little while,functionality in a game is more important then putting in as many frames you can possibly draw.


lastly be car full in the event editor, you should never have more then one event running continually.

and yes alpha channeled object's especially with ink effects like 'ADD' are MUCH slower.

Quote:

---

Originally Posted by Dynasoft

Quote:

---

Originally Posted by MechaBowser

Quote:

---

Originally Posted by The_Alee

eg. we cannot have floating point angles or positions.

---

How the hell do you position an object at position 341½ pixel? I mean, you can't put something between two pixels, so it's obvious that if you need floating positions you need VARIABLES. And with the angles, 360 degrees seem enough for me, but if it isn't for you then you're requiring a process that may take longer to calculate and even slow down the rotating process of standard round values. I see no use in getting to have a 321½ degree angle, but sure, I guess some could use it.

---

It's less for positioning, and more for custom movements. If we could just add 0.2 to an object's X location every frame...
An object's position and angle are only variables anyway, they don't necessarily correspond to the exact location the object is drawn at.

---

May I add. Chill out Mechabowser.

YES of course its possible to attempt to draw something at position 341½ pixel with the use of antialiasing or by making the position a variable and positioning it as close to that variable as possible when drawing it to screen. Obviously you can't draw something in-between pixels, but you can get very close to emulating this with anti alisasing. And thats what I meant by "floating point positions".

How do you think 3d games position objects? by pixel integers? I think not.

And i think you overestimate how many angles 360 is. Create a large and start rotating it one angle at a time. Its not pretty.

In my opinion, there's no need to make something positioned at a ½ pixel, if you use it for movement then use variables to calculate the position. As for 360 degree angles, you'd need an awfully large active that would eat more framerate than it's worth it, I'd suggest making each frame an angle.

>As for 360 degree angles, you'd need an awfully large active that would eat more framerate than it's worth it, I'd suggest making each frame an angle.
With HWA it's as expensive to draw something at any rotation, so you might as well use floats. On top of that, if the active is too large to do the rotation at runtime, you think 360+ frames to have a precalculated rotation wouldn't be far too much memory?

>In my opinion, there's no need to make something positioned at a ½ pixel, if you use it for movement then use variables to calculate the position.
The X and Y position in MMF are just variables anyway. No reason they couldn't be floats. In most engines objects' coordinates are rounded to the nearest pixel for display, but they're floating point internally to simplify movement.

After all, MMF is designed to be simple and easy-to-use for people who haven't programmed in their life. Not being able to do "Always set X to X+0.5" isn't intuitive for them.

MechaBowser, being able to rotate with decimals is really useful. Just because you can't find a use doesn't mean we can't.

Quote:

---

your just looking for a program to take the work away...

---

Well, duh. If you're making a game by yourself you need all the cheats you can get. There's plenty enough work in making the 3D models, writing the dialogue scripts, setting up the special effects, implementing the ridiculous number of special abilities available to the player (while designing to make sure none of them are redundant), coding all of the actual object behavior, putting together the level generators and all of the background graphics that go with them...

I've made enough games to know that you will be bulldozed with work even with the small ones. Anything that takes work away is *good.* That's MMF's entire purpose. In fact, my entire design is centered around getting the most gameplay value for the least time. (And "the least time" is still calculated to be 9 months worth of work...)

Quote:

---

mmf will realistically not slow down unless you have many object's. extremely large objects or...... "BAD" work on the developer's part.

---

The game actually runs fine once it's loaded. The only problem is the loading time (which is almost a full minute for the frame, and almost a full minute per object for the recoloring).

Quote:

---

and yes alpha channeled object's especially with ink effects like 'ADD' are MUCH slower.

---

I know they're slower at runtime. What I was wondering was whether they were slower to load as well, though I'll probably end up dropping the alpha either way (it was necessary before, but I found a workaround for it.)

Quote:

---

lastly take a step back every little while,functionality in a game is more important then putting in as many frames you can possibly draw.

---

Heh...draw 5000 frames? I'm nowhere near stupid enough to think I could do that. I'm using pre-rendered 3D models. (In the arena of game development, I cheat everywhere I possibly can.)

And my first impulse was to cut the framecount, but when I stepped back I realized I had already designed it as efficiently as I could, given the nature of the game. The only things I could take out were things that only took up 4 or 5 frames anyway. The most important animations were also the ones that took up the most frames.

Quote:

---

*coloring cloths* as for changing color just have all the cloths mono-chrome and a parent cloth object with black and white(NOT just mono-chrome). with ink effect of and/add then use replace color on the parent.

---

Another excellent idea...I was thinking of something along those lines earlier (albeit not as efficient as using a single black and white object) but I was worried about the fact that it would shove the frame count even higher (it would double it at minimum). But if it turns out that stripping the alpha out of my graphics will make them load faster and I can jockey having frames loaded at different times, it might not matter, and if it's pure black and white, I don't imagine the image files will be very big...I think I'm going to go ahead and switch to external files, since I checked and going with a hojillion .pngs is actually smaller than putting them all in MMF natively. It means the user will have an image directory with a hojillion pngs in it (something I was hoping to avoid), but you do what you have to do to get the thing to work...

That is, of course, assuming it's faster for it to load a .png than it is for it to load it from it's own memory after frame jockeying is accounted for. But still.

Quote:

---

Originally Posted by Dynasoft

If we could just add 0.2 to an object's X location every frame...
An object's position and angle are only variables anyway, they don't necessarily correspond to the exact location the object is drawn at.

---

Uh... you can, actually.
Set value A to the beginning X coordinates *100 of an object and Value B to the Y starting coordinates * 100. Then ALWAYS set x and y position to value A/100 and value B/100, respectively. You can, on every frame, add or subtract 1 or 2 to the A and B values to get a really slow subpixel movement (your ADD 0.2 pixels every frame).
Before complaining about not being able to do things, why don't you try exploring the software first? MMF's made it easy for you already. I guess it's too much to ask to put some effort yourself to accomplish something.

Quote:

---

lastly take a step back every little while,functionality in a game is more important then putting in as many frames you can possibly draw.
-----
Heh...draw 5000 frames? I'm nowhere near stupid enough to think I could do that. I'm using pre-rendered 3D models. (In the arena of game development, I cheat everywhere I possibly can.)

---

It's called dedication. Frankly, you had me awed till I read you're using pre-rendered 3d models. In that case, reduce the frames you're using. If they were hand made, though, I'd be bowing my head right now.

Quote:

---

Originally Posted by Alonso

Quote:

---

Originally Posted by Dynasoft

If we could just add 0.2 to an object's X location every frame...
An object's position and angle are only variables anyway, they don't necessarily correspond to the exact location the object is drawn at.

---

Uh... you can, actually.
Set value A to the beginning X coordinates *100 of an object and Value B to the Y starting coordinates * 100. Then ALWAYS set x and y position to value A/100 and value B/100, respectively. You can, on every frame, add or subtract 1 or 2 to the A and B values to get a really slow subpixel movement (your ADD 0.2 pixels every frame).
Before complaining about not being able to do things, why don't you try exploring the software first? MMF's made it easy for you already. I guess it's too much to ask to put some effort yourself to accomplish something.

---

LOL

Professional Games Developer here.

Anyway, I know this. But we keep getting people asking on the forums because they have trouble with calculations ending up with int results when they expect float, and we keep getting people trying to do custom movements for the first time who try to add fractions to an object's coordinates.

e.g: http://www.clickteam.com/epicenter/ubbthreads.php?ubb=showflat&Number=68843#Post68843

If using fractional numbers just worked in the locations, then lots fewer people would have problems. Just because something is possible isn't a reason for not making it easier.

EDIT: I just realised that you were recommending *100 and /100. You do know Alts support floating point numbers right?

Dear "Professional games developer here," I most expectedly had no idea that MMF could support floats, nor that not only "Alts" do, but virtually every other variable.

Both floating point angles and floating point positions would make it easier, it may not take much to use alterable values but it is 2 more variables to work with per object.

Angles, if they can be, should be floating point too, at the moment in engines you need to calculate the angle in a variable and set the angle to that. Not only would this prevent that problem, but if you are drawing lines with active objects and they reach any decent length 360 angles is not enough (yeah you can use the overlay but anyway...)

Every part of your game should share the resource budget.
There are hundreds of stories of best idea/realistic idea scenarios out there, and these are from the best of the best, no matter how fast the computer or how powerful the tool, if you add enough graphics anything will slow down, even C++.

The Character might just have to be scaled back, Realistic character sizes are 16x16 32x32 64x64 and 128x128. Largest size 128x128 is really only optimal for a Main Boss type character with no other characters active on the screen.

Plus you need to Optimize your work, lower your frame rate by reducing the colors, change the resolutione etc...

Quote:

---

Originally Posted by Novabrain

Hardware acceleration will certainly have a large impact on MMF2, but as with 3D game creation, that impact will not be limitless and users will still have to apply skills and techniques to get the most from it, I think.

---

3dgames creation with mmf2?
i missed something lol:) i know that there are few extentions that allow some 3d inside the 2d and i saw samples, but i still coulden't see impressive sample of 3d..so what are the 3d abilties?

Quote:

---

Originally Posted by 00J

Plus you need to Optimize your work, lower your frame rate by reducing the colors, change the resolutione etc...

---

Yeah, you probably didn't forget, but there's always these basic options. If you're using 16 million colors, 32000 is more than adequate (imo, anyway).

i made a pretty " impressive " 3d sample a while a go, (Sarah said so(an admin)); about a tank and some hills

but mmf goes threw far to much overhead to properly render 3d.

Quote:

---

It's called dedication. Frankly, you had me awed till I read you're using pre-rendered 3d models. In that case, reduce the frames you're using. If they were hand made, though, I'd be bowing my head right now.

---

Yeah, I'm a better modeler than I am an artist. (Though some of the game graphics will be hand-drawn, as determined by which is faster. The 3D graphics are set up to look drawn just so I can do this.)

My experience is that dedication and cleverness are interchangeable to a certain extent, but combined they are worth many times more...

Quote:

---

The Character might just have to be scaled back, Realistic character sizes are 16x16 32x32 64x64 and 128x128. Largest size 128x128 is really only optimal for a Main Boss type character with no other characters active on the screen.

---

I've never had a problem with MMF choking on sprite sizes (though I haven't made anything bigger than about 600x600). It's really not size that's the problem.

And 16x16 is not in any way a realistic character size unless you're running on an Atari 800. 800x600 is the minimum respectable game resolution, and even that is pretty embarassingly low to most people.

Quote:

---

Plus you need to Optimize your work, lower your frame rate by reducing the colors, change the resolutione etc...

---

The frame rate is fine. It's just the loading time. Changing resolutions doesn't affect that, but reducing the colors does. I was stuck with 16 million colors before, but that was because of the recoloring requirements (the source colors get changed) but I may be able to sidestep that using the technique SEELE suggested. (So far I haven't had a chance to try it yet because I've been trying other stuff...for some reason MMF doesn't want to load graphics from external files...)

Quote:

---

Originally Posted by Maggott

800x600 is the minimum respectable game resolution, and even that is pretty embarassingly low to most people.

---

Where did get this info based on a poll or something?. "embarrassingly low to most people"? This could be true to some hardcore player used to play 3D games with hardware acceleration and outrageous resolution in highest anti-aliasing mode and stuff like that. But 800x600 is absolutely fine for 2D games.. and for my affirmation I'm using as reference games published by large portals like MSN, Pogo, Shockwave, they're all 800x600, and they sell like hotcakes... those millions customers does not seem to be embarrassed with the resolution...

Diablo 2: LOD runs in 800x600 and it's still one of the prettiest games I've ever played :)

you can also speed up loading by starting the game on an exmpty frame then changing frame as soon as it start's, you cauld also use this as an opitunity to change the priority of the app to high/realtime. then return it to normal when the main frame load's.

if you are really desperate you might have it move slow parts of the app to virtual memory... but you'd be pretty desperate.

good luck. :cool:

LoL interesting thread.
Yeah Andos Diablo II. Historic...

Don't forget StarCraft...

I think StarCraft even ran on Pentium 90's, with like 16 mb ram, and under 1 mb Video Ram. [laugh]

600x600 for a Character, eek. Well I've never come anywhere near that size, but I've actually read in the forums where people have used that size, but wow. The only thing I can imagine is for some sort of Shooter Boss Mega Ship Enemy or something.

[s]As for the color selector, I once used alterable values to store the last color of my character parts. Then you can work from there. You need a few more bits to make it work, but the overall result is what you want, a character that can be re-colored.

We have to remember that we still have to think like designers using C++ even though MMF makes it easier. The fundamental rules of design still apply, because the hardware remains the same. heh



Actually Seele's idea sounds interesting.