Win32 Build
http://quakespasm.sourceforge.net/devel/quakespasm-r898.zip
Sorry, but i still havent tested that wheelmouse hack on windows (rev 884). It is still in subversion, but if it has nasties it should be removed.
Come winter maybe i'll get the chance to play through some of tronyn's pre-quakespasm mods, which only ever crawled along on my boxes with darkplaces.
Lol
#732 posted by Spirit on 2014/04/25 10:02:12
]save pak0.pak
Saving game to /home/me/.quakespasm/id1/pak0.pak...
and on the next start:
QUAKE ERROR: ./id1/pak0.pak is not a packfile
Please always append .sav to savegames if the user-supplied name does not already end in .sav
Wha?
#733 posted by ijed on 2014/04/25 10:21:06
Huh?
#734 posted by mfx logged out on 2014/04/25 10:33:14
#735 posted by Spirit on 2014/04/25 12:37:36
Imagine getting that stuffcmd'd from an evil server. :)
I guess it is an old original bug that most engines are vulnerable to.
Whoa...
#736 posted by szo on 2014/04/25 19:50:18
Never have thought such a way of shooting myself in the foot...
#737 posted by ericw on 2014/04/25 23:21:26
I posted a few patches on: https://sourceforge.net/p/quakespasm/patches/
The most substantial one is the brush model drawing rewrite to use the world drawing code. This should fix the problem necros mentioned in the screenshots thread, where large brush models kill fps. In the unreleased telefragged.bsp, the patch doubles my fps in one place, from 18 to 36. The downside is a divergence from the original fitzquake drawing code.
The other one that's interesting is the lightmap fix for mfx's map. It turns out the dimensions of the lightmap data for each surface are calculated via a fragile floating-point calculation (something like a dot product of vertex coords and texture coords). The engine and light compiler need to do the floating-point math exactly the same.. more so than C guarantees. If my understanding is correct, this affects all engines and all compilers. For anyone compiling a map compiler, make sure it's not using SSE2 floating point, which it probably is if you build a 64-bit executable!
Caution
#738 posted by metlslime on 2014/04/26 01:12:39
skip removal tools operate differently on brushmodels than world models, relying on the fact that engines draws them differently. If you don't traverse the Surfaces list on brushmodels, and instead use Marksurfaces, skipped polygons may end up getting drawn on brushmodels. Have you checked this in any maps with known skip textures on brushmodels?
Yep
#739 posted by ericw on 2014/04/26 01:38:38
thanks for the warning - I left the loop over the model's surfaces in R_DrawBrushModel the same as before (just replaced the call to R_DrawSequentialPoly with a new R_ChainSurface), so that still works correctly, and just verified it in a test map.
RE: Lol [the Save Issue]
#740 posted by szo on 2014/04/26 09:54:31
Fixed in the quakespasm svn repository as of rev. 902:
http://sourceforge.net/p/quakespasm/code/902/
Yeah - That Server Save Thing Is A Real Bomb
Thanks Eric. You're a great hacker.
I committed the new keyboard bindings.
*Sorry* - but have reversed your weapon cycle order. Be thankful i didnt bind jump to right mouse. Oz can change it back if he wants, and apply the complicated patches whatever.
QS Changes
Hmmm - we're going to put the new default.cfg and the custom background image into a separate pak i think , for the next release.
Might change the background image too if i can find a decent new one.. suggestions ? They have to be 8-bit.
Please No Unnecessary Stuff
#743 posted by negke on 2014/04/27 11:43:35
I'm much in favor of clean exe (and dll if required) releases. Additional files like paks or folders are clutter.
RE: Please No Unnecessary Stuff
#744 posted by szo on 2014/04/27 11:53:59
I'm much in favor of clean exe (and dll if required) releases. Additional files like paks or folders are clutter.
id1/quakespasm.pak is purely optional, not required for operation. The real clutter was the way we used to violate the engine for content customizations, and now not.
#745 posted by dwere on 2014/04/27 14:41:38
Was it really necessary to include that custom background image in the first place? I mean, it's nice and all, but still.
#746 posted by Joel B on 2014/04/27 17:08:22
FWIW: if an engine has custom content, I prefer that it squirrels it away in a custom directory, rather than id1. E.g. the approach used by super8, reQuiem, Qrack, ezQuake, etc.
#747 posted by Spike on 2014/04/27 20:20:20
including stuff like an id1/*.pak infects other engines (having to take care with numbering paks is stupid). we really don't want quakespasm branding etc in other engines because users are already stupid enough.
custom/private gamedirs are indeed the way to go if you're trying to push custom stuff for a specific engine.
#748 posted by szo on 2014/04/27 21:13:58
including stuff like an id1/*.pak infects other engines (having to take care with numbering paks is stupid). we really don't want quakespasm branding etc in other engines because users are already stupid enough.
custom/private gamedirs are indeed the way to go if you're trying to push custom stuff for a specific engine.
I see. How about not using any subdir for it at all and loading directly from com_basedir and/or com_userdir?
#749 posted by Spike on 2014/04/27 23:56:58
Append it to the end of the exe if you want to be fancy about it, like self extracting zips.
Shoving it in the basedir should be safe I guess, no worse than a dll.
Either way, you might need to come up with some cunning way to not break mod-specific (as opposed to engine-specific) conbacks etc, especially if its a tga. That's more of a general problem though. meh.
#750 posted by szo on 2014/04/28 00:50:10
Append it to the end of the exe if you want to be fancy about it, like self extracting zips.
We used to embed the pic by perversely violating the engine, and I managed to persuade Steve about using a pak, so no, I won't do that :)
Shoving it in the basedir should be safe I guess, no worse than a dll.
Yeah, easiest and non-infectious solution, IMO.
you might need to come up with some cunning way to not break mod-specific (as opposed to engine-specific) conbacks etc, especially if its a tga. That's more of a general problem though. meh.
The pak is loaded just and only after id1/pak0.pak, so any other mod with a customized conback or anything else are safe, those include the hipnotic and rogue mission packs.
Screenshot Made In Xubuntu
#751 posted by mfx logged out on 2014/04/28 07:01:59
Someone over at quaddicted reported this:
http://i.imgur.com/gvkld5W.jpg
RE: Screenshot Made In Xubuntu
#752 posted by szo on 2014/04/28 10:40:59
Seems that the issue happens with screen widths that aren't a multiple of 4. Fixed in the quakespasm svn repository at rev 909:
http://sourceforge.net/p/quakespasm/code/909/
Fix will be integrated in the next release, whenever that happens.
Sv_aim
#753 posted by ericw on 2014/04/28 19:38:44
Would it make sense to change the default sv_aim value to 1 in Quakespasm (to disable aim-assist)?
and maybe make it CVAR_ARCHIVE since most of the other control preferences are saved too?
#754 posted by negke on 2014/04/28 23:42:28
Maybe something along the lines of "if mouselook=on -> autoaim=off".
Yes
#755 posted by ijed on 2014/04/28 23:44:39
Autoaim sucks.
|