Messages

Thanks for the support guys.

ildu, the reason for making the demo as a stand-alone game was that I myself, just like Flop, usually prefer to "wait for the full game in all it's glory". Releasing just the first day of the game as a demo would mean that people would have to wait 6 or 8 months for the rest of a story they've begun . Plus, the first couple of hours with the full game would be spent on something they'd already played. That doesn't seem very satisfying to me. For the very same reason I gave up the idea of publishing Shadowplay in acts - it needs to be one whole package.

I'm currently in the "general systems" stage of development, where all the functions that are re-used throughout the game, are set up with as wide a range of functionality as possible. The tech demo will show off some of these features, the most recent of which is the html-like system used for the in-game computers.

Regarding the "Release Something!" day on the 25th (which is tomorrow), I realized that it's a Saturday I won't be able to get online. I hope to upload something on Monday though, even though it's a bit late.

You're not a pain in the ass . It's perfectly true that I've take much too long with the demo and made a lot of empty promises about a it's release date.

The current status is that the standalone demo has been put on hold - I simply wasn't able to come up with a demo design that I was satisfied with. For some reason I find it extremely difficult to write "comedic gameplay" a la LucasArts, which was the style of the demo story. If Modgeulator hadn't written all that cool demo music (which doesn't really fit the full game), I'd just drop the concept altogether.

However, I DO intend to release something quite soon. Not a full demo, but more of a "tech demo" which shows off the interface and some of the techical features of the game. I won't promise anything, but if you've looked elsewhere in the forums, you'll know that a "Release Something! Day" has been announced very soon...

If you're searching for games at flea markets or garage sales, REMEMBER TO LOOK AMONG MUSIC CDs. A lot of people throw out their boxes, and CD ROM games in jewelcase end up along with the other CDs. I couldn't care less about audio CDs (I collect LPs), but this weekend I happened to look in a box of CDs and found: Monkey Island 1, King's Quest VI, Willy Beamish, Loom and the Sierra-non-adventure Jones in the Fast Lane. For under $1 each! (not that I would pay much more for a game without box or manual )

I agree with netmonkey that structs rock. How about an unofficial documentation?

Edit: Actually, I would like a better documentation of some features. They may seem obvious to C++ programmers, but I don't believer neither "bool" nor "define" are listed in the manual. I don't know what other there are.

I see what you're asking for. Currently, drops/flakes are seen through the standart camera. It's usually enough as most background images for AGS games are drawn in a similar perspective but there are exceptions (like a top-down view) or a free camera view (like in Alone in the Dark).
So, I thought about having a way to change the camera position/orientation for a future version.

EDIT:

p.s. Are you after some starfield simulation or what?

Sorry, I didn't notice this before now. Thanks for the reply Scorpiorus. Well, yeah, technically I suppose it would work like a starfield simulation except that scaling/rotation of raindrops would be a bitch, so I'm not really asking for that. In my case, I'd probably put the center of gravity well below the screen area itself, just to make it fit the perspective and avoid the "curtain" look that it sometime has now, falling straight down.

I was wondering if there's any way to check for Caps Lock being on/off (like you can check for Shift being pressed)?

In my opinion, the lighting effect is much too hi-res/hi-color compared to the rest of the picture. I think you'd be better off simplyfying it - first of all reducing it to three or four shades max (the same ones as are on the ceiling/floor) and secondly by making it much more jagged. Currently it looks like you resized a 320x200 pic to 640x400 and then added the light effect.

Other than that, I really like the style of the picture. And the guy is cute. Is the shading(?) on his arm and knees supposed to be greener than the rest of the uniform?

Thanks for the replies CJ. They were very helpful.

I'm very happy with the new DynamicSprite functions. I am wondering though, if it would be possible to add a character.LockGraphicOffset command?

If you mean a way to set the character to a sprite slot rather than a view, it would require fairly major changes to AGS. It is currently assumed that all characters have a current view/loop/frame so it's not an easy addition to make.

I understand. That's pretty much what I thought. I wonder if it would be possible then, as a workaround, to add a function that changes the sprite number of a specific view frame at runtime? Such as SetFrameSprite(int view, int loop, int frame, int slot)?

Why don't you just move them physically? It seems a hell of a lot easier to have a function to call everytime you switch one on or off.

Edit: Oh yeah, this uses an array for the buttons to shorten the code, but you could script it all out if you wanted to.

sort of:


function organize_buttons {
Ã, 
Ã,  short buttonx = 0; //where the leftmost button will be on the gui.
Ã, 
Ã,  short numofbuttons = 8;
Ã,  short buttonnum = 1;

Ã,  whileÃ,  buttonnum < numofbuttons {
Ã,  Ã,  Ã, if button[buttonnum].Enabled = true {
Ã,  Ã,  Ã,  Ã, button[buttonnum].X = buttonx;
Ã,  Ã,  Ã,  Ã, buttonx = buttonx + button[buttonnum].width;
Ã,  Ã,  Ã,  Ã, }
Ã,  Ã,  Ã,  Ã, buttonnum++
Ã,  Ã, }

buttongui.Width = buttonx;
buttongui.X = player.X - (buttonx/2); //to center it under the player

}



Or something like that

Sure. Don't RawDraw the reflection, use an object instead.

Edit: Of course this means that you can't delete the sprite until the player leaves the room. And you must set a default (non-dynamic) sprite for the object at the same time, or the game will crash the next time you enter (as it's referring to a non-existing pointer).

Edit 2: Alternately, you could animate the background "by hand" in the same repeatedly_execute_always function as the reflection script. Instead of RawRestoring, you could draw another frame on top of the existing with 0% transparency. Then you could put in a counter for the animation to decide WHICH frame should be drawn. (you may come across a crash problem when redrawing the same frame over itself - I'm not sure how to get around it). This seems like a considerably slower solution though.

Yes, transparent RawDrawing of lines/geometric shapes would be a wonderful addition. I've faked it by drawing the lines and the RawDrawing a copy of the background semi-transparent on top of it, but it's so sloooooooow.

Edit: I think that there should be two settings actually: Additive drawing, where lines are layered on top of eachother, gradually becoming less translucent. And "flat" painting, as if the whole RawDraw "layer" has a single transparency setting (thus 20% red on 20% red wouldn't equal 40% red but still 20% red). Anyone know what I'm talking about?

As for the second suggestion, you do realize that the room masks don't affect the backgrounds, right? You wouldn't actually achieve anything that couldn't be done with several regions and a bit of scripting to change their light levels. To have moving light affecting the background, you would either have to use the Flashligth Plugin, or animate the background yourself to match the lighting.

If you want realtime shadows on the other hand, well - let's say I have something up my sleeve...Ã, 

Some feedback:

1) I don't feel any difference with the editor sprite caching, except perhaps that there's a bit more hard drive acces when opening up a sprite folder.

2) Sprite compression doesn't cause any slowdowns either on my 2.4GHz P4. On the other hand, it isn't quite as effective as I had hoped. My game .exe file went from 69MB to 55MB, which is decent. But compressing the files afterhand using WinRar, gave me a slightly larger distribution file for the version where the sprites were already compressed (22MB and 23MB). I'll have to see how much this changes when I downgrade my sprites to 16 bit.

I'm very happy with the new DynamicSprite functions. I am wondering though, if it would be possible to add a character.LockGraphicOffset command? I'm aware that it could be a problem as character sprites are normally assigned using the View/Loop/Frame system. But it would allow you to put e.g. a floor reflection at the same x,y as the player sprite and thus use area scaling instead of DynamicSprite scaling (which I understand is slower?). I suppose an alternative would be the already suggested LockObjectOffset command, but for many situations, re-using a character would be preferable to setting up separate objects in every room.

This leads to another question... Is DynamicSprite.Resize actually slower than area scaling if the x/y ratios are identical?

Thanks for a wonderful beta!

monkey, I wasn't trying to put your template down. I was just implying that it's been presented as a solution to the problem, but I can't really recommend it myself as it crashes whenever I try to use it.

Oh thank you, thank you, thank you. The new dynamic sprite functions are just what I need.  I'm crossing my fingers that any-degree rotation will sneak it's way into another beta I can't wait to check out this baby.

Edit: And the new sprite compression sounds awesome too. I was getting a bit worried when my game file size doubled after I'd imported 150-something grayscale 120x200 frames.

Nope, 'cause there isn't any foreground color select unless you turn it into a text window guiÃ, 

Edit: I'm sure someone else will come along and tell you to use the scrolling dialog template - but personally I still haven't seen it working.

Thanks strazer. As often before I fail to notice an existing suggestion. Sorry 'bout that.

Sorry for digging this up again, but I realized another issue relating to this suggestion:

If you do choose to implement any-angle-rotation of temporary sprites, PLEASE consider implementing independent x/y resizing of temp sprites as well. This is a different suggestion from the "free x/y scale object/character" one, as it would allow you to change the dimensions of a sprite and THEN rotate it. Thanks.

Thanks Gilbot, I'll check it out. I wonder if Font Creator, which I'm using, can do this as well.

On a slightly different note, would it be possible to add a small piece of functionality to allow us to press CTRL+C on the palette screen to allow easy copy/pasting of the color number?

My god, how come I've totally missed this thread for such a long time!?!?  :o I guess I might as well stop wasting time on my own feeble attempts at  AGS vector graphics now.

Looks good though - you've come much farther than I did.