Which version of SDL did you base this on? Metl and I were planning on waiting for SDL 3, because it has some useful new features.

The mouse thingy willem describes is a known issue. I had tried to fix it, but it didn't work. Don't imagine it to be too hard to fix though.

Keyboard mapping is difficult because you have to translate SDL key codes to Quake key codes. I intended to ditch Quake key codes and use SDL throughout, which would squash all those problems. 

I haven't read the small print but what is the difference between Protocol 15 and Protocol 666? 

Which version of SDL did you base this on?

I just updated your version exactly as-is. 

Increased a handful of limits from 255 to 65535 (models, sounds, ammo, frames), allowed for edict limits above 8192, added per-entity alpha support, added high-precision aiming, and added a timing hint for interpolating models that aren't animating at 10Hz. I think that's it. 

hey guys,

I just picked up Quake with FitzQuake and I'm LOVING IT. Newb question: how do I bind the keys for next/previous weapon?

thanks! 

SDL FitQuake-0.85 seems to run ok for me :>. Finally i can piss off Darkplaces again - god that thing is slow.
First impressions: like the redone status bar, and it's very smooth - but maybe i'm just a little blotto tonight.

Here's a hack to allow for switching between fullscreen/window modes (SDL version) using the ALT-ENTER key combo. It's bloody rough, and may not apply cleanly because of tabs/spacing so ping me if there's any probs. I might get the inspiration to polish it up now i have the 0.85 source, but in case i don't/can't:

-------------------start of patch
--- keys.c.orig 2009-04-13 11:58:08.000000000 +1000
+++ keys.c 2009-04-13 12:18:28.000000000 +1000
@@ -1023,17 +1023,27 @@
}

// johnfitz -- alt-enter to toggle fullscreen. FIXME -- this does NOT work
-#if 0
- if (!down && (key == K_ENTER) && keydown[K_ALT])
- {
- extern cvar_t vid_fullscreen;
+// stevenaaus -- but this hack (from sf.net/uhexen2) for SDLFitz works for me. SDL ;>
+
+ if (!down && (key == K_ENTER) && keydown[K_ALT]) {
+
+ extern SDL_Surface *draw_context;
+ extern cvar_t vid_fullscreen;
+
+ // VID_Restart ();
+
+ S_ClearBuffer ();
+
+ if ( SDL_WM_ToggleFullScreen(draw_context) > 0 )
+ {
if (vid_fullscreen.value)
- Cvar_Set ("vid_fullscreen", "0");
+ Cvar_Set ("vid_fullscreen", "0");
else
- Cvar_Set ("vid_fullscreen", "1");
- VID_Restart ();
+ Cvar_Set ("vid_fullscreen", "1");
+ } else {
+ Con_Printf ("SDL_WM_ToggleFullScreen failedn");
+ }
}
-#endif
// johnfitz

//
-------------------end of patch 

I get a segfault too when using the "game" command to change games and then loading a map. I made a debug client and there's two backtraces below. Looking at them, I then tried running with "-nosound" and it f-ing works!

Hmmm.... I tested fitzquake-0.80 on FreeBSD and the diagnosis is the same: it only segfaults with sound enabled. But testing on my laptop (with the same OS as my desktop, AC97 sound and ATI mobility radeon), there's no segfault at all. I'm a little confused here, but this may indicate it has to do with CPU optimisations or memory structure allignments (this box is a Core 2 Duo, laptop is a PIII), but can't see anything too unusual happening really. Making with gcc3.4 is no diff.

Gdb reports "Program terminated with signal 11", which from the signal manpage ("man 7 signal"), is:
Signal 11 is "SIGSEGV 11 Core Invalid memory reference"

# gdb fitzquake core
--------------------
Program terminated with signal 11, Segmentation fault.
#0 GetLittleLong () at snd_mem.c:186
186 val = val + (*(data_p+1)<<8);
(gdb) bt
#0 GetLittleLong () at snd_mem.c:186
#1 0x0807522f in FindNextChunk (name=0x809d487 "cue ") at snd_mem.c:206
#2 0x08075434 in GetWavinfo (name=0xaf485850 "dragon/sight2.wav",
wav=0xb7045498 "RIFF];", wavlength=15205) at snd_mem.c:296
#3 0x080757e1 in S_LoadSound (s=0xaf485850) at snd_mem.c:128
#4 0x0806bd05 in S_PrecacheSound (name=0xbff68fec "dragon/sight2.wav") at
snd_dma.c:346

and othertimes:

Program terminated with signal 11, Segmentation fault.
#0 0xb7effd16 in glGetIntegerv () from /usr/lib/libGL.so.1
(gdb) bt
#0 0xb7effd16 in glGetIntegerv () from /usr/lib/libGL.so.1
#1 0x0805f823 in Draw_BeginDisc () at gl_draw.c:691
#2 0x0808e9e6 in COM_LoadFile (path=0xb44541d4 "sound/ambience/wind2.wav",
usehunk=4)
at common.c:1649
#3 0x080757b1 in S_LoadSound (s=0xb50feb5c) at snd_mem.c:120
#4 0x0808440f in S_PaintChannels (endtime=139264) at snd_mix.c:189 

Welcome to fun!

Here's an example of the commands to change weapons. You can type them in the console or put them in your config files.

//cycle weapon forward
bind SHIFT "impulse 10"

//cycle weapon back
bind CTRL "impulse 12" 

Metl, any chance at CSQC support in a future Fitzquake?

It would pretty much be at the top of my wish list. I believe the full potential of client-side qc hasn't really started to sink in, but it should.

Anything that uses custom keys or items could benefit from a nice looking inventory (instead of microscopic status bar slots) and an equally nice looking HUD.

Not to mention moving sounds (example: rockets emitting sound in flight, sound following trains, monsters etc) and stuff like completely new HUD elements controlled from qc.

Not to even remotely mention the possibility of choosing a player model etc. via a CSQC menu. (I know that Quake only has one player model, but that will change.)

As far as I know the stuff works by having a clientside progs.dat as well as a server side one. 

As time permits, Spike has a prototype CSQC WinQuake he gave me to do a test integration with ProQuake.

I'm pretty good at working with Avirox (QuakeC CSQC and FTE lover) and over the coming time there may be a standardized NetQuake implementation of CSQC with great docs and a good tutorial for engine authors to use.

Without this, really no one can implement CSQC and there certainly needs to be a standard implementation so any engine author's engine behaves in an expected manner.

This will unfold. 

That sounds great. Much better than anything I would have hoped for! :-) 

I'm hoping that someday I will add support for this. Right now the standard needs to actually be finalized. I am also looking forward to example implementations or tutorials that might spring into existence in the future. 

At least not any time in the next few years... 

It has to be finalized to be mainstream. You try the line somewhere, accept the limits and write up the specs.

The secret to success is to finish, standardize, educate.

Commercial companies are good at this because things have to shipped.

You can always do more, but at some point in time you have to pull the cake out of the oven and call it a day ...

... knowing is it better than what you have today.

DarkPlaces and FTE have many features and yet so few mods because they are impressive science projects with some level of stability but never reach done.

And that's fine except no one can't write up specs and documentation.

Perhaps the best thing about FitzQuake 0.80 is it didn't have updates for nearly 4 years, drawing a new "standard" and giving everyone time to adjust.

(yes fog, skyboxes, enhanced limits, lits isn't the world but no one targets glquake as the main engine in single player any more. Probably largely due to Fitzquake 0.80) 

Perhaps the best thing about FitzQuake 0.80 is it didn't have updates for nearly 4 years

I hope that's not the best thing about it :P 

Haha ;)

Context, context, context ... 

but I agree, standards are important and if an engine implements something without a standard, that implementation can become a standard. It mostly depends on what content (maps/mods) actually use the feature.

I have tried to be cautious about adding crazy new features, and luckily most of the features I've added had a near-complete standard for how they worked (lit files, skybox, fog, external textures, .alpha, etc.)

When I do have to do my own thing (new protocol) I try to at least make it sane, and in the case of the protocol, I tried to add as much as possible in the first version to reduce the need to constantly make new protocol versions which only add one new feature.

Bumping limits is a stealthy way to set (or break) informal standards of course, and luckily aguirRe's engine has stabilized on which limits it bumps, and I was able to mostly bump all of those limits in a single release. 

hey, this is anon again..

don't know if this is a bug or just me being stupid BUT, upon completing all of the episodes/runes nothing happens. Specifically, I get back to "Introduction" and the last two episodes are locked (passed). The rest are open, even though I clearly remember them being locked upon completion. Also I only see 2 runes in the HUD.

Wazgoingon? 

You accidentally launched a new game after completing episode 2 and did not notice. 

You saved somewhere other than the start map. Which doesn't work too well... 

Old Mobility Radeon (gonna check the type later).
Driver: 6.14.10.6430

gl_clear 1 makes the game run ultra slow (think ~1 fps) in 32 bpp. In 16bpp it is slightly better (3-4fps I guess). 

No idea what type the chip is.
M6, 1002-4C59, 1028-00E3 (Dell Latitude something 610)

This is a new bug in 085. 080 works fine. 

The M6 Radeon is a mobile derivative of the Radeon 7000. Whatever the bug is, if it's on the Win32 driver side then it won't be fixed. I'd probably just keep gl_clear set to 0 until metlslime has had a chance to look at it. 

is this a bug specific to fitzquake 0.85 or do other fitzquakes (or glquake and derivatives) do it too? 

Fitzquake 085 only.

It seems related to how Fitzquake sets the resolution.

If I launch it with -width xxx -height xxx -bpp xx it works fine.
If I launch it normally, it does it's resolution change flicker and then runs so slow. I also noticed that the loading pentagram in the top right corner (always?) shows in funky colours then (like a normal map). Also a part on top of the display might flicker a bit.


PS: Setting a windowed mode with 16bpp when Windows is 32bpp is not fun. :P