Messages

Thanks for pointing out the case sensitivity. I'm using it to sort listboxes and structs alphabetically and never experienced problems, but then all my Strings started with a capital letter. So I guess I should actually use "String.LowerCase()" inside the compare function to be on the safe side.

I can't seem to set an optional int parameter value to less than -31999 or greater than 32000.  I get the following error

As Gilbot says this is by design, it's because optional parameters are an unofficial feature that were never designed to be used in custom scripts; had they been then the range would have been 32-bit.

Related to this, I'm curious if there is a proper procedure for setting default values for optional floats? It seems that optional parameters can't have any decimals but must be provided as ints. When I put an int default value for a float, it seems to accept it. However, when I try to display the value of the float afterwards, all I get is garbage characters. I managed to get it working for a function with nine optional float parameters, but only because it sets a default value of 31999 and the function only checks whether the parameter value is smaller than this (if not, it's ignored). Can I count on this method working consistently, or is it just a fluke that it does? Is there truly no way to set a float parameter to, for instance, 1.0 if the player doesn't input one himself?

[UPDATE: From today (Monday 15th September), you can post guesses on the submitted song titles in the thread. Please use spoiler tags. (In case you're the first to post and have everything figured out, consider not posting the full list but letting others have a chance as well). If your own song title hasn't been guessed by the end of Tuesday, please post it yourself.]

UPDATE: From today (Monday 15th September), you can post guesses on the submitted song titles in the thread. Please use spoiler tags. (In case you're the first to post and have everything figured out, consider not posting the full list but letting others have a chance as well). If your own song title hasn't been guessed by the end of Tuesday, please post it yourself.

After a year's absence, Photoshop Phateverday returns. TerranRich, the winner of the last competition, didn't have time to host one of his own. So with Gilbot's permission, I decided to kick off a new round myself. The time frame for this first competition will be a single week. I hope this will encourage people to get started right away instead of thinking they have plenty of time and then never getting around to posting anything.

-------------------------------------

What is a Photoshop Phriday? (just in case you forgot)

Photoshopping isn't drawing a completely new image -- It's editing images to create a new image, such as editing one image or combining several images. The contest usually lasts for a fortnight. Also, you don't have to specifically use Photoshop -- Paint Shop Pro, MSPaint, or any other programs can be used. Please make sure your image doesn't exceed the width of the screen.

See this link:
http://www.somethingawful.com/photoshop/

And for other examples, see here:
http://www.worth1000.com/

-------------------------------------


This week's mission, should you choose to accept it, is: Illustrate your favourite song title

Note that I write "favourite song title", not "title of your favourite song". This is all about translating a cool, fun or evocative song title into visuals in an unexpected way. Go through your record collection or mp3s, I'm sure you'll find at least a few titles that bring up absurd imagery in your mind. Here's an example that I mocked up a couple of years ago for reasons I no longer remember:



Personally I much preferred it without the song title on the poster, but someone I showed it to found the American playwright and Pink Floyd references a bit too obscure. This, however, leads me to the one rule of the competition:

Please try not to reveal your song title in your post or as text in the image itself. It's more fun for the rest of us to try to figure it out on our own. If you want, you can include the title using spoiler tags, or reveal it by the end of the competition if nobody has guessed it. Let me know if this is a problem, we can make exceptions if using the title is absolutely necessary for your image (a newspaper headline for instance) - especially if it's funnier that way.

Deadline is 16th September. I wish you all good photoshoppery.

At the start of the summer there was some talk about reviving Photoshop Phriday, but nothing came out of it. So I was wondering, would anyone mind if I relaunched the competition?

Looks great. And I love the retro NES style. The character reminds me of the dude from Dragon Ninja (aka Bad Dudes vs. Dragon Ninja). Hopefully this game can prove once and for all that AGS isn't just for adventures.
If I wasn't busy with other projects, I'd contribute with a 2D Katamari clone (then I discovered that somebody had already done it, but I still think my AGS powered version would be cooler).

I have to throw in the towel, there's 8 minutes left and I'm still missing three characters and an elaborate dialog script. The game was supposed to take place at a spelling contest. 8-year old Victor Silverman's spelling skills are far from perfect, so it's up to you to help him out. The judges are not impressed with his initial attempts, but what they don't know is that Victor comes from a long line of wizards who cast their magic by spelling out the names of the spells. Otherwise they wouldn't have asked him to spell big, complicated words such as "lycanthrope" or "incinderary"...

What I managed to finish was this background and the Victor character. The judges would be sitting in the lower right corner. The gameplay consisted of one long dialog puzzle where you had to choose the correct spelling for a word spoken phonetically by the judges. Every time you got one right, you would accidentally cast a spell and horrible things would happen to the judges. If you managed to kill them all off, Victor would become the winner by default.

I suppose it's mostly a matter of personal preference  but I think that then easiest way of supporting a 16:10 background image on a 4:3 monitor is to use the full vertical height of the monitor and allow the room to scroll left/right, which is AGS's default behavior.

I don't know, as a player I would find it extremely annoying to have to walk across every room just to check if I missed a hotspot on the far side of the screen. And as a background artist I think it severely compromises any attempt of a balanced composition. A compromise would be to draw an additional 10% on each side of the background which would be cropped to a centered 4:3 non-scrolling room, just like widescreen is cropped with pan-and-scan. But that solution means you can't put any hotspots or exits outside the 4:3 area.

Likewise, IMHO, the easiest way of supporting a 4:3 background on a 16:10 monitor is to again make use of the full vertical height and leave black bars on either side of the  background.  This is what normally happens when a 4:3 video is played full screen. 

I agree that this is the easiest solution, but surely not optimal. For some reason, probably the habit of watching widescreen films on a regular TV, I find that bars on the side look much more crap than normal letterboxing on 4:3 screens. My suggestion was made based on the fact that many if not most games actually don't use the full height of 4:3 monitors for background but instead fill out the top and bottom with GUIs and text display/status bars. These can easily be modified or repositioned without compromising the actual background artwork (SCUMM backgrounds are basically letterboxed by default).

It should also be noted that 4:3 monitors have permanently disappeared from retail shelves and now can only be found on craig's list for free or at yard sales. They are destined for the dust bin of obsolete technology and so I am wondering why anyone is still developing for that format?

You forget the millions of existing 4:3 monitors that will stay in people's homes until they burn out. The people I see getting rid of 4:3 monitors do so mainly to replace a bulky CRT screen with a flat one. Those who invested in TFT monitors before 16:10 became the standard are not likely to replace them anytime soon, as widescreen doesn't offer any real benefit for a computer user (and is downright terrible for word processing and web browsing unless you have one of those that can rotate 90 degrees). Personally I'm not letting my lovely 19" CRT monitor go before it dies, nothing flat (and affordable) can replace the true colors and black levels.

If someone started a 4:3 game today I doubt there would be any 4:3 monitors left to play it on by the time the game was finished.

I still think there would be enough monitors around to warrant 4:3 support, but I agree it would be foolish to start a game today in a resolution like 800x600. Anybody in pre-development of a game should put a lot of thought into how their game will appear on 16:10 displays.

Thanks for taking this issue up again, CJ. Unfortunately I was on a month-long holiday at the time, but now here are my two cents:

While I agree that it would be great if as many users as possible could play their game in their native resolution, I think it's more important to find widescreen resolutions compatible with existing 4:3 resolutions. Creating a new 16:10 game resolution that doesn't correspond to any existing 4:3 resolutions just furthers the gap between 16:10 and 4:3 users and complicates things for the developer.

With any TFT monitor, widescreen or not, we are bound to see stretching in full screen mode AGS games. Yes, some 4:3 TFT monitors do use multiples of 320x240 (such as 1280x960) as their native resolutions, but many don't. This is something we must accept when working with bitmap graphics. And while the graphics appear less crisp than in the native resolution, I personally don't see it as a big problem. For instance my last laptop had a 1400x1050 display on which I played Blackwell Legacy (320x240 pixelart) and Nelly Cootalot (640x480 flash cartoon style), and both looked great despite the slight blurriness of stretching the pixels to 1400x1050.

My main concern throughout this discussion has been the possibility of creating a game that run in full-screen mode in both 4:3 and 16:10 resolution while retaining square pixels. The easiest solution would be to create a 320x200 aspect ratio game and accept the letterbox bars when playing on a 4:3 monitor. However, it wastes vertical screen space and can currently only be used up to 640x400 resolution.
For the game I'm currently working on, I decided to support both 4:3 and 16:10 format. By compiling the 640x480 game in 640x400 mode, I get a reduced viewport and can set ViewPort.Y to center the background as I want it to be cropped. The game_start code checks for the size of the viewport and repositions GUIs (or replaces them with widescreen versions) accordingly. It works, but the GUI coordinates sometimes behave strangely and it's a pain to have to compile twice when you want to test something - and of course the game will eventually have to be distributed in two separate .exe files.
As I've stated before, what I would love to see would be a setting in the game's setup menu that made a 4:3 game initialize in a viewport sized to its corresponding 16:10 resolution offset by a number of pixels specified by the developer. When I originally made the suggestion I didn't think of whether 800x500 or (for the new 1024x768 mode) 1024x640 were valid widescreen resolutions, but definitely I think we should look into widescreen resolutions that can be compatible with the existing mode. (The alternative, finding a widescreen resolution that can be cropped at the sides to create a 4:3 image doesn't seem as attractive as it's more common to occupy the bottom or top with GUIs and status bars - stuff that can be repositioned in a different aspect ratios - than putting them on the sides).

Check in the manual under "Character.LockView". The code for your animation should be something like this:

Code: ags

cEgo.LockView(5);
cEgo.Animate(0, 2, eOnce, eBlock, eForwards);
cEgo.UnlockView();

Change the second parameter of cEgo.Animate to slow down/speed up the animation.

Dave Gilbert's  Blackwell series. They're commercial but well worth the money if you're into mystery and  Gabriel Knight-style investigative gameplay.

I believe that click detection for inventory items uses a simple rectangular check (the size of the rectangle is set using the InvWindow.ItemWidth and  InvWindow.ItemHeight properties). Most likely your inventory item graphic is too large, so the charm is actually outside that rectangle. Either change the ItemWidth/ItemHeight for your inventory window, or redraw the necklace sprite to fit within the current size.

For the first question, it's true that on_mouse_click doesn't register over GUIs. However, instead we have on_event (EventType event, int data) where you can check for the event type "eEventGUIMouseDown".

Another solution is to import the button functions in the GUI header and call those from the GUI elements' OnClick event instead of calling functions from the global script. By putting "// $AUTOCOMPLETEIGNORE$" at the end of the import line, you can make sure that users of the module won't be using the functions by mistake because of autocomplete showing them.

Edit: I really thought the second method would work, but after testing it, that seems not to be the case. It seems that OnClick only refers to the global script, not global functions in general. There was some discussion of a suggested AGS feature which would solve the problem here, but I don't know if CJ is seriously considering implementing it.

I'm quite sorry that I don't have the chance to test out the betas during my holiday. This version seems to contain some of the most important changes to AGS since DrawingSurface was introduced. I can't wait to get working with hi-res coordinates, and I'm very curious to see how well 1024x768 mode runs.

I know that I've been lobbying for better widescreen support forever, so at the risk of repeating myself, I'd just like to point out that it's unfortunate that the two highest resolutions of AGS don't have corresponding 16:10 modes (as 320x200 and 640x400 are to the lower resolutions). I don't expect that it will be possible to run the same game .exe in both  4:3 and 16:10 modes (fullscreen - not letterboxed) anytime soon, as I've previously suggested, but a 1024x640 and an 800x500 mode would be greatly appreciated. It seems quite contradictory that the most contemporary and hardware demanding resolutions can't take advantage of the full screen area of what is becoming the current monitor standard.

Hi-res coordinates? Oh bollocks, I foresee months of revising my scripts. Awesome feature nonetheless, should make for some smooooooth scrolling.

Yeah, I'll do that for the next version. By that time 3.03 might also be near final.

11 Jul 2008 Update: No bugs (except the one I found myself) or feature requests were reported for the beta, so I'm declaring this slightly updated version the official 1.0. The download link should work directly. Many thanks to Joe Carl for suggesting googlepages:

JigsawModule 1.00 including demo game

Edit: If you're using AGS 3.03 beta 1, it fixes a bug in the handling of DynamicSprites as object graphics, so you should be able to uncomment this line which creates problems in older AGS versions:

Code: ags

//if (jigsaw_shadowsprite != null) jigsaw_shadowsprite.Delete();

I've got a well written intro scene that closely resembles how a novel would be written

Well, that's your problem right there. Unless you're making a text adventure, games are a visual medium. If anything, you should write cutscenes in the form of a screenplay rather than a novel. And keep in mind that less is more. It's a bit ironic that you say you "kept editing it and adding detail", rather than editing to whittle it down to the bare essentials.
Even if you find a certain piece of information crucial to the game (and the player will maybe agree with you 25% of the time), perhaps the flow of information can be distributed differently? Do we really need to know from the get-go that the hero's parents died in a tragic accident involving an ice cream truck and he was raised by his eccentric archeologist aunt? Or could that somehow be revealed later, through in-game dialog, or even through look-at interactions in the character's home? Withholding exposition or giving vague hints can also work in your favor by intriguing the player and making the eventual moment of revelation even stronger.

Try to think in images rather than words. Is the character feeling a certain way? Perhaps it can be shown visually, with colors, camera angles and music rather than told in a voice-over. If you absolutely need to resort to narration, try to check out some graphic novels for inspiration on how to combine text and visuals.

I discussed some of the same issues in this thread: http://www.adventuregamestudio.co.uk/yabb/index.php?topic=16551.0

I'm guessing the problem is that the character doesn't change rooms, matti

Could you please post your code, guns4party? Otherwise it's difficult to tell what is wrong. You should also write whether you get an error message or the event just isn't being triggered.

Why do I have the feeling that SSH will eventually turn his hypertext module into an AGS based web browser?   

Great work, scotch! I'm already considering possible uses for the plugin.

This had better be good, or I foresee review headlines reading "The Vacuum sucks" 
(sorry, horrible joke, I know)

It does look a bit like 6 Days a Skeptic, but in a good way. It's a very simple, to-the-point style. Thumbs up.
The concept sounds really cool, and had you announced the game early on I would probably have considered it overly ambitions. But I'm thrilled to see how close this is to being finished. Kudos. I look very much forward to see how it plays. Best of luck with the project!