SUGGESTION: Overlay.Merge[Overlay/Sprite]/Overlay.[Width/Height]

Started by monkey0506, Thu 24/05/2007 18:21:00

Previous topic - Next topic

monkey0506

More suggestions for overlays. Hooray.

I would find it very useful if we had some functions to merge overlays together (possibly another for merging new sprites into the overlay). Something like this:

void Overlay.MergeOverlay(int x, int y, Overlay* otherOverlay, int width=SCR_NO_VALUE, int height=SCR_NO_VALUE)
void Overlay.MergeSprite(int x, int y, int slot, bool transparent, int width=SCR_NO_VALUE, int height=SCR_NO_VALUE)

X and Y would of course be relative to the..erm..parent overlay. WIDTH and HEIGHT would default to the width/height of the overlay/sprite you are merging in, otherwise they would be cropped.

Also it appears that there's no way to get the width or height of an overlay. This could be useful to know.

It might not be very obvious why one might need to do this, but, for example, if a module writer wanted to piece together a single graphic from several other graphics he could either use the RawDraw functions or he could use Overlays. There's really no other alternative (plugin? :X) at this point. Assuming that said graphic is expected to move around the screen, RawDraw functions wouldn't really be very practical. So then the module writer is left no choice but to use a single overlay for every single graphic he wants to use in creating this larger graphic. There's no guarantee that he will be able to create as many overlays as he needs, so it all boils down to nothing more than luck and hoping that he'll have enough overlays available to piece together this graphic. Mmm...tasty Propagandistic-logical-fallacy soup.

But seriously, in such a situation, though not necessarily the most common of cases, it could be difficult to ensure that the graphic was properly created. I have personally encountered several instances where I would have found such a function extremely beneficial, however have found myself unable to efficiently replicate any such functionality. Just an idea.

Pumaman

If the RawDraw commands were able to draw onto overlays, would this solve your problem?

GarageGothic

Why not just RawDraw onto the background, create a DynamicSprite from background and use that for a graphical overlay? I do that all the time - even for text menus.

Edit: And in response to CJ, how about RawDrawing onto DynamicSprites instead? That would be much more versatile and could then be used for a graphical overlay. (the main difference from the above suggestion being that RawDrawing directly to DynamicSprites should support alpha channels, but of course that makes no difference for overlays since they can't display alpha).

monkey0506

RawDrawImageTransparent working on Overlays (or DynamicSprites) would work just as good. In fact...it would work exactly the same as what I was asking for with the Overlay.MergeSprite function. But I would still find Width and Height properties beneficial.

There are instances where I want said sprite to have non-rectangular transparent areas. The RawDraw/DynamicSprite route wouldn't really solve my problem.

Would it then be too much to ask if there were some way to retrieve the Graphic/Text of the Overlay?

[EDIT:]

An example of where this might be useful (as opposed to just vague references) is perhaps aligned textual overlays. If overlays could be merged a text-splitting function could then be called to create multiple overlays (one per line of text) which would be merged into one overlay, resulting in aligned textual overlays. Not the only example I could think of...just the first one that came to mind that didn't leave me sounding like a crazed dodo bird. 8)

GarageGothic

Quote from: monkey_05_06 on Thu 24/05/2007 20:24:17There are instances where I want said sprite to have non-rectangular transparent areas. The RawDraw/DynamicSprite route wouldn't really solve my problem.

Could you please elaborate? Why shouldn't it be possible to have non-rectangular transparent areas?

monkey0506

I'm just failing to see how it would be possible to grab a DynamicSprite from the background if it's irregularly shaped. The only DynamicSprite function for creating a DynamicSprite from the background automatically grabs a rectangular sprite. If I then need to move the irregularly shaped sprite around the screen, it would move the rectangular areas around the sprite because the sprite would actually be a rectangle (due to the workings of DynamicSprite.CreateFromBackground). Unless I've just missed something here...?

GarageGothic

Just

Code: ags
RawClearScreen(63519)


before RawDrawing the sprite. All the pink pixels will become transparent when using DynamicSprite.CreateFromBackground.

monkey0506

In my test the pink areas change to white. Might be a 2.8 issue, but for what I'm currently working with 2.72 wouldn't work. :=

It's not anything high priority for me...just something I'm working on.

GarageGothic

Strange, I've never had problems with this, neither in 32- or 16-bit games, pretty much since DynamicSprites were introduced.

Edit: Just to make sure, you did remember to set the transparent parameter for Overlay.CreateGraphical, right?

SSH

I've imported the walkcycle generator to 2.8 and it depends on the "magic pink" a lot, and it works fine, so I don't think its 2.8 that is the problem
12

monkey0506

Below is listed what I was going to post, but since I've gotten it working, don't need to post. However, the methods I had to use weren't very nice. Trying to import sprites in 2.8 (apparently) isn't working properly. I tried importing the room background and it became completely corrupted, as did the sprite I tried importing for making the Overlay.

The thing that started me thinking along these lines was the fact that I was using the default sprites in the Overlay while the room was supposed to be at 16-bit color. I ignored the room background being corrupted for a good while as I tried to discover the reason that the "magic pink" was appearing white.

The solution in the end? Starting a new game in 2.72, importing the room background and sprites for the Overlay, porting to 2.8, and finally copying and pasting the code.

Quote from: What I was going to postOkay, here's what I'm doing:

Code: ags
// global script header

import Overlay* ov;

// global script

Overlay* ov;
export ov;

// rep_ex

if (ov != null) {
  ov.X = mouse.x;
  ov.Y = mouse.y;
  }

// room script

Overlay* MergeSprite(this Overlay*, int thisGraphic, int x, int y, int slot, bool transparent) {
  if ((x < 0) || (y < 0) || (thisGraphic < 0) || (slot < 0)) return this;
  RawSaveScreen();
  RawClearScreen(63519);
  RawDrawImage(0, 0, thisGraphic);
  RawDrawImage(x, y, slot);
  int width = (Game.SpriteWidth[thisGraphic] - x);
  if (Game.SpriteWidth[slot] > width) width = Game.SpriteWidth[slot];
  int height = (Game.SpriteHeight[thisGraphic] - y);
  if (Game.SpriteHeight[slot] > height) height = Game.SpriteHeight[slot];
  DynamicSprite* spr = DynamicSprite.CreateFromBackground(0, 0, 0, x + width, y + height);
  RawRestoreScreen();
  if (spr == null) return this;
  Overlay* newOv = Overlay.CreateGraphical(this.X, this.Y, spr.Graphic, transparent);
  this.Remove();
  spr.Delete();
  return newOv;
  }

function room_FirstLoad() {
  ov = Overlay.CreateGraphical(mouse.x, mouse.y, 5, true);
  ov = ov.MergeSprite(5, 25, 25, 3, true);
  }


Can anybody tell me what I'm doing wrong?

If I don't call RawRestoreScreen() I'm seeing the screen being covered in pure white, however, if I use 63519 as a text-color, I can see through the text (i.e., I'm using a font with an outline, and all I can see is the outline)! In the editor I see 63519 as pink...but when using RawClearScreen() with it, it appears to be white.

I also tried:

Code: ags
  RawSetColor(63519);
  RawDrawRectangle(0, 0, System.ViewportWidth, System.ViewportHeight);


Instead of RawClearScreen() with the same results. If it makes any difference I'm running 2.8 alpha 8, 320x200x16 using the default sprites.

P.S. One of the major flaws with the above method I was implementing is that it requires you to pass the graphic displayed by the Overlay. This means that the most you could merge would be two sprites. However, I'm currently implementing two classes for Overlays (OverlayGraphical and OverlayTextual) the former of which will have a DynamicSprite property for holding the Overlay's graphic, making more complex merges possible. ;)

SMF spam blocked by CleanTalk