Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

DarkBASIC Professional Discussion / Split screen game + Camera facing particles => hmm...

Author
Message
Quel
17
Years of Service
User Offline
Joined: 13th Mar 2009
Location:
Posted: 7th Apr 2012 13:49
How would anybody here go about the problem which is in the title?

I mean, there is a nice particle system, which mostly operates with camera-facing plains. It would look nice to Player1, but Player2 would see - seemingly - randomly rotated plains all over the place instead of smoke trails and explosions.

This has never been a problem to developers, so it should be possible, but how?

My closest guess would be to make a second limb for each particles, which would be an exact clone of the particle itself, and Limb1 would be rotated towards Camera1, while Limb2 would be pointed to Camera2. The only real problem here is that i don't know how to show Limb1 only to Cam1, and Limb2 only to Cam2.

Is there any command that hides an object, or what would be even better, a limb from one camera but not the other(s)?

Any help would be highly appreciated...

-Mental Hybrid: A unique heavy story based shoot'em ~40% (primary project)
-CoreFleet: An underground commander unit based RTS (canned) ~15%
James H
19
Years of Service
User Offline
Joined: 21st Apr 2007
Location: St Helens
Posted: 7th Apr 2012 14:48 Edited at: 7th Apr 2012 14:56
Not at my machine atm but off top of my head have a look at these commands

set current camera x
x=object in screen(x)
used together I think the detection should work

set object mask x,x
this will only show object to specified camera until the mask is changed

however they won`t orientate your planes to face the correct camera, instead I think you will have to work it out for each plane between each frame after detection, then update the orientation of each plane followed by setting the object mask.
Alternative to object mask would be to use hide/show/exclude object on/off, object/object limbs between viewport syncs. As there is no limb in screen() command you would have to use a seperate object that is positioned and orientated then removed from render after detection for each limb if you went the limb route. Another pair of commands that you may find some use for are object visible and limb visible commands which only relate to show/hide commands - you can have an object thats excluded but not hidden and the object/limb visible command will still tell you if its hidden or not

Also idk what code you are using for viewports but I did ask lee for an example some years ago and I can acces that email from this machine so here is the example so you can check if its the way yours is set up similarly;




There is a way using shaders to orientate the planes to camera but I do not know at this point if something would need passing to the shader to tell it which camera to orientate towards, additionally I have no clue as to how using point object for particles would affect performance versus making the calculations in dbp yourself, but cheap solution might be to take the current camera angle and rotating each particle to the same angle plus 180 degs, but this might not work if you start zrotating the camera
Pincho Paxton
23
Years of Service
User Offline
Joined: 8th Dec 2002
Location:
Posted: 7th Apr 2012 15:37
Draw the same scene twice at different coordinates. The problem might be that you lose the speed advantage of billboards.

Fallout
23
Years of Service
User Offline
Joined: 1st Sep 2002
Location: Basingstoke, England
Posted: 7th Apr 2012 16:07
I would use the sync mask command. Point the particles at camera 1, sync just camera 1, then point the particles at camera 2 and sync just camera 2.

Pincho Paxton
23
Years of Service
User Offline
Joined: 8th Dec 2002
Location:
Posted: 7th Apr 2012 16:16
Quote: "I would use the sync mask command. Point the particles at camera 1, sync just camera 1, then point the particles at camera 2 and sync just camera 2."


My guess is that its slower than building the scene twice, because of the extra sync. But maybe test both.

Fallout
23
Years of Service
User Offline
Joined: 1st Sep 2002
Location: Basingstoke, England
Posted: 7th Apr 2012 16:30
To be honest, I've not used multiple cameras before, but I'm fairly certain each camera is rendered by it's own sync anyway. I don't think a scene can be rendered from two different perspectives without a sync for each camera. So I would expect performance to be the same pretty much. Rather than letting DBP sync cam 1 then sync cam 2, you sync cam 1 manually, rotate particles, then sync cam 2 manually.

Would be interesting to know how it actually works though. I'm just assuming!

Pincho Paxton
23
Years of Service
User Offline
Joined: 8th Dec 2002
Location:
Posted: 7th Apr 2012 17:56 Edited at: 7th Apr 2012 17:58
Quote: "To be honest, I've not used multiple cameras before, but I'm fairly certain each camera is rendered by it's own sync anyway. I don't think a scene can be rendered from two different perspectives without a sync for each camera. So I would expect performance to be the same pretty much. Rather than letting DBP sync cam 1 then sync cam 2, you sync cam 1 manually, rotate particles, then sync cam 2 manually.

Would be interesting to know how it actually works though. I'm just assuming!"


I don't know which is faster either. It's hard to say. If you used two setups though you might not need to rotate distant objects for a long time.

Penfold
22
Years of Service
User Offline
Joined: 3rd Dec 2003
Location: RED postbox houses of parliment
Posted: 9th Apr 2012 00:24 Edited at: 9th Apr 2012 00:26
would it be simpler to put a slice of code in

if player 2 exists
create a second set of plains for the 2nd player facing him?
end if

the only problem I can see with thtis is maybe a couple of smoke plains intersecting a fireball plain...might look odd. might just mean you have to change the way the object is displayed or create an actual 3d object for it.

'Ooh 'eck chief'...'crumbs'
Mage
Valued Member
19
Years of Service
User Offline
Joined: 3rd Feb 2007
Location:
Posted: 9th Apr 2012 04:11
I agree with the most of the suggestions being offered. You need to sync the cameras separately/manually using sync mask, and rotate the particles before each sync.

Quote: "My guess is that its slower than building the scene twice, because of the extra sync. But maybe test both."

This is true. This can be very significant.

Alternative Method
You can convert all particles from being rotated planes into 3D objects eliminating your need to rotate them for the cameras.
This requires some artistic flare to make the job look decent.
This eliminates the problem and thus makes the bottleneck of syncing separately unnecessary.

I would use this method because at high detail levels you experience less performance loss. Especially at HD resolutions and if shader effects are used.

Quel
17
Years of Service
User Offline
Joined: 13th Mar 2009
Location:
Posted: 12th Apr 2012 10:02
The SYNC MASK + An ordinary sync for each camera works like a wonder, Fallout was right, it equals two sync's to have two cameras.

Thank you!

Forgive me Mage, but spheres for explosions are so early 90s... you aren't sad that DBPro won't be updated to a newer DirectX, do you?

-Mental Hybrid: A unique heavy story based shoot'em ~40% (primary project)
-CoreFleet: An underground commander unit based RTS (canned) ~15%
Fallout
23
Years of Service
User Offline
Joined: 1st Sep 2002
Location: Basingstoke, England
Posted: 12th Apr 2012 13:56 Edited at: 12th Apr 2012 13:56
Just when I was getting a syncing feeling about my suggestion!

Yes, I'll be here all week.

Mage
Valued Member
19
Years of Service
User Offline
Joined: 3rd Feb 2007
Location:
Posted: 13th Apr 2012 03:35 Edited at: 13th Apr 2012 05:56
Quote: "
Forgive me Mage, but spheres for explosions are so early 90s... you aren't sad that DBPro won't be updated to a newer DirectX, do you? "


Well I agree that's why I said this...

Quote: "This requires some artistic flare to make the job look decent."

(don't use spheres)

Here's a rough example... Although its not split screen and the effect hasn't been taken as far as I suggested.


For an explosion, you can create several separate objects, with randomized orientations. They are a series of expanding planes with varying speeds. Some are flash waves, some are smoke, some flames.
It's sort of crucial to use several objects for an effect to achieve a decent level of detail. Or 1 object with several scalable/rotatable limbs.



If you arrange the look and feel properly, you can create excellent and dynamic 3D effects that don't need to be faced at the camera. It's not the easiest thing to do but the same applies to most other types of effects.

Edit: Another good example. The sparks aren't camera facing sprites.


TheComet
18
Years of Service
User Offline
Joined: 18th Oct 2007
Location: I`m under ur bridge eating ur goatz.
Posted: 13th Apr 2012 09:02
@ Quel

I believe you can use fastsync for camera 1, and then a normal sync for camera 2. Should save you some extra speed, otherwise your game has to run at 120 fps, which is ridiculous.

TheComet

Mage
Valued Member
19
Years of Service
User Offline
Joined: 3rd Feb 2007
Location:
Posted: 14th Apr 2012 00:48 Edited at: 14th Apr 2012 01:07
Quote: "I believe you can use fastsync for camera 1, and then a normal sync for camera 2. Should save you some extra speed, otherwise your game has to run at 120 fps, which is ridiculous."


Great advice but the other way around. Use fastsync for everything but camera 0.

Oh yeah. Always use SYNC for Camera 0, or at least once per loop, or the sound system won't work. Sounds don't update position, etc properly until the next SYNC is called. FASTSYNC does nothing to help this.
http://forum.thegamecreators.com/?m=forum_view&t=177326&b=1

Multiple Sync Can Rapidly Advance Object Animations
Also if you use the built-in commands for animations like Play Object or Loop Object, animations might advance on each use of sync/fastsync, and thus multiple times per frame drawn to screen. This causes erratic animation, and performance loss.

So remember this if your object animations seem erratic. You might have to manage animation playing and looping yourself with the use of Set Object Frame command, and "Management Skills".

Off Topic:
The benefit to managing animation yourself however is that you can easily stop everything, and still animate menus and objects on screen without having to manually stop/start every single object. Like having a pause menu overlaying the paused game. Or you can uniformly slow everything for bullet-time effects. Etc.

Login to post a reply

Server time is: 2026-07-09 00:08:53
Your offset time is: 2026-07-09 00:08:53