https://i.imgur.com/RCNnx1L.gif
You can now sit/lay in rooms.
Printable View
https://i.imgur.com/RCNnx1L.gif
You can now sit/lay in rooms.
Are you using a library like PixiJS or Phaser? Or did you create your own canvas "game engine"?
I can't wait to see the code, this looks so good. It'd be extremely educational (at least for me)
I'm rendering everything on my own, no libraries but jquery for the interface is used.
- - - Updated - - -
https://i.imgur.com/eLmglqA.gif
Not a perfect transition yet, but it's a start. Rewrote the server sided path finder execution as well, should be a bit smoother in the background now.
- - - Updated - - -
https://i.imgur.com/zjExgej.gif
Scratch that, repaired it.
I used to do my hit registration similar to this as well, its pretty inefficient. I suggest instead creating a hitmap and storing 1 hitmap for each texture (your texture should ofc be reusable). Here's the order of how it should work
1) Before wasting any resources make sure the (x, y) being checked is within the bounding rectangle of the sprite being checked
2) If point is found within the bounding rectangle, check if a hitmap has already been created for it (sprite.texture.hitmap or similar)
3) If it doesn't, generate it
- Create the hitmap & iterate pixel data of the texture, setting any alpha pixels below our threshold (127) to 0
4) Using the hitmap, find pixel data relative to the point being checked and test if the value does not equal 0Code:const imageData = context.getImageData(0, 0, width, height);
const hitMap = new Uint32Array(Math.ceil(width * height / 32));
for(let j = 0; j < height; j++)
{
for(let i = 0; i < width; i++)
{
const num = j * width + i;
const num32 = num / 32 | 0;
const numRest = num - num32 * 32;
if(imageData.data[(4 * num) + 3] > 127) hitMap[num32] |= (1 << numRest);
}
}
texture.hitMap = hitMap;
texture.hitMapWidth = width;
- I'm unsure of how your code is written but getting the pixel data from the hitmap should be something like this
Doing it this way will entirely remove the need of having a separate canvas, redrawing and coloring pixels. The hitmap is reused across all sprites with the same texture so you only ever need to generate it once per texture. This will drastically improve rendering performance.Code:const hitMap = texture.hitMap;
const dx = Math.round((x + texture.frame.x));
const dy = Math.round((y + texture.frame.y));
const num = (dx + (dy * texture.hitMapWidth));
const num32 = ((num / 32) | 0);
const numRest = (num - (num32 * 32));
return ((hitMap[num32] & (1 << numRest)) !== 0);
I don't render the hit registration all the time, only when needed, I draw a spritesheet of each furniture upon the creation of tee furniture, with its defined rgb colors. It doesn't take more than some millisecond to draw the hit registration.
Please don't use jQuery for the UI, beyond the fact that jQuery is going to be deprecated in modern web applications, but it doesn't suit complex structures like Habbo Client because after little time it becomes a nightmare of functions, unmaintenable (I know because my first Client UI was only jQuery).
The best way to write the UI, as it must manage really much data, is by using a Frontend Framework like Vue or React with a solid state management system like Vuex or Flux.
If you need, I can help you with this side.
https://cdn.discordapp.com/attachmen...18/unknown.png
https://i.imgur.com/PlUQd4H.gif
Not a lot of progress but it's coming together.
This project has much potential. I really hope you finish this one out. Keep up the great work.
Any update?
- Via Tapatalk -
I haven't been posting a lot recently because I took 1 (or 2?) weeks to chill to not wear myself out, which by the way, if you're a developer, you should considering taking breaks through your projects, it helps!!!
Either way, I've begun a process of working with performance issues, I brought room rendering down from 200ms(don't even ask me how it got to 200ms LOL) to less than 20ms no matter the scenario.
https://i.imgur.com/huxFr7M.gif
I know exactly how you feel. Doing a lot of development after work hours myself - it may eventually break you if you do that on a daily basis. Take care of yourself. You're doing great work. Can't wait to see more progress!
It'll be the same deal: (do ignore the speed of the ice elephants, I think they were converted while the converter was still being written and it's missing a piece or another, will look into it)
https://i.imgur.com/05CKfGn.gif
Honestly, I don't know what would take up the most performance right now, but it all looks kinda basic at the moment, they all work with a furniture_animation visualization type from what I've seen and the way I've written it for basic animations are pretty simple: add a sequence index to all layers where the animation is to be updated (e.g. not static, has animation, etc), if the frame in the sequence differs from the old frame, then render the new state, which, judging by the current stats and output (^), seems to be working just fine.
As for the transitionTo and transitionFrom, they'll be pretty simple to implement, like I did before.
Lol, I'll look into why they aren't shown!
Edit:
There is some clear issue with the data generated for the ice elephants, which I'm pretty sure is from the early stages of the converter. Specifically the animation sequences.
https://cdn.discordapp.com/attachmen...43/unknown.png
As for the pre-processing/drawing performance:
https://cdn.discordapp.com/attachmen...56/unknown.png
Pre-processing = it's the part before drawing the new frame, this is where the updates are done to let the graphic entities render the furnitures with new animations.
Drawing = the time it takes to draw the pieces on the canvas.
Do let me note that these messages are not displayed for every frame, they're only displayed when the process takes over 20ms.
Edit #2:
https://cdn.discordapp.com/attachmen...26/unknown.png
Shadows added! (currently set to 0.25 opacity, not sure what it needs to be, gonna check in a minute)
Quality is in the small details so shadows is something you cant leave out :D