Messages

What's the problem then? Character.Tint DOES support grayscale and luminance at the same time. Region tinting does not.

You mean for region tinting, right? Because if you set the R, G and B in Character.Tint to the same value, you WILL get grayscale characters already (at saturation 100, saturation works a bit differently in AGS than you're used to from e.g. Photoshop), and can use luminance at the same time. It's a pain that Regions don't support both luminance and color tint (one reason for my module). But it should be quite easy to write some code in repeatedly_execute_always which tints every character in the current room to their current region's luminance (only up to 100%) AND to grayscale.

Code: ags

  int index;
  while (index < Game.CharacterCount) {
    if (character[index].Room == player.Room) {
      Region *charregion = Region.GetAtRoomXY(character[index].x,  character[index].y);
      int lightlevel = charregion.LightLevel + 100;
      if (lightlevel > 100) lightlevel = 100; //because character.Tint doesn't support +100 values
      character[index].Tint(255, 255, 255, 100, lightlevel);
      }
    index++;
    }

If you're going to keep on drawing comic book heroes, you might want to get a copy of How to Draw Comics the Marvel Way by Stan Lee and John Buscema. I got it as a kid and I still keep it on my shelf - even if I have very little interest in superheroes there's still a lot of useful stuff on anatomy and perspective.

* Added DynamicSprite.CreateFromDrawingSurface script function

Oh thank you, thank you, thank you!!! I can't wait to get started using this feature.

Now kids, we can all learn a valuable lesson from this: If you pester CJ enough, he'll eventually give in to your demands 

Edit:

Also, the label's coordinates in the game/editor are still not representative of each other

Is the font antialiased in-game? If so, I wonder if this isn't the exact same issue I reported three years ago? I came to accept it as a bug in the external libraries, but perhaps now that DrawingSurface supports hi-res coordinates it would be possible to fix? I remember reading somewhere that all true type text in the game is rendered as DynamicSprites internally before being displayed, so perhaps a pixel adjustment would be possible?

I second Vince's suggestions. The volume functionality is confusing and definitely needs an overhaul, and I'm glad that someone else also saw the use of millisecond (and remaing) timings of other sounds than music.

With the risk of sounding obsessive, I'd also like to restate my wishes for widescreen support and a DynamicSprite.CreateFromDrawingSurface(DrawingSurface*, int x, int y, int width, int height) function. The latter may seem like a minor issue to most users, but it's very important to me so that I can convert my RawDraw scripts to DrawingSurface routines.

As for the widescreen support, the sooner this issue is cleared up, the better. Currently I'm holding back on importing more art until I know if I should continue developing in 640x480 or need to switch to 640x400 if I want my game to look nice on widescreen laptops.

Who said it has to be confined to a singular room?

Urinate, the contest coordinator.
http://www.adventuredevelopers.com/forum/index.php?topic=1632.msg9762#msg9762

Where exactly does it say that? Yes, the theme is "escape THE room", but he also clearly writes "scene(s)" with an optional plural and says it "does not actually need to be a room". I see no mention that the location can't be a series of rooms.

I wasn't making a suggestion as much as reflecting on skuttleman's (I believe) joke, saying that there actually may be a game idea in there. Of course it's far from original - Toy Story 2 has a somewhat similar storyline, but I was thinking of a darker game, a bit of Tim Burton and Terry Gilliam, not to mention the excellent Twiilight Zone episode 'Five Characters in Search of an Exit'. My first association when I read skuttleman's post was the tabletop roleplaying game Puppetland.

But to be honest, I think it's not a bad idea for a game. Puppets can be quite different, vary greatly in size and posess unique accessories. A multi-character game about puppets could let them have different skills that are all needed to solve the puzzle. For instance, a Teddy Ruxpin-like bear may be the only one able to communicate with non-doll characters, but only through prerecorded phrases on a cassette tape in his stomach. Or a marionette may be able to use his strings as grapnel ropes or whatnot. It could be fun, and doesn't have to be cute at all. Try watching Jan Svankmajer's 'Alice' for a totally new perspective on stuffed animals.

OK. So we take a carebear, and chain him to a pipe and the only thing within reach is a seamripper...

Not a bad idea at all! How about a game about a group of dolls and teddy bears trying to escape from a demented toymaker? (self mutilation is optional)

Ah, good point indeed. I think my main issue with saturation maps is that while I have a pretty good idea of how to draw a color or light map, I wouldn't know where to start in drawing a realistic looking saturation map for a room. Currently I've implemented saturation based on the HSV S value, and it works pretty well with the saturation fading as RGB values near white. At the moment I'm wondering whether it shouldn't be the same at the other end of the spectrum, that saturation of colors lessens the less light there is.

I made a test room where the character is walking around a huge gradient like this:



and I must say he adapts pretty well to the tonal range. Obviously there are values you cannot achieve with automatic luminance/saturation calculation, but it will take some experimenting to see what needs to change.

In addition, I think this module would benefit greatly if support of luminance values up to 200% was implemented for Character.Tint as it is for region lighting (to gradually "white out" the character). I've mentioned it before, but particularly now that I'm coding the module, I see all kinds of cool uses - for instance you could have a very smooth looking fog effect. 

Getting the saturation and luminance from a light map pixel probably won't give you a decent result, because then you're effectively drawing three different components (colour, saturation and luminance) from the same source.

Ah, thanks for clearing that up. I somehow suspected I would need separate maps for these values, but thought I might at least be able to retrieve brightness from the RGB map since AGS tinting seemed to be more about value than luminance - even very low RGB values can give light tint colors if balanced properly. I guess I will let this be up to the end users how it's implemented. I think the best solution would be to have a color map, a light map and a per-room saturation value, since you'd rarely need to change saturation at different spots in the room.

I think I misunderstood what lightmaps are in SLUDGE. I thought it was like our region lighting/tint, just with as many "regions" as there are pixels. But when I read the extract from the manual now, it seems to be an overlay that shades the sprite pixel by pixel like a multiply layer in Photoshop would. My module is simpler in that it shades the whole sprite in the color of the pixel at character.x, character.y.

Another idea that comes to mind (apart from the obvious one of animation) is to allow the offsetting of light maps according to a characters' position. And even scaling! Imagine a room where an overhead projector is turned on (using lightmaps). A character could walk between the projector and the wall and have the image shown on their face, offset and scaled in a dramatic way.

I actually already have this in a different module for my game (which also features projectors ). I may consider merging the modules, but technically it's a different thing altogether from the tint lightmaps. These projection overlays also support animation and offset values.

Heck, they could even cast a shadow! But I suspect that would be a lot of work for one gimmick.

And another module still  , though one currently so buggy that I probably won't release it publicly until it has shown its worth in my own game. (Example screenshot here)

I'll take all your other comments into consideration for the lightmap module. Thanks for your input!

Edit: Oh, as for the scale of the lightmap, it must have the correct screen dimensions but can be in any resolution (such as using 320x240 lightmaps in a 640x480 game).

Filling a large array with text wouldn't take more than 10 seconds at most, I think. I had a function which read in a short story from a .txt file, and it managed to do it every cycle without a framerate drop (though I eventually optimized the function to only read/draw the text once). You could even code a progress bar to show the user that the computer hasn't frozen.
However, a large array will take up memory space and increase the size (and save/restore time) of the player's savegames. It may also be possible for the user to read spoiler-filled cleartext from the game if they open a savegame in notepad (I often do this as a means of cheating if I'm stuck in a game).

Personally I use one long if/else sequence for my custom dialog system, but that's mainly because I can easily run other code from within the dialog. It doesn't need to be messy if you structure it properly, and in my opinion it's easier to troubleshoot - and less prone to cause problems in the first place, than trying to keep track of a huge bunch of array indexes.

But if your main concern is the speed, you shouldn't let that keep you from using arrays.

Thanks tolworthy, that was very helpful. I've been looking for the SLUDGE manual online but couldn't find it anywhere but in that trojan infected installer.

Multiplying the color seems like it would create very dark sprites if it works anything like in Photoshop (I'm not even sure what the process AGS performs is called, colorizing?). As a former SLUDGE user, were you happy with the way the engine interpreted lightmaps (both in regards to color and lightness)? Do you have any preference as to how you'd like to see it implemented in AGS?

Edit: I converted the RGB values to HSV and tried using S and V for saturation and luminance. It was closer to what I'm trying to achieve, but the character still gets VERY dark while passing through blending areas. I have a feeling that it could work, possible using some multipliers, but this whole thing makes my head spin.

Thanks for the reply!

I'm using the DrawingSurface.GetPixel function to retrieve the pixel at (character.x, character.y), then converting the color value to RGB and applying it as a Character.Tint. Would it help me in any way to convert the RGB values to HSV and then converting the S and V values to percentages (sat, lum) to use in the Character.Tint(r,g,b,sat,lum)? - I'm still unsure if it makes any sense to try to retrieve saturation from the lightmap, since I guess a less saturated color will already tint the character less noticably (so lowering the tint saturation would make the tint almost invisible).

I didn't quite understand, did you say that tinting already changes the shading of the sprite's pixels and not just their color value? If so, is there any way to counterbalance this through arithmetic when calculating the luminance value?

If someone else has your password, they can also alter your birthdate, location, secret answer and whatnot, so you cannot rely on those to reset your password. Start off by contacting Microsoft. If the account was created in your name, at least providing a scan of your ID would gain you a lot of credibility.

Inspired by one of tolworthy's recent blog entries I decided to script a lightmap module, where the tint values of the character are applied based on the colors in a sprite or an external bitmap file rather than regions. This allows for much smoother (and easier to set up in cases of many shade values) lighting effects. Also, lightmaps can be easily swapped or even animated if room conditions change - e.g. flipping a lightswitch.

Currently retrieving and applying RGB tint data works great. However, I'm having a few problems deciding how to interpret saturation and luminance values based on a lightmap and haven't been able to find any existing implementations for reference. I tried downloading SLUDGE, which alledgedly has the feature, but my virus scanner found a trojan in the .exe (it may have been a false positive, but the next time I restarted the computer I was logged out of windows instantly, even in safe mode - I ended up having to do a full reinstall).

My one solution for it would be to retrieve the brightness values from a secondary black and white bitmap file, but it seems to me that it should be possible to calculate the values from the colored image. Trouble is that whenever I used an average (or even weighted average) of the RGB values, it's only possible to get 100% brightness in pure white light. I want it to be possible for instance to have the character tinted bright red (which with an average calculation of (255,0,0) would give 33% brightness) yet be 100% bright. Whenever I try to implement workarounds, I still get the problem of the luminance dropping whenever two colors mix - so that a character walking through a gradient from pure red to pure green drops in brightness while he's passing through the middle section.

Any suggestions on how to implement saturation/luminance without resorting to separate lightmaps? I'd really like to see this module available to the public - I'm even working on an in-game lightmap painting tool.

Do the NPCs use scaling or are they drawn to actual on-screen size? If so (although not a fix to what seems like an engine bug) you could create a pre-scaled view for the player character too and switch to it in this kind of scenes.

(of course the walking speed of the character would need to be set manually for these screens and reset on exit)

Check out the DrawingSurface functions. This allows you store background frames as sprites and change the background graphics when needed.

Code: ags

DrawingSurface *backgroundsurface = Room.GetDrawingSurfaceForBackground();
backgroundsurface.DrawImage(0,0,spriteslot);
backgroundsurface.Release();

Just replace "spriteslot" with the number of your background sprite.

Edit: Wrote this while skuttleman posted his entry. Just to clarify, you do NOT need to use DynamicSprites unless you actually create new graphical content (such as drawing lines an whatnot onto the background) and need to store them for later use. As longs as you just paste an already existing sprite to the background, DrawingSurface should be enough.

Not to take the credit, but a while back I came up with a pixel perfect collision detection technique, which SSH then developed into his Pixel Perfect Collision Detection module. You might want to give that a try.

This:

Code: ags

RawRestoreScreen();                                        //erase it
RawSaveScreen();

seems quite redundant (you're saving the exact same screen that you already have stored). Considering how slow an operation RawSaveScreen() is, it should generally be kept out of repeatedly_execute if at all possible. Overall, functions like these - including many of SSH's modules, but I know he's been updating them - would benefit greatly from the new DrawingSurface commands in AGS 3.0+.