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?”
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.
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)?
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
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.
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!