"Big Maps" FitzQuakeprotocol: [90/10 Non-Tutorial]

[Baker]

This is a 90/10 non-tutorial: it doesn't tell you what to do, but tells you where to look. It operates on the idea you have some sort of diff application like .



What This Does

Implements the FitzQuake protocol, which is the ability to run super huge maps like:

1. (2007)
2. (December 2009)
3. (December 2008)

And other giant maps like Laboratory X, Masque of the Red Death and some others I just can't recall.

This isn't going to work on memory impaired systems (PSP), slow systems (Flash), etc. It can work in software renderers but you may need to consult the source for "aguirRe Enhanced WinQuake" at: http://user.tninet.se/~xir870k/ to work out the specifics for a software renderer. aguirRe's Enhanced WinQuake can run all those maps too.

Sources Needed

1. FitzQuake 0.80 () - didn't have phat map support
2. FitzQuake 0.85 () - added the FitzQuake protocol to play giant maps

There are a lot of changes, they are all platform neutral and involve a lot of changed limits and #defines plus support for alpha and a couple of other fields.

You can read a discussion about the protocol by Metlslime (author of FitzQuake) here:

viewtopic.php?t=1799

And his documentation here:

http://quakery.quakedev.com/qwiki/index ... e_Protocol

Changed Files Relating To Protocol

1. cl_input.c (client writing the angles as a short)
2. cl_main.c (lerp flags, CL_ReadFromServer)
3. cl_parse.c (the client reads the bits, yada, yada, yada)
4. cl_tent.c (less spammy overflow messages, technically not required)
5. client.h (limits)

6. gl_model.c (limits higher on map load, etc)
7. gl_model.h (flags, clipnodes, limits)
8. gl_efrags.c (technically not necessary, warnings and messages)
9. gl_rmain.c (alpha and other new protocol flags support)
10. gl_rmisc.c (lerping stuffs)
11. render.h (flags, etc.)

12. common.c (MSG_Write, MSG_Read)
13. common.h ^^ that

14. host.c (technically not necessarily, msgs and so forth)
15. net.h (NET_MAXMESSAGE)
16. pr_cmds.c (protocol support)
17. pr_edict.c (alpha support)
18. progs.h (alpha and lerping)
19. protocol.h
20. quakedef.h
21. r_alias.c (interpolation and lerping)
22. r_brush.c
23. r_world.c (dynamic lights #define moved elsewhere and surely raised)
24. server.h (protocol and sign on buffer)
25. sv_main.c (protocol)
26. sv_phys.c (lerping)
27. sv_user.c (protocol + MSG_ReadAngle
28. world.c (clipnodes)

[Baker]

I'm in the process of implementing this in Engine X and I have to say that from top to bottom that the FitzQuake 0.85 protocol implementation is amongst the most well-written engine modifications as to the comments and clarity.

[mh]

[Baker]

As I am implementing this, I can't stop thinking about how impressed I am by Metlslime's code and comments.

And how "polished" and well-written it is. It was very carefully thought out and very cleanly implemented.

This is something that historically you would think would be majorly difficult to implement and understand, yet it is so clean as to both be easily understandable, to learn from and clean to implement.

[metlslime]

[Baker]

10 hours +/-

Implementation imperfect. But close.

If I was working with a more vanilla base, it'd be 6 hours or maybe even 3.5 hours. Had plenty of decisions to carefully make and had to occasionally consider what the implications of some of the changes were meant to be.

[Baker]

[goldenboy]

[Baker]

Whatever you guys do will be supported in my engine[s].

Adding to the post above: Engine X 4.61 source code: . All changes to support FitzQuake protocol encased in #ifdefs.

[andrewj]

[Baker]

Protocol 666 ...

And it's not just for hardware renderers any more!






But of course I added it to the ProQuake OpenGL/D3D/DX8 builds anyways ...

[qbism]

[Baker]

And not just for Windows any more

Well ... Quakespasm already runs on non-Windows platforms and uses 666 being a mod of FitzQuake.

Anywho ...

[Note: Nope not just OpenGL, ProQuake 4.66 is available in software renderer form for the Mac too.

[dreadlorde]

Did I just see software-rendered transparent water?

[Baker]

Yeah, courtesy of code from MK's engine.