 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
An NV 960 is irrelevant unless you can get a test case that goes below about 500 fps.
Gimme the Intel benchmarks, that's the interesting stuff. There's probably things I can do for lightmap updates but I'm not willing to gut the code unless I'm satisfied that there will be payback at the end of it. I might also make one of my experimental GPU lightmaps engines available, because I'm interested in how that might perform. I'm cautious about not creating expectations in the community though.... Map = ad_magna
In console type: "setpos 2496 56 -292" And you'll be at the mirror. screenshot /In Mark V, you can type "viewpos" to see your current x, y, z -- which also sets the default setpos. So if you type "viewpos" at a red armor, walk away and then type "setpos" you'll be back at the red armor. If it is lightmaps --- and that's an if --- slowing things down.
Type: r_dynamic 0 Then dynamic lighting is simply turned off. In Mark V, do the following after starting up Arcane Dimensions.
Type: temp1 0 // Turn extra ad particles off r_dynamic 0 // Turn off dynamic lights sv_cullentities 2 // Strict visibility tests on all entities map start // Restart the Arcane Dimensions start map Play See if your fps improves. These commands helped a lot in previously barely playable maps like ad_tfuma and ad_swampy. I might leave temp1 on 1024 and r_shadows on 1, still.
Cool! Glad it helped out some.
In the Quakespasm thread, mh, ericw and myself and others are discussing performance related issues related to Arcane Dimensions. I'm starting to warm to the idea of doing some kind of release of one of my GPU lightmap experiments. ericw has expressed interest in how parts of it work and I'd be fascinated to learn how it performs on QuakePone's machine.
I've basically got 3 engines: Quake/OpenGL/assembly shaders, Quake/Direct3D 11 and Quake II/Direct3D 9. The Quake II engine is probably the most developed but it misses D3D 11 enhancements and draw call overhead does pile up. The Quake/GL engine is very barebones and I'm not sure where the code is. The Quake/D3D 11 is most likely to be let out. Huh. About the issue where models in front of the sky look "darkened"
(see my post on Old Page #1321 with screenshot illustrating that fullbright textures get ugly and washed out when contrast is applied) Here's a screenshot showing this effect: http://imgur.com/a/2C4Ez Shaft looks better with sky behind it! Maybe something like this could help all fullbright textures to make them not as ugly when contrast is applied.... Starting with -nostencil removes the sky effect, though it still lets you see r_shadows 3 through models (second screenshot above shows a distant grunt shadow visible through a dog's butt, heh). I know you're aware of the stencil issue, mh, but I just had to display these interesting screenies ;) On your server with JimBob and ORL.
Hadn't played Frostbite in some time, that map and the rest of the "2005 Wintery Map Pack" are always great experiences. You might talk JimBob or even yourself into delete all maps and extra sounds in your Quake folder to watch the map/model/sound download in action. JimBob wondered how I had the maps and the music, haha ;) Well, I didn't until I connected. They downloaded automatically, of course. Mark V has the best stay-connected http map/model/sound download this side of FTE. The auto-downloading is great. And I have noticed the
I just wasn't sure if you actually got the music. I don't mean the intermission dance loop WAVs. Rather, I mean the soundtrack MP3s I selected to match the edited Also, I'm not sure where it all comes from, since I think the FvF server is still Magic Proquake? I do vaguely seem to recall you talking (once upon a time) about having downloads come from a 3rd-party source like QuakeOne or w/e? Locs are for team deathmatch and such (dm3, etc.) like "At the red armor with 87 health"). You can turn off downloading locs. Type "find loc" in the console, you'll see a cvar that can be set to turn that off.
/mp3 don't download, mp3 tend to be large, aren't needed to play. It's a player preference anyway. of also moving r_shadows and r_waterquality variables into config.cfg?
I find it a bit complicated to set them externally through autoexec.cfg. And since texture filtering has already been moved... I've been really enjoying the winquake build, it runs very well. I ran into this little guy after I disabled mips. He's harmless but has worn out his welcome :)
just found "showram".
Whenever I get stuck on something I just make a forum post or drop a message on irc so 30 seconds later I can figure it out myself :P never fails. ever. Don't know, but I'll think about it.
I worry about mods changing obscure things, causing niche settings to write to config. Examples: 1) quake.rc, autoexec.cfg 2) QuakeC Case in point, Malice messes with untold numbers of weird cvars like viewidlescale that most users have never heard of. Imagine if you exited and everything saved, all those peculiar settings would be part of your config and short of reseting/deleting your config, you wouldn't know how to reset them. I'll think about it. But my instincts tell me that no matter what, someone with very specific tastes is always going to find something that needs to be an autoexec.cfg Mods should be properly set "gamedir" and yes everything saved, including
that's true except, when you switch gamedirs during a session, the cvars and aliases and keybinds are retained, and when you eventually quit that session they will be written to the last gamedir you switched to.
Some people use game command (i.e. "game travail"). Some people like R00k probably use gamedir capability more for CTF.
And although no small number of people use the command line either from habit or because of the Quake Injector -- there are those that use "game travail" way. And these different set of circumstances have to be factored in. when implementing the command in fitzquake, i considered writing the config to current gamedir, clearing all values to default and then loading the config in the new gamedir as a way to resolve this, but it could have negative results such as changing your video mode or mouse sensitivity, or other settings that the player doesn't expect to be per-mod.
The core problem is that some settings are global user settings and some are mod settings and there is no formal distinction between the two. Most experienced players don't feel too much pain from this since they have autoexec.cfg files that force the correct settings (of course this breaks down when a mod includes an autoexec!) These are major things that, in addition to the topics noted above and earlier in the thread, are likely to be goals in the spring.
List of some different future possibilities 1. Coopable 3D "Quake Injector" built-in, concept Undergate screenshot About everything needed to finish the concept is in the engine already. 2. iPad/iPhone/Android versions with Minecraft-like controls (Minecraft is very playable on an iPad). I played the awesome Kurok mod for Quake FitzQuake version on a PlayStation Portable and am not likely to be satisfied until I can play Quake on at least an iPad and also like it. I also did tons of engine modding of PSP Quake engines, so yeah I'm not pleased about not being able to Quake on devices. 3. Kurok capability screenshot. I have added almost every required capability into Mark V, but a small few remain. 4. Multiple-players, same computer. working prototype demonstration. This means studying Microsoft's XInput for game controllers, because the working code does not have the needed input support. 5. Spiked Quakespasm's super-compressed protocol. I like demo rewind and will have plan out right way to achieve it. 6. Playing 7. LAN Co-operative peer-to-peer multi-threaded download of required files (Like the client downloading "travail.zip" from the server). Would make LAN co-op setup even easier and Mark V already has a ton of co-op capabilities. Mark V actually has a beta form of capability disabled in the engine for polishing. (Note: Even a 70 MB download is nothing on a LAN. Over LAN that file could have downloaded hundreds of times while I typed this sentence.) 8. A re-written sound caching system to allow changing sndspeed between 11025, 22050, 44100 at any time. 9. Native Linux without SDL. Will add better support for video capture, hardware gamma. (Might adopt Spirit/jdhack's Requiem Engine decision to use fmod for mp3 playback, but I still haven't explored all the mp3 options, including some of ericw's thoughts.) 10. Other things mentioned elsewhere in the thread, I'm sure. "when you switch gamedirs during a session, the cvars and aliases and keybinds are retained, and when you eventually quit that session they will be written to the last gamedir you switched to."
Uhh, I just tested, and Mark V does not actually do that. Well, I mean, it does carry over settings, but all config changes seem to save to the directory you started in, always, not the last dir you were in when you quit. But if that's the way you are starting the mod every time, I guess you would end up with all your config settings each time you play anyway.... Though I don't think that's the correct way to go about it. I'm with Rook on this -- let each game dir house its own cfg stuff for that mod. And I still say it should automatically exec that config stuff upon changing to a new gamedir. This would allow the user to keep settings for each game truly separate. And if someone changes to a new dir, it won't carry over config stuff from a previous dir that perhaps shouldn't apply (assuming there's a setting for the mod that should supersede an old setting -- just retaining defaults is fine). And it wouldn't (shouldn't) save config stuff you change while playing that mod back to the base id1 folder (as it does now if you start in id1 and manually change to the new dir). So yeah, each game dir should have its own configs, really, which override anything from outside that game dir. And when you quit, the config for your current game dir SHOULD save within that game dir. I could illustrate a problem with the current approach: Start Quake normally (plain id1). Let's say you have normally bound "shift" to cycle weapons. Then you want to play FvF or something with a grapple, so after you change "game fvf" and "bind shift +hook" then you quit the game, it saves that binding back in your id1 flder.... Now if you want to play normal Quake again, you have to rebind the shift key. If it saved your (now altered) bindings in the fvf folder, you wouldn't have a problem. And if it would exec all the configs from the folder you changed to, it would all be set up automatically the next time you change to the gamedir.... Then that would make everything work consistently in the same manner no matter what method someone uses to select a gamedir: starting: "marv_v -game fvf" would behave identically (loading configs) to typing in the console: "game fvf" Wouldn't that consistency be better? If someone uses the game console command (i.e. "game travail" or such), they start out in id1.
Then switch to travail. Obviously, if you always start up in id1, you would want any changes to video resolution or setup to also apply to id1. Since id1 is the config run on startup, yeah, that's where it should save too! If someone uses -game whatever from the commandline or the Quake Injector, the config saves in game whatever just like you would expect.
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |