stevenarella
stevenarella copied to clipboard
iceiix
Client crashes when unfocused
When the client is unfocused (by making it non fullscreen and then clicking on some other application on the same monitor) the client sends no keep alive packets more (it seems like it freezes somehow, which is good in theory but in practice it doesn't respond to any packets sent to it anymore, like for example keep alive packets... which causes it to crash after a timing out from the server. This can be fixed by handling some specific packets in the reader thread, and not sending them to the main thread via the channel. (I already fixed it in my custom version of this client, which I can't merge into this one, cuz I removed web support and I am about to switch to vulkano as a rendering engine)
Was going to say this sounds vaguely familiar, there are/were platform-specific conditions where window events are not delivered, at least: https://github.com/rust-windowing/winit/issues/219 - but if you've solved it... handling packets on a separate thread I agree does seem like a good solution to me (maybe all/most packets?).
I already fixed it in my custom version of this client, which I can't merge into this one, cuz I removed web support and I am about to switch to vulkano as a rendering engine
In this fork? https://github.com/terrarier2111/stevenarella
Web support (https://github.com/iceiix/stevenarella/issues/446 🕸️) is very incomplete, wouldn't be too much of a loss to break or disable it, may be worth the rendering backend upgrade. Looked into alternatives in https://github.com/iceiix/stevenarella/issues/34 Investigate rendering backends, and I switched from a custom OpenGL wrapper from Steven, to glow in https://github.com/iceiix/stevenarella/pull/262 - abstracting OpenGL/ES and WebGL. But now, there's newer tech like WebGPU on the horizon, which more closely resembles vulkan, and vulkano does look to be a very nice library (safe Rust wrapper around Vulkan API). And the industry appears to be moving away from OpenGL to newer graphics APIs, so I wouldn't mind moving this project, either. Just saw this recent gfx-rs update: https://gfx-rs.github.io/2021/07/16/release-0.9-future.html "a single Vulkan-like Rust API with multiple backends that implement it: Direct3D 12/11, Metal, Vulkan, and even OpenGL ES". And then there are implementations of Vulkan which bridge to other platform APIs. It is all quite confusing, many options, no clear best winner...
I suppose what I'm saying is, I'm all for your porting to use the vulkano graphics backend (if not necessarily to merge into this repo - at least it will be a worthwhile alternative for some usages - a step forward beyond the OpenGL/WebGL hegemony). The ideal scenario I see is full support for all native modern rendering backends for each platform (Vulkano? Metal? Direct3D? WebGPU?), ideally abstracted away, but, that's a long way off (if ever), not easy...
In this fork? https://github.com/terrarier2111/stevenarella
No its not a fork in the traditional sense, I just uploaded the modified files to a private repo on github, as i don't think anyone except me would work on this project, if published, so I decided, I'd loose nothing when making it private (and probably open sourcing it later on down the line).
Was going to say this sounds vaguely familiar, there are/were platform-specific conditions where window events are not delivered, at least: rust-windowing/winit#219 - but if you've solved it... handling packets on a separate thread I agree does seem like a good solution to me (maybe all/most packets?).
I handle all packets on a seperate thread which also boosts perf dramatically. (for this i had to restructure many parts of this project to use Arc/Arc->RwLock ie. the Server has no mutable stuff in it anymore (the same is true for the World) as they are both only passed in Arcs which allows me to use way more multithreading in order to improve the performance. (i think i was able to improve the perf by at least 3 to 4 times the original perf, thus I get an average of 100 frames, when standing still and 20-40 fps when moving and loading the world initially, and all of this in an unoptimized build)
