that is 2x scaling

nice and simple. 

Well, I'm trying to set it to 960x540 on my 1920x1080 laptop lcd (so, exactly half-resolution).

I tried exactly that a few days ago with no luck :( I thought I was just doing something wrong, guess not... 

I'm trying to get a low-resolution display of the game blown up on the screen so I can see da pixels nice and chunky.

Anything in windowed mode isn't going to be blown up - unless I'm missing a trick here?

Also, I still kinda want it fullscreen and using the same aspect ratio as my monitor.... 

I always felt you had impeccable taste. 

 

might have more luck


-width 960 -height 540 -fullscreen quakespasm in linux just defaults to 720p with a black border 

also, i assume you've run vid_describemodes in the console? 

Uh, Run In Dosbox With Dosquake?

Nah, that sounds like a rubbish way to play QuakeSpasm. 

so install windows in dosbox then install and play quakespasm 

also, i assume you've run vid_describemodes in the console?

Yes, hence:

960x540 doesn't appear in the menu

Anyway, if my laptop just can't display 960x540, then I guess I'm out of luck. Stupid laptop. 

What kind of GPU is in the laptop? On this computer (Geforce 210) the Nvidia control panel seems to think it can set a custom resolution not supported by the monitor (LCD 27" 1920x1020"), but by default only lists the standard resolutions down to 800x600. I've never tried it though. 

 

This is my attempt at getting some of the things that annoy me about quakespasm resolved, as well as some stuff that I think people like Sock would want to use if they could.

http://triptohell.info/moodles/junk/quakespasm-spike-r1.zip
contents:
1 patch
1 readme
1 qsextensions.qc file
1 win32 binary (without deps)
some source files (without libraries)
1 copy of the gpl license...

Check the readme for the actual changes.
I'll probably update it a bit when people find all my bugs, or if someone I respect critisies me for not bothering adding something I was too lazy to bother with or didn't think of. Or other weasel phrases that get me out of any obligations both expressed or implied... 

Spike makes it sound boring. Has some very, very serious Kung Fu in the patch.

/Laughs are strlcat/strlcpy inclusion, I can't stand to see code that doesn't use those BSD originated functions. 

goddamn, just seeing QC file access stuff is almost enough to get me modding again. I haven't even read the rest of the readme! 

what is "bsp introspection"? 

@Kinn, posh words for DP_QC_GETSURFACE (which is handy for figuring out textures, or weird particle effects or whatever, I've used it to align csqc UIs to walls in the past, but meh). AD uses it to fix solid-sky issues with vanilla maps. smc uses it for figuring out footsteps, etc.

@Baker, strlcat+strlcpy were already in there. I just included ALL the .c+.h files from the 'Quake' subdir, because I'm lazy. I only two new .c files, but they're both bigger than any of quakespasm's existing c files...
check the patch for the actual changes, and good luck trying to isolate the parts that you're interested in. 

sprintf (ver, "QuakeSpasm %1.2f.%d"BUILD_SPECIAL_STR, (float)QUAKESPASM_VERSION, QUAKESPASM_VER_PATCH);

Spike adds the (float) type cast.
But in C, variadic parameters of float are converted to double.

/Just a jokey comment.

Misc Noticed #1 ...

#define TEDP_PARTICLERAIN 55 // [vector] min [vector] max [vector] dir [short] count [byte] color
#define TEDP_PARTICLESNOW 56 // [vector] min [vector] max [vector] dir [short] count [byte] color

Misc Noticed #2

===============
TexMgr_AlphaEdgeFix

eliminate pink edges on sprites, etc.
operates in place on 32bit data

spike -- small note that would be better to use premultiplied alpha to completely eliminate these skirts without the possibility of misbehaving.
===============

Misc Noticed #3

Spike does something with SZ_Clear and SZ_GetSpace, probably fixing a bug. Looks like buf->overflowed was set to true, then nuked. However, the buf->overflowed=false was removed in SZ_Clear and SZ_Clear is called all over the place. (Mistake?? Too engine rusty but looks like a possible mistake. And what bug was it fixing? I believe there is a bug it was trying to fix)

Misc #4

Looks like Spike made MAX_MTU work on packets (it never worked in Fitz 0.85) and then implemented something to allow multiple ones. (Wondering, is backwards compatible? I would guess no. And backwards compatibility probably shouldn't be important in this case.)

Misc #5

Yay!

#define NUMQUAKECOMMANDS (sizeof(quakebindnames)/sizeof(quakebindnames[0]))

I hate it when people don't do that, haha.

Misc #6

gl_model.c

"spike -- this is actually a pointless waste of memory.
//its not like this data will actually be used beyond this function in any gl renderer.
//this makes copying it pointless"

memcpy ( tx+1, mt+1, pixels);

@Spike: In Mark V, I use that data to allow real-time toggling on/off of external textures. And if I recall right, I use that data to quickly reupload textures if a video resolution change occurs that doesn't let GL context be reused without re-reading it from disk.

Misc Note #7

Some great comments in net_dgrm.c


-----

Anyways, it's all some very nice and incredible stuff in there! 

Spike - cheers - sounds very cool :)

oh wow the particle system sounds great :o 

Not everyone on func_ is a programmer/wizard/jesus... what's all the excitement about? 

There's a readme in the download. Kinn has rummaged through it.

I didn't reveal hardly any of huge surprises. 

@FifthElephant, sorry, I suck at explaining, so I left it kinda raw.

basically, there's:
1) a load of boring uninteresting stuff that mods might use. eg, you can imperfectly run smc (check the readme for the issues I know of). smc itself isn't the aim, but the lack of any extensions in fitzquake-derivatives is why we can't have nice things like string concatenation or traceboxes in the mods that really should be using them instead of crappy hacks.
2) some networking fixes/tweaks that if nothing else should make coop significantly easier to get going, just open a udp port, set your server as public, and people should be able to find you.
3) particle system that can be used by mappers to emit custom particles from surfaces based upon their texture names, like rain, snow, sparks, etc. I should give a proper example of this.
You can also use particle configs made for either fte or dp, just so long as they didn't use jpg or png textures, but that wasn't the real aim here, mostly for rain/snow/sparks/emittance/smoke vents/etc.
4) some other stuff. ramble ramble. modders blah blah. *continues to make uninteresting noises*
there's not really meant to be anything fundamentally new here (if there was then I'd have added it to FTE first, thereby making it not new). Really its just a version of quakespasm that tries to NOT be crippleware for modders, as well as fixing some networking/connectivity issues.
it still has no csqc nor replacement texture support. :P

The thought of people doing non-quakey things with the particle system is a worry, but hopefully the community and that continued lack of replacement textures will keep those people grounded somewhat.


@baker,
#2) alpha testing with a reference value of 0.666 will probably kill skirts well enough, but with linear sampling you get weird curved shapes to it. when blending, premultiplied alpha is much better, especially with mipmapping. I was trying to tread lightly and I'm lazy so I just left it as a comment rather than making any actual changes there.

#3) few things use allowoverflow, and thus few things can actually have the overflowed flag set. really its just unreliables, and those only check the overflowed flag when there is actual data inside them. that change just makes things a bit cleaner in that case.

#4) really I just reduced the mtu size of reliables back down to 1450, from 32000. nq always fragmented reliables, but it used the same value for reliables and unreliables. unreliables are still unfragmented and I didn't change any limits there, so there's nothing 'new' here. reliables now fragment much more frequently, this will have increased latency and made (non-local) load times worse, but should keep packet sizes below ethernet thresholds, preventing 100% packet loss and the inability to connect properly.
the protocol itself is identical, the receiver is in no way harmed by this change, but its still above 1024 and thus will still be an issue for vanilla clients.

#5) I have a countof macro in fte.

#6) I stopped copying the extra mips (because only fte would dare trying to use those in a gl renderer), but it still copies+preserves mip0 because of paranoia (I couldn't be arsed to read through the entirety of gl_texmgr.c to make sure it was safe).
And yes, I can be quite harsh with my wording even when I don't follow it myself, sometimes its just easier to not bother fixing it - I'd say it was nice to know what you could be fixing, but frankly its more a reminder of how many things you cba to fix... Lets just say that the comment was for a rainy day.

#7) well... I'm glad someone got something out of it at least. 

some stuff that I think people like Sock would want to use if they could
Wow this is just awesome, QS + DP/FTE particle effects! Spike you are coding genius! Really nice to see all my DP particles flying around! :D

So I manually load the effectinfo.txt file (with the QC you specify in the readme file) and AD starts to use the new effects. For some reason I am getting 'backup Past 0' constantly spammed to the console when I load a map. I tried out ad_test10 and I get the following visual issues. Not sure how to fix this, any clues? 

backup past 0 is a traceline/tracebox thing (I think I included a note about how the vanilla code was stupid, but didn't dare fixing it due to probable precission differences and resulting minor incompatibilities).
the particle system does quite a lot of traces against the world and brush entities, so I guess I ought to try to rewrite that, even it it ends up behind a cvar.
or maybe I should just make a specific version for the particle system, where precision doesn't matter so much.

the diagonal Os look like a REALLY big copy of the particle font... I have no idea what's going on there.
the lines in the middle are something else, and the bit on the left is utterly bizzare, I've no idea what they're from either.
Hurrah for making sure I retested everything!... or not!...
only things I can think of is a NAN (possibly from uninitialised memory, a degenerate triangle, or even qc (read: division by 0). note that this could also explain the 'backup past 0' spam).

also I suspect I broke weather effects by trying to get decals working, it might be related. shows how much I test things...
I'll be sure to test ad_test10 to see if I can reproduce it.

try setting r_particle_tracelimit to 0, that should stop it from spamming traces (which will also disable blood decals).

Sock, just so you know, I also snuck in a 'cl_recordingdemo' cvar which will contain the filename, use cvar_string to read it or something. :) 

the glitches appear to be from decals.
it doesn't seem to happen in debug builds, so its probably something that I left uninitialised somehow.
I don't get the 'backup past 0' spam.