full screen menu
Moderator: InsideQC Admins
9 posts
• Page 1 of 1
full screen menu
by ajay » Fri Nov 05, 2004 6:17 pm
Is there a non-engine way of displaying a full-screen menu, so that one you pause the game you get a full screen still image.??
It's not important, but would be nice.
It's not important, but would be nice.
-
ajay - Posts: 559
- Joined: Fri Oct 29, 2004 6:44 am
- Location: Swindon, UK
by Wazat » Fri Nov 05, 2004 7:11 pm
Yes, I'm considering doing that with the Conquest menus, eventually...
I'm going to use entities that are .drawonlytoclient (an engine value to cut on network traffic) for the graphics. Unfortunately that still creates lots of entities, and you need some way to know what the player's screen size is...
I'm going to use entities that are .drawonlytoclient (an engine value to cut on network traffic) for the graphics. Unfortunately that still creates lots of entities, and you need some way to know what the player's screen size is...
When my computer inevitably explodes and kills me, my cat inherits everything I own. He may be the only one capable of continuing my work.
- Wazat
- Posts: 771
- Joined: Fri Oct 15, 2004 9:50 pm
- Location: Middle 'o the desert, USA
by Spike » Fri Nov 05, 2004 7:21 pm
Wazat wrote:and you need some way to know what the player's screen size is...
erm... why?
Ajay, have you tried playing with the scr_centertime cvar? Okay, it's not conveinient, but should work with any engine, and if given a large enough value will be effectivly permanent over pauses.
- Spike
- Posts: 2892
- Joined: Fri Nov 05, 2004 3:12 am
- Location: UK
by Supa » Sat Nov 06, 2004 12:23 am
Wazat wrote:Yes, I'm considering doing that with the Conquest menus, eventually...
I'm going to use entities that are .drawonlytoclient (an engine value to cut on network traffic) for the graphics. Unfortunately that still creates lots of entities, and you need some way to know what the player's screen size is...
Err, you should be using .viewmodeltoclient instead. You'll have to play with the origin a bit to get it to look right, but it'll work far better overall. .drawonlytoclient would result in your menu not angling properly when the player looks up and down, and wouldn't scale with the player's resolution like .viewmodeltoclient does.
aut viam inveniam aut faciam
-
Supa - Posts: 164
- Joined: Tue Oct 26, 2004 8:10 am
by Wazat » Sat Nov 06, 2004 4:27 pm
But self.weaponmodel can only have one model there. I'm going to need many entities working together to create the graphical menu.
When my computer inevitably explodes and kills me, my cat inherits everything I own. He may be the only one capable of continuing my work.
- Wazat
- Posts: 771
- Joined: Fri Oct 15, 2004 9:50 pm
- Location: Middle 'o the desert, USA
by leileilol » Sat Nov 06, 2004 4:53 pm
Why not have cursor movement frames and such? i.e. weaponframe 4 points to choice 4 on the weaponmodel menu model, etc.....
I know it's a bit hacky but it's visual at least, and if lighting's a problem, you could use _luma.tga's
I know it's a bit hacky but it's visual at least, and if lighting's a problem, you could use _luma.tga's
i should not be here
- leileilol
- Posts: 2783
- Joined: Fri Oct 15, 2004 3:23 am
9 posts
• Page 1 of 1
Who is online
Users browsing this forum: No registered users and 1 guest