Topic: AGS Draconian Edition 3.4.11 r10 (December 31, 2017)

[monkey0506]

I was actually wondering why you assumed it to be completely impossible without the compiler being open. I mean, I don't see why the linking would be so drastically different as to prevent internal changes to the engine but yet work fine for plugins. Obviously the plugins are a separate compilation (assembly), but the linking I should think would work the same.

In any case, good, someone's finally looking into improving the engine.

[Calin Leafshade]

I guess i just wasnt as cool as you

Try this acwin:

http://www.thethoughtradar.com/AGS/acwin.zip

It allows true alpha blending.

Only done preliminary testing but seems to work perfectly fine.

Heres the code for Alan's version

Code: [Select]

void Manual_Draw(BITMAP *src, BITMAP *dest, int destx, int desty, int trans)
{
trans = 100 - trans;

long srcWidth, srcHeight, destWidth, destHeight, destColDepth;

acquire_bitmap(src);
acquire_bitmap(dest);

unsigned char **srccharbuffer = src->line; //8bit
unsigned short **srcshortbuffer = (unsigned short**)srccharbuffer; //16bit;
    unsigned long **srclongbuffer = (unsigned long**)srccharbuffer; //32bit

unsigned char **destcharbuffer = dest->line; //8bit
unsigned short **destshortbuffer = (unsigned short**)destcharbuffer; //16bit;
    unsigned long **destlongbuffer = (unsigned long**)destcharbuffer; //32bit

int transColor = bitmap_mask_color (src);

srcWidth = src->w;
srcHeight = src->h;
destWidth = dest->w;
destHeight = dest->h;
destColDepth = bitmap_color_depth(dest);

if (srcWidth + destx > destWidth) srcWidth = destWidth - destx;
if (srcHeight + desty > destHeight) srcHeight = destHeight - desty;

int startx = MAX(0, (-1 * destx));
int starty = MAX(0, (-1 * desty));


int srca, srcr, srcg, srcb, desta, destr, destg, destb, finalr, finalg, finalb, finala, col;

for(int x = startx; x < srcWidth; x ++)
{

for(int y = starty; y <  srcHeight; y ++)
{
int srcyy = y;
int srcxx = x;
int destyy = y + desty;
int destxx = x + destx;
if (destColDepth == 8)
{
if (srccharbuffer[srcyy][srcxx] != transColor) destcharbuffer[destyy][destxx] = srccharbuffer[srcyy][srcxx];
}
else if (destColDepth == 16)
{
if (srcshortbuffer[srcyy][srcxx] != transColor) destshortbuffer[destyy][destxx] = srcshortbuffer[srcyy][srcxx];
}
else if (destColDepth == 32)
{
//if (srclongbuffer[srcyy][srcxx] != transColor) destlongbuffer[destyy][destxx] = srclongbuffer[srcyy][srcxx];

srca =  (geta32(srclongbuffer[srcyy][srcxx])) * trans / 100;
           
if (srca != 0) {
   
srcr =  getr32(srclongbuffer[srcyy][srcxx]); 
srcg =  getg32(srclongbuffer[srcyy][srcxx]);
srcb =  getb32(srclongbuffer[srcyy][srcxx]);
   
destr =  getr32(destlongbuffer[destyy][destxx]);
destg =  getg32(destlongbuffer[destyy][destxx]);
destb =  getb32(destlongbuffer[destyy][destxx]);
desta =  geta32(destlongbuffer[destyy][destxx]);
               

finalr = srcr;
finalg = srcg;
finalb = srcb;   
             
                                                               
finala = 255-(255-srca)*(255-desta)/255;                                             
finalr = srca*finalr/finala + desta*destr*(255-srca)/finala/255;
finalg = srca*finalg/finala + desta*destg*(255-srca)/finala/255;
finalb = srca*finalb/finala + desta*destb*(255-srca)/finala/255;
col = makeacol32(finalr, finalg, finalb, finala);
destlongbuffer[destyy][destxx] = col;
}

}
}
}

release_bitmap (src);
release_bitmap (dest);



}

void DrawingSurface_DrawImage(ScriptDrawingSurface* sds, int xx, int yy, int slot, int trans, int width, int height)
{
  if ((slot < 0) || (slot >= MAX_SPRITES) || (spriteset[slot] == NULL))
    quit("!DrawingSurface.DrawImage: invalid sprite slot number specified");

  if ((trans < 0) || (trans > 100))
    quit("!DrawingSurface.DrawImage: invalid transparency setting");

  // 100% transparency, don't draw anything
  if (trans == 100)
    return;

  BITMAP *sourcePic = spriteset[slot];
  bool needToFreeBitmap = false;

  if (width != SCR_NO_VALUE)
  {
    // Resize specified

    if ((width < 1) || (height < 1))
      return;

    sds->MultiplyCoordinates(&width, &height);

    // resize the sprite to the requested size
    block newPic = create_bitmap_ex(bitmap_color_depth(sourcePic), width, height);

    stretch_blit(sourcePic, newPic,
                 0, 0, spritewidth[slot], spriteheight[slot],
                 0, 0, width, height);

    sourcePic = newPic;
    needToFreeBitmap = true;
    update_polled_stuff();
  }

  BITMAP* dest = sds->GetBitmapSurface();
 
 
  if (bitmap_color_depth(sourcePic) != bitmap_color_depth(dest)) {
    debug_log("RawDrawImage: Sprite %d colour depth %d-bit not same as background depth %d-bit", slot, bitmap_color_depth(spriteset[slot]), bitmap_color_depth(abuf));
  }

 Manual_Draw(sourcePic, dest, xx, yy, trans);



  if (needToFreeBitmap)
    destroy_bitmap(sourcePic);
}


[Alan v.Drake]

Thank you Calin, I've applied your changes.
I'm wondering if I should release the current version I'm working on, or compile it withouth the region tinting modification, becuse while it works all cool and dandy through scripting, it breaks up if you set region tinting from the editor. (Not sure what I'm missing there...)


- Alan

[Shane 'ProgZmax' Stevens]

Some nice improvements here, Alan.  I'm not sure how much utility people will get out of the added filters since they're optional (so if you want a game to look old school with scanlines this wouldn't be the way to enforce it) but I suppose some people will try these out.  You might add a color scheme option to the preferences section of the editor so people can adjust the colors themselves and save the result to the prefs file.  That would be pretty cool.

[Alan v.Drake]

Since I've been busy with things and there's been movements on AGS' code I'm uploading my current code.
I did not include "nativelibs" and "manual". Also, beware of the region tinting code, since it breaks compatibility expecting 5 values instead of the usual 4 and setting region tint through the editor does not work right yet. Unless you need region tinting as badly as me you're probably better off without.
Don't think badly of me of how I handled the alternate editor colors, I was doing trial and error, if you want a better way to handle them try looking at the source of apps like notepad++ that have a good implementation of Scintilla.

Calin's alpha blend fix is included.

http://www.mediafire.com/?7a6561ucdvwnd5i


- Alan

[monkey0506]

For some reason I thought that using this "alpha blend fix" would be faster than re-rendering the entire screen. However, when I did a speed test comparison, I'm actually experiencing a speed drop of 10 FPS by drawing a series of sprites semi-transparently onto a transparent surface as opposed to snagging the background frame, drawing everything onto it to recreate the scene, and then drawing the sprites semi-transparently onto that.

Despite Calin's statement of its inefficiency (due to locking the surface, drawing a single pixel or image, and then unlocking it), the AGSBlend plugin produced better results than this. So, I'm a bit confused why:

Code: [Select]

// rep_ex
DynamicSprite *sprite = DynamicSprite.Create(width, height, true);
DrawingSurface *surface = sprite.GetDrawingSurface();
// draw images...
surface.DrawImage(100, 250, 30, 85); // ...etc.
surface.Release();
theOverlay = Overlay.CreateGraphical(x, y, sprite.Graphic, true);
sprite.Delete();
Is so inefficient with this version of acwin.

Edit: I don't experience the drop with a GUI in place of the overlay. I'm continuing to tinker with it.

[Calin Leafshade]

Overlays are a special case I believe.

The underlying workings of allegro are quite arcane and I dont quite fully understand how it works.

I have slowly begun documenting the AGS source but its a daunting process. I've only just finished documenting the file structure and CLib (I also ported CLib it to C# to better understand how it packs the files).

My suggestion is to avoid overlays where possible.

[ig299]

is this a new version?

[Alan v.Drake]

is this a new version?

Not exactly, this is  just a different version with some quirks. I released the source so other devs could take the pieces they need.
In the first post there's an older version, but more compatible. (no /almost/ improved region tinting and no Calin's blend)
If you spend a lot of time coding you might want to try the editor with dark colors.

- Alan

[Ryan Timothy B]

[..]as opposed to snagging the background frame, drawing everything onto it to recreate the scene[..]

Seeing as this is slightly related to your conversation, would it be possible to have something similar to  DynamicSprite.CreateFromScreenShot  that actually grabs the screen before it applies the overlays (GUI's, cursors, speech, etc)?

Also Monkey, how are you drawing the characters and such behind walkbehinds with your method? Or is this done on a pixel per pixel level while checking the walkbehinds? Drawing everything onto the background sprite, then checking walkbehinds and drawing a background pixel over top of anything that a character/object actually is.

[Alan v.Drake]

A little patch to support WFN fonts with 256 characters, which means accented characters and whatnot.
There won't be any compatibility issues since the format was not altered.

256-WFN are also compatible with older versions of acwin, even though they'll only display the usual 128 chars.

Source only: http://www.mediafire.com/?2yb9duar7r285lh

To actually make a 256-WFN, though, you'll have to wait for Radiant to update his FontEdit.
Unless you have an hex editor and a strong feeling of confidence.

p.s: This is only for the engine, I can't include support into the editor because AGS.Native has no source.

- Alan

EDIT: Ehrm, seems like I had linked my compiled acwin which I advise not to use due to Region.Tint incompatibility, I've corrected the link now... sorry it was late.

[DrJone.s]

I made a feature suggestion to Chris Jones and he told me to ask one of the developers in the Technical Forum thread, as he is currently inactive. I didn't know which thread was the proper one to make suggestions, so I've used this one. Sorry if this is not the correct place to do so. 

The feature suggestion is that I would want to be able to make characters with only two walkcycle views, South-West and North-West, which I would mirror to get the NE and SE views of the character. Currently AGS only supports three types of views: Side-view only, LucasArts-style (N,W,S views), and Sierra Style (N, NW, W, SW, S views), and none of these styles display correctly a character that only uses NW and SW views.

It would be great if it could be included in the main builds of AGS, and I hope it'll be useful for plenty of AGSers that right now are required to draw at least 3 walkcycles to get a full 360º view of any NPC.

Thank you! 

[Alan v.Drake]

Ah, I thought it was already possible to do, but I now see somethings breaks up along the way preventing the diagonal loops to show. I will look into it.

- Alan

[Shane 'ProgZmax' Stevens]

This isn't really the thread for this, it would be better to make a Feature Request: post in tech or simply follow some of the instructions I offer below.

So you want the character to only move in diagonals?  One way to do this would be to avoid the ags movement logic and do a simple script for movement yourself that checks where the mouse click is relative the x/y of the player and then run the animation of choice until they come to a stop, at which point you'd select a standing frame (it's only slightly more complicated than I'm explaining here since you would also need to check for standing on a walkable area so the character cannot just move anywhere).  So basically, if you clicked up and to the left of the character you would play the NW walking animation and then do a repeat check for the character to stop moving, at which point you'd change the character frame to the NW standing frame.  This would be done for a down-left click, a down-right click, and an up-right click (you would supply number ranges in each case that fit into these directions).  In the rare case of a pure up/down/left/right click you'd just appoint one of the diagonals to handle the job.  I hope this makes some sense as I'm a bit tired right now.

Bear in mind that I don't personally believe the AGS editor needs native support for this since it's so easy to do via scripting but if someone wants to implement in then there's no harm in having it as an option.  My advice, though, is that since you can do this through scripting is that rather than wait, start on it with some help from beginner's tech.

[Snarky]

This is a good example of the kind of functionality I think should ultimately be separated from the AGS core and turned into a user-editable module. Sometimes you want to use just an up-down walkcycle, or just a left-right, or just the diagonals. Sometimes you might want to adjust the angles that separate each direction (even make it vary depending on the walkable area angle and distance). Any non-standard version of this currently requires you to override the built-in walkcycle system, while it would be better if you could just set the game to use a different module.

[Alan v.Drake]

AGS Draconian r2 (March 24, 2012) DOWNLOAD

• Fixed the previous issue when displaying tints that were set to regions from the editor.
• Added an optional acwin_perspective.exe that handles better characters direction when in perspective, rename it to acwin.exe if you wish to use it (I did not test it with diagonals views).
• 256 characters WFN font support without compromising compatibility (we just need an updated FontEdit now)

[Monsieur OUXX]

That's really sexy.
On a similar topic: I was wondering if someone has released a "version" of AGS that includes all the ultimate plugins -- such as "Dialog Designer" and "Speech Center", for example.
It would be cool to upload it alongside the "regular" AGS on the donwload page, just with a "not supported, don't come whining if it doesn't work" warning label.

[Alan v.Drake]

AGS Draconian r3 (March 29, 2012) DOWNLOAD

• Windowed mode gamma support! Only for brightening, though, because I don't care about darkening and frankly I don't see the point, if you want to do that too, the source is at the usual place.
  
  - Alan

[subspark]

Love the updates Alan.
Would it be piss simple to get the luminance feature to work under conditions like:

Code: [Select]

if (this.type == _eTweenRegionTintR) {
    int saturation = this.regionRef.TintSaturation;
    int luminance = this.regionRef.TintLuminance;
    if (saturation < 0) saturation = 0;
    this.regionRef.Tint(Lerp(this.fromX, this.toX, amount), this.regionRef.TintGreen, this.regionRef.TintBlue, saturation, luminance);
  }
Also, is there any reason why it breaks backwards compatibility? Why don't we just revert to the default luminance value if the parameter is not included, like the non-essential Animate parameters (eOnce / eBackwards) do?
It's no huge burden to comment out some code until the Tinting stuff is completed. Is it so far away?

[Alan v.Drake]

Love the updates Alan.
Would it be piss simple to get the luminance feature to work under conditions like:

Code: [Select]

if (this.type == _eTweenRegionTintR) {
    int saturation = this.regionRef.TintSaturation;
    int luminance = this.regionRef.TintLuminance;
    if (saturation < 0) saturation = 0;
    this.regionRef.Tint(Lerp(this.fromX, this.toX, amount), this.regionRef.TintGreen, this.regionRef.TintBlue, saturation, luminance);
  }
Also, is there any reason why it breaks backwards compatibility? Why don't we just revert to the default luminance value if the parameter is not included, like the non-essential Animate parameters (eOnce / eBackwards) do?
It's no huge burden to comment out some code until the Tinting stuff is completed. Is it so far away?

Well, seems you're lucky, it was just necessary to add a "=100" to agsdefns.sh, otherwise I would never have done it, ahah.
Overwrite AGSEditor with the one inside here and it's done: http://www.mediafire.com/download.php?ficdrl37i9h9yyv

You can use  Region.GetLightLevel()  (regionRef.LightLevel) for the luminance.

- Alan