Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 19 Aug 2002
Offline Last Active Today, 01:16 AM

#5219515 [Visual C#] Help with passing an object between forms

Posted by Nypyren on Yesterday, 09:11 PM

You have several options:
class Form1 : Form
  void OpenSecondForm(object thingy)
    var form2 = new Form2(thingy);  // Option 1:  Pass it via the constructor when you create your second form.

    form2.Thingy = thingy; // Option 2:  Set a public field.

    form2.ThingyProperty = thingy; // Option 3: Set a public property.

    form2.SetThingy(thingy); // Option 4:  Call a function to set it.

    // NOTE: You only need to use one of the four options.  I listed them all at once to reduce the amount of typing.


class Form2 : Form
  public object Thingy;

  public object ThingyProperty // Generally you would not make a property when the field is also public - this is for demonstration only.
    get { return Thingy; }
    set { Thingy = value; }
  public Form2(object thingy)
    Thingy = thingy;

  public void SetThingy(object thingy)
    Thingy = thingy;

#5219234 How do you stop your game from being stolen/torrented?

Posted by Nypyren on 25 March 2015 - 11:27 PM

SOL-2517 has the right idea: Most of the time, you should not even be thinking about pirates. You should be thinking about total players.

Every game has a "funnel" of some kind, which you can think as a series of filters - each filter is a barrier-to-entry, removing a subset of your potential player base. The first filter is whether or not the player has even heard of your game. The next filter is whether it keeps their interest enough to think about playing it. Is it a genre they like? Do their friends like it? How is the review score? Does it have lots of bugs? How expensive is it? Do the developers help people on their forums?

You always want your game's funnel to let as many people in as possible. If you are aware of the funnel, you can think of more ways to get players in the door.

Pirates are just people who are using a slightly different funnel than the one legitimate people use.

Make a free demo. Some people pirate games because they're worried that they won't like it, and want to "try before they buy". Then they end up getting lazy after playing all the way through and decide "I don't like it ENOUGH to buy it." A demo gives them enough experience to decide if they like the game or not, AND tempts them into a purchase with the unknowns of additional features/content in the full game.

Think of ways to make people feel good about buying your game. Is there some benefit the non-pirates enjoy that pirates don't? *Optional* online features such as Borderlands' Golden Keys system might work.

Never make your game more convenient to pirate than to play legally. I'm talking about always-online stuff that many of the big publishers try to do recently (Uplay, Origin, etc). Players don't like that nonsense.

Not all pirates are bad: Pirates have friends. Some of those friends may not be quite as big of a pirate and could buy your game. Depending on how things work with the game, the friend may even be able to convince the pirate to buy the game so that they can play online together. Nothing is quite as powerful as peer pressure.

Above all: NEVER PISS OFF ANY PLAYER - pirate or otherwise. If a pirate thinks, "you know, these developers are pretty cool, actually... I feel kinda bad about pirating from them," that is a win even if they still don't buy your game.

#5218589 c++ count lines in txt file and then read these lines without reopening a file

Posted by Nypyren on 23 March 2015 - 02:27 PM

Since we're going crazy with memory mapping, why not just go the C-style route?

- Load the entire file into memory.
- Scan it for newline characters, converting each into a null terminator as you find it.
- Keep the count of each newline you replaced.
- Allocate a char*[] using newline count.
- Loop over the modified file again, setting each pointer to the start of each respective string (the start of the file and at the character following each null terminator). Stop your loop when you hit the newline count you've been tracking.

#5218361 what do you use to document your c++ code?

Posted by Nypyren on 22 March 2015 - 05:45 PM

I use plain old comments. I don't make closed-source libraries, so I have no need to generate a second set of documentation from the code.

I use "the code is the documentation" methodology mentioned by Hodgman.

#5218179 Anybody with a Windows Phone could lend a hand?

Posted by Nypyren on 21 March 2015 - 08:07 PM

Affirmative, music works now!

#5218098 Tiny .ini parser

Posted by Nypyren on 21 March 2015 - 12:37 PM

INI parsers are usually very minimal effort to write from scratch, especially if you're only going to read your own personal INI files with it.

- Read one line at a time.
- If line is completely whitespace, ignore.
- If line begins with the comment character (';' or '#' depending on what you want to support), ignore.
- If line starts with '[', set a 'currentSectionName' variable.
- Find first '=' character in the line, handle the part before the '=' as the key and everything after as the value. Send the current 'currentSection', 'key', and 'value' variables to your handler or store them in a data structure.

- Writing them is trivial.

If the only INI files you read are the ones you write yourself, you don't need any more than that. You can add any additional features (such as escape sequences for \n, \t, etc) when you need them.

#5218011 Anybody with a Windows Phone could lend a hand?

Posted by Nypyren on 21 March 2015 - 02:24 AM

Lumia Icon here, game seems to run just fine. Audio works. No music that I've noticed (not sure if there's supposed to be music or not). Can't tell what the framerate is but it feels fine.

#5217989 Graphic corruption

Posted by Nypyren on 20 March 2015 - 07:42 PM

Well, it's a long shot, but I've had glitches like that when the video card was defective. Does the problem happen in any other software?

#5217921 How to shoot using Bulllet Physics

Posted by Nypyren on 20 March 2015 - 01:24 PM

I'm not sure what version of bullet you're using, but I found one version of the code you're looking for here:


Line 553.

Bullet's demos are set up as classes that derive from DemoApplication; so most of the common input handling and stuff is in there.

#5217900 Doge Indirection

Posted by Nypyren on 20 March 2015 - 12:08 PM

My reaction:

"Wait... that..."

".... oh good lord."

#5217895 How to shoot using Bulllet Physics

Posted by Nypyren on 20 March 2015 - 11:41 AM

You have the documentation and the source code to the demos, right? You should be able to figure that stuff out pretty easily from that!

This is all very basic stuff. "Give a man a fish..." and all that.

#5217789 Under what class / category is a Golem?

Posted by Nypyren on 19 March 2015 - 07:49 PM

class == GameObject?

#5217785 How many songs should I put in an album?

Posted by Nypyren on 19 March 2015 - 06:56 PM

With more and more online services letting people buy individual songs, I'd say it doesn't particularly matter. It used to be that you'd put X songs on a CD to balance the (effort of X tracks + manufacturing and marketing cost) vs. (the price you'd sell the thing as a unit to the customer). If X was too small, your customers might feel like they were paying too much due to the publishing overhead.

If it's entirely online, then there's no "per-disc" manufacturing overhead anymore. If the online service lets you buy individual songs, customers also don't have to buy whole albums when they only like a couple songs on the album.

As a consumer, the only time I use the album-as-an-organization-system is when I find a compilation by different artists including one artist I know I like, hoping that some of the other songs are similar and could suit my tastes.

#5217701 2D vs 3D

Posted by Nypyren on 19 March 2015 - 01:36 PM

2D is easier than 3D for a beginner. 3D = more state in your program. More state = more ways you can set things up wrong.

The very first problem you run into when learning how to render stuff is: "Why isn't my thing drawing?"

- It might be off-screen.
- Your alpha channel might be all zeroes.
- Your shaders (if using shaders) might be working incorrectly.
- You might have forgotten to call Draw.

- All of the above, plus:
- It might be behind the camera.
- Your view/perspective transforms might be set up incorrectly.
- You might be looking at the back of the triangle and it's getting culled.
- Your normals might be reversed.
- etc.

#5217562 how to comunicate with diffrent exe files?

Posted by Nypyren on 18 March 2015 - 11:52 PM

Wait, is this based off of my suggestion in your other forum post ( http://www.gamedev.net/topic/666672-systemnetsocketsoverlappedasyncresult/ ) where I said this?

I highly recommend separating your receive code from your data handling code;

I didn't mean you should make a separate EXE. I meant that your function was doing too many different kinds of tasks (socket receive, SQL queries, etc) all in one function.

I normally have a single BeginReceive/EndReceive loop to read data from the socket, which splits the data up into messages. The messages are then routed to different functions (in the same EXE). This makes it easier to add more functionality later without having to write several BeginReceive/EndReceive pairs each time (and worrying about accidentally starting a second BeginReceive on the same socket at the wrong time).

I was under the impression in that thread that this was a WinForms server EXE (which is fine for debugging purposes, I'm not sure why Sean's brain died). I have no idea why you would need a third process in addition to your Unity game and your Server, though.

In your Unity game, even if you don't need to send/receive data every frame, you can still have your socket code work the same basic way without too much overhead. Here's what I do in Unity (you'll have to excuse any typos I make here since I'm freestyling this):
public class UnityTcpComponent : MonoBehaviour
    // (these are wrapper classes on WP8/Metro that function the same way)
    TcpClient tcpClient;
    NetworkStream stream;
    IAsyncResult arConnect;
    IAsyncResult arReceive;
    byte[] recvBuffer = new byte[2048];

    // TODO: There would be some event/callback/dispatcher member here that can be configured to pass received data to whatever other code you're using this instance for.

    public void Connect(string hostname, int port)
        tcpClient = new TcpClient(...);
        arConnect = tcpClient.BeginConnect(..., null);

    void Update()
        if (arConnect != null && arConnect.IsComplete)
            tcpClient.EndConnect(arConnect); // end completed connect operation.
            arConnect = null; // don't accidentally handle it again.
            stream = tcpClient.GetStream(); // get the stream to read from.
            arReceive = stream.BeginReceive(recvBuffer, 0, 2048, null); // begin read operation immediately.

        while (arReceive != null && arReceive.IsComplete) // while loop allows fast receipt when there is more than one buffer of data available per frame.
            int bytesRead = stream.EndReceive(arReceive); // end completed read operation.

            // TODO: accumulate the received data and handle it if there are one or more complete messages received.

            arReceive = stream.BeginReceive(recvBuffer, 0, 2048, null);  // begin another read operation.
Of course there's a bunch of exception handling in the real code as well, but that's the basic idea. The reason I'm using Begin/End is that my code needs to be used on WP8 and Metro, which have slightly different versions of the socket library which don't support the select-and-recv pattern that you'd normally use if you were polling on a single thread (because MSFT decided in their infinite wisdom that nobody would ever want to care about which thread their code was running on anymore so they got rid of most of the blocking-oriented methods). The reason I don't use the callbacks in the Begin* methods is because Unity is a little b**** about making pretty much ANY UnityEngine.dll calls from background threads, so pretty much everything needs to happen in its Update methods - it's more wasteful in Unity to use the callbacks AND a concurrent queue to message-pass back to the Unity thread than it is to poll every frame.