Messages

Re quotes - I've had them for a long time. I've never had trouble with receiving stuff until now. Anyone having trouble PMing me should use my username, which is what should be done anyway, it's how it works. Surely, it's been established quotes are NOT the problem.

I remember having this problem too when PM'ing you. I wonder, shouldn't the functionality of the forum be changed so that clicking "Send this member a personal message" would insert the registered user name in the "To:" field rather than their current name?

The problem is that you're using an inventory pointer as an index. What you want to do is:

Code: ags

if (player.InventoryQuantity[iLockPick.ID] == 1) { // player has the lock pick?

These aren't my all time favourite albums (but some of the would also be on that list), just some albums I've been listening to a lot lately.  They're from my LP collection, so that's why there's no recent stuff.

The Clash - London Calling
The Smiths - The World Won't Listen
Lou Reed - Transformer
The Ramones - Rocket to Russia
The Replacements - Let It Be
Steppeulvene - Hip
Stiff Little Fingers - Hanx!
Bob Dylan - Blonde on Blonde
XTC - Waxworks (singles 1974-1982)
The Housemartins - The People Who Grinned Themselves to Death

Hmm, perhaps we need an opposite letterbox mode, whereby if the game is 320x200/640x400 it will run full screen, but if it's 320x240/640x480 it will get black borders at the side. The problem with this approach is that AGS would have to initialize a graphics mode like 384x240 and then paint black bars down the side, and I imagine that the graphics cards don't support any such resolution...

But please, please, please, for those of us who'd like to make use of the full screen area in either resolution, wouldn't it be possible to force a vertical cropping of a 640x480 screen as I suggested above? The engine does seem to support this kind of thing already (though currently it's an error rather than a feature). This is what I got when running Blackwell Unbound windowed 1280x960 with the 2x filter on a 16:10 laptop:

Normal 4:3 resolution:


Windowed 2x resolution on 16:10 monitor:


As you can see, here the top op the screen has been cropped off by the engine and the GUI has moved down 40 pixels. If we as developers had control of this behaviour we could easily design our games to be compatible with either kind of screen.

Although I don't (yet) speak the language, my girlfriend is Italian, so I do have a bit of knowledge of the swearwords

First of all, it depends how religious the guy is, since blasphemy and insults towards God or the Virgin Mary ("porco dio!"/"porca madonna!") are quite common exclamations, equivalent of "Holy shit!". Another common exclamation is "cazzo!" ("dick!", similar to the English "fuck!"), and insults towards others are often of a sexual nature, using the words "cazzo" (dick) or "culo" (ass) such as "vaffanculo!" ("go fuck yourself!"), "testa di cazzo" ("dickhead!") or "che cazzo vuoi?" ("what the fuck do you want?").

This page has quite a collection of them. But make sure to get someone Italian to proofread your text before publishing the game. Also, don't forget body language. Hand gestures play a big part in communication, so animate a few to accompany the character's talking view. There's a pretty limited youtube video of some of them here.

I think a lot of the ideas are good (albeit not original in other media, they would be new to adventure games). I think the film noir idea is overused these days, especially by people who don't know too much about the genre - if you could avoid the hardboiled detective stereotype and actually instill some of the feeling of fatalism and moral decay instead of just making a game in black and white, it could be interesting.

My favourite is probably 2. Since I'm a huge fan of the Hitman series, I think it would be great to see an assassin game where every hit doesn't turn into a bloodbath due to overly paranoid AI. I must emphasize the need for multiple and not too contrived solutions though, not something like 6 Day Assassin. You could have more focus on deception through dialog and other character interaction instead of sneaking and hiding in the shadows. If you haven't already, try playing DreamWeb for a good example of exciting and unique assassinations in an adventure game context. One thing though, the plots in the Hitman games are mostly there to string together the missions and always seems strangely random and quite contrived. Try to come up with a solid conspiracy plot first, then let that inspire the missions rather than the other way around.

The aspect ratio problem is something I've been considering a lot lately. I wanted to create a new thread about it, because I do think it's a big deal, but since it's already being discussed here, I might as well throw in my two cents.

After my beloved laptop with its nice 4:3 screen died miserably, I borrowed a 16:10 laptop and was instantly confronted with the horrors of the new format. Seeing as an increasing amount of users are replacing their desktop machines with llaptops and it's almost impossible to find a 4:3 laptop these days, this IS an issue that AGS must deal with eventually. It may be that some laptops support 'sidebars', but the one I had (a HP notebook with an onboard Intel video chipset) didn't allow any such choice.

In fact, AGS already DOES support resolutions with the 16:10 aspect ratio: 320x200 and 640x400. And it's perfectly possible to create a game that supported both 4:3 and 16:10 screens by creating your game in 320x200 or 640x400 and requiring 4:3 users to check the "Force alternate letterbox resolution" box in winsetup.exe. This would give nice, non-stretched images in either aspect ratio.
HOWEVER, as someone developing a game in 640x480 (albeit with black letterbox borders used for interface and text display) and loathing wasted screen space, I'd like to propose a new feature which at least I would love to use in my game: Optional cropping of a 640x480 viewport to 640x400.
By checking System.ScreenHeight in game_start, the game developer could then reposition GUIs, text displays and similar to custimize the game for the specific resolution. Of course this would require a bit of planning and extra implementation on the part of the developer, but I think it's worth it. Many games using the LucasArts interface could easily have an alternate GUI for 16:10 users, taking up less vertical space and still displaying the backgrounds without any cropping.

What I'm asking from CJ is this:

1) An offset value (Game.ScreenOffset or similar) ranging from 0-40 (in the engine's 320x200 grid), which would position the 240/480 pixels high image within the 200/400 pixel tall viewport of the screen. A 640x480 image with an offset of 15 would thus have 30 pixels cropped from the top of the screen and 50 from the bottom.

2) Winsetup support for the feature (possibly just having the "Force alternate letterbox" checkbox work in reverse if a game is 320x240 rather than 320x200).

The only possible problem I see is that a new resolution (800x500) would have to be implemented for the feature to fully support all existing resolutions. Thanks for reading my lengthy suggestion.

Edit: I actually discussed this issue two years ago, but nobody seemed to really get the point back then. I hope that the almost ubiquitousness of 16:10 laptops (and growing number of widescreen desktop displays) makes it a bit more relevant now.

Hmm, if using multiple loops for a talking animation actually makes the game crash in AGS 3.0, you should really report this to CJ. It sure sounds like the shift from loop 0 to loop 1 causes the problem, so if nothing else, it ought to be mentioned in the manual.

Edit: Oh, I see you did

Thats interesting.

Will that return a Pixel* object or something? and will it support alpha channel?

A SetPixel would be cool for manipulation of images.

You already have a SetPixel function in the form of DrawingSurface.DrawPixel. I'm guessing that DrawingSurface.GetPixel(int x, int y) would return the color number of the pixel. A separate Pixel class doesn't seem very useful since it's so limited what you can do with it (get/set), and you'd have to renew the pointer a bunch of times just to edit a small part of an image.

If you deselect the "Run next loop" box, so only loop 0 runs, do you still get the problem? 24 frames is a lot for a talking loop, so I guess there could be a glitch when using multiple loops. But it would surprise me if nobody tried it before. AGS 3.0 doesn't have any frame limit per loop, so you might give that a try if it's really the case.

Have you set a BlinkingView for the character? If so, what does it contain?

Yay, this may well mean further Rabbi Stone adventures!

Oh gosh... I hope not! Dude had a substantial adventure, any more and it's just wedging a character into stories just to keep brand recognition going. Urgh

What? And miss out on such exciting Talmudic detective stories as "The Bris" and "The Bar Mitzvah"?

I didn't realize that your game doesn't allow savegames, then of course ProgZmax' suggestion is much easier to implement. I'm storing gamma settings (along with other game options such as audio volume) in the acsetup.cfg file exactly to avoid the problem of them being changed whenever the user restores a savegame with older settings, and I just assumed you wanted the same. Good luck with the game!

Um, they didn't MAKE them orgasm.  The article clearly states "the nine women who REPORTED being able to achieve vaginal orgasm". They simply chose
the two groups of test subjects based on whether or not the women previously had experienced g-spot orgasms.

The argumentation of the article seems quite flawed though. In one part it says that the tissue was "on average" thicker in the women who did achieve vaginal orgams, followed by the unambiguous quote that "it is possible to determine by a simple, rapid and inexpensive method if a woman has got a G spot or not".

Awesome! Congrats, Dave. Or should I say Mr. Chief Executive Officer? I trust that you won't be selling out like Jane Jensen with her minesweeper clones and hidden object games. Remember your roots, man. Will this be an AGS game, I wonder?

The game context taken into consideration, I think Pumaman's solution (time of exposure) makes more sense than measuring the distance in whatever way. Why shouldn't it also get unbearable for a character standing still on the hot floor?

May I suggest a DrawingSurface.DrawStringWrapped function? Seeing as global and room messages are slipping out of use, DrawMessageWrapped seems a bit limiting (especially as Room.Messages is read-only, so there's no easy workaround). I tend to write my own linebreaking code for most RawDrawing of text, but for some purposes it would be quite helpful.

That was a very quick reply . Please also check my edit.

I assumed that you were RawDrawing everything to the screen every game cycle and were therefore already clearing the screen in-between game cycles. Since that doesn't seem to be the case, yes, you must use CreateCopy() and restore the background at the beginning of a cycle. Alternately, to optimize it a bit, you could simply redraw the tiles surrounding the player character before drawing the character.

Edit: Perhaps a better solution would be to stick with the regular character, and instead draw the "walkbehind areas" onto a full-screen sprite with a clear background. This sprite could then be displayed as an Overlay. That way you could avoid RawDrawing and restoring background every cycle, since this is pretty slow in the new Direct3D mode.

Well, first of all, in the code you're writing to "Brightness.cfg" and reading from "brightness.txt". But I assume that's from your fix.

Instead of putting the write to file code in your repeatedly_execute script (which will slow down your game), just put it in the code for closing the options menu where the player changes the gamma. There's no need to rewrite the file unless the setting has changed, right?

The reading back code should have a check for whether the file exists or not, since it will be missing the first time the game is run, unless you include it in your distribution. Like so:

Code: ags

File *fmark = File.Open("brightness.txt", eFileRead);
if (fmark != null) {
   System.Gamma = fmark.ReadInt();
   fmark.Close();
   }

What do you mean that you "created" the file? That you created an empty file using notepad or similar? If so, it's no wonder you get an error. Unless you use the ReadRaw functions, only try to read back files created by AGS itself.

Edit: You should put a similar null check for the writing code, although there's very few circumstances (such as a full drive or a protected folder) that could cause an error.

I think both I and Radiant understand that part, KhrisMUC, but the question is how the built-in pathfinding can deal with obstacles in the background when the background consists of RawDrawn tiles rather than objects or pre-set walkable areas.