Jump to content
  • Advertisement

Arctous

Member
  • Content count

    12
  • Joined

  • Last visited

Community Reputation

103 Neutral

About Arctous

  • Rank
    Member

Personal Information

  • Role
    Programmer
  • Interests
    Design
    DevOps
    Programming
  1. Arctous

    UDP Confusion c++ sockets

    In that case, you may need to review how you are implementing your commands/queues/locks. You should be able to draw with a minuscule amount of lag. With that said, I am assuming that a finger-down, pixel movement (either per-pixel or several pixels in some time snapshot) and finger-up are all discrete events that can be sent on their own (i.e. finger down is sent, then movement is sent, then finger up is sent ~ all individually and not together). Totally agree.
  2. Arctous

    UDP Confusion c++ sockets

    Have you defined what "realtime" means for your application? What is the benchmark you are trying to achieve? Also, if you are going to the world with this, there is inherent latency in any communication from (for example) California, USA to Perth, Australia. Is that part of your benchmark parameters?
  3. Arctous

    UDP Confusion c++ sockets

    Interesting. If you comment-out the communication does the server drawing latency go away?
  4. Arctous

    UDP Confusion c++ sockets

    Yes, I completely understand. That is most likely where your drawing latency is coming from. Another approach for you would be to have the queue only be locked when a command is either pushed or popped off of it. ** Warning: quickly created pseudocode follows... So the creation of the command at the server would be (in its own thread): while ( threadIsRunning ) { // I'm not sure of your command creating mechanisms, // so, this could be a bit off-the-mark Command command = GetCreatedCommand(); if ( command ) { LockQueue(); PushCommandOnQueue( command ); UnlockQueue(); } } And the sending of the command would be (in its own thread): while ( communicationThreadIsRunning ) { LockQueue(); Command command = PopOneCommandFromQueue(); // Could be null if nothing is in the queue UnlockQueue(); if ( command ) { SendCommand( command ); } // Give up the thread so others have a chance to use the queue GiveUpTheThread(); } This would alleviate some of the drawing latency on the server. You might also see an improvement in the communication times because when the system is drawing it is not sending commands. A similar mechanism could be utilized for received commands.
  5. Arctous

    UDP Confusion c++ sockets

    Are you blocking the server command queue while you are sending commands out? Or, is the server able to add commands at the "same time" (with thread safety) that commands are being sent without having to wait for the queue to be emptied?
  6. Arctous

    UDP Confusion c++ sockets

    UDP is best suited for data that does not need guaranteed delivery. For example, in a real-time network game where user positions are being broadcast, dropping a packet is no big deal because another packet is coming shortly with updated information. And, as @the incredible smoker wrote, the sender indexing the packet (for example, with the current time down to ms) will allow the recipient to determine if the packet should be used or discarded because it is older than the last packet received. In your example, regardless of potential fragmentation, if the recipient of the packet needs to receive the "hello" in order for your system to be effective, then UDP would not be a good choice and TCP would be the right choice.
  7. Unity3D dropped support of their WebPlayer a number of versions ago (many browsers starting blocking it, starting with Chrome). However, WebGL remains one of their target build platforms. Additionally, Unity3D has end-of-life'd their UnityScript support (the JavaScript-like language). They are going the C# route. With that said, they still support Java, C++ plugins.
  8. Arctous

    Unity dropping Monodevelop a let down for small indie?

    Happily, Unity3D has taken the majority of those headaches away, as well. The Xcode project is complete, including icons/images (both of which are configured inside of Unity3D) and libraries (added during the development process inside of Unity3D). Unity has been doing a good job of keeping up with the Xcode/AppStore requirements. I've only run into a couple of issues with the Unity3D->Xcode workflow over the years, but those turned out to be incompatible or poorly implemented assets from the Unity Asset Store (HockeyApp plugins come to mind).
  9. Arctous

    Unity dropping Monodevelop a let down for small indie?

    Strictly speaking regarding the Unity3D workflow options (and if you are not doing any Apple-native implementation that requires Obj-C/Swift) the only knowledge you really need to have about Xcode is the building/packaging/signing/uploading stuff. Everything else could be VS.
  10. Arctous

    Unity dropping Monodevelop a let down for small indie?

    The Mac is a fully functioning stand-alone development system. I use Unity3D and VisualStudio-for-Mac (formerly Xamarin) for design/development/debug/test. It's my entire development environment (including creating IPA and APK/OBB files). Git keeps everything flowing between team member's different development environments. No. As you probably know, Unity3D creates a fully signed, ready-to-go APK/OBB files for Android. For iOS, however, Unity3D creates a fully hydrated Xcode project as the output for Apple. You then have to launch Xcode to build and package the app. Initially, I was disappointed in this workflow, partially because it was an extra step versus Android (yes, I'm lazy...) but mainly I was unhappy about the Apple's workflow, in general. Apple was: Unity->Xcode->IPA_Stuff->AppStore_Upload versus Android Unity->APK/OBB->GooglePlay_Upload. However, since Apple has improved the Xcode workflow over the last couple of years it's much better. I can use Xcode to manage the IPA and sign/verify/upload it to the AppStore, as well. So, it's the same amount of steps.
  11. I have been using Orge3D for over 10 years and still have an active Windows desktop application that uses it. I have been super happy with the Ogre3D product and the community. However, I moved to Unity3D for the mobile development. The following narrative is the reasoning for the change. To start, let's move back to 2007. The team inherited an application (originally VS6, C++, XP, MFC, D3D7) that needed to be modernized and have a better/more-flexible/higher-level graphics system implemented so that the project could be moved forward and expanded. Also, we did not need/want to be "on the hardware" for the graphics system, so a higher level of abstraction (above DX and OpenGL) was desirable. After research, we chose Ogre3D because it had the features, flexibility and abstraction that were needed for the redesign of the graphics/object system. Additionally, the library architecture fit well with my personal past experience of using IRIS Performer and OpenInventor. We implemented Ogre3D and were delighted with the results. However, we still relied on MFC for all of our UI needs. Now, let's move move forward to 2015. The client wanted to add mobile to the project for both iOS and Android. We looked at many libraries and ways we could approach cross-platform development (neither Java nor Objective-C are in our wheelhouse). We also took stock of the areas of code that could be extracted from the desktop application. Unfortunately, only the graphics/object system put in place during the implementation of Ogre3D could be reused. There was no UI (it was MFC) or file management (it was also MFC) that could be leveraged. So, much of the application needed to be created from scratch. We created a few of proof-of-concept projects with the various offerings (one being in Unity3D) to test the development time and workflow. In the end it was decided that Unity3D meshed best with our needs and provided us a great environment for design, development and workflow. Also, it bridged a concerning gap by providing us with the tools to create the UI needed for the mobile apps (the new UI system is great). Finally, we were able to deliver the mobile apps faster than expected. I have been very happy with the choice of Unity3D for the mobile applications and I really enjoy working in the Unity editor. The progress that I have seen being made in Unity over the last 2+ years has been impressive and has helped us delivery great mobile apps. With that said, there are no plans to move from Ogre3D in the desktop application. Thanks for reading!
  12. Arctous

    Unity dropping Monodevelop a let down for small indie?

    Unity with Visual Studio on Mac works great! When VS and Unity started playing nice in the sandbox, I moved to VS immediately. I'll have to admit that I am used to using VS (have been since VS6) and other IDEs. I prefer to use a professional grade IDE over any other setup (e.g. make, vim, cc, etc... ~ all of which I have done plenty of times on multiple platforms). I'm also confused as to opinion of 1.5GB being "heavy". It doesn't feel too heavy by today's standards. Xcode is over 5GB. Android Studio is 0.5GB, but with the SDK/tools it's 2GB. As a note, Unity released a preview for a VS Code debugger extension with the latest release (2018.2).
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!