Multiplayer + Raycasting?

[bmarslandCN]

Is your feature request related to a problem? Please describe. This is not a problem, just a future feature request :)

We love the multiplayer extension and we love the raycasting extension, and would love to see multiplayer ability available in a game that uses raycasting in the future!

Describe the solution you'd like Allow for multiplayer in a game that incorporates raycasting!

Describe alternatives you've considered We tried using it currently, and it is not possible while in raycasting mode.

Additional context Thanks for considering our request!

[eanders-ms]

@jwunderl Looks like the way the raycasting extension renders the screen doesn't work with how the multiplayer board reads it.

[jwunderl]

It looks to me like it plays as expected https://arcade.makecode.com/--multiplayer?host=59169-39428-75390-60169 / nothing clashing between the two, it just looks like another instance of https://github.com/microsoft/pxt-arcade/issues/5113 as this explicitly different views per player to work in a way that supports multiple people playing together; when we have multiple cameras we'd have to have player specific renderables & raycasting should be relatively simple to update to work there in the same way any player specific ui would be done.

[eanders-ms]

Here's one that repros for me: https://arcade.makecode.com/--multiplayer?host=S27122-90434-15832-10838

[eanders-ms]

@bmarslandCN what was your repro case?

[jwunderl]

Ah I see, looks like it must have been an older version of the extension in the link I shared, it now digs a bit deeper than I expected and is overriding the actually place where we call into the sim to render: https://github.com/AqeeAqee/pxt-raycasting/blob/master/render_raycasting.ts#L395-L403 I'm not sure I see the benefit in that right away -- it looks like it's done when swapping between top down / raycasting view, but that should work fine to either render directly onto screen or as a renderable without too much change.

(But even with that fixed there won't be many things you could implement until there is multi cam, which would also need updates at that point.)

[bmarslandCN]

I believe the multi-cam is what is needed - I made a simple tilemap maze then used the raycast and multiplayer extensions to try creating a multiplayer version, but only one player was able to use the "myself sprite" function to navigate the raycasted tilemap. The other players had blank screens until the raycasted player toggled the view to the regular tilemap, then all players could see and navigate through the tilemap.

[eanders-ms]

Sounds like a fix should be made in the raycasting extension, if I read that right.

[AqeeAqee]

Hi all ! Sorry for "late reply", I just happened to this. Yes, as @jwunderl said to support this feature completely, we need multi cam. The bug shown in @eanders-ms test project, is because I invoked a tempScreen, and update to low level Screen directly (skiped pasting it to the screen img object then update the low level Screen by arcade), for perfermence considering.

Hi @bmarslandCN A quick fix could be: game.onShade(()=>screen.drawImage((Render.raycastingRender as any).tempScreen,0,0)) You can add this line to anywhere of your code. Glad to hear you like my Raycasting extension. And, actually I am not a team member of Arcade. You can contact me on Raycasting 3D render – Blocks Edition about this extension, or pin me at forum at any time for any question.

@jwunderl The reasons why invoke tempScreen instead of rendering on the screen are:

1. The particle feature draw doesn't have a target parameter, it can only draw directly onto screen img. particle.__draw(this.camera) Screen has contents rendering for current frame already at that time. So calling particle.__draw() for each sprite, then blit them from screen to tempScreen.
2. Blit these 2D drawing output(particles or sayText or etc. ) of arcade features to 3D rendering (with some transform parameters), we need another surface, that is the tempScreen.
3. As mentioned, for perfermence, I didn't blit tempScreen back to screen. This would be a little faster, especially on hardware consoles. But this really leads to some issues, like this. I had tried to write them in renderable or sprite.update/draw pattern, it's possible and looks better, but abondant finally for a little perf impact. But nowadays, thing like sim in high res and online features more and more pop. Less and less guys play on console, I feel. So maybe refator them in next release.