search

vasl-developers / vasl

Virtual Advanced Squad Leader
http://vasl.info/
GNU Lesser General Public License v2.1
66 stars 27 forks source link

Resizeable overlays in Overlay Extension #519

Open BigAl737 opened 5 years ago

BigAl737 commented 5 years ago

VASL gives the option of converting a non-DASL board to DASL size. It looks to me like a simple size multiplication factor is applied to the board when the DASL option is checked. Is there a way to apply that same multiplication factor to a non-DASL overlay positioned on the board from the Overlay Extension? Maybe a marker trait I can add to each overlay that calls on code that checks if the DASL option is checked and if so, it resizes the overlay in the same manner as the board?

The DASL option does resize overlays placed using the legacy system.

And for future reference, I shouldn't apply this marker trait to the DASL overlays in the Overlay Extension. They work fine when placed on a DASL sized, non-DASL board.

derimmer commented 5 years ago

Al

I have been able to replicate the problem. We try to do some work on a solution soon.

BigAl737 commented 5 years ago

Thx Doug. You coders seem pretty busy with non-VASL stuff lately. Put this on your "when I have time" list. It is that time of year. Well who am I kidding, life is always busy :-) Hope you are doing well.

Have a great day!

derimmer commented 5 years ago

@BigAl737 I have worked on this a bit and also spoken to David Sullivan. I can see what causes the issue. It would be fixable in code but not necessarily simple.

David and I both agree that the neater, cleaner solution would be create a DASL-version of your Overlay Extension, just as there is for the Draggable overlays that exist within the VASL module. Of course, I have no idea of how much work would that be for you. Perhaps too much?

If so, I can take another look at coding a solution but realistically, I don't think I would be able to start working on it until the second half of the year. I have some bug fixes to do, a tournament to organize, and a couple of CGs on the go! Sorry, I can't be more helpful.

BigAl737 commented 5 years ago

Hi Doug. Thanks for the response. This is not a high priority issue. I do like the idea of a separate DASL Overlay extension but as you surmised, it would be a ton of work. Plus the current overlay extension isn't where it needs to be yet. The overlays aren't crop-able and terrain transformations don't work with them. The only real user advantage of the overlay extension is the drag and drop placement it offers. While huge IMHO, the old system still has it's merits. I'd like to see more of a combination of the two systems, if that's even possible, before starting work on an exclusive DASL extension.

derimmer commented 4 years ago

Al, as per my comments on another related issue, since overlays in the overlay extension are created as counters they are not able to be transformed as overlay image files can be. At least, I cannot determine how to access the counter image. If we could do that then we might be able to transform the image.

Also, because the "old system" overlays are images and the drag-and-drop overlays are counters, I don't see a way of combining these two tools.

BigAl737 commented 3 years ago

With all the coding going on, is this worth one more look? Let's close this if it's not possible.

derimmer commented 3 years ago

@BigAl737 @mtl1971

Hi Al

There are at least 3 things that you would like to be able to do to the draggable overlays from the overlay extension

(1) Resize them #519 (2) Crop them #525 (3) Terrain Transform them

All good ideas. The challenge as explained above is that these overlays are created as counters. To do the above we need to access the counter image. I have not been able to figure out how. I wrote to VASSAL about it. Here is the reply from Joel @uckelman

__Thus spake drimmer:

Is it possible to access the image file of a GamePiece via custom code (and also manipulate that image)?

Something like:

p is a variable of type GamePiece

Image i = (Image) p.getProperty("Image"); (this does not actually work) BufferedImage bi = new BufferedImage(i.getWidth(), i.getHeight(), BufferedImage.TYPE_INT_ARGB);

Can I get the image and then can I use the BufferedImage bi to change color pixel by pixel?_

_You can get the piece image via BasicPiece. However, you MUST NOT alter the image your get that way. You have to make a copy of the image and modify that. Modifying the image directly will interefere with image caching.__

So, sure I think this is worth taking another shot at. I have added the issues to the milestone list for 6.6.2.

mtl1971 commented 3 years ago

I can certainly have a look and experiment with a few options. For the cropping at board edges, It might be worth changing the extension to use a specialised class derived from BasicPiece to handle it's own drawing and cache friendly image manipulation. We can then change this in isolation without worrying about introducing bugs in the rest of the code. Is the source for the Terrain Overlays extension in github?

derimmer commented 3 years ago

No, extensions are not stored in github. They are found on vasl.info. You can open and edit an extension using the VASSAL editor just as you would a module. Although, in my experience, you have to "add" them to a module first - using the VASSAL editor.

In theory, it is possible to add a java custom class to an extension via the VASSAL editor. I believe I tried this at one point. Can't remember if I got it to work or not.

mtl1971 commented 3 years ago

Ahh, that'll explain why I couldn't see the code or resources anywhere! I sort of expected them to be in source control. Yes, it works ok - I was fooling around with a new component: public class OverlayGamePiece extends Decorator implements EditablePiece

image

And it's draw() method is getting invoked - but that's as far as I've gotten so far. My rough plan in draw() is to:

  1. Get the image from the counter
  2. Figure out if the bounding rectangle of the overlay Image intersects the boundary of the boards (excluding bdNull, bdEmpty, etc.)
  3. If it does: 3.1 Create a deep copy of the image 3.2 Make the original image invisible 3.3 Set the unwanted section of the image to transparent 3.4 Draw the cropped image 4 else 4.1 Make the original image visible 4.2 Draw the original image

I'm not sure that is the best strategy - another approach might be to defer the drawing to ASLBoard, which already handles the old style overlay cropping.

derimmer commented 3 years ago

I wonder if @BigAl737 and @uckelman have any thoughts on this?

I say that because I believe a lot of the existing draw methods in VASL are now a bit outdated and don't make use of changes in VASSAL in 3.4.x and beyond.

Plus we had a discussion about a year back about SVG graphics. See https://github.com/vasl-developers/vasl/issues/627.

I understand virtually nothing about graphics and the drawing of them so maybe I am just confusing things here.

uckelman commented 3 years ago

Any rendering that you're going to do repeatedly should be encapsulated in an ImageOp and thereby cached, so that you're not redoing all the work on each repaint.

derimmer commented 3 years ago

We did not get to this in 6.6.2. Better luck in 6.6.3.

mtl1971 commented 3 years ago

Nope. I had a go, but without much success. I got lost in a sea of decorators...

derimmer commented 3 years ago

Yes, I can believe it. I understand the theory of decorating and have used the decorator pattern in other code but man, everytime I look at decoration in VASL, I want to call for someone at a higher pay grade! LOL.