I set out to find out why Firefox renders the world layers all fuzzy, while Chrome and Edge render the svg crispy clear. Turns out, there's a reason the game runs at a smooth 60fps in Firefox but not in the other browsers. Read more in the final section (Learnings).
Good news
New things
update! add car upgrades: 2 types of GT wings (improves speed + steering)
update! add turning wheels (see the front wheels steering)
update! reinstated pit crew (where all my homies at?)
update! re-add gamepad logic (now it's a Real Game!)
update! no more frame drop when going off-track and on-track
Is that a GT wing or are you happy to see me?
But wait, there's more
improve skid mark location + don't draw skid marks off track
improve checkSurfaceType routine
fixed debug window
update code to reflect changed markup (car layers)
lots of variables renamed in GC sidequest goose chase (dumb)
remove lots of debug code
Learnings
Weird frame drop (this one's simple,it turns out)
The game would set a class to the body reflecting the surface type. This was a bit of a lazy implementation because I could just use the body class as a hook to also update some UI elements. This routine was even optimized to only update the class when the surface was something other than its current value and everything! But after a whole bunch of debugging -- IN THE WRONG PLACE -- I found out this was what's causing the frame drop: When changing the body class, the browser basically has to re-draw the entire body element because of 'dirty' pixels. When I moved the updated class to some fixed element inside the body, the frame drop was gone immediately. Shame on me for actually knowing better but not doing the work.
Fuzzy svg
Turns out, FF renders the svg to its native size (3200 × 3200 px, which is still manageable) and then scales it to the target size (32k × 32k). This is Actually Good:tm: because, as my CPU found out, when setting the svg and viewBox sizes to the desired dimensions (ie, 32k) then Firefox will render things crispy BUT also drop to 0-5 fps. Problem is, the resulting bitmap is probably 32? Megapixels? and this will grind any and every browser to a halt, especially when you have 3-4 of those chonkers.
I guess the trick is to find a sweet spot that still yields pleasant imagery, but also keeps the FPS up.
A second trick is then to find a way to "downgrade" the image fidelity for Chrome etc. so they too can render the game at ~ 60fps.
There's bad news but also good news
Bad news
I set out to find out why Firefox renders the world layers all fuzzy, while Chrome and Edge render the svg crispy clear. Turns out, there's a reason the game runs at a smooth 60fps in Firefox but not in the other browsers. Read more in the final section (Learnings).
Good news
New things
update! add car upgrades: 2 types of GT wings (improves speed + steering) update! add turning wheels (see the front wheels steering) update! reinstated pit crew (where all my homies at?) update! re-add gamepad logic (now it's a Real Game!) update! no more frame drop when going off-track and on-track
But wait, there's more
improve skid mark location + don't draw skid marks off track improve checkSurfaceType routine fixed debug window update code to reflect changed markup (car layers) lots of variables renamed in GC sidequest goose chase (dumb) remove lots of debug code
Learnings
Weird frame drop (this one's simple,it turns out) The game would set a class to the
bodyreflecting the surface type. This was a bit of a lazy implementation because I could just use the body class as a hook to also update some UI elements. This routine was even optimized to only update the class when the surface was something other than its current value and everything! But after a whole bunch of debugging -- IN THE WRONG PLACE -- I found out this was what's causing the frame drop: When changing thebodyclass, the browser basically has to re-draw the entire body element because of 'dirty' pixels. When I moved the updated class to some fixed element inside the body, the frame drop was gone immediately. Shame on me for actually knowing better but not doing the work.Fuzzy svg
Turns out, FF renders the svg to its native size (3200 × 3200 px, which is still manageable) and then scales it to the target size (32k × 32k). This is Actually Good:tm: because, as my CPU found out, when setting the svg and viewBox sizes to the desired dimensions (ie, 32k) then Firefox will render things crispy BUT also drop to 0-5 fps. Problem is, the resulting bitmap is probably 32? Megapixels? and this will grind any and every browser to a halt, especially when you have 3-4 of those chonkers.
~ ~ to be continued. ~ ~