0

I'm an upcoming programmer who is trying to build games in C++ (Console applications right now). But one annoying thing is bugging me and stopping me. The thing is I want to be able to multithread when letting the game character move as well as spawn enemies. But the problem is that because these two things are seperate functions and that there's only one input-spot used by the setCursorPosition the game always get messed up when these two functions get entangled. What are the solutions to this? If you guys need it I can send some source codes to try to explain my problem further. Examples and videos are very appreciated!

Felix Nilsson
  • 7
  • 4
  • I don't understand what is the problem if you use separate threads for character moving and enemy spawning? – unlut Feb 25 '19 at 19:08
  • 2
    Please create a Minimal, Complete, and Verifiable question, we can help a lot more. – Kevin Kouketsu Feb 25 '19 at 19:10
  • 1
    Since you are a beginner, I'd advise using a state machine and a *single* thread rather than multiple threads. Threads are quite tricky and *IMHO* very much expert-only territory. – Jesper Juhl Feb 25 '19 at 19:27
  • 1
    I agree with @JesperJuhl that State Machines are the beginner way to go here. But if you want the solution with threads, you should look into [Mutex](https://stackoverflow.com/q/4989451/2602718). – scohe001 Feb 25 '19 at 19:36
  • @JesperJuhl I took your advice and implemented mutex into my program. Thanks it helped and my game is now complete! – Felix Nilsson Mar 08 '19 at 17:41

1 Answers1

1

One solution is to only ever let a single thread update your screen.

You could for example have a framebuffer, which is a region of memory your threads draw into, and then another thread which in regular interval draws the entire framebuffer onto the screen. When you use two such buffers you can hide intermediate drawing steps. But actually this thread design is quite messy.

The best solution would be to use only one single thread (no multithreading, no std::thread at all). To me it appears you do not need multiple threads, but rather an event based system in which individual entities act independently and draw to the same screen. You do not need threads for this.

Multithreading is rocket science in 2019, especially in C++. Do not do it unless you are an expert.

Johannes Overmann
  • 4,914
  • 22
  • 38
  • I've already done that a countless amount of times. I've done games where as soon as you click one key arrow your character moves after the screen updates and the new playboard is displayed with the new position of the character. It's time to move on, but this whole thing is bugging me. Got any tips on how to get around this issue? – Felix Nilsson Mar 03 '19 at 16:09
  • @Felix: Tip: See my answer. Do not let multiple threads update your screen. It won't work. Your screen is a shared resource. Either you have to use mutual exclusion (mutex) or you ensure mutual exclusion by design (only let one thread update the screen). – Johannes Overmann Mar 10 '19 at 20:40
  • yeah I tried using mutual exclusions by including the header file . I then watched a couple of videos and eventually figured out how to implement a mutex "key" into my program to give the results I wanted, which it did. – Felix Nilsson Mar 10 '19 at 21:12