Messages

1

NGUI 3 Support / Re: Using SetMatrix on UITexture

« on: June 30, 2014, 01:37:14 AM »

Originally I was hoping to do just that. However, the image is a rectangular aspect ratio and the texture may not have the same orientation as the target mesh (IE a landscape oriented texture being applied to a portrait oriented mesh). This leads to stretching of the image.

Theoretically the mesh could be rotated AND resized to accommodate the texture that is mapped to it. Would resizing the mesh cause distortions when the texture is applied (in particular I don't know if it would muck with the things you are doing to make the GUI "pixel perfect")? Are there any extra apply calls I would need to use after doing a resize on the mesh?

2

NGUI 3 Support / Re: Using SetMatrix on UITexture

« on: June 28, 2014, 01:46:58 AM »

The texture I am trying to apply to my UITexture is a snap shot taken from Unity's WebCamTexture. When sampling textures from the WebCamTexture, the image is rotated arbitrarily based on the physical camera device. I am trying to simultaneously display 4 different UIImages each with 4 different snap shots taken from 4 different physical camera devices (each with an arbitrarily different rotation).

I tried using UITexture.drawCall.dynamicMaterial to do the necessary setup in a Start method, but kept getting null references on the dynamicMaterial. I also tried instantiating a new material, setting the rotation on it, and then assigning that material to the UITexture. However, the matrix appears to be reset upon assignment (probably when the material gets copied into NGUI's pipeline).

I'm not concerned about increasing the number of draw calls by 1 per snap shot shown.  However, I do need some way to rotate each of the snap shots arbitrarily. I managed to get the rotation to work fine with a standard unity plane. If it is impossible to get the rotation working with UITexture, is it possible to put something else in the NGUI hierarchy and get the rotation working on it?

3

NGUI 3 Support / Using SetMatrix on UITexture

« on: June 27, 2014, 02:36:56 AM »

I have a simple custom shader I am trying to use with UITexture to rotate an image on a UITexture. I am trying to use UITexture.material.SetMatrix to set the rotation, however UITexture seems to be ignoring all SetMatrix calls. Aside from the lack of rotation, the texture is rendering just fine. I have confirmed that my shader and matrix init code works perfectly on a standard Unity renderer.

Here is how I have it setup:
I have a GameObject with a UITexture component.
That UITexture component is using a material that is using my custom shader.
In a script file, I set the UITexture.material.mainTexture to something.
I then try to set the UITexture.material.SetMatrix.
I get no error messages and there appears to be no effect on the SetMatrix call (although changing the material.mainTexture is working fine)

What do I need to do to make the SetMatrix stick?

4

TNet 3 Support / Re: Making a simple ready room

« on: June 10, 2014, 02:48:37 PM »

It might. I do recall seeing the player.data field. Is that synchronizing now, or is that a future update?

I constructed the example in my OP because I thought it might be easiest to relate to while helping me come to a solution. My real issue is that I have a ready room where each player picks an image file from their phone, the file is synchronized across all players in the ready room, and then a new scene is loaded for gameplay where each player's image file is used. I don't want to rebroadcast the image file upon entry into the gameplay scene because that would consume additional bandwidth and time. To get around this I ended up combining the gameplay and ready room into one scene. But I am still interested in a "correct" way to do something like this in case I end up expanding the game to the point that it is too unwieldy to have them in the same scene.

On the topic of synchronizing image files: Am I correct in thinking I just convert it to a byte array, send it, then convert it back to my image format? Is there something built into TNet to detect when the entire byte array has been received?

5

TNet 3 Support / Re: Making a simple ready room

« on: June 03, 2014, 03:57:23 PM »

2 replies back you said something about saving data across multiple channels. That is where I thought maybe scene loads cause you to join a different channel. I am not interested in preserving data across channels, I am interested in preserving data across scene loads AND having that data sent to players that join the channel later. Is there a way for objects marked with DontDestroyOnLoad to use saved RFCs?

6

TNet 3 Support / Re: Making a simple ready room

« on: May 29, 2014, 03:06:53 PM »

Do scene loads cause the players to join a new channel? I'm only worried about preserving data across scene loads and keeping a history for players that join the channel later. Keeping this data in a file seems like overkill, it is only relevant for that game session. In other words, I want it wiped when the channel closes.

7

TNet 3 Support / Re: Making a simple ready room

« on: May 27, 2014, 04:29:29 PM »

Ideally saved RFCs would be used to track each player's choice so that players joining the channel after the choice are updated with the details. These choices need to be preserved across a scene load, meaning DontDestroyOnLoad most likely is required. However, you can't use DontDestroyOnLoad on objects that are created with TNManager.Create(). This means the data would have to be on static objects, but static objects can't have saved RFC calls.  Making the whole idea a catch 22.

Clearly I must be overlooking something because this usage (preserving player decisions across scene loads and informing players that join in the future about those decisions) should be trivial. How would you recommend doing this?

8

TNet 3 Support / Making a simple ready room

« on: May 23, 2014, 06:24:00 PM »

This is my first time using TNet and overall I like how much it simplifies many of the networking details. However, I have been bumping into a few design decisions on TNet that has made my design process more difficult than it needs to be.

I'm trying to create a very simple RTS styled ready room. The important details for this are:
1) As players join they are assigned a player number in order. IE the first player (likely host) is Player 1. The second player is Player 2 and so on. If a player leaves, the next player to join takes over that vacancy.
2) All players in the same channel must "see" the exact same player number assignments. (IE we must all agree that Bob is Player 1, Sue is Player 2, etc.)
3)In the ready room, each player can make arbitrary choices such as choosing a color and choosing a faction.
4) The player numbers assigned in 1 and the data choices in 3 must be preserved through scene loads.

I have determined the following design details about TNet that relate to this:
1) RFC calls only save the most recent invocation for each object. This means I can't have all this data on a single instance of a single object (unless I want to go crazy with copy paste on RFC calls). I must have one player object for each player number I wish to assign (otherwise player number pairings and player choices are lost when "old" RFC calls are dumped)
2) If I wish to use DontDestroyOnLoad on an object with the TNObject script, I can't create that object using TNManager.Create. If I do, all kinds of strange things happen.
3) When the Host player creates the game, I am not getting an OnPlayerJoined event to fire for the host player.

Because of this (especially the part about the host not triggering OnPlayerJoined events), I'm not sure what the cleanest design for this would be. I know the player objects must be in the scene (instead of created). However I do not know the best way to detect when players join / leave. I also do not know how to handle ownership for the static objects. Dynamically created objects were nice because I could create them as players joined and they were auto destroyed when the players left.

What is the cleanest design you would recommend for this? Are there other major TNet design details that I may run into regarding this?