Messages

I've started converting my RawDraw routines to DrawingSurface functions, and I find myself missing a DynamicSprite.CreateFromDrawingSurface(DrawingSurface*, int x, int y, int width, int height) function similar to DynamicSprite.CreateFromBackground.

Most of my distortion effects work by retrieving part of an image, distorting it and drawing it to either the original surface or a new one. Previously, I used the background as a buffer (which is no longer feasible due to slowdowns in Direct3D mode), and found DynamicSprite.CreateFromBackground very handy. But now my workflow looks like this:

1) Draw surface to a temporary DynamicSprite (sprite A)
2) Create an even more temporary copy of sprite A (sprite B)
3) Crop sprite B down to the actual area to deform (often a single row of pixels)
4) Deform cropped sprite B and draw it back to DrawingSurface
5) Repeat steps 2 through 4 until the whole sprite has been deformed

Without knowing exactly how AGS handles copies of sprites internally, I would guess that the repeated copying and cropping of the full sprite must be quite a bit slower than creating a new sprite consisting only of the needed area.

I just made some experiments, and it's perfectly possible to re-compile a 640x480 game to 640x400 resolution and control the screen offset through creative use of SetViewport. The main problem is that you'd have to distribute the game in both a 4:3 and a 16:10 version, which could confuse some people and lose you a download - it would be much easier if this choice could be made in winsetup instead. Or through auto detection as suggested by subspark. Of course this would have to be a feature "allowed" by the developer, not something you could activate for any game since they might not support it.

Another problem is that screen coordinates for GUIs lock to the smaller viewport, causing misplaced GUIs as shown in the screenshots from Blackwell Unbound that I posted in another thread. Since most GUIs would have to be placed/sized differently in a 16:10 game anyway, this is not too big a deal, as long as it happens consistently (haven't done much testing of that). But nevertheless it's somewhat annoying.

Sure, I know we're arguing the same cause here, and I didn't mean to detract from your suggestions. I just felt that the three bullet points in your "All that has to be done is the following" post didn't directly address the issue I'm currently struggling with (although the development aspect is a prerequisite of the automatic detection suggestion).

Of course it would be great if as many features as possible were implemented, but everything takes time and I'd rather see some basic support of multiple aspect ratios implemented as a first priority. Let me put it like this: If I know that the engine supports different aspect ratios, I can develop my game with that in mind (customizing the GUI for each resolution, design my art to fit either aspect ratio etc.). This is something that is currently holding me back, whereas automatic aspect ratio detection doesn't make any difference while I'm still working on the game. It would be nice to see it implemented before release, but still it's no big deal to me whether the end user needs to check a single box in winsetup or not.

Filtering modes are already available, so I'm not really sure what you're asking for there?

Lt. Smash, I suggested something earlier in this thread, which would make your requests quite easy to implement through a module:

If the savegame compatibility issue [between different graphics resolutions] was solved, and RunAGSGame was made to re-initialize the engine, as monkey_05_06 suggested [...] you could let the player change the graphics [and other] settings from an in-game options menu, write them to acsetup.cfg using File functions, save the game in progress, then restart the entire game using RunAGSGame (whereby the engine would re-initialize using the settings from the .cfg file) and then restore the savegame to resume gameplay.

I'm still mainly interested in my original suggestion:

1) An offset value (Game.ScreenOffset or similar) ranging from 0-40 (in the engine's 320x200 grid), which would position the 240/480 pixels high image within the 200/400 pixel tall viewport of the screen. A 640x480 image with an offset of 15 would thus have 30 pixels cropped from the top of the screen and 50 from the bottom.

2) Winsetup support for the feature (possibly just having the "Force alternate letterbox" checkbox work in reverse if a game is 320x240 rather than 320x200).

And additionally:

3) A 800x500 widescreen alternative to the 800x600 resolution.

One thing's for sure - I'm not going to continue developing 4:3 games unless AGS gets better support for multiple aspect ratios.

What's the problem with using DrawingSurface along with SetBackgroundFrame? In what way doesn't it work? As an alternate solution to animated backgrounds, you could store the remaining background frames as sprites and draw them to the background DrawingSurface when needed.

Maybe I went a little far ahead on the modularization of my code, but today I got a 'Too many scripts in the game' message. I got 16 scripts, plus the GlobalScript.

Hmm, I'd forgotten that limit was there. Seems like you're the first person to need that many scripts
I'll take a look at it.

Heh, I remember mentioning this limit a while back on version 2.72, and it was actually one of the changes I looked most forward to in 3.0. I just assumed it was gone now (with most of those other arbitrary limits), so I didn't even test it.

If your character uses alpha channel, smooth scaling will only work when using the Direct3D display mode of AGS 3.0.

Unlike graphical resource, you don't actually import music and sounds into AGS itself. You simply place audio files (.mid, .mp3, .ogg, .mod or .xm format) in the game's "music" subfolder on your HD, renaming them to music1.mp3 or music2.ogg and so on. Sound effects are placed in the "sound" subfolder and named sound1.mp3, sound2.ogg etc. You can then play the music from within the game using the PlayMusic(x); function, where x is replaced by the number you added to the file name.

When the game is compiled, the audio will be stored in the music.vox and sound.vox files in your "compiled" subfolder.

First of all, I think you should report this as a bug to CJ (hopefully he reads this, but you could also mention it in the AGS 3.0 thread). I'm pretty sure that the font color isn't supposed to be randomized. Him fixing it in the engine is probably the best solution since it means you can use the built-in dialog editor without resorting to run-script commands to run a custom speech function for every single line of dialog.

Second, yes you could try making a custom GUI and see if that works. But if you do indeed end up using SSH's workaround (not necessarily via the Hypertext module, but the idea of hiding AGS' speech text and parsing the String to a text label or overlay instead), I would recommend hiding the spoken text in another way than using spaces - that will cause problems in case you want to use AGS' lipsync-to-letter function. It used to be possible to set the speechcolor to the magical pink color (or was it just zero?)  to make it invisible, but I'm not sure if it still works in AGS 3.0. Alternately you can use an empty font (delete every character in the font editor) for the AGS speech, and obviously choose another font for the label/overlay.

No, AGS is neither compatible with Sierra's intepreters (AGI/SCI) nor LucasArts (SCUMM). However there exists several tools to view the scripts and resources of those games. Check out LucasHacks!, SCI Studio, and AGI Studio. For more tools for Sierra  games see The Ultimate AGI & SCI Website.

Thanks for the CTRL-X fix, CJ.

SOLVED! See Edit 2 for detail.
I just discovered that the transparent AA text on GUIs bug I mentioned above isn't isolated to text. While testing the verbcoin mode from my game, I got this:



The hand is supposed to be grey, but here it's transparent (creating a see-through hole in the solid GUI). Perhaps you can even glimpse a bluecup object behind the GUI.

Edit: I think I now worked out why it affects some sprites/labels but not others: If the GUI has a background image, all text and images render fine. If the GUI background is a solid color, AA text is see-through. Button sprites that don't have transparent areas look fine, those that do are displayed in this way (transparency in the sprite is unaffected, but the non-transparent areas "punch holes" through the GUI).

Edit 2: Aha! I think I got it! It's related to the BackgroundImage property. If it's set to 0, everything is as it should be. If it's set to -1 (as it for some reason was for some of the GUIs - despite never having caused trouble before) it displays as described. I'm not sure if this is as designed? Anyhow, now I'm setting all the BackgroundImages to 0 and the issue should be solved.

Additionally, I would like GetWalkableAreaAt() to use Room coordinates, not Screen coordinates, as it is right now. If someone can point me to a hack that shows if a point is inside an off-screen walkable area, I would like to know (right now I'm using regions).

Can't you use GetViewportX() and GetViewportY() as offsets? If GetWalkableAreaAt() doesn''t work at all outside the displayed screen area, you could alternately SetViewport to the area in question, do your check and then ReleaseViewport, all within the same game loop so the player wouldn't see it.

Edit: And two three suggestion for CJ (sorry for being so demanding):

1) Any chance that the slight offset of labels using antialiased fonts as compared to non-antialiased fonts could be fixed now that DrawingSurface supports hi-res coordinates? I remember reading that anti-aliased fonts were rendered as DynamicSprites internally in the engine.

2) Using DrawingSurface, I developed my own method of rendering outlined TrueType fonts to display nicer looking text overlays. Basically I'm drawing the text 8 times non-antialiased at 1 pixel offsets for the outline and then drawing the interior text anti-aliased. Any chance that this could be implemented in the engine? While it's OK to do for speech, it's a bit of a pain to keep DynamicSprites for every single text item on a GUI. See screenshot below for comparison with AGS' own font rendering:


Above: Custom rendering of text as graphical overlay.
Below: Text on GUI label. Note especially the 'a' and the 's' as less readable.

3) Now that we have DrawingSurface.GetPixel, I would find it very useful to also have a reverse GetColorFromRGB function, such as Game.GetRFromColor, Game.GetGFromColor and Game.GetBFromColor. Edit: After posting this, I worked out how to calculate these values using the (2048, 64, 1) ratios, and after lots of testing I got it right. Still I wonder if an engine-internal function wouldn't be faster? If that's not the case, never mind me.

Perhaps the entire thread could just be moved and renamed, and a new completed game announcement posted when the game is actually available for purchase?

Great idea, Vince. I don't think it should necessarily be a constant feature, because it would be a shame to put too many limitations on  unpredictable themes like "game title anagrams" and whatnot. But providing a number of source images as a theme in itself is an excellent idea and adds to the variety of the competition.

What happened to Photoshop Phriday/Biweekly? It's not crossed out in the forum charter, yet there hasn't been one since last summer. I really enjoyed those since it was something fun you could whip up in a couple of hours and didn't require the commitment and time of most other competitions.

Amazing how one in every 3 or 4 results is pure gold. "Drunken Shaving Punch-Out!!", "Crazy Zamboni Tycoon", "Atomic Scooter Psychiatrist", "Muppet Ninja in the Dark ",  "Silent Nudist 2K". One title I'd really like to see made is "M.C. Escher's Basketball Preacher", and hell, "Tiny Skydiving Invasion" could actually be a Pikmin spinoff.

I was surprised to see the nice new debug menu for teleporting between rooms. However, I have one small request: Could the text field please be empty by default? Perhaps it's just a habit from the old functionality, but by reflex I keep pressing CTRL-X, typing the room number I want to go to (without using backspace) and pressing Enter, leading to the game crashing because I teleported to a non-existing room (for example I intend to teleport from room 8 to room 2 but end up in room 82).

While I appreciate the use of displaying the current room number, there's rarely any need to teleport to the same room that you're in. Perhaps there could be a label displaying "Current room:" at the top right corner of the menu instead?

Edit: Are anybody else having problems with some anti-aliased GUI fonts being displayed as transparent in the latest beta (on an otherwise solid GUI you can see the room's background through the letters, while the antialiased edges are still in color)? I haven't been able to find any consistency to it; they are all truetype fonts using a wide range of colors, yet some display normally and some are see-through. None of them use outlines. Once I turn off anti-aliasing, they all appear normal. This is in DirectX 5 mode, I can't test Direct 3D on this computer. It happens in full screen as well as windowed mode, and independent of whether "downgrade to 16-bit color" is checked (game is 32-bit, 640x480).

Edit 2: Added screenshots. Seeing them upscaled, I realize that it's not the antialiased edges that are still displayed, as I previously thought but just random(?) pixels of the font. The room background here uses the magical pink color, but the effect in other rooms is the same. It's just easier to see the nature of the issue here.

Font with anti-aliasing:


Font without anti-aliasing:


Edit 3: Problem solved! See below.

JBurger beat me to it, but as I was explaining while he posted:

The problem is that you're adding 1 to myCounterPurple within the subroutine. So if (myCounterPurple == 3), you get the fizzle message, but since you're adding 1 to the value, it's now 4, so (myCounterPurple > 3) will also register as true and give you the "no need to add more" message.

"else if" is indeed your friend.