Make pak code more consistent.
* Added 'Pak_CloseFile' to SDK.
* Added partial rebuild of 'Pak_ProcessPakFile' to SDK.
* Added compile time assert for 'PakFileHeader_t' structure.
The min spec is SSSE3, using SSE4.1 instructions (_mm_extract_epi64) will break compatibility. The code containing the defect is debug only, and %90+ of the user base uses an SSE4.1 capable processor.
A mistake has been made, certain area's of the engine actually do allow strings larger than 128 bytes, just one routine that doesn't (console commands). Tokenizer only tokenizes it up to 512 bytes, so null all the other bytes past this. This still fixes the flaw mentioned in the comment at the place where the nulling happens.
Combine ClearAutoComplete with ResetAutoComplete, full reset needs to be performed when calling this. Combining avoids confusion and potential bugs later on.
* Fixed redundant call (every frame) to 'ResetAutoComplete()' if the list was empty while having text in the buffer.
* 'ResetAutoComplete()' also resets 'm_bCanAutoComplete' now.
Don't update the view once we already found the 'active' object, or if we are at the park position (-1). This fixes the hack of having to have CConsole::m_bSuggestMoved to be true all the time.
If you had a list of suggestions, and had an active element halfway through the list, and then update the suggestion list again by changing what's in the input buffer, the view would remain at the old position (displaying whatever is there). This makes sure the view gets reset all the way to the top if the list was updated.
Move it back to caller hook instead of in the ProcessMessages function as there were crash reports when running the listen server. Moving this back solved the intermittent crash problem entirely while still rate limiting process time.
Some parts of the engine have to be rebuild in order to implement this correctly, therefore, it has been removed for now to avoid potential performance problems.
fps_max_rt and fps_max_gfx have been limited to 295 to avoid a contest with the engine's hard limit causing huge performance hits.
CEngine::Frame() tends to return out early if we are ahead of frame time, and therefore need to sleep. In this particular engine, CEngine::Frame() returns true if it had actually executed an engine frame, else it returns false.
Therefore, we end up calling 'NvAPI_D3D_Sleep()' multiple times a frame, and thus causing a major loss in performance. Now we check if we have actually ran a frame (incrementing reflex frame if so). If the frame was not incremented, but 'GFX_RunLowLatencyFrame()' was called, it will not call 'NvAPI_D3D_Sleep()'.
Code has been tested and appears to work on my system (never called twice or more per frame). Needs more testing on other systems to make sure its good.
Propagated latency markers in an attempt to further reduce input latency. Code is pending rigorous testing on several systems, including systems powered by an AMD GPU to make sure we are not impacting performance on systems that does NOT support NVIDIA Reflex.
