Transparent message passing is the way to go

Except when it isn't.

and I am quite amased why not everyone has transitioned to the paradigm already.

I can think of many reasons, such as perhaps having tried it and it turns out that "transparency" always comes at a cost. I gave a few other reasons in my original response, such as when you have a need for authentication over networks. As I also said in my original response, ZeroMQ has done this for a long time, and there are successful systems built on top of that.

the moderator gives obvious BS advice

Specifics would be much more useful.

Transparent message passing is the way to go

Except when it isn't.

and I am quite amased why not everyone has transitioned to the paradigm already.

I can think of many reasons, such as perhaps having tried it and it turns out that "transparency" always comes at a cost. I gave a few other reasons in my original response, such as when you have a need for authentication over networks. As I also said in my original response, ZeroMQ has done this for a long time, and there are successful systems built on top of that.

the moderator gives obvious BS advice

Specifics would be much more useful.

Well if you really need to know that you are doing authentication from a certain place you are "screwed". Anyone can hack your binary and make you think you are wherever they want you to believe you are. There is no protection against that. As a programmer you are blind and deaf to the world in your little black box of assumptions i.e code.

To the BS I found this at the top

start_quote

1) read inputs

2) calculate simulation

3) render graphics

With networking, the "read inputs" step includes both keyboard and network, and you typically send the inputs to others right before going to the calculate simulation step.

end_quote

And I answered exactly that by saying no, that is very bad practice as you have different frequencies and workloads in these different steps. In most OSs though you are obliged to keep graphics rendering in the main thread which is a shame. At least as long as you use the legacy languages OpenGL or DirectX. GPUs bye-bye...

I had a look at ZeroMQ thanks to your comments and it seems quite interesting. It is intriguing although since I am almost done (on my third re-write) I just will go with the current architecture. It does deserve a closer inspection as the authors of ZeroMQ definitely have put a lot of good engineering into their product.

Lets just say that they have one major fallacy. You can handle reliability over UDP. Ponder on that.

spinningcube

Well if you really need to know that you are doing authentication from a certain place you are "screwed".

I think you got it backwards. To be able to DO authentication, the network-receiving part needs to know that it's talking to a network, and needs information like what the remote IP address is.

Anyone can hack your binary

I don't understand why you're discussing clients at all. The client does not have multiple networked nodes to use, so I don't understand how network-versus-local-node transparency would help you there at all.

To the BS I found this at the top

1) read inputs
2) calculate simulation
3) render graphics

Just to make it clear: You state that you think the game structure from almost every real-time game, ever, is bullshit? (Note that the specifics of reading/calculating/rendering may vary greatly, but clearly that has to be the data dependency.)

Well if you really need to know that you are doing authentication from a certain place you are "screwed".

I think you got it backwards. To be able to DO authentication, the network-receiving part needs to know that it's talking to a network, and needs information like what the remote IP address is.

Anyone can hack your binary

I don't understand why you're discussing clients at all. The client does not have multiple networked nodes to use, so I don't understand how network-versus-local-node transparency would help you there at all.

To the BS I found this at the top

1) read inputs 2) calculate simulation 3) render graphics

Just to make it clear: You state that you think the game structure from almost every real-time game, ever, is bullshit? (Note that the specifics of reading/calculating/rendering may vary greatly, but clearly that has to be the data dependency.)

If you don;t understand the client thing no big deal.

No. You have obviously not worked on a commercial game as most have input in a separate thread at a high frequency. What you describe here is the beginner way of programming straight out of high school class. The OP asked about async design and you did give him bonafide BS advice and keep on doing it.

But please keep on the pretenses. Maybe like that you feel better. Do not try to help others, just make yourself be right. That's what is important after all, not telling how to do thing in a good way, just that people accept the crappy advice as gold. After all if people don't respect the authority of the moderator, what would happen? Oh gosh.

Since you have no intention in bending your mind to understand I simply stop this for my own minimisation of time waste.

spinningcube