Hello Guest

Author Topic: Buttons within the Batcher  (Read 3892 times)

Arqane

  • 2D Toolkit
  • Newbie
  • *
  • Posts: 1
    • View Profile
Buttons within the Batcher
« on: May 28, 2013, 06:23:53 pm »
I have a hex map that I've split up into regions to organize things and save some processing time with the batcher.  I'm having an easy enough time pulling up basic information on the batcher when used as a button, but I'm trying to find the best way to reference the children.  Each hex group in the batch files are 19 tiles/sprites (radius: 3), and I want to reference single hexes, but they seem to lose any scripts attached when batched together.  I have some ideas of potential ways to do this, but I haven't figured the top ones out yet.

1 (best, I think). Get a straight reference to the children in the batch with the first raycast.  The problem I'm finding with this is that the raycast is attached to the script which I can only attach to the batch.  So all I'm getting is the coordinates of the batch instead of extra information which could pinpoint the correct sprite within the batch.

2. Allow children to have scripts.  Might defeat the purpose of the batch on memory, but would be infinitely more useful in wanting to use batches in the first place.

3. Deconstruct the batch, and reconstruct it later when needed.  I'm sure it might be a memory nightmare at runtime, but it would be fine for my purposes.  I can't find a runtime option for this, though.

4. Do extra work finding the mouse position and doing the math to locate the correct hex.  Horrible for portability, and at that point it would be better to get rid of the batch, and just put scripts on all the single sprites (475 instead of 25 groups of 19).

Any hints if the better choices might work?

EDIT: Just an update... I did get it to work.  But I'd still like any suggestions for how to possibly improve the method I'm using, since it's not nearly as efficient as I'd like.  Right now I'm:

-Calling a TK2Dbuttonpress
-Picking up the event and performing another raycast
-Getting the delta X/Y between the transform.position and the hitinfo.point
-Sorting for the closest 2 hexes through a binary-type search
-Comparing the distance between the two closest hexes to finalize what object should be used

It's not a process that's used a lot, so all the extra steps and processing shouldn't even be a huge deal on the slowest computers.  Still, more efficiency, as well as ease of use of the batcher would be nice.  Perhaps a public class with the residual information from the sprites in the batch (especially position).  Finding the correct sprite on a regular hex grid was tricky enough.  Trying to get any info on separated sprites would be horrid.
« Last Edit: May 29, 2013, 03:02:49 am by Arqane »

unikronsoftware

  • Administrator
  • Hero Member
  • *****
  • Posts: 9709
    • View Profile
Re: Buttons within the Batcher
« Reply #1 on: May 29, 2013, 09:19:13 am »
1. You can get info about sprite positions in a batcher no problem.
2. Can't do this, the children don't individually exist when the batcher is committed - a composite mesh is created and this is what you see.
3. This will be crappy, and thats why there isn't a runtime option for this. If you're gonna do this, you might as well not use the batcher at all and save yourself a lot of trouble.
4. This is similar to #1, but working "blinder".


About your implementation:
Why do you use tk2dButton press? Why not simply create your own behaviour? Is this so you can detect which batcher the user is clicking on?
Apart from that it looks logical.
If you know where the hexes are its much easier to simply do what you're doing to find the closest one.

You can also work out exactly if a click is inside a hexagon without a search. Again this is just an idea - you've got something that works already :)
http://stackoverflow.com/questions/7705228/hexagonal-grids-how-do-you-find-which-hexagon-a-point-is-in
Or you can approximate using overlapping circles too.