Buffer the user input in a new thread?

Troubleshooting General Help
1

I was wondering if I could buffer all input using a new thread,
and convert it to a commands queue to be issued at the main thread?

why? main thread temporary freezes and low fps basically.

why not “fix” the main thread limitations? because thats not the point, many ppl cant buy a new machine, ssd drives, etc.

2

What kind of input? Network, disk, keyboard and mouse?

1 Like
3

good one…
user input only: mouse, keyboard, joystick and so on

4

That’s a tough one… I don’t know about the technical details of getting input on a different thread, i.e., what threading requirements need to be met (if any). I would assume that it’s possible.

However… I also can’t imagine that this would be a bottleneck, and I’d guess that buffering this would likely be a bigger source of latency and overhead than just receiving the events in the main thread. Have you done any profiling to isolate your project’s “hot spots?”

5

I think it happened more when loading on demand (without pre-caching) a fully animated model with textures. But my own code could create that when initializing some stuff too.

I am recreating the project, so I cant make it sure right now, and I am preparing to step on something I can count on. Mainly to let the user not be puzzled when issuing commands.

Basically, It is not about issuing like dozens of commands, it more about the last 2 or 3 commands the user issued, as he sees it is frozen, and may be desperately insisting in some action/key press, or is just holding the key pressed (what could not require the buffer, but would in case of the “key down” is not recognized in the main thread, by having happened after the begin of the freeze right?),
so he just waits a bit and will know will not have to issue the commands again.

So I think it will not become a source of more slowness. And I can also restrict the amount of buffered commands, and that could also be an user option.

6

Why not just let the user know he pressed the key, before sending the command to the main thread? Separate the visuals/input/feedback from the processing.

1 Like
7

If your render thread locks up long enough for the user to care about where their input went then you have an architectural/design problem with your game.

8

to me, an important thing to overcome is the long time loading screens, so my goal is:

  • load all collision data near the player and near whereever is action happening, and readily give the control to the player
  • further load remaining collision data
  • of active enemies: load visuals and sounds without compromising minimum fps (I am speaking about 5 to 10 fps, I used to play that way predicing other players movements online, many years ago, quite fun hehe), even going from low to high quality to speed it up (debug collision visuals, then low texture res, low poly models, to high…)
  • load all remaining visuals and sounds

so, this means, I am trying to avoid the initial load time, boring the player up, if he can accept low initial quality, and gradually let it be improved, mainly wherever he is looking at, for low end PCs. Mainly the big industry looks forward, even demanding new hardware to allow ppl to play their games. I am looking backwards. I you have any minimum requirement pc, you will be able to play, and all fancyness can be disabled, if you are able to accept it.

unless you are speaking about another kind of design (not about pre-loading/cache)? :slight_smile:

also, on the very startup, we could be allowed to type some commands like: ESC to open the menu, hit Down 3 times to access options etc… as we have it in our brainy memory, instead of having to wait the application be ready to accept the commands. So this way I would basically make it sure the user input thread is fully running before allowing everything else to be run.
EDIT: on many games, this happens even after we activate some option and it is being set, and you have to wait the application be ready again, quite annoying…

like showing tiny visual indicators that certain keys were pressed at some screen corner? could be an option, but if I could have a buffered commands feature w/o messing things, it would be interesing/relieving :slight_smile:

9

“My main render thread bogs down because I’m loading lots of data on that thread. How can I buffer keys so the user gets frustrated and pounds the keyboard a lot?”

Well, the first thing “don’t load lots of data on the render thread”. Why move input to another thread when you could do the loading on another thread and let the user still have a responsive app?

I mean, I load 100s of megabytes worth of visual data on Mythruna… while the user is walking around… without any noticeable “can I buffer input” slow down.

1 Like
10

so, this also means, move away to other threads anything possible that could burden the main thread, even an user changed option can be gradually applied if possible.

that would minimize these troubles a lot, I have to try it thx!

11

How long it takes to you to load all necessary things? There is nothing wrong with loading screens, but maybe the issue is somewhere else.
Do you have DXT compressed textures? (files with .dds extension) Loading and uncompressing formats like png or jpg, (which aren’t supported by GPU, so you need pure bitmap) takes time. Loading unbuffered .ogg file lasts three times longer than loading .wav file and in the end both of them needs the same amount of memory.

1 Like
12

Anything more than 3 seconds is quite annoying to me, probably mostly because loading screens are utterly boring and repetitive.
It was some blender models with bundled textures. I am creating a cache with uncompressed and JME native formats (.j3o). thx!

13

No, use compressed, but instead using jpg/png you need to have something that is supported by hardware.
http://vandaengine.org/an-overview-to-common-compressed-texture-formats/

1 Like