No announcement yet.

Modifying Quakespasm to support large maps?

  • Filter
  • Time
  • Show
Clear All
new posts

  • Modifying Quakespasm to support large maps?

    Hello everyone.

    So, I have recently been working on a physics platforming game in quakespasm. One thing that I noticed after making a very large map was that quakespasm just kinda gave up after traveling far enough in the map, and this is obviously from map limits. This is extremely important in my game, as you are able to very quickly cover a lot of distance, I'm talking like 1000 units in one leap. This is obviously an issue, so how would I go about expanding the map limit in the engine?

    I know spike can help me out with this, since he made spiked-quakespasm, which has very large map support.

    I'm pretty sure this isn't going to be easy, so if you help me out, thanks in advance.

  • #2
    I assume you're using protocol 999? otherwise you're limited to +/- 4096.
    there may be some issues with subdividing skies. if you get those then just disable sky subdivision (I don't remember the cvar name) and use a skybox.
    beware of lightmap sizes. large surfaces = even larger lightmaps, expect problems if you've a large terrain-style map with massive walls.
    iirc the only other real limit is are bsp29's node bounds at +/-32767. compile it as bsp2 to bypass this issue in quakespasm.
    other than that all I can really say is to check your map in another engine (eg fte or dp) to see if they cut off at the same place too. if so, its probably the map compiler's fault.

    if you go far enough, you'll eventually find that floating point precision degrades too much, and everything gets a bit glitchy.
    Some Game Thing


    • #3
      Not sure what protocol 999 is, I'm not using your spiked-quakespasm. I am using 666, however.

      Okay, I'm using tyrutils to compile my maps, I'll try bsp2.

      Thankfully, my game doesn't use lighting, so lightmaps are nonexistent. Skyboxes aren't used at all as well. Pretty much all of the maps for my game are within an enclosed space, and sky textures are never used due to them not being there.

      BSP29's limits are huge, and they shouldn't pose a problem. I will test this in dp and see what happens.


      • #4
        So, dp isn't hindered whatsoever, so its not the map compiler, it's QuakeSpasm. I'll see if this 999 protocol is in the engine im using. I am using ericw's version of it on github here:


        • #5
          protocol 999 does work, so I guess that's cleared up then. I will change the default protocol. Thanks for helping me!


          • #6
            Just an alternative idea: if you're making your own game, you could re-reference everything in relation to the player. Example: lower his view offset, lower his movement speed, build the game world smaller and reduce texture scaling. If you reduce all of these by the same factor (say 50%) you will have a game that looks the same but uses half the space, doesn't get close to limits, and takes up less RAM.
            'Replacement Player Models' Project


            • #7
              I don't know, the game looks like shit as is anyway. Once there are more levels, I will think about posting it somewhere. Its also near the stage of being put onto github.