Messages

Interesting idea. What do people think about allowing the player to register/unregister the game with a button in setup? Is this giving them too much control or does it sound reasonable?

I think it's a valid suggestion, considering that more people distribute their games as .zip and .rar files than with installers (which - considering the number of AGS games I try out every month - is a good thing). However, I think this brings up another issue which has been bothering me for a long time - the many superfluous features of winsetup, which may confuse the player, requires mention in the documentation despite doing nothing for that particular game, or may even break the game if not blocked by game code (such as displaying a hi-res game in 320x200 causing unreadable fonts and crashes). Yes, some of them can be locked out in the .cfg file, but these settings will disappear if the .cfg is deleted for whatever reason.
How much work would it take to add a pane in AGSEdit to customize the winsetup, choosing which checkboxes and dropdown menu items to allow, and perhaps allowing for some minor customization of the layout (and maybe a piece of your own artwork to distinguish it from every other AGS game)? It's probably too late for the current version, but with the Direct3D driver option, a lot more end-users will need to run the setup program than before.

I haven't had time to play around with the new RawDraw commands, but it seems that the new handling of alpha channels has broken my old RawDraw based functions in that drawing RGB color (255,0,255) no longer works as a transparency mask for the sprite. In addition, this wouldn't work anyway if the alpha channel was retained for the DynamicSprite.

I guess the best way to handle this would be to add an out-of-range DrawingSurface.DrawingColor value that draws 100% transparency to the DrawingSurface (allowing a value range to draw an actual gradient alpha channel is probably too much to ask, though it would be awesome ).

Thanks for the great addition. One small request:

*DynamicSprite.CreateFromExistingSprite now preserves alpha channel

Could it please be made optional whether to keep or remove the alpha channel (with an optional bool at the end of the function perhaps)? I need to use transparency on shadows created from character sprites, and anti-aliased sprites don't support transparency.

I know it's not much of an advice, but the font does make it look a bit like a Neverwinter Nights expansion pack. Otherwise it's looking good - perhaps the artwork could take up a bit more room. I like InCreator's higher contrast version although it loses some of the detail.

BTW, nice use of the number 2 for both your second and third points.

Well, I thought it might make me seem less demanding

Some nice rawdraw functions would include realtime (manual) scaling and rotation.

I don't understand how this is different from scaling/rotating a DynamicSprite and then RawDrawing it or displaying otherwise? What do you mean by "realtime"?

Gotta love how the shadow and sprite deformation modules that I spent years coding might now be replaced by engine-internal functions. Serves me right for wanting to show off...

As for new RawDraw routines:

1) Copying the transparency map (either single color or alpha channel) from an existing sprite to a DynamicSprite of the same size. To support alpha channels, it would of course be necessary for DynamicSprites not to automatically remove the alpha channel (but this should probably be an optional, since that also has it's uses).
2) Not quite RawDraw, but DynamicSprite.Tint as someone suggested in another thread would be great.
3) It would also be great to be able to set linewidth for the RawDraw routines to only draw a single pixel in hi-res mode. Currently I use all kinds of workarounds (drawing double scale, then resizing) for this.

I've been working a lot with RawDraw, and I'll probably think of more suggestions. But these are things I've been missig just off the top of my head.

Edit: As for this -

It would be nice to have a RawDraw or Dynamic sprite function that had a "perspective squash", that is made a sprite drawn as if it were the a surface of a 3D object.

I tried to implement this in my shadow module, but it turned out to be too slow, so I do support an engine function to do it. I think a geometrical deformation of a rectangle to a shape where you specify new coordinates for each of the four corners (similar to Photoshop's 'Distort' transformation) should do the trick.

* Added ability to RawDraw onto dynamic sprites (see new DynamicSprite.GetDrawingSurface method); started to port RawDraw functions to object-oriented schema

You, Sir, have just converted me to a 2.8 user!

My main advice would be to play a lot of adventures - good and bad - and note what you like and dislike about it. Of course it's impossible to just patch together a good game out of the best elements from you favorite titles, but learning from the mistakes of others is a sure way of avoiding the most obvious pitfalls.
I'm a professional game reviewer and tend to be very picky about anything that annoys or bores me in a game. But instead of just criticising flaws, I come up with solutions for them and implement those into my own game. An example from an otherwise great game is the slow walking and poorly marked exits in Ben Jordan 6. Even as I was playing it, I started up AGS, loaded my game in progress and scripted a number of improvements to the existing code to identify exits, as well as writing an entire module to handle cursor highlighting on the edges of scrolling rooms.

Also play non-adventures - often they are much better games than current adventures, mainly because modern adventure games are developed for a hardcore audience of conservative genre afficionados. A lot of replies to this thread have emphasised non-linearity which is an area where we could certainly learn from games like GTA, Hitman and Deus Ex. Non-linearity isn't mainly about shaping the story based on the players choices, it's about offering him enough choices to make the game world real and interesting (for instance, I find the idea replayability misunderstood and highly overrated - you replay a game because it's good, not to see the alternate ending - and always thought the Indiana Jones and the Last Crusade a much more satisfying experience than Fate of Atlantis).

Two characters grouped together shouldn't cause any slowdowns. You can have 30+ characters on-screen at the same time without a framerate drop, at least in 320x240 resolution.

Oh yeah, I hadn't looked at Khris' picture properly, I thought the white parts were just shining through. Anyway, the technique is the same, and it's even easier to do just an inverted character. Good solution.

How weird. I understand why you're confused then...
I'm assuming that I have a different version of my own loading screen in a folder somewhere, and apparently AGS shows that by default. Interesting "feature"

Edit: How embarassing, apparently I copied the preload.pcx to the Unbound folder when trying to make the Direct3D version of the engine work. Damn, and here I thought "great minds think alike" and all that...

Sorry for the confusion.

Sorry for being obscure Dave. I just meant to say that only today, when I started up Blackwell Unbound for the third time, I realized that we're using the exact same font and message on our loading screens. (Though for you to recognize it from a game that won't be released for another half year would of course have been quite a feat ).

I'm happy to see that at least you're not using the font anywhere in-game. Otherwise I might have to change all my menus.

I KNEW there was something familiar about that loading screen:

Edit: Never mind the confused guy.

monkey, In my experience, anything using RawRestoreScreen and creating DynamicSprites from background every game loop will pretty much always be slower than pure DynamicSprite deformation (even more so with the new Direct3D engine). Especially as this DynamicSprite would only be one or two pixels wide until rotated. Also, using a sprite would allow for better resolution (if it's a hi-res game) and let you draw the laser beam with gradients.

The only small problem about rotating the sprite, is that you must recalculate the x coordinate for the object every frame. But that's simple geometry and not too complicated.

It's not possible to RawDraw in front of objects. What you can do is make the laser beam as a sprite, which is then copied to a DynamicSprite, stretched, rotated and placed in the room as an object.

Well, if all screens look like what KrishMUC posted, one way could be to have two character overlaying eachother:

One with only the black parts of the character, one with only the white (possible including a thin black outline surrounding the white lines). The rest of each character would be transparent. By using walkbehinds and baselines you could then have the black character drawn behind any bright on-screen area. This of course doesn't achieve a realistic light effect, but it could replicate KrishMUC's picture.

Edit: In using this technique, the white character must be set to always be drawn on top of walkbehinds. But possibly you could change this using regions in the area where the effect is actually needed.

Until I saw the name of your character I thought you were making a game about lens flare. Sorry for off-topic.

System.ScreenHeight and System.ScreenWidth are the properties that you want. These are returned as the true pixel resolution (e.g. 320, 640 or 800), not as in-engine coordinates (320 and 400 for 640 and 800).

Ah, finally I can see the scrolling rooms. It looks good, and I've yet to encounter any more bugs. But my html module has slowed considerably despite only using RawDraw (mainly text) without RawRestoreScreen. I'm guessing this is due to the enormous size of the background (640x4000).