8 bit bigmap Halloween special
-
- Posts: 268
- Joined: Tue Nov 24, 2009 2:20 am
- Contact:
-
- Posts: 268
- Joined: Tue Nov 24, 2009 2:20 am
- Contact:
Re: 8 bit bigmap Halloween special
When saving, there's an option to 'save state.' What exactly is this? I noticed that sometimes my saves don't seem to work properly if I don't also save and load the state when I save and load a game.
Get off my lawn!Ken Thompson wrote:One of my most productive days was throwing away 1000 lines of code.
Re: 8 bit bigmap Halloween special
"Save states" are Quake-style saves. "Save games" are console-style saves, like the saves in the Saturn or Nintendo 64 versions of Quake - they only save the information used for starting the map, so when you load them you'll be at the start of the level.
Re: 8 bit bigmap Halloween special
Thanks for clarification... and sorry, I was thinking "save setup" in the options menu, which I use frequently. I've always used typical binds F2 "menu_save" and F3 "menu_load" and was unfamiliar with the singleplayer menu selections.
Re: 8 bit bigmap Halloween special
Great to see a map like venividifuzi on this scale in normal Quake.
I often wondered what it would be without a gl engine, but in normal Quake it reaches max limit.
I usually play on 800x600 and I must admit it looks crispy in orginal 256 colours, as the skyboxes do.
Found some strange clipping errors on my last map, although it was extra vised.
Good work on the engine!
I often wondered what it would be without a gl engine, but in normal Quake it reaches max limit.
I usually play on 800x600 and I must admit it looks crispy in orginal 256 colours, as the skyboxes do.
Found some strange clipping errors on my last map, although it was extra vised.
Good work on the engine!
Re: 8 bit bigmap Halloween special
It's great to hear mappers enjoying this! To me it's like moving art or magic to see such large-scale projects rendered in a primitive un-smoothed way. gl_nearest comes close, but it's not quite the same...
Clipping issues result from limitations of the renderer rather than vis. One type occurs with map situations that would be discontinuous in the real world, such as entities or geometry behind sky. The vis tool can't hide all of these surfaces, but with hardware rendering, or standard scrolling Quake sky in software, the sky masks therm. Another problem looks like entities Z-fighting with walls when the distance is great. Z-buffer precision? I'm not sure. A third type that has been fixed AFAIK looked like gray rectangles that flickered briefly. I'm pretending that it's impossible or too computationally expensive to fix the other issues
Clipping issues result from limitations of the renderer rather than vis. One type occurs with map situations that would be discontinuous in the real world, such as entities or geometry behind sky. The vis tool can't hide all of these surfaces, but with hardware rendering, or standard scrolling Quake sky in software, the sky masks therm. Another problem looks like entities Z-fighting with walls when the distance is great. Z-buffer precision? I'm not sure. A third type that has been fixed AFAIK looked like gray rectangles that flickered briefly. I'm pretending that it's impossible or too computationally expensive to fix the other issues