Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multiplayer + Raycasting? #5702

Open
bmarslandCN opened this issue Feb 15, 2023 · 8 comments
Open

Multiplayer + Raycasting? #5702

bmarslandCN opened this issue Feb 15, 2023 · 8 comments
Labels

Comments

@bmarslandCN
Copy link

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
Copy link
Contributor

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

@jwunderl
Copy link
Member

jwunderl commented Feb 15, 2023

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 #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
Copy link
Contributor

@eanders-ms
Copy link
Contributor

@bmarslandCN what was your repro case?

@jwunderl
Copy link
Member

jwunderl commented Feb 15, 2023

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
Copy link
Author

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
Copy link
Contributor

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

@abchatra abchatra added bug Something isn't working p2 extension multiplayer labels Feb 18, 2023
@AqeeAqee
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants