Messages

It sounds very strange that a full-screen GUI will slow down your computer. I have a 2.4 GHz P4 and experience absolutely no slowdown with such an effect. You should try updating your graphics drivers and DirectX.

However, as an alternate solution, have you tried using AGS's built-in fade function?

Code: ags

SetFadeColor(255, 255, 255);
FadeOut(64);
FadeIn(20);
SetFadeColor(0, 0, 0); //to return to default black fades

It should be quite easy seeing as there's little to those games than pre-drawn animations triggered by correctly timed keypresses. You main concerns will be:

1) How to display the video. External video such as .AVI files may seem the way to go, but they often cause problems on machines with different codec packs installed (Diamonds in the Rough couldn't even start on my computer before I deleted the intro video). Users will also be able to watch all videos directly from the game's folder using media player. And as far as I know, the issue of a short black flash between in-game and video playing hasn't been solved yet. The FLI/FLC doesn't have this problem though, and may even be quite appropriate if you use less than 256 colors. However, I'd recommend using sprites instead, and a full-screen animated object, so you can use the View editor to synchronize sounds. And it will allow you to also animate the screen WHILE the player makes his choice.

2) To write a special function that triggers a timer and waits for either the player to press a key or the timer to end, and then plays the appropriate video and updates the game state. It's not as difficult as TwinMoon makes it sound, but it's something you should plan thoroughly so it's generic enough to work in every situation without dodgy location specific hacks.

I pretty much always work on my game using the latest version, even the betas, to take advantage of new features that I've requested. I never used the interaction editor, so porting the code has never been a real problem, even though I started development in version 2.62. Parts of it were completely rewritten when object oriented scripting was introduced. But I still have quite a bit of legacy code (using old style strings and whatnot) and will keep them as long as they work.

Playing AGS games with the Wiimote would be awesome. If that should happen, I predict a flood of Leisure Suit Larry fan sequels and remakes.

This wiimote plugin was released on April 1 last year, but allegedly it *does* work.

It's a result of having "large size fonts" activated, which is typical on higher resolutions. Is this AGS 3.0? I believe CJ made some changes to correct the worst cases of overlapping in the latest 3.0.1 betas.

So you're telling me AGS won't support XBox's state of the art boob physics? Will there at least be a plugin or module of some sort? Most of the appeal of my next slate of games would depend heavily on this

Judging by the animations posted by the Forgotten Element team, their AGX plugin supports excellent boob physics.

I think I saw the movie version, Steven Seagal was in it. Someone is going to get roundhouse-kicked! I really like the sound of this game, kind of like Eco Quest with a polar theme.

Is this the game developed for Playfirst? What happened to that Indian god project, didn't they think it was casual enough?

Awesome news. As we all know, PC games are dying and this seems a great chance to jump on the console bandwagon. Of course our games will have to be dumbed down a bit to work with the 360 controller, but didn't we all grow to love the Grim Fandango interface?
I'm a bit worried about the outsourcing of engine development. On the other hand, the boys at Microsoft love adding marginally useful features to their products, so I'm sure many of my feature requests will finally be implemented. Speaking of which, it's great to see a higher resolution even if it might require a DirectX10 compatible video card, and I'm guessing we'll finally get proper 16:9 aspect ratio support since that's part of the HDTV specifications.

Apart from the cost of the product license, will it require any special devkit hardware to test the 360 code? I remember that a PS/2 devkit cost thousands of dollars when I worked at EA, and that kind of expense would probably hold many indie developers back. Of course I assume this is all in the hands of MS, so I'm not blaming you, CJ.

Congrats on the deal! I guess you'll be arriving at Mittens in a Ferrari now?

Ok, I uploaded all three rar files. I think you want the second file to get to the lab section.

http://www.mediafire.com/?si3b2lw1tbh
http://www.mediafire.com/?8vjje9hxyb2
http://www.mediafire.com/?dxjtjyjydjm

Good luck!

The patch for the game is indeed still available (here), but it doesn't say anything about fixing the problem you've encountered.

Before uninstalling the game you could try the savegames at http://www.ggmania.com/cheat.php3?cheat=67. Perhaps they'll help you skip past the problem.

Edit: In case those savegames don't work, I discovered that I have three compressed files of savegames for the patched version of Sanitarium (68 saves in total, though some may be identical). They're only about 1.5MB combined, so I can easily upload or email them.

It's most likely the savegame folder for your game. It seems that since 3.0, Game.SetSaveGameDirectory is set to "$MYDOCS$/folder name"  by default. The name of the folder can be changed from the General Settings screen (under Saved Games).

I was hoping for a second that DynamicSprite.CreateFromDrawing(DrawingSurface*, int x, int y, int width, int height) had made it in. But this:

* Added zooming and mask transparency to the room areas editorSurface.

Is pretty damn cool too. I love that there's a slider to change the transparency, and I don't experience any slowdown on my 5+ year old computer (2.4 GHz P4, GeForce4 Ti4200, 1GB RAM). I think it would be a benefit though, if the zoomed viewport could be scrolled with the arrow keys. Currently they change the zoom level, and I understand that this is standard behaviour for a selected slider so perhaps it cannot be altered. But it would feel more intuitive if arrows scrolled the room window (also for rooms larger than the viewport) while PgUp/PgDn and mouse scroll wheel controlled the zoom level.

It is marked as changed and updated at the end of the loop, so if you have multiple calls to GetDrawingSurface and then Release for the same sprite, it should only actually get updated once.

Great, just as I hoped. Thanks for clearing that up.

Hmmm, yes I guess that means the sprite isn't uploaded to video memory until either the loop or a blocking command finishes. Sounds weird about the mouse trail though. Part of my html-like script uses Wait() commands in-between chunks of drawing code to avoid drops in framerate which lead to choppy audio. I wonder if the mouse issue would also happen if I don't Release() the DrawingSurface until the end of the process.

Thanks for the info, Rui. I hope CJ can clarify further.

As I explained in the linked thread, there are workarounds. Your solution avoids the cropping stage, which is a great idea. But still, since I need to perform the same operation 1-200 times every loop, I'd rather avoid copying/drawing the full sprite:

Ok, I'll look into it.

Thanks a bundle!

CJ, I have a question about how DrawingSurface.Release() works. I have several different visual effect scripts in my game which may need to draw to the same DynamicSprite (running multiple particle systems at the same time for instance). Back in AGS 2.72 when I used the background as a temporary drawing surface for DynamicSprites, I avoided using RawRestoreScreen() within the functions, but rather set a variable to mark the background as dirty and then RawRestored the screen in a script at the very bottom of the module list.
Now, as for 3.0, the manual states that DrawingSurface.Release() "[t]ells AGS that you have finished drawing onto this surface, and that AGS can now upload the changed image into video memory." Does this mean that the changed sprite is directly uploaded to video memory, or does the function rather - like my 2.72 script - mark the sprite as changed and update it at the end of the loop.

In other words, can I use DrawingSurface.Release() multiple times during a loop without any slowdown, or should I rather keep the DrawingSurface open throughout the game loop and only release it at the very end?

If I remember correctly, the speed is how many pixels the object moves every game loop. So the lower the value, the slower it moves. At least this is the case for the Object.Move function, but it seems you're using the interaction editor? Try a speed of 1 or 2, or a negative value (which works as fractions of pixels).

Suggestion: A DynamicSprite.CreateFromDrawingSurface(DrawingSurface*, int x, int y, int width, int height) function similar to DynamicSprite.CreateFromBackground.

Can you not use something like DynamicSprite.Create(width,height) and then DrawImage(-x,-y) to simulate this?

As I explained in the linked thread, there are workarounds. Your solution avoids the cropping stage, which is a great idea. But still, since I need to perform the same operation 1-200 times every loop, I'd rather avoid copying/drawing the full sprite:

Most of my distortion effects work by retrieving part of an image, distorting it and drawing it to either the original surface or a new one. Previously, I used the background as a buffer (which is no longer feasible due to slowdowns in Direct3D mode), and found DynamicSprite.CreateFromBackground very handy. But now my workflow looks like this:

1) Draw surface to a temporary DynamicSprite (sprite A)
2) Create an even more temporary copy of sprite A (sprite B)
3) Crop sprite B down to the actual area to deform (often a single row of pixels)
4) Deform cropped sprite B and draw it back to DrawingSurface
5) Repeat steps 2 through 4 until the whole sprite has been deformed

Without knowing exactly how AGS handles copies of sprites internally, I would guess that the repeated copying and cropping of the full sprite must be quite a bit slower than creating a new sprite consisting only of the needed area.

[DynamicSprite.CreateFromDrawingSurface(DrawingSurface*, int x, int y, int width, int height)]

Sorry for double posting, but I was afraid that this might get lost among the other wild ideas in the suggestions thread.  I consider it somewhat of a "lost functionality" in the move from RawDraw to DrawingSurface, so I'm sorry I didn't point it out during the 3.0 beta phase:

Suggestion: A DynamicSprite.CreateFromDrawingSurface(DrawingSurface*, int x, int y, int width, int height) function similar to DynamicSprite.CreateFromBackground.

Please see full explanation for this request in my original post in the Suggestions for AGS 3.0.1 thread.

I really hope you'll consider this, CJ.

EDIT: Oh, by the way. Is that divider movable for you? Because it's static over here... I can provide screens.

It's definitely movable. You just have to find the right pixel since it's not marked (the divider isn't the same as the edge of the white script window). Try just left of the arrow at the bottom, where the slider to scroll the dialog script horizontally is located.

Did the Show and Say for the dialog script get moved somewhere wierd in 3.0? Because I can't see them...

I don't know for sure about the stable 3.0 release, but at least the latest beta version has them right next to the dialog options as it used to be. Have you possibly moved the divider between the dialog options and the dialog script too far to the left so that they are hidden?