AGS 3.4.0.6 (Alpha) - Builder Patch

[Crimson Wizard]

Ok, I see what is going on now.
"Unable to find a suitable graphics driver" -- this message comes from Allegro actually. So it could not init something, probably windowed DirectDraw5.

There seem to be an incorrect logic in AGS that lets game continue to run even though gfx renderer could not initialize properly.
I will be fixing that.

And, yes, debug mode does not allow to run fullscreen, for some reasons. However, in that case it must try windowed mode with other renderer (D3D9) if possible.

EDIT: Actually DirectDraw5 seem to be not able to make 1366 x 736 window. AGS needs to find a nearest possible window size.

[Dropped Monocle Games]

I have bumped into a little problem using 3.4.0.3 but it could just be something I have missed or doing wrong.
I'm making a game in 1280x720



But when I build the game and open Winsetup.exe it looks like this

1. The native game resolution is wrong
2. I can't choose Direct3D only DirectDraw is on the driver list
3. I can't choose different Modes apart from the "Native" resolution and my Desktop Res (1080)
4. if I check Window Mode the mode sticks at 1280 x 960 but when the game is running it runs at 1280 x 720

Shouldn't the native change to 1280 x 720 and shouldn't I be able to change to loads of different resolutions?
is this down to something I have done wrong or is this an error with the editor?


Update:
Using this option gives me all the options back


but the resolution changes I make don't seem to save or doesn't downscaling work in fullscreen mode?
ah, I'm an idiot I had the Stretch to fit option on.
but the Mode seems to always default back to my desktop size even if I change and then save

[Crimson Wizard]

Soxbrooker, can you make same thing as I asked PortableTaco to:
http://www.adventuregamestudio.co.uk/forums/index.php?topic=51050.msg636504588#msg636504588

[Dropped Monocle Games]

sure, not sure what one you wanted so I did both or if it makes a difference

here is the new build one
Log
and here is the legacy compiler one
Legacy Log

[Knox]

Hi Crimson,

Unlimited Custom Properties, woohoo!! I tested this new version out today and so far so good...Thanks 
I'm currently using Helio123's Custom Properties Helper plugin to set custom properties at runtime: http://www.adventuregamestudio.co.uk/forums/index.php?topic=42446.msg563322#msg563322

Would it be in your future plans to possibly integrate that feature (setting custom property values at runtime) directly into AGS  so we no longer would need the plugin?

[Crimson Wizard]

Would it be in your future plans to possibly integrate that feature (setting custom property values at runtime) directly into AGS  so we no longer would need the plugin?

You may remember that it was already integrated in a test build before. We would need to copy these features here.

[abstauber]

I've found another alpha transparency / magic pink issue

It seems like CopyTransparencyMask doesn't ignore magic pink anymore (it did in 3.3)


The raster sprite is a 32bit png with an alpha channel, the portrait is a 32bit import from a gif. In AGS 3.3 I could happily merge those two, but in 3.4 the magic pink shines through.

Code: ags

  // Sprite 6 is the raster png
  // Sprite 7 is the portrait gif
  DynamicSprite *TileRaster = DynamicSprite.CreateFromExistingSprite(6, true);
  TileRaster.Crop(0, 0, 37, 49);
  
  DrawingSurface *roomSurface = Room.GetDrawingSurfaceForBackground();
  
  DynamicSprite *temp_fg = DynamicSprite.CreateFromExistingSprite(7,true);
  temp_fg.CopyTransparencyMask(TileRaster.Graphic);
  roomSurface.DrawImage(10, 20, 7, 0);
  roomSurface.DrawImage(50, 20, temp_fg.Graphic, 0);
  roomSurface.DrawImage(100, 20, 6, 0);
  roomSurface.Release();

[Crimson Wizard]

Can you please attach the pictures you are importing?
Also a screenshot of how it is supposed to look normally.
Also, what is the "sprite alpha rendering style" setting is?

[abstauber]

PM sent

In the meantime I've discovered another issue: When you select "run game setup..." the new acsetup.cfg is only updated in the .\windows folder. But the editor still uses acsetup.cfg in the root folder, so I have to copy the file back myself.


edit:
This is a screenshot from AGS 3.3 - same images, code and settings:


The alpha rendering is set to "proper alpha blending"

[Crimson Wizard]

This is actually the issue of combining "magic pink" with alpha channel.

Code: ags

DynamicSprite *temp_fg = DynamicSprite.CreateFromExistingSprite(7,true);

Here you import an image without alpha but with "magic pink" into new image with alpha. When you do this, "magic pink" should no longer be considered "magic" and becomes plain magenta.
I would rather wonder why it worked in older AGS. This is something I am very curious about and going to investigate.

There are couple of ideas how to fix this; I am leaning towards replacing magic pink with zero alpha color, like (0;0;0;0) or (255;255;255;0) when you create new sprite with alpha channel from existing sprite without one.

[Knox]

Would it be in your future plans to possibly integrate that feature (setting custom property values at runtime) directly into AGS  so we no longer would need the plugin?

You may remember that it was already integrated in a test build before. We would need to copy these features here.

Yes, I was hoping that it could be added to this version!

[abstauber]

I am leaning towards replacing magic pink with zero alpha color, like (0;0;0;0) or (255;255;255;0) when you create new sprite with alpha channel from existing sprite without one.

That would be great. To be honest I thought this would already happen during import and 32bit conversion. Otherwise I wonder how AGS can e.g. draw half-transparent gifs on surfaces.

[Crimson Wizard]

I am leaning towards replacing magic pink with zero alpha color, like (0;0;0;0) or (255;255;255;0) when you create new sprite with alpha channel from existing sprite without one.

That would be great. To be honest I thought this would already happen during import and 32bit conversion.

This can't happen during import, if you are importing 32-bit image without alpha channel, because you will loose transparency this way.
Again, I am talking about image without alpha channel, the one that must use magic pink to draw transparent areas.

E: Regarding why this works in previous versions of AGS. I appears that Allegro drawing functions take a note of magic pink even if I am using my own alpha-blending callback (which is very unexpected, from my opinion...). It seems that if the result of alpha-blending is exactly magic pink (a magenta color with 0 alpha), it skips it, while any other color, even with zero alpha, gets to the destination surface.
The difference in newer version is that it produces "correct" blending results by setting 255 alpha on final destination, unlike previous version which was setting 0 alpha, "unintentionally" producing magic pink along the way.

E2: actually I told a wrong thing before. This line does not create image with alpha channel:

Code: ags

DynamicSprite *temp_fg = DynamicSprite.CreateFromExistingSprite(7,true);

The "true" only means "keep alpha if there is one", while the original does not have alpha channel, so nothing is kept and the new sprite is w/o alpha as well.
What adds alpha channel is this:

Code: ags

temp_fg.CopyTransparencyMask(TileRaster.Graphic);

because it merges other sprite's alpha channel with the sprite w/o one.


E3: This whole thing in AGS is so inconsistent! I sometimes think it generally works simply by luck, because some functions ignore the incorrect results of other functions.
For instance, CopyTransparencyMask ignores magic pink on dest image and converts it to actual color.
I think it is a bug... What do you think? What should logically happen if I apply an opaque mask pixel over transparent (magic pink) pixel?

[StillInThe90s]

Lots of lovely new features. Good work, people!
I was wondering if the issue with characters scaling in the wrong resolution when using d3d, has been addressed in 3.4.0.3?
It was last discussed (as far as I can tell) in the 3.3.0 Beta thread, HERE and HERE although people seemed to be confusing several different issues.
The draconian build fixed this but that was 3.2x.

[abstauber]

Yeah, I know - all these alpha blending and magic pink issues must be highly annoying. If this is a too annoying thing to fix, I simply look for a different way to raster out graphics. So there's no need to be worn out by this.

I think it is a bug... What do you think? What should logically happen if I apply an opaque mask pixel over transparent (magic pink) pixel?

If the transparent pixel is the master sprite to which the mask is applied I expect that the transparent pixels win and the area will stay completely transparent.
To my logic </Spock>, magic pink pixels are pixel that should be completely ignored and they should never ever appear ingame.

Otherwise it is never possible to create this raster effect - no matter what other combinations I try - magic pink always appears. Even if my raster images doesn't have an alpha channel and utilizes pink as well.

But as said before, I highly appreciate all the work you put into 3.4.x. If this won't be "fixed" I can happily accept it.

[ddq]

Running into a bit of an annoying bug with 3.4.0.2 and 3.4.0.3. When I run the game with F5 or Ctrl-F5, it doesn't respect the settings in winsetup, always showing it at max fit. Doesn't follow scaling multiplier, interpolation type, anything. Works in 3.3.2. Other people I've talked to have not been able to replicate. Running Win7.

[Crimson Wizard]

Running into a bit of an annoying bug with 3.4.0.2 and 3.4.0.3. When I run the game with F5 or Ctrl-F5, it doesn't respect the settings in winsetup, always showing it at max fit. Doesn't follow scaling multiplier, interpolation type, anything. Works in 3.3.2. Other people I've talked to have not been able to replicate. Running Win7.

There is an error that makes it read display settings from incorrect directory. Probably this is it.

[monkey0506]

I noticed elsewhere that someone had commented about this issue, and I meant to ask about it.

I've made a separate thread for it.

[AGD2]

Just got around to importing the mammoth source code for Mage's Initiation into 3.4.0.3 to see how it would go. The new features are awesome - thanks a lot to everyone who's contributed to this excellent new Alpha!

That said, I wanted to mention a few things I've ran into so far:

1) Small issue. I have this line in a script header:

import void UnhandledEvent(CursorMode, LocationType, InventoryItem*=0);

Which compiles in 3.3.3, but gives a compile error in 3.4.0.3. Adding a space after the * makes it compile again.

2) Bigger issue. I keep getting "symbol table overflow" compile errors. I actually started running into this problem in 3.3.3 about a month back, but I deleted a bunch of Views, Dialogs, enums etc. and I was able to compile again and continue. My source code currently compiles just fine in 3.3.3. However, if I copy the exact same source over to 3.4.0.3, it spits out the following:

__DialogScripts.asc(20): Error (line 20): symbol table overflow - too many symbols defined

There was also another issue relating to DynamicSprites, but I can't currently compile the game in 3.4.0.3 to investigate what's happening and report it. So, I'll post that one at a later time.

[Gurok]

The *= thing was introduced by the patch to support the remaining assignment operators ( /= &= |= *= etc ). I've made a small pull request to ensure that the compiler parses * and = separately in this context.

For the bigger issue, I'd really like to get your code. I know that it's pretty sensitive and that might not be a possibility. I can make the symbol table use vectors, but there are complications that go along with that. I also can't guarantee it's actually a symbol table overflow -- it might be some underlying parsing issue. Are you able to verify that the source compiles if you delete a few more views, dialogs and enums?