func_monitor resolution
Hey,
One of the levels I'm currently working on for the portal stories mod (LP_WIP_2) involves a button which opens a door quite far away. To make it more obvious what that button did I installed a world portal there, with some panels opening in front of it.
However, I wanted to make it more clear, by parenting a func_camera to a func_tracktrain so people can see where that door opens. HOWEVER. When I do that the camera is pretty bad, it has a really really bad resolution, you can only make out a few pixels and it actually makes it a lot worse. So I wondered: are there any other ideas how to do this more smoothly? Now you might think something like ?! it's working fine for me? Yes, it might be, but I THINK that the screen should be a bit big, so my screen was 192x128 px (eat that nasty old cellphone!!!) to make the tv_screen texture fit it
I could also just remove the panels, and use a trigger_look to enable/disable the worldportals. There is however a small possibility that you can actually see the worldportal close with optimal portal placement and it'll be extremely hard to fix that.
What do you think?
Thanks for any help!
~Lp
What texture are you using for the monitor? Try to hit the "fit" button, that sometimes helps.
PortalStories.com
"Oh, in case you got covered in that repulsion gel, here's some advice the lab boys gave me: DO NOT get covered in the repulsion gel."
I used the dev_monitor texture, and I tried the fit button.
Bad thing: dev_monitor is 64x64 px.
Would it help to use a bigger texture?
I tried a 2048x2048 texture, which was transparent, and that didn't work...
Maybe it wasn't a good idea to try it with a transparent texture?
Ok, I'm afraid you're right skotty.
I think I'll go for a worldportal hax then 
~Lp
How about a func_monitor
Subject: func_monitor resolution
OH BRILLIANT! I COULD HAVE NEVER THOUGHT THAT MYSELF!
-Sarcasm self test completed. 
Edit:
(Maybe actually READ the title and the contents of the first post? That usually gives you an indication of the issue, so "Gow about a func_monitor?" is a stupid reaction, since I was talking about the resolution of the func_monitor. func_monitor can't be the solution of the problem I have with the func_monitor.)
conclusion: Please read a bit more careful before making this kind of posts. Agree, my wording in the fist message is a bit of a mess. but still...
OH BRILLIANT! I COULD HAVE NEVER THOUGHT THAT MYSELF!
-Sarcasm self test completed.
Edit:
(Maybe actually READ the title and the contents of the first post? That usually gives you an indication of the issue, so "Gow about a func_monitor?" is a stupid reaction, since I was talking about the resolution of the func_monitor. func_monitor can't be the solution of the problem I have with the func_monitor.)
conclusion: Please read a bit more careful before making this kind of posts. Agree, my wording in the fist message is a bit of a mess. but still...
I wasn't specific enough, I meant to use multiple func_monitors.
64 x 64 is the size of the texture, so just use 9 point cameras 64 units apart and 9 64 x 64 func monitors pointing to each camera.
Unless you're talking about making the resolution better on one focused area, then try to edit a vmt and make a bigger vtf.
64 x 64 is the size of the texture, so just use 9 point cameras 64 units apart and 9 64 x 64 func monitors pointing to each camera.
Unless you're talking about making the resolution better on one focused area, then try to edit a vmt and make a bigger vtf.
Your first idea won't work since the source engine is limited to just one point_camera active at the same moment.
The second thing is that the vmt points to $basetexture = _rt_camera (something like that, don't know the thing for sure). To be able to use a texture as a func_monitor its $basetexture has to be that _rt_camera file. PROBLEM: that vmf isn't in portal 2. And the resolution will never be better than 256x256... So that func_monitor thing just ain't gonna help me. A func_worldportal will though 
~Lp