Was mostly wondering about this:
Because then every furniture object gets the same image imported probably eating up a lot of memory. If you say make a Furniture class like this:
Code:
class Furni
prop ImageSet* <- Pointer to the imageset for the furniture, load once
prop x
prop y
prop z
prop state
prop rotation
func draw()
use Imageset->getImages(state, rotation) to draw on x/y/z location.
You don't need to import the images everytime you make a new instance of the furniture.
Webpack compiles all furniture assets (scripts and sprites) into module files (javascript format) so when a a dynamic import is made like in the image above it checks "is a module with this path already loaded?" if it is use that, if not download and load it. Webpack is really smart so when i write import "furniture/container/sprites/id.png" it actually looks up something like public/build/module18.js because that's the module that was generated from that url upon module compilation.
I am assuming you are sticking to Habbos 24fps?
The fps is uncapped so whatever your monitors refreshrate is will be your max potential fps. However the update cycle handling which frame of the avatars/furnis to use is currently running ~58 times a second. Uncapping that cycle made the avatars glide around with no jitter like we see on Habbo. The fps is not capped to the same amount as that cycle because you should still be able to drag the UI and see chatbubbles move etc with as good fps as you can get. (144hz monitor makes a big impact on the UI experience)
Have you tried loading in bigger furniture (say the schoolbus) and see how well that performs?
I'm not sure how the schoolbus is but as a rule any furni that has separate images for separate squares will always be more heavy than a 1x1 furni. 1 Lodge divider = 2 pineapples in terms of performance so schoolbus would probably be 6 pineapples or so unless it's all one big image.
Is there an easy way to see CPU time for functions?
Chrome has a neat profiling devtool that let's you record frames over a period of time and shows time spent on each function execution etc both at a specific frame or as an average over the time period spent recording. The great part is that even though the typescript is transpiled to js and the js is bundled and minified we can still get references to the actual typescript file and line number due to source mapping!
Is this using OpenGL & GPU rendering? If so how does it perform on CPU only?
No WebGL/GPU boost but it could be possible to benefit from GPU's in the future by using libraries like gpujs with webworkers. For now it's only CPU based.
If you are running 60fps and you're already having issues at 5k furniture, I feel like you should see if you can improve that. I'm sure you can get a much better results than flash. (I can make the Flash client run 60fps, which looks really great)
I understand your concern and I agree it's not optimal atm. However I am not currently using any rendering techniques to boost performance, everything that exists gets handled and rendered even if it's out of screen or hidden from view or doesn't need rerendering. There's lots of optimizations that can be made so i'm not worried about spending a lot of time on this and then realizing that the performance can't be improved, it most certainly can
With that said tho.. I am really impressed that it can handle this amount of load before decreasing in performance at this stage in development and I feel like I can focus on implementing core features of the game rather than spending time trying to improve the renderer at this point in time. I'm sure most people would be more stoked to have a fully functional demo with room creation, chatting etc than less features but better performance seeing that most rooms will not reach the threshold for performance loss anyway.
Thanks for showing interest!