Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[bloop_bleep]

So, you're planning to send the raw graphics data over? How "large" (memory-wise) are your graphics? I hope you're not trying to stream 60 hi-def raw graphics frames per second to ten clients from a single user machine  ... Or do you plan to have textual graphics with a more telnet sort of thing?

[mko]

Just vaguely on the subject of Masters of Orion, after playing Stellaris so much lately I've been kicking around the idea of possibly trying to make a space empire building game like it but taking the DF philosophy of focusing on gameplay and mechanics more than graphics.

Sounds interesting, good luck with this project!

So, you're planning to send the raw graphics data over? How "large" (memory-wise) are your graphics? I hope you're not trying to stream 60 hi-def raw graphics frames per second to ten clients from a single user machine  ... Or do you plan to have textual graphics with a more telnet sort of thing?

See http://www.bay12forums.com/smf/index.php?topic=98412.msg8120777#msg8120777

client/server may be about two programs on the same machine

And

thin client polls data from the server to display the UI elements

so rendering would clearly happen in a client


------------------------------------

And in my project I managed to finally render textured mesh (with both mesh geometry and texture proceduraly generated), what revealed some wrong assumption.

In short, code was written as designed, effects are not as designed. Also, ****** off by one errors.

No image as everything is covered by piles of debug labels, debug lines and other debug markers.

[itisnotlogical]

My roguelike-ish game project is going well. Of course, that's always what I say right before I get bored or hit a stumbling block.

Defining creatures with a simple tag-based system, similar to Dwarf Fortress RAWs, is really fun. Read all the data as a string, split it by newlines, split those by colons, and wham I've got very easy-to-parse data. It's not quite mod support given the limited scope of my (mostly imagined at this point) game, but it's something.

The only problem I envision will be remembering my own rules and syntax, since the IDE can't hold my hand on this.

[bloop_bleep]

Oh, sorry, I didn't read Reelya's post fully. I thought they were saying Telgin does not necessarily need server hosting because they could run the server on a local network (but a different machine). And I might have misunderstood the format of the data that Telgin was planning to send, I thought it was already-rendered graphics.

[Telgin]

Yeah, the idea was for the server process to just have an API or subscription system that the client would use to get updates on things like ship positions as needed, and just handle the rendering however it saw fit.  That could mean a < character in a terminal window or a 3D rendered ship, with the data just being a ship ID and 3d vector for its position, for example.

I'll keep pondering the idea and see if I ever muster the energy to start on it.

[McTraveller]

Ugh holy crap are code auto-generators dumb.  Especially considering how expensive they are, they make some of the most inefficient code out there...violating the principle of least astonishment at every opportunity...

/rant

(sorry I can't go into details for NDA reasons. But holy crap....)

[bloop_bleep]

Ah, that reminds me of how some people complain how templates "cause executable bloat" in C++ and then opt to use a code generator to bloat both their executable and their code instead. *facepalm*

Don't get me wrong, there are uses for code generators, but "doing a template's job in a more convoluted way" is not one of them.

[MorleyDev]

I know that if it ever needed to be multithreaded that really needs to be done up front, but that would greatly complicate the design.

I tend to think of its more that going multithreaded requires a design that lends itself to multithreading, since trying to write concurrent code with primarily centralized/sequential data access is a square-peg round-hole type situation, and results in mutexes and pain.

For quick development, a basic 'procedural oo' approach is faster to just bash out and be done, but that can be hard to maintain in the long term. So definitely over-kill for a proof-of-concept or prototype.

But some of the patterns that separate dependencies and break down code into self-contained processing units, which can be easier to maintain in the long-term, also can lend themselves quite well to natural concurrency.

For games, I'd imagine something closer to the actor model would fit, being based around message passing and self-contained computation units. I think this could be an elegant solution for breaking up what is a complex problem into separate self-contained parts that can be reasoned about and worked on independently. This is especially suited to the server in a client-server, and it also lends itself very well to multithreading.

C++ as a language doesn't have a lot of the native constructs that make that kind of programming easy though, unfortunately. An actually practical futures/promises library was supposed to come to the STL in C++20 but they've apparently postponed that to the next standard -_- Even then I don't think it'd look anything close to pretty until if they bring an async/await-type syntax into the language itself.

[Telgin]

My experience with multithreaded execution in C++ is pretty limited, so it's definitely an aspect I'm a bit anxious to even tackle.  I've written some things with pthreads in C on Linux, but I'd prefer to use my Windows desktop as my development machine and I actually have no idea off the top of my head if pthreads is a Linux specific library or cross platform.  Pretty confident Win32 would do it differently, or at least offers a different threading interface.  An abstraction library would be very nice, especially if it were a core language feature.

And of course, let's not forget that I have written C++ seriously in about 10 years, so I'm not familiar at all with the modern dialects, or even things like auto pointers.  The latter is my fault since I'm pretty sure auto pointers have been part of the standard library forever, but still.

It makes me reconsider trying to do everything in Node.js since I have a lot of experience with it from my day job.  It also comes with a lot of convenient features for free, like native JSON parsing for config files, easy to use libraries for things like web sockets for client connections, web servers for debug interfaces, and good asynchronous code support.  Plus it makes it really easy to later add modding support since custom code could even be written in JavaScript.  But... it's single threaded, and while Node's performance is way better than Python's in my experience, it's still not native C++.

I'll have to look and see if there are any libraries for doing multiple threads in Node.js.  I feel like there have to be some that work in a somewhat generic manner.  I won't be surprised if they're Linux only or something though.

[McTraveller]

The key with all of this is not in the particular syntax model or library you use for threading - the important part is understanding what can be done in parallel and if it will benefit your use cases.

You have to think about how your pieces of code share data, if they have dependencies, if they are truly "independent", etc.

[Telgin]

Oh, sure.  Agreed completely.

More than anything I'm just trying to make sure I don't waste my time.  That's one thing I truly came to appreciate when I started doing web development: high level languages save you just so much time.  They have their shortcomings, but I'd try to use a high level language anywhere it would be enough for that reason alone.

From a different angle, I'd rather waste as little time as possible on technical problems.  For example, the last time I had to compile something in Visual Studio that required Boost, I spent a day figuring out how the heck to get Boost installed, compiled and linking to the project.  Admittedly, I was trying to compile an executable using V8, which is itself extremely complex, but... I'd just rather not waste that time if I don't have to.

[McTraveller]

I came across this interesting paper recently - language issues, package management, etc. are all "accidental complexity" as opposed to the stuff we want to get done, which is "essential complexity".

http://www.cs.unc.edu/techreports/86-020.pdf

[Telgin]

That was an interesting read and still surprisingly relevant almost 35 years later.

Yeah, that's what I was getting at - I want to deal with as little "accidental complexity" as possible.  Everything flows well when you have the data structures laid out nicely, and that should be the main focus.

[Reelya]

My experience with multithreaded execution in C++ is pretty limited, so it's definitely an aspect I'm a bit anxious to even tackle.  I've written some things with pthreads in C on Linux, but I'd prefer to use my Windows desktop as my development machine and I actually have no idea off the top of my head if pthreads is a Linux specific library or cross platform.  Pretty confident Win32 would do it differently, or at least offers a different threading interface.  An abstraction library would be very nice, especially if it were a core language feature.

And of course, let's not forget that I have written C++ seriously in about 10 years, so I'm not familiar at all with the modern dialects, or even things like auto pointers.  The latter is my fault since I'm pretty sure auto pointers have been part of the standard library forever, but still.

Just use STL Threads, they've been part of the reference since C++ 11. After these, really nobody should be using platform-specific threads libraries. I kinda feel everyone should be up on C++ 11 since it was the first major revision in many years. C++14 and later stuff still feels like it's optional to know, but C++11 is pretty much mandatory knowledge now.

https://en.cppreference.com/w/cpp/thread/thread
https://en.wikipedia.org/wiki/C%2B%2B11

There's a bunch of sections in the C++11 page explaining all the changes they made to the language to support multithreading natively.

Spoiler (click to show/hide)

While the C++03 language provides a memory model that supports threading, the primary support for actually using threading comes with the C++11 standard library.

A thread class (std::thread) is provided, which takes a function object (and an optional series of arguments to pass to it) to run in the new thread. It is possible to cause a thread to halt until another executing thread completes, providing thread joining support via the std::thread::join() member function. Access is provided, where feasible, to the underlying native thread object(s) for platform-specific operations by the std::thread::native_handle() member function.

For synchronization between threads, appropriate mutexes (std::mutex, std::recursive_mutex, etc.) and condition variables (std::condition_variable and std::condition_variable_any) are added to the library. These are accessible via Resource Acquisition Is Initialization (RAII) locks (std::lock_guard and std::unique_lock) and locking algorithms for easy use.

For high-performance, low-level work, communicating between threads is sometimes needed without the overhead of mutexes. This is done using atomic operations on memory locations. These can optionally specify the minimum memory visibility constraints needed for an operation. Explicit memory barriers may also be used for this purpose.

The C++11 thread library also includes futures and promises for passing asynchronous results between threads, and std::packaged_task for wrapping up a function call that can generate such an asynchronous result. The futures proposal was criticized because it lacks a way to combine futures and check for the completion of one promise inside a set of promises.[21]

Further high-level threading facilities such as thread pools have been remanded to a future C++ technical report. They are not part of C++11, but their eventual implementation is expected to be built entirely on top of the thread library features.

The new std::async facility provides a convenient method of running tasks and tying them to a std::future. The user can choose whether the task is to be run asynchronously on a separate thread or synchronously on a thread that waits for the value. By default, the implementation can choose, which provides an easy way to take advantage of hardware concurrency without oversubscription, and provides some of the advantages of a thread pool for simple usages.

[Telgin]

Oh, cool, I'd forgotten that threads had been standardized in C++ at some point.  That's very helpful and encourages me to possibly actually tackle this with C++.

I'll have to see if I can find C++ libraries for other things I'd like to have, like JSON parsing and maybe a scripting interface.  I know Lua is popular for this sort of thing and it may be the best option.  I did successfully get V8 integrated into a project once, but at great pain, and I know it would introduce some issues with multithreading.  Not sure if Lua has any kind of thread safe implementation, but presumably I could run the scripts in some sort of manner that they were implicitly thread safe by limiting was was available to the scripts at any given time.

Probably getting ahead of myself there anyway.  One thing at a time.