Krabs

he/him
Sonic Team Junior
g o o d b y e
attachment.php

attachment.php

attachment.php


(I made this as a test to demonstrate how mapmakers can move away from the old style of thok barriers - ideally, the player would be prevented from actually jumping off the map using invisible barriers, but I thought it would be funny to release the thing as-is)
 

Attachments

  • srb20204.gif
    srb20204.gif
    1.8 MB · Views: 11,874
  • srb20203.gif
    srb20203.gif
    5.3 MB · Views: 11,869
  • srb20172.gif
    srb20172.gif
    7.2 MB · Views: 15,994
  • gfz1cursed v3.zip
    174.1 KB · Views: 1,038
This is SUPER funny!!! I actually got a really good laugh out of this. Weird variations on GFZ1 will forever be one of my favorite forms of humor. It has a good lesson to learn, too, about designing in ways other than the carving valleys into canyons mindset.
 
This is utterly bizarre and I'm deeply impressed by the lack of visual errors. The next stage would be filling in the empty spaces between the islands, but I don't know how much that would pain the renderer.
 
Man flying up with Tails and seeing the actual scope of GFZ1 is pretty cool. Wish there was a mod that could do this for every level :P
 
I'm deeply impressed by the lack of visual errors.

So this was a huge pain to do, but I'll do my best to explain everything that went into this map's creation

- Convert all caves into FOF caves, using vertex slopes to maintain the original geometry
- Raise ceiling of all thok barrier sectors
- Use a large sector that encases the level in a death pit with f_sky1 and horizon lines
- Add textures to the backside of the thok barriers

I think, after this, the next step would be to remove the death pits and try to find a visually-obvious way of signaling where invisible barriers would exist. I think this can be done by using palette textures for the top of the thok barriers to signal that "this part of the level is uninteresting and not a standard location", but I'm unsure. Performance is also an issue, I agree.
 
This is utterly bizarre and I'm deeply impressed by the lack of visual errors.
I'm trying to build a large, explorable stage for myself, so I went to check out this map for comparison. After doing my own research, I wanted to elaborate on how this map relates with SRB2's internal performance limits.

The traditional mantra of "13k+ view distance causes graphical errors" holds true here. In order to get a line of sight above 13k, you basically have to fly Tails out to the edge of the map extents (a large square) and turn to face the other corner. Most of the map -- especially the normally-accessible play space -- doesn't allow for 13k+ lines of sight.

When you give the renderer this much to handle, each rendering engine actually breaks differently.

Software will still draw the objects at 13k+ away, actually! However, the entire stage seems to wobble a little bit. (Maybe software wobbles normally, and I don't play Software most of the time, so I can't tell?) Also, there are definitely framerate issues here. I was playing this stage on a very powerful PC (I have my work desktop at home right now, because reasons), so the performance concerns must be integral to Software in a way that's not dependent on the hardware.

OpenGL doesn't get any performance issues, and it doesn't wobble. However, it simply stops drawing geometry at 13k+.

This is still a lovely proof of concept for an interesting idea, but I can't imagine this becoming commonplace. Most stages are bigger than GFZ1, and this feels like the size limit for the technique. GFZ2 in this style would be impractical. Maybe pumping a stage between open and closed (much like vanilla GFZ1 already does) would be an acceptable compromise between performance concerns and explorability.
 
OpenGL doesn't get any performance issues, and it doesn't wobble. However, it simply stops drawing geometry at 13k+.
So, following up on this, one of the recent patches to v2.2 fixed the OGL draw distance so that it clips the geometry at a predictable draw distance; it truncates stage geometry polygons at radial distance from the camera instead of unpredictably dropping polygons. I haven't measured what that distance is (yet), but it's a lot higher than what the "drop polygons" threshold used to be.

Note that the "draw distance" setting for OGL in your settings menu is just for Things (sprite/model-based obejcts), not for level geometry.
 
Last edited:

Who is viewing this thread (Total: 1, Members: 0, Guests: 1)

Back
Top