 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
I'm working on my quakespasm-irc engine thingy, and expanding it with more streamer-features.
One thing that I've been wanting to add are the joequake demo features. Rather than reinvent the wheel, and being that quakespasm and mark v share a bunch of code already, I was wondering if I could have a look at the mark v code to steal... uh, borrow from. GL_BGRA was really only ever significant as an Intel performance fix, and even then it also needed GL_UNSIGNED_INT_8_8_8_8_REV (which was probably the most annoying GLenum to type) in order to get the fix; without both it still ran slow.
Both NV and AMD also ran slower without these (with BGRA being by far the most important), but insignificantly so; Intel was catastrophically slower. This is trivially easy to benchmark. Just do a bunch of glTexSubImage calls in a loop and time them. Adjust parameters and compare. Both GL_BGRA and GL_UNSIGNED_thing are core since OpenGL 1.2, with the latter being adopted from GL_UNSIGNED_INT_8_8_8_8_EXT in the old GL_EXT_packed_pixels extension. So if you're targetting GL 1.2 you can quite safely use them without compatibility concerns. Since Microsoft did the world a favour by forcing the hardware vendors to standardise on RGBA in the D3D10 era, I don't believe that any of this stuff is even important for Intel any more. Basically if it's less than 10 years old it probably has good support for RGBA (if less than 5 make that definite) so you can really just use RGBA and no longer worry about this stuff. I obviously don't speak for mobile hardware, where the rules may be different, and anyway there are far more interesting formats such as RGB10A2 which lets you do a 4x overbright blend without sacrificing bits of precision and with only 2 unused bits per texel. I never formally benchmarked this format but tests ran well. What's more important about FitzQuake is that it uses GL_RGB for lightmap uploads. Even in the days of robust RGBA support, that's always going to force a format conversion in the driver. Combine that with hundreds of tiny updates (rather than few large ones) and FitzQuake can still chug down to single digit framerates even on some modern hardware. No amount of BGRA can fix that, and here's where I believe FitzQuake has done the community a disservice. There are lots of interesting things that mappers can do with dynamic lights and animated lightstyles, but because FitzQuake performed so poorly with them I suspect that much of that early potential was never realized. NV and AMD both suffer from this, but if all you ever benchmark is timedemo demo1 (or map dm3) with gl_flashblend 1 you'll probably never even notice. Intel suffers from this AND needs BGRA/UNSIGNED_etc. Again it's trivially easy to demonstrate the perf difference, but to robustly fix in the engine requires more reachitecting than I'm willing to do within the scope of my current work. If you look around in the Quaddicted engines directory, you can find older Mark V versions like this one where I marked things very cleanly
Current Mark V isn't structured like for many reasons including that the WinQuake software renderer has been combined into Mark V, but the source is on the Mark V page. ... how the hell did I not see the source link the first time I looked at that page...
just looking at host_cmd.c
maybe use an external file for the bad words array rather than a hardcoded one, that way it can be user updated Probably at some point I'll do that.
Thinking about host_cmd.c give command extra options give silverkey give goldkey give rune1 // rune1 to rune4 If you already have the gold key and wish to remove it, typing "give goldkey" will remove it if you already have it. Typing "give" in the console will display a list of item names. QMB effects: lava balls or knight spikes do not leave trails when traveling very fast (velocity 2000) when the server is at
The QMB trails work fine at Non-QMB particle trails do work under these conditions, but they tend to "skip" a bit. Most engines assume a distance traveled per update frame of 200 units or more is a teleportation.
That's my guess without looking at the code because 2000/10 (ticrate An entity that is assumed to have teleported won't be treated with any kind of continuous movement treatment. I saw on Quakeone, Dutch mentioned Mark V has "a difficult time playing external MP3" on his WinXP computer.
That's not very specific, but I wonder if he's seeing the same issue I reported, where there is a pretty significant delay loading the MP3s, during which time the game is completely frozen up. We tried LOTS of troubleshooting steps in the old thread, but nothing helped for me on my netbook (though the problem didn't exist on my older WinXP laptop). The only thing that made a difference in the end was me re-encoding the MP3s with certain settings that decreased the loading delay (from 17 seconds to 4.5 seconds!). I've noticed that with the latest Mark V, it doesn't carry over my video settings (from id1 config) when playing a mod.
Also some occasional flickering/corruption when using GL. I know it's not helpful just to say that so I'm experimenting a bit more to see if has anything to do with my latest NVidia driver update and/or if it happens in other engines. If there's anything you'd want me to do or try that would be helpful in debugging that, let me know. FWIW, latest qconsole.log is at https://dl.dropboxusercontent.com/u/11690738/temp/qconsole.log Hm. Upon startup, my autoexec.cfg sets up some aliases (or runs other cfg files that set up aliases).
But then if I am sitting on the server and I reconnect to the same server (by "connect fvf.servequake.com" -- I was toggling external lit files), many of my aliases are forgotten. But not all of them.... For example: alias zoom_out "chase_active 1;chase_mode 1" Is always forgotten upon reconnecting, but: alias start "changelevel start" is never forgotten. This is pretty inconvenient. It means I have to re-run my cfg files when I want to reconnect or connect to a different server without completely restarting Mark V. QMB effect difference: Particles in Quake are "fullbright" but the QMB blood effect is not fullbright.... So, in Quake you can always tell when you are hitting a monster in a dark area, but with the (more realistic) QMB blood, you can't tell.... Perhaps in this case it would be good to throw in a few standard red particles (even QMB particles are fullbright) in addition to the blood sprites (they are kind of sprites, aren't they?). But this will fall under QMB fine-tuning.... alias zoom_out "chase_active 1;chase_mode 1"
Cannot reproduce. I bound the above exact alias. Connected to a random server. Disconnected. The alias was there. Reconnected. Disconnected. The alias was there. Even connected to your server, disconnected, reconnected, changed the map, disconnect, reconnect, disconnect. The alias was still there. red fullbright blood - monsters in the dark Interesting difference. Although I haven't looked into it, I suspect QMB blood is already fullbright, it just isn't very bright. Something to think about. QMB blood types 1 and 2 have a blend mode of GL_ZERO, GL_ONE_MINUS_SRC_COLOR, so they're not lit, they're just blended with the background geometry.
Probably should change then. At least for the ones that aren't intended as true "ambience" and few of them are.
Ok... There's some weird interaction of FvF + my tricky aliases + Mark V
So in FvF, when a player connects, or when a map first loads, I do: stuffcmd(self, "re-exec\n"); Then I can set up stuff like this, in autoexec.cfg for example: --------------- alias fogon "fog 0.05; bind f8 fogoff; alias fogset fogon; echo Fog On" alias fogoff "fog 0; bind f8 fogon; alias fogset fogoff; echo Fog Off" alias re-exec "fogset" alias blah1 "echo blah1 is set" fogon alias blah2 "echo blah2 is set" ------------------ Yeah, I don't know how "correct" that is, but it works. It lets me toggle fog on and off with F8, and at each level change the automatic "re-exec" alias will run the "fogset" alias which will be assigned to either the "fogon" or "fogoff" alias, depending on which I last toggled with the F8 key.... But I think the problem is arising where I am assigning one alias to another alias like that ("alias fogset fogon" within the fogon alias...). So, as I said, usually all this works fine. Every level change the fog setting will be re-applied after the level starts, or upon first connecting to FvF. But if I am sitting on the server and I re-connect to the server, things go wrong, and ANY alias that was assigned AFTER the "fogon" command in the cfg above will be forgotten (so blah1 above will remain, but blah2 will be forgotten, as will any alias you have manually entered into the console). OHHH, I think I may get it... or part of it.... It seems to happen upon DISCONNECTING from the server. So this may be happening: - All aliases are set up before connecting. - Upon connecting, the server has you run "re-exec" by stuffcmd, which runs "fogset" which runs "fogon" which includes "alias fogset fogon" so now Mark V thinks it's a SERVER stuffed alias, so it discards it when you disconnect from the server....? Maybe? That still doesn't explain why ANY alias set after that point (either in your cfg file or manually by console) is also forgotten.... Let me see if I can trim this example down a bit more.... The above fog setting code is actually useful (to me anyway -- I don't just do this crazy stuff for no reason!), but here's just a proof of concept to show the issue I'm having: ----------- alias setblah "alias blah say blah" alias re-exec "setblah" alias blah1 "echo blah1 is set" setblah alias blah2 "echo blah2 is set" -------------- The odd thing is if you remove the manually running of "setblah" from the autoexec,cfg file above, then everything seems to work, and only the "blah" alias will be forgotten upon disconnecting. Blah2 will remain. Ah, but any alias you set AFTER connecting to the server will be discarded. But if that line is there, then every alias after that point will be forgotten upon disconnecting from the FvF server.... blah2 will be gone, as will any alias you set in the console after that point. That's weird, right? QMB Effects: I think I know why my splash effects are being destroyed so quickly... and also why my chat smoke looks a bit odd.
It seems that most QMB particle effects are quickly removed if they are touching a player. Try jumping up and shooting the floor below you with the shotguns. You will see that the particles vanish as soon as you come back down on them. Perhaps this is an attempt to prevent obscuring the player's view with too many particles right on top of him? Though the explosion effects are what's really bad at doing that, and this doesn't work for them! But yeah, that's messing with my splash effects, which are created at the player's location. QMB particle effects are quickly removed if they are touching a player
They are. In single player fire a rocket an even angle. Type "freezeall". Now with everything frozen except you Walk through the smoke, any smoke you walk through goes away. I've noticed that with the latest Mark V, it doesn't carry over my video settings (from id1 config) when playing a mod.
I used to have Mark V read those settings only from id1. Then someone said, I when "I play a mod, it ignores my settings I changed when I play it next". So I had to iterate through the proper Quake way. Which might describe what is happening in the above. To get it to be ideal (both!) would be bit involved, but I do have a plan for that in version 1.3, it's elegant and simple. It also involves some slight evil, but it's awesome kind people like and some other engine coder will say "Ah, that's ingenious." Story for another time ;-) my latest NVidia driver update Let me know. Is it new for the driver or new for the version of Mark V? They say NVidia's latest driver does flicker, but I'm not going to assume that it also couldn't be the engine's fault somehow in some rendering circumstances. None of the FitzQuake derived engines have a state manager. Which means there can easily be an errant situation where something crazy like a glBegin without a glEnd or two of them or such other possibilities exist. 1) If the problem persists or exists without the current driver 2) Or if a previous version of Mark V doesn't have issue 3) Or if a certain map 4) Or certain combination of options Short version is that at some point Mark V will have state manager, which would reduce the chances of the engine being at fault greatly (but a few other situations would still be possible). Let me know if it persists and if it happens with a certain map or a certain setting on. It happens to me too. It has started once I switched to geforce 1060 videocard. It happens in both old and new versions of mark v on any map. I hope it helps.
And there's one minor issue about mirrors. I want to make a small map about mirrors. I placed two mirrors on the opposite sides of the room (I know it's not the way it should be intended, but it looks soo cool), you can't see them both at a time, they reflect well, but one of them turns off once I stand close the other mirror (touching it with player's back). I supposed that the second mirror somehow got in the view (but it didn't) so I placed a clip brush in front of it, so I can't get close to it. But it happens the same way once I touch that clip brush. And it always happens with only one of two mirrors (the rooms are completely symmerical), while the first one works as it should when I touch it with player's back. I tried it in two different rooms and the problem always occurs with the south mirror. The problems disappears once I get 1 unit away from the wall. It seems that the flame cut-off system for the QMB particles doesn't work on replacement models. I'm using this pack and the flame polygons stay:
http://www.quaketastic.com/files/models/auth_mdl163.zip Another minor nitpick is that only the main Enter/Return key works in the menus, the numeric pad Enter doesn't. backbuffer.clear(depthandcolour);
for (i = 0; i < nummirrors; i++) { scene.addclipplane(mirror[i].surfaces.backplane); //ensures the mirror can only draw what is actually reflected, and not things that cross the mirror's plane. //fixme: set scissor region mirror[i].draw_reflectionof(scene); scene.killlastclipplane(); mirror[i].draw_diffusetransparent(); backbuffer.clear(depthonly); //anything in the real scene should not be obscured by the mirror for (j = 0; j <= i; j++) mirror[j].draw_onlydepth(); //mask the depth so nothing further within the real scene can overwrite. } //fixme: reset scissor scene.draw(); assuming I typoed it wright and you already know which mirrors you want to draw, the above algorithm should allow you to have cubes with mirrors on each face or whatever. if you can make the mirror-list calcs recursive like in FTE(r_portalrecursion > 1), then you can get mirrors reflecting other mirrors. Just beware that if one mirror can see two mirrors then any further recursion will likely be exponential (read: really slow). here's some obscure territory
Quake is originally designed for 320x200 resolution to be run on 4x3 displays (just like Doom). This means, that whole screen should be stretched vertically. The original game nicely adjusts viewport so that actual gameplay window is always at true aspect no matter what resolution is set - 320x200 will look exactly like 320x240. But the UI is not. It is designed to be stetched, so it only looks right on 320x200 and 640x400 resolutions and is "squished" on every other. So what's the problem? Mark V removed id's aspect corrcection and treat every resolution identically. Setting up 640x400 and 320x200 result in stretched in height gameplay window. The ideal solution would be to add an option to make correct UI scaling. Here's some example shots of original winquake and Mark V scaled to 4x3 and upscaled http://i.imgur.com/ZnPksXb.jpg http://i.imgur.com/mJLsJH5.jpg http://i.imgur.com/dWRoC5M.jpg http://i.imgur.com/fj0f4aI.jpg http://i.imgur.com/n8lznjF.png http://i.imgur.com/tmH5eHL.png http://imgur.com/a/jAW3U Right now, I treat Open GL and WinQuake identically (it's biased towards Open GL treatment).
From your screenshots I do see what you are saying. Thanks for providing screenshots. At some point like what Spike hinted at, I would like to improve the mirrors.
There are certain 3D calculations, reworked drawing, even tool support (.vis) and possibly some recursion that could make mirrors better. Blocking a mirror with a brush doesn't necessarily help because Quake map vis truly sucks and does a relatively poor job (play r_lockpvs 1 and walk around and be prepared for surprises). I'd like to put mirrors on 2 sides of a room too. Limits suck and you can hope for better in the future, but right now you can't have 2 mirrors that can see each other according to map vis. And it is worse than that, because in the current implementation there should not be a location where 2 mirror planes can be seen from anywhere in the map. That being said, it still gives plenty of freedom to do awesome stuff with mirrors --- even with current limitations.
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |