Messages

I beleive thats an importrant technical question. So far backwards compatability between versions has been an impossibility. I think we should start exploring ways to address future versions with backwards compatibility such as Glenn has expressed. It would be nice to clear the bridge between versions for small and large projects with a revised editor version.

Cheers,
Sparx.

Hard to believe but it seems to have been out for about 8 months.
Awesomeness! Not only for windows but its even out for MacOS X and a theres a semi-stable build for PocketPC.

Check it out:
http://www.glumol.com

Cheers,
Sparx

Sorry if this has already been suggested before, but it would be lovely to be able to display text at specific coordinates for text-based effects like a character snickering (imagine like in DOTT "SNICKER!" being displayed upward diagonally 3 times, one after the other. Additionally I would also like to see text effects extended to the screen rather than just for characters using the character's font and color. To have "CRASH!" and "BOOM!" display at any coords whithin the screen as dynamic text would be really handy rather than creating bitmap replicas of the fonts and styles. Perhaps I've missed an important memo and this functionality is already very possible.

Cheers,
Sparx.

Brilliant work DKH. When did the idea of making an FPS system out of AGS spawn in your head? I find my brilliant moments come in the early hours of the morning.
This is cool. Major cool, man.

Cheers,
Sparx.

Thereby ensuring that if the line you want to skip times out just as you're clicking, you don't miss the next line.

Good suggestion Snarky. I second that. Too long have I been haunted by the unpredictable window of time that text is displayed and how long I have before I can skip it before it times out. Perhaps AGS could be the first engine to specifically support a feature to counter this undesirable behavior.

Cheers,
Sparx.

Is there any chance to include nice and perfectly working LucasArts GUI in upcoming release?

Not this release but Scummbuddy, a few others and I have been working on a LucasArts template and wanted to have it finished and out the door with an iMuse implementation for AGS 3.0.1.
After a few setbacks, I've resumed work on it and it should be ready within the next couple of versions. Of course provided that those whom originally offered to help keep their promise.

Sorry if this has been asked, but an extra perimeter to the .Say command to specify the time the text is displayed on screen:

cCharacter.Say("Stay on for 3 game cycles",120)

I second that.

So's this a bug or...

Sparx.

Well, a lot of game developers here seem to hate smooth scaling, and wouldn't want people to play their games antialiased. So any implementation would have to work with pixel-doubling scaling, hence the resolution problem.

I totally get you now. My request in the general sense is this:
Isn't there any way for AGS to use 3D rendering to render the scene onto a polygon while still allowing for pixel perfect doubling or quadrupling without blurry or antialiased results? Perhaps the user can choose to turn anti aliasing off?
Emulating pixel doubling in 3d rendering must be possible if the calculations are measured correctly?! Am I correct?

I appreciate all your hard work on AGS Chris.  I think I speak for everyone when I say you're a true phenomenon! LucasArts would have LOVED you back in the early 90s. Jeepers.

Cheers,
Sparx.

Heheheh fair enough my friend. Lol.

Cheers,
Sparx.

Hey wasn't your name Gilbot V7000a once? Why are you now Gilbert V7000a? Is there a grand prize for the first person to notice this?!

I'm not sure what the benefits of rendering to two triangles

Its not a matter of benefits. In every raster engine, all 3d objects are reduced to triangles. It would be silly to render the screen onto a single triangle because your graphics would be cut in half. It's like getting a sheet of a4, cutting it diagonally from one corner to the other and discarding one of the two pieces. So to speak.

Cheers guys,
Sparx.

I'm not really sure what you mean about the polygon, but yes the resolution system is under consideration for an overhaul

Oh sorry for the confusion, Chris. I meant drawing the scene onto two triangles like a texture. Two triangles making up a quadrangular polygon.
When referring to widescreen, I generally speak about low-res games being scaled up by filters. I prefer straight up pixel doubling whereas others prefer smoother scaling interpolation. We certainly need both methods to work with all aspect ratios.

Cheers,
Paul.

I thought the resolution system was going to undergo an overhaul anyway. Such as drawing the screen to a polygon.

Cheers,
Sparx.

I think you're making things overly complicated, Subspark.

Your probably right. The problem is the height of the background graphics. I was going to go your route and suggest designing our background art to be 4:3 in the first place and then dynamically cropping it at 16:10. This seems like the best method and in turn does not approximately double your game's file-size.

Good thinking Garage. I guess wishful thinking and excitement got the better of me. You can call me Sparx btw.

Cheers.

I was going for the same thing Garage. Thats what I meant in my first post.

I imagine something like this:


The user makes background art for both modes and the GUI labels, borders and background image can be aligned, scaled and positioned differently and independently of the opposite mode.
I think there should be a background region tool which essentially draws the background room into a region so that it can be repositioned. The region would also have right-hand-side pane values for which image to use for what aspect mode.

Cheers,
Sparx.

PS: I'm sure someone can come up with a better example than my crappy MI1 sample.

I wish for the AGS Editor to support designing games and their GUI's for both widescreen 16:10 and standard 4:3 in the same compiled exe. A smart auto-detection feature should decide which aspect ratio to launch our games in.

Cheers,
Sparx.

In fact, what I want is the opposite, I'd rather have different test versions installed into different folders.

Oh I get you now. Fair enough actually.

You also make a good point, CJ. I guess we don't really install every version there is without first removing the old ones.

Cheers,
Sparx.

Your point above is 1 of two of the annoyances I was pointing out.
If the install path was standardized then RC installers wouldn't be such a problem.

No more cluttering:
C:\Program Files\Adventure Game Studio 3.0
C:\Program Files\Adventure Game Studio 3.0.1
C:\Program Files\Adventure Game Studio 3.0.2
C:\Program Files\Adventure Game Studio 3.1
C:\Program Files\Adventure Game Studio 3.1.1
C:\Program Files\Adventure Game Studio 3.1.2

I could go on.

Cheers,
Sparx.

One rather annoying thing is the default install path.
There are so many versions of AGS 3+ available now that I believe they all need to be housed in a neat folder like:

C:\Program Files\Adventure Game Studio 3\

or C:\Program Files\BigBlueCup\Adventure Game Studio 3.x.x\

Cheers,
Sparx.

Digging up an old thread. Tisk. I don't think Chris is actually going to implement any raw flash support into AGS. Better to use flash for flash based games so to speak.
On the other hand, as suggested many times before, you can export images and movies from flash for use in the AGS engine. File/Export...

Cheers,
Sparx.

Your not talking about setting the character to face a certain direction are you?

The manual describes the following:

(Formerly known as global function FaceLocation, which is now obsolete)

Character.FaceLocation(int x, int y, optional BlockingStyle)

Similar to the FaceCharacter function, except that this faces the character to room co-ordinates (X,Y). This allows him to face not only other characters, but also hotspots or anything else as well (you can get co-ordinates by watching the co-ordinates displayed in the Room Settings mode as you move the mouse over the room background).
If the character has Turning enabled (ie. the "Characters turn to face direction" game option is turned on, and the character does not have the "Do not turn before walking" option checked), then the character will turn on the spot in order to face the new direction. In this case, the BlockingStyle parameter determines whether the script waits for the character to finish turning (eBlock, the default) or whether the script continues immediately and the character finishes turning later on (eNoBlock).

If the character does not have Turning enabled, he will immediately turn to face the new direction and the BlockingStyle parameter has no effect. In this case, the screen will not be refreshed straight away -- if you want to see the character facing his new direction immediately, call Wait(1);

Example:

cEgo.FaceLocation(cEgo.x + 50, cEgo.y);

will make the character face to the east.

Cheers,
Sparx.