Messages

Nice work. I think the cracks in the tiles draw a bit too much attention. Try making them a bit lighter and with shading like those on the wall.

Try using "#define" written in all lowercase, it seems to work for me. I also had some problems with all cap "#DEFINE"s when converting to the most recent AGS versions.

Looks great, reminds me of Adventures of Fatman. I think it's well composed and shaded (the light source seems to be behind the player's viewpoint?). I would add a bit of diagonal glare in the windows though, as they are now they look more like blackboards. Or perhaps show some dark gray silhouettes of what's inside?

I think I discovered a bug in the DrawingSurface.GetPixel function. If I use it on a DrawingSurface retrieved from a sprite image, or a clean DynamicSprite where a sprite has been drawn with DrawImage, it works fine and returns the correct color.

However, if I use GetPixel on a pixel that I have drawn myself using DrawPixel (also Clear and DrawRectangle, probably all pixel drawing functions), the color returned is a ludicrously large negative number.

I'm writing a graphical toolset for my light/scale-map module, and obviously it needs to be able to repeatedly read/process/draw from and to the same pixel. I've been troubleshooting my code for the last hour before tracking it down to this issue. I hope it can get fixed for the next beta, because it's halting development on the module. Thanks.

Edit: An example. When using this code:

Code: ags

        int x = mouse.x;
        int y = mouse.y;
        int beforecolor = paintsurface.GetPixel(x, y);
        Display("pixel color: %d",beforecolor);
        paintsurface.DrawingColor = beforecolor;
        paintsurface.DrawPixel(x, y);
        Display("pixel color: %d",paintsurface.GetPixel(x, y));

The first Display message will return 59260 (the color of the original sprite), then we draw a pixel using the same color. At most we should expect a slight degradation in tonal range due to AGS' 16-bit values, but while the pixels look identical on-screen, the second GetPixel command returns -1642778. Should we try to draw anything using that negative value, it will be invisible, and the value is unusable for processing RGB data.
I should add that it doesn't make any difference whether or not you Release a drawingsurface in-between writing and reading the pixel values. I've only tested this in a 32-bit game using HiRes coordinates for the DrawingSurfaces.

... or ask Ali for the Nelly Cootalot source code and just change the names 

I would restructure the game a little, so perhaps one of the "useless" locations offers an alternate solution to a puzzle while the shopkeeper in the other can provide you with information about the town and perhaps give you some hints about the other characters. It's an hour or two's work for you, and the player won't keep on returning to seemingly less important locations to see if anything useful has appeared.
I don't necessarily think every location in a game should be used in gameplay, but I believe in an economy of resources. If a room neither provides gameplay, information or is used in a cutscene, there's little point in wasting time on the artwork. I understand what you're saying about making the game world fully explorable, and transitory locations do play a role in making a game world feel whole (the map view in Quest for Glory 3 just didn't give the same feeling of adventure as exploring every nook and cranny of the forests in QfG1 and 4). But why not include some kind of gameplay - not necessarily essentiual to completing the game - and offer the player the best of both worlds?

I agree that the Audio Manager is an excellent and very useful plugin. I don't know about packaging it with AGS though. If you've followed the thread about automatic lipsync, you'll see that Smiley considers implementing that functionality in the Audio Manager, which would not only have to include Annosofts .exe file (which can be distributed freely), but also need the user to install Microsoft's SAPI 5.1 SDK.

I guess that the plugin could be somehow made to detect the presence of SAPI 5.1 and deactivate the lipsync feature if it isn't available. But in case that's not possible it could create issues for beginners who aren't aware of those dependencies.

Great, so it's not just me then

I'll turn on left-to-right operator precedence for now. I think I've been paranoid enough in my scripting to have added parentheses everywhere needed.

Thanks for looking into it, CJ!

Yes, that was what I thought too, and it's one of the first things I tried. But I haven't been able to located anything named just "new". Is there any limit to where this second "new" definition can be? Would I get the error if it was a variable defined in a script further down in the scripts list? I checked all the headers and it's not defined or imported anywhere there. Could it be in a room (object/hotspot/variable)? I didn't think AGS managed those unless the room file was open.

I should mention that "Enforce new-style strings" and "Enforce object-based scripting" are set to false to support some of my older code.

Edit: By the way, I'm a bit concerned about how the new editor allows script-o-names not preceded by a letter specifying it's type (e.g. oKey, cEgo). Isn't this likely to spawn lots of difficult-to-trace conflicts for beginners?

Edit 2: I PM'ed you a link to my game's source code. It would be great if you could take a look at it. Thanks!

I did a full reinstall of AGS (the latest beta) in a clean folder and also cleared the compiled and _debug folders of my game. A new game created using the same version does run the code, my game does not. I worry a bit that my game code got corrupted somewhere while moving through all the betas.

Have you tried using dynamic arrays in games that started development on older AGS versions?

I'm gonna try a reboot now at see if that changes anything, somehow I have my doubts 
Thanks for the help!

Edit (after reboot): Nah, it didn't

As I said:

if I put it in the definition, I get the same exact same message, probably because the size of the array is now static and therefore defined.

(I meant that I get the same error later in the script (when using the "new bool" command) because the size of the array was set when defining it using your code)

Anyhow, it does seem to be a problem specific to my game. The example code that compiled fine in my default game now gives an error (same "Parse error in expr near 'new'") at the "new bool" part when run from either it's own module or from the global script. I'm pretty sure this code doesn't have any mistakes:

Code: ags

int characterHealth[];

function game_start() {
  characterHealth = new int[Game.CharacterCount];
  }

You mean in game_start()? Then I just get:

LightMap.asc(382): Error (line 382): Variable 'origscalesetting' is already defined

which makes sense since it's defined at the top of the script. And if I put it in the definition, I get the same exact same message, probably because the size of the array is now static and therefore defined.

Edit: Strange, when I create a new game from the default template, I can use the example from the manual without any compile errors.

I get the same error even with:

Code: ags

origscalesetting = new bool[10];

I'm creating it inside a function in a module where "bool origscalesetting[];" is defined at the top. It's the first module in the script lists, so I doubt it's because there's a global variable named "new" somewhere (if that's even possible?). The function itself is imported in a struct in the module header, but in this case it's called from within the module's own EnterRoomBeforeFadein event.

Edit: To track down the issue I commented out both functions and instead put it in game_start

Code: ags

function game_start() {
  origscalesetting = new bool[10];
  origlightsetting = new bool[10];
  }

Top op the script reads:

Code: ags

bool origscalesetting[];
bool origlightsetting[];

Same error message for the new line, so the details for the other functions don't really matter.

Edit 2: Hell, even copy-pasting the example from the manual gives this error. It seems that it doesn't like the word "new", but I can't see that I have any gui's, characters or global variables named new.

I've been trying to set up a dynamic array of bools (tried replacing with "int", but I get the same error). However, the compile fails with the message:

LightMap.asc(317): Error (line 317): Parse error in expr near 'new'

The line in question is:

Code: ags

origscalesetting = new bool[0];

At the top of the script module I have declared:

Code: ags

bool origscalesetting[];

If I comment line 317 out (I thought perhaps the zero-size array was a problem), it just get stuck at the next "new bool" line, which is:

Code: ags

origscalesetting = new bool[Game.CharacterCount];

That's just a modified version of the example from the manual, so it should work. What am I doing wrong?

[Object.Scaling property]

I'm pretty sure this is already on the to-do list, but now that I got my bitmap based scaling module fully working for characters, it would be awesome to have an Object.Scaling property so the module can fully replace walkable area scaling.

Edit: Oh, and also an Object.ManualScaling property.

Thanks for the list. I've thought about letting the user add automatical converting rules, e.g. AY0 always becomes AA0 etc (After Annosoft->Pamela conversion).  But you will always be able to change the value manually.

Wouldn't it make more sense to keep the original source format (with all phonemes), and do any customization in AGS' lipsync setup (just add AA0 to the same frame as AY0 if using your example)? That way the information would still be stored in case the user decides to add more mouth shapes later.

Since the plugin can already find the usage of audio files in scripts, it should be easy to get the text...if it's already in thescript/dialog.

Awesome! And even better to hear that it can also retrieve it from script since I use a custom dialog system which doesn't at all refer to the AGS dialog script.

Yes, that last one seemed to do the trick. Works perfectly now. Thanks!

I think you're right that there's no need to alter the 0-255 range. Any "resolution gain" would be pure illusion since we already have the full range of scaling values available. And it's much more convenient for the user just to be able to put RGB(scale,scale,scale) as the color rather than having to figure out some arbitrary conversion system.

I'll keep working on the in-game editor. While it won't create smooth transitions, it's a good way for the player to prototype the base scale for each screen area while watching the character move around. It can then be saved to a .bmp/.pcx and opened in Photoshop to add smoothing and gradients.

Great work Snarky, it does scale pixel perfect now! I tried passing the GetPixel value directly, and to my amazement it worked (I understand now that's how you coded the application, but I was expecting some kind of conversion necessary). Way cool.

However, I'm not sure about the multiplier. While the dark end of the spectrum works fine (scaling down to zero), I get light values going up to 479! Even though I can script around this, it puzzles me. Shouldn't it be 255?

You could be right about green having 1 more bit (5+6+5=16, yeah ), but I'm not sure how AGS handles it - if it does, that accuracy should already be available in the RGB code from the colormap module. However, that still only brings us up to 128 levels out of the 200 (or 195) needed, so I think your last solution makes most sense.

It would be awesome if you could write a bitmap color converter app. Just supply me with the arithmetic for the color encoding and I'll get it set up in my module. Thanks, man!

Oh yes, the free Annosoft code does indeed allow you to sync to both text and wav. It seems a bit ambitious for a plugin to try to retrieve the lipsynced text strings from AGS's dialog and script files, but if the Audio Manager got a new field for the spoken line (people might want to use the "Description" field for other things), perhaps that string could be used for syncing it.