Messages

Code: ags

cEgo.Transparency = 100;

Well, there's probably a festival for any kind of music, so I think there really are no rules or guidelines or anything this round. Not sure whether that's a good idea, to be honest.

You have a german title, so you will need a german version.

Why is that? Deus Ex didn't have a latin translation.

Normally when you on track, you can go back to main menue with <Esc>,
and in the main menue you can exit the game with the exit button.

That's very wierd, I am absolutely sure I hit ESC a bunch of times, but nothing happened.

When you stuck in a wall, best way is to head back (push down arrow 2times, 2nd time when the car stands) out of the wall area and go on.

I mashed all buttons for several minutes, including the down-arrow, it didn't seem to work.

Anyways, I'll give it another try, now that it seems that I've experienced some rare glitch or whatever!

Congratulations for winning.

I got stuck in a wall on my first race though and couldn't get out. Only after minutes of backing up, going front and turning in circles, I was able to free myself, but then I was all damaged and would barely move at all anymore. It was right at the beginning and I couldn't do anything than quit, because it would have taken my ages to reach anything, so I tried quitting but didn't find a way either except for Alt+X, I think. Kinda put me off a bit.

1. Using precalculated tables for sin, cos, tan etc. is faster than using Maths.Sin etc. when you only need to have like 360 values of each (this I haven't actually tried with AGS)

That one's definitely true, for obvious reasons.

2. Using bitwise operations instead of arithmetic operations is actually a little slower. For example: x = x * 64; -> x = x << 6;

Are bitwise operations even possible in AGS? I doubt it, but am prepared to be surprised.

3. Using 16-bit color mode instead of 8-bit seems to have no performance hit at all.

True.

4. Direct3D9 is a little slower than DirectDraw5 with RawDraw. (IIRC this was mentioned in the manual)

Yup, it's mentioned and true. Actually, it's a lot slower. Also, if you're using a higher resolution, or, even worse, a filter, performance drops significantly.

5. Launching the compiled exe rather than testing the game from editor results in about 1,5x performance.

Doesn't apply here, there's no difference in performance, and I'm pretty sure there shouldn't be one. This might be a problem within AGS.

ps. have any tips for performance optimization?

Try finding your bottlenecks, if it's the math, try to simplify it as best as possible using smart and elegant formulas and terms. If it's the drawing, don't drawing anything off screen or hidden, also design your game in a way that it's not necessary to draw quite as much stuff.

It's certainly a very honorable idea to give every person with every possible preference or disability a chance to enjoy the game equally, but it's just not realistic. At least not for all games or projects.

Also, if you had created a freely configurable interface that allows every armless, blind or deaf person to play the game, shouldn't you also be extra careful not to have a love-interest in game because homosexuals might be offended or, for that matter, exclude any kind of joke that could offend for example a person with a certain disability?

Once your train of thought starts heading into this direction, it ain't coming back so quick, it leads ad absurdum in a split-second.

Even on Mac OS you can right-click.

I absolutely agree with everything you say, but I just think designing your UI with people who have only one mouse-button in mind is a little over the top.

Electroshokker, you're right on everything you mentioned except that I think it's actually very safe to use two mouse-buttons in a game. You name laptops and PDA's as examples for environments with only one button but both those devices have two mouse-buttons as well and have had them since decades. So, allowing the player to play your game with one button only and not using them both would actually worsen your design because of over-thinking and -reaction.

[bitmap-fonts]

I just got an idea, how about giving AGS's users the ability to import bitmap-fonts?

In addition to the possible font-types right now (such as importing *.ttf-files), we could choose to import a font using a sprite (this sprite works like all other sprites that we import into our games, it consists of a transparent background and all characters, similar to how normal fonts are presentated in AGS at the moment). I would picture it working something like this: once the option to add a new bitmap-font is selected, a new dialog will pop up reminiscent of the sprite import dialog, with a button allowing the user to select a simple sprite from the hard-drive and then allowing her or him to either a.) set up a character width and height (a grid will be drawn over the selected sprite for the user to confirm her or his input) or b.) to draw several selection rectangles (similar to the ones you draw for importing a portion of a sprite) defining where what character is. Of course, that last step (either a or b) is necessary in order to tell AGS from what part of the bitmap it is going to read the characters for the font from.

This would allow fonts that use characters which are hand-drawn one by one using more than one color. People could also add in shadows via alpha-channel manually or outlines etc. All of this is somehow "workaroundable", but I still believe this feature would make a great addition to AGS. One thing that has to be considered is that, unlike normal, one-colored fonts, bitmap fonts already would have the color pre-defined. So, if you change the color in the code (by calling the SetFontColor ( )-function or whatever its equivalent is called right now or by letting a character use it for speech and then having set up a speech color) it's not quite clear how that would work best.

I'm a little uncertain about this at the moment, just wanted to throw it out there.

What I mean is that games I compile with ags are really big (like 30mb) [...]

In addition to what has been said, 30mb is not big at all.

I would really advice you to learn the ins and outs of walk-cycles in a low resolution. Only a very low resolution allows you to make changes in somewhat efficient way. After you manage to make a black silhouette that fits into a 32x32px block animate fluidly, you can upgrade to higher resolutions.

or Chris could add the switch command. One 'switch' could replace all of these 100 if/else.

Then you get 100 case/breaks.

Code: ags

cEgo.Say("Thanks i'll do that)

Missing closing " and ;

Works fine here. Using WinXP and AGS 3.01, no problems at all.

I think it's fixed behavior of the MouseYPos-setting for GUIs to make them disappear whenever the mouse has been clicked. So, put short, setting a GUI with clickable arrows etc. to pop up on MouseYPos is not a good idea.

Write your own code for better results (not only to be able to fix that problem, but writing your own routine for stuff like this also drastically increases flexibility - imagine you want the GUI bar to not only appear, but quickly scroll down whenever the mouse is close, it's easy to do with your own function), something like:

Code: ags

// in rep_exec

if ( mouse.y < 20 )
// if mouse is close to top-edge of the screen
{
      // if GUI is not yet visible
      if ( !gBar.Visible )
            gBar.Visible = true;
}
else
// if mouse is not close to top-edge of the screen
{
      // if GUI is not yet hidden
      if ( gBar.Visible )
            gBar.Visible = false;
}

Code not tested, might not work out of the box, but the jist is there. It'll show or hide the GUI depending on your cursor's y-position.

Clearly Yahtzee.

BA-ZING.

What, oh what, did I do to deserve this, cruel fate?

Eh, I have a lot of exams for my bachelor-degree this very month. I have recently worked with NES-restrictions and I would LOVE to work on a little something, but it's just not possible this month. Of course, needless to say, due to three months summer-vacation, the following months would have ALL worked great up to October.

An 80's guy would say: "*sigh*, *sigh* to the max".

Sure, but do you have frames of the guy rotating? Looking in any direction (8 or 12 minimum)? Walking in any direction? Are there going to be vehicles, how do you draw these?

New versions look better, but how are you planning on drawing units in that perspective? Do you have some drawn already? Because - as long as you're not rendering them in a 3d-program (doesn't look like you will because buildings are pixel-art and both styles do not mix well at all) - I know that drawing units in all directions is a major pain in the behind. MAJOR.