Jump to content
  • Advertisement
Sign in to follow this  
biophaze

Multithreading

This topic is 3173 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Alright, Long story short I'm developing a game that plays similar to ADOM in that it's ASCII rendered and is non networking. I've decided to multithread my Engine, but I'm very new to this subject. Could some one please point me in the right direction of 1) a game engine development tutorial/book, and 2) a tutorial/book on multithreading in games. Much obliged, Alex

Share this post


Link to post
Share on other sites
Advertisement
For something as simple as a rougelike ASCII RPG, do you even need multithreading? What do you plan to run on multiple threads?

Share this post


Link to post
Share on other sites
No I don't need multi threading, but I'm new to multithreading, and wanted something fun to start with, and I wanted something easy(relatively), thus, rogue like ASCII rendered game for me ^^.

I planned on running the games physics/graphics on a different thread than the Processing functions... My engine, and yes I know it's rather crude, is structured like this


Input->Process->Render

where input is both AI and User, processing encompasses both physics and commands and renderings is fairly self explanatory.

really I know it's redundant and even circuitous to include multithreading in this program. But it's just for the learning. This game wont be released outside my close friends so it doesn't matter how out of the way I go to make it.

edit: thank you salavous for you're link, It will come in handy.

Share this post


Link to post
Share on other sites
Quote:
Original post by biophaze
No I don't need multi threading, but I'm new to multithreading, and wanted something fun to start with, and I wanted something easy(relatively), thus, rogue like ASCII rendered game for me ^^.

I planned on running the games physics/graphics on a different thread than the Processing functions... My engine, and yes I know it's rather crude, is structured like this


Input->Process->Render

where input is both AI and User, processing encompasses both physics and commands and renderings is fairly self explanatory.


Check out here for how to use Boost::Thread here.

But what I'm really wondering, is why you have a graphics engine for a Rouge-like game. Then again, you should start like that. So have a go at my link to get some tips on how to use Boost::Thread.

Share this post


Link to post
Share on other sites
Quote:
Original post by biophaze
No I don't need multi threading, but I'm new to multithreading, and wanted something fun to start with, and I wanted something easy(relatively), thus, rogue like ASCII rendered game for me ^^.


The fact that it is rendered in ASCII doesn't make it simpler.

With rogue-likes, simulation is fully input-driven. Unlike simulations with real-time loop, rogue-likes only advance state when player takes an action. As such, concurrency has little benefit, since overhead of starting the distributed tasks is large compared to work that needs to be done in response to user input. It is also counter-intuitive.

There is very little that can be multi-threaded in this case, since it's a different kind of processing model.

It is possible to develop a very flexible input-driven architecture for MUD-like multi-player games, but that introduces all the complexities of multi-player programming and some other issues which are also not exactly learning material. But even in this case, multi-threading doesn't bring any real benefits, it's just possible to design it in such a way.

Quote:
Input->Process->Render

where input is both AI and User, processing encompasses both physics and commands and renderings is fairly self explanatory.


In rogue-like, these 3 are always sequential. They cannot be split concurrently, unless you deliberately waste cycles by redrawing the map when it doesn't need to be redrawn.

Input blocks until user types something. When they do, process runs, and if needed, updates the display.

This is different from GPU-based graphical games, where rendering portion is asycnhronous and has its own state, changes to which are communicated via messages (OGL, D3D).

Share this post


Link to post
Share on other sites
Thank you both for your responses. I will take all information into consideration. As I said I'm new to game programming and new to Multi Threading, so this is all a learning experience.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

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

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!