Overbrights do not render properly in super8

qbism Super8 is a gritty software-rendering 3D engine based on Makaqu and other GPL Quake source code.
Woolie Wool
Posts: 16
Joined: Sun Aug 30, 2015 12:17 am

Overbrights do not render properly in super8

Post by Woolie Wool » Sun Aug 30, 2015 12:26 am

I was playing through the first episode of Quake in DOS v1.06 (installed straight from an OEM CD I got with a joystick in 1998) and noticed the lighting in the DOS executable seemed more vibrant than in super8. I took a screenshot in v1.06 and then another in super8 and it seems like super8 does not render overbrights properly, perhaps not at all.

Image
Quake v1.06 for DOS. The lighting is stark and high-contrast.

Image
Qbism super8. The lighting is flat and subdued.

Image
Makaqu also displays overbrights correctly, which is strange because isn't super8's renderer based on Makaqu's?

I would definitely call this a bug. Do you think you can restore overbrights to the same intensity they have in the DOS executable?

Woolie Wool
Posts: 16
Joined: Sun Aug 30, 2015 12:17 am

Re: Overbrights do not render properly in super8

Post by Woolie Wool » Sun Aug 30, 2015 2:02 am

An additional problem I discovered is that the entire view is squashed when you have the classic status bar with background enabled. The view squashing problem did not happen in QbismS8 v140 (just tested) so it appeared at some point between then and now.

fixbot
Site Admin
Posts: 3
Joined: Sat Aug 01, 2015 1:19 am

Re: Overbrights do not render properly in super8

Post by fixbot » Mon Aug 31, 2015 1:16 pm

See comments on github- generally reset everthing, use latest version, delete old junk, some inconvenient design decisions. The overbrights issue is the one that I'm surprised about. Regarding view model clipping looks like 640x360 resolution?

Finally, if everything is 'clean', would you mind posting your config and the s8report?

Woolie Wool
Posts: 16
Joined: Sun Aug 30, 2015 12:17 am

Re: Overbrights do not render properly in super8

Post by Woolie Wool » Mon Aug 31, 2015 6:46 pm

My resolution is 1920x1080 in super8, 320x240 in 1.06, and 1280x720 in Makaqu. Those images I posted were imgur thumbnails.

Overbrights still do not render and the super shotgun still distorts even on a completely clean install. Gamma doesn't seem to affect overbright rendering--however, the s8pal palette can give the illusion of there being overbrights due to its high brightness and intensity . This illusion is immediately dispelled when you change r_palette to "palette" or "orig-pal" (which I would argue should be the default, and s8pal the option).

super8.cfg

Code: Select all

bind TAB +showscores
bind ENTER +jump
bind ESCAPE togglemenu
bind SPACE +jump
bind + sizeup
bind , +moveleft
bind - sizedown
bind . +moveright
bind / impulse 10
bind 0 impulse 0
bind 1 impulse 1
bind 2 impulse 2
bind 3 impulse 3
bind 4 impulse 4
bind 5 impulse 5
bind 6 impulse 6
bind 7 impulse 7
bind 8 impulse 8
bind = sizeup
bind B impulse 12
bind C +movedown
bind D +moveleft
bind E +moveup
bind F +back
bind G +moveright
bind R +forward
bind S +attack
bind T impulse 10
bind Y messagemode
bind \ +mlook
bind ^ toggleconsole
bind ` toggleconsole
bind a +moveleft
bind b impulse 12
bind c +movedown
bind d +moveright
bind e +moveup
bind f +back
bind g +moveright
bind j joymode
bind r +forward
bind s +back
bind t messagemode
bind w +forward
bind y messagemode
bind z +lookdown
bind ~ toggleconsole
bind UPARROW +forward
bind DOWNARROW +back
bind LEFTARROW +left
bind RIGHTARROW +right
bind ALT +strafe
bind CTRL +attack
bind SHIFT +speed
bind F1 help
bind F2 menu_save
bind F3 menu_load
bind F4 menu_options
bind F5 menu_multiplayer
bind F6 "echo Quicksaving...; wait; save quick"
bind F7 capture_start
bind F8 capture_stop
bind F9 "echo Quickloading...; wait; load quick"
bind F10 quit
bind F11 zoom_in
bind F12 screenshot
bind INS +klook
bind DEL +lookdown
bind PGDN +lookup
bind PGUP +lookup
bind END centerview
bind MOUSE1 +attack
bind MOUSE2 +forward
bind MOUSE3 +mlook
bind JOY1 +attack
bind JOY2 +j2
bind JOY3 impulse 10
bind JOY4 joymode
bind MWHEELUP impulse 10
bind MWHEELDOWN impulse 12
bind PAUSE pause
joystick 0
m_look 1
m_side 0.8
m_forward 1
m_yaw 0.022
m_pitch 0.022
cl_maxfps 60
sensitivity 5.500000
lookstrafe 0
lookspring 0
cl_vibration 0
cl_sidespeed 350
cl_backspeed 400.000000
cl_forwardspeed 400.000000
_cl_color 0
_cl_name player
crosshair_custom17 251
crosshair_custom16 244
crosshair_color 12
sbar 1
sbar_show_bg 0
sbar_scale 0.8
bgm_extmusic 1
cd_enabled 1
r_part_sticky_time 24
r_part_explo2_vel 300
r_part_explo2_time 0.3
r_part_explo2_count 200
r_part_explo1_vel 400
r_part_explo1_time 5
r_part_explo1_count 400
r_part_blob_vel 200
r_part_blob_time 0.2
r_part_blob_count 256
r_part_scale 1.0
r_shadowhacksize 2.7
r_skyfog 0.20
r_wateralpha 0.50
r_light_style 1
r_drawviewmodel 1
r_fog 1
r_coloredlights 1
capture_mp3_kbps 192
capture_mp3 0
capture_hack 0
capture_fps 30.0
capture_codec XVID
scr_fadecolor 4
viewsize 100
snd_stereo 1
snd_swapstereo 0
snd_mixahead 0.15
snd_bgmvolume 0.4
snd_sfxvolume 0.7
vid_nativeaspect 0.0
vid_windowed_mode 0
vid_fullscreen_mode 8
_windowed_mouse 1
vid_config_y 720
vid_config_x 1280
vid_default_mode_win 0
vid_wait 1
vid_mode 20
vid_ddraw 0
sv_imp12hack 0
sv_enable_use_button 0
sv_aim 1
sv_aim_h 1
sv_idealpitchscale 0.8
saved4 0
saved3 0
saved2 0
saved1 0
savedgamecfg 0
r_palette palette
chase_pitch 45
chase_yaw 180
chase_roll 0
chase_active 0
chase_right 0
chase_up 16
chase_back 100
r_fisheye 0
ffov 123
gamma 1
v_gunkick 1
cl_bobmodel_up 0.15
cl_bobmodel_side 0.3
cl_bobmodel_speed 7
cl_bobmodel 3
cl_bobup 0.5
cl_bobcycle 0.6
cl_bob 0.007
scr_ofsz 0
scr_ofsy 0
scr_ofsx 0
cl_nobob 0
crosshair 2
s8report.txt:

Code: Select all

>>>>>>>>>>> SUPER8 BUILD 236 DIAGNOSTICS REPORT <<<<<<<<<<<<
Time: 12:07:19 Jul 26 2015

Status: Normal exit.

>>>>> system information: 
  Operating system: Windows 7. Version number 6.1
  Processor architecture: Intel x86
  Processor revision: 1027
  Number of processors: 4
  Page size: 4096
  Processor type: 586

>>>>> graphics: 
  video mode: 2
  resolution: 1024 x 768 

>>>>> cvars that are different from super8 defaults: 
sensitivity[value] Sets mouse sensitivity.
Value: 5.500000   Default: 6   Saved in super8.cfg: yes

cl_backspeed[value] Maximum backwards speed.
Value: 400.000000   Default: 200   Saved in super8.cfg: yes

cl_forwardspeed[value] Maximum forward speed.
Value: 400.000000   Default: 400   Saved in super8.cfg: yes

Warning - do not set directly.
Value: 0   Default: 22   Saved in super8.cfg: yes

vid_fullscreen_mode[value]  Initial fullscreen mode.
Value: 8   Default: 4   Saved in super8.cfg: yes

vid_mode[value] Video mode.
Value: 2   Default: 4   Saved in super8.cfg: yes

sv_cheats[0/1] Toggles allow server cheats.
Value: 1   Default: 0   Saved in super8.cfg: no

hostname[name] Name of server.
Value: Godzilla   Default: UNNAMED   Saved in super8.cfg: no

pr_checkextension[0/1] Warning- set internally by the engine. Enable qc check for extensions.
Value: 99   Default: 0   Saved in super8.cfg: no

r_palette[name] Default palette.
Value: palette   Default: s8pal   Saved in super8.cfg: yes

cmdline[string] command line read by stuffcmds for dynamic mod loading.
Value:     Default: 0   Saved in super8.cfg: no

registered[0/1] 0 is shareware, 1 is full game version.
Value: 1   Default: 0   Saved in super8.cfg: no

gamma [value] Sets the darkness level. Lower values are brighter. Recommended range is 0.7 to 1.3.
Value: 1   Default: 0.95   Saved in super8.cfg: yes
I switched the resolution between 1920x1080 and 1024x768 and found that the SSG displayed the distortion at both resolutions so I did some experimenting. The view model offsets are incorrect by default. That's why, even with corrected vid_nativeaspect, they look "wide" compared to QuakeSpasm's. scr_ofsz 2.5 and scr_ofsx -4 make the weapon models look correct, and the SSG no longer distorts.

Woolie Wool
Posts: 16
Joined: Sun Aug 30, 2015 12:17 am

Re: Overbrights do not render properly in super8

Post by Woolie Wool » Tue Sep 01, 2015 12:02 am

"Agreed that the original Quake palette looks bad with this engine, which is why the s8pal was created."

That's a horrible excuse. If you can't render the game properly with the color set it was originally created with, why even bother making a software engine? You broke the lighting system (removing functionality that even the DOS version has, namely overbrights) and then you create a garish new palette to cover it up? No, that's not going to fly. The lighting system is broken. If it looks bad with the original palette, then it looks bad period because the game was designed for those colors, the entire reason why I would ever play with a software renderer at all is because of the original 256 color palette that Id Software created, that all of Quake's art was done in, that creates the grimy atmosphere that has drawn players to the software engine all these years, and then you say that "looks bad". No, the lighting "looks bad", because essential lighting functionality is broken in super8. Are you seriously saying you care so little about your own work that the Band-Aid solution of a distorted, oversaturated palette that I turned off the moment I loaded super8 for the first time is "good enough"? You're offering a software rendered engine. Your target audience is people who remember Quake as it came off the CD in 1996. Who want a stable, mature, limit-removing software port that can carry on that look, quite literally the way Quake was always meant to look because GL was an add-on made after the fact, and then add all the nice features of modern GL engines like water vis and colored lighting and fog and gigantic maps on top of that. But the foundation is the classic Quake atmosphere that would make people even want to use a software engine instead of QuakeSpasm. That's why ZDoom is so popular, it's why eDuke32 still has a software renderer (and people still use it), it's why people have kept asking for and using software rendered ports for games despite the massive inherent advantages of using a GPU. Because those 256 color palettes the old games were made in mean something, because there is artistic value in them as they are.

This target audience could be all yours. They have no alternatives--Engoo is unfinished and buggy, Makaqu has been discontinued, neither support modern editing features. All you have to do to get and keep this audience is to repair the parts of the renderer that have regressions.

User avatar
func_qbism
Posts: 76
Joined: Tue Aug 04, 2015 1:51 pm
Contact:

Re: Overbrights do not render properly in super8

Post by func_qbism » Tue Sep 01, 2015 2:09 am

A modern software renderer with faithful lighting would be great. This is intentionally lacking in the Super8 project, but it's not a case of false advertising. Realize lighting was altered, destroyed even, as a core feature of the engine years ago. Many screenshots and YouTube videos bear witness to the unfolding story. The name itself alludes to the inspiration. There's even a shader named after it: http://reshade.me/forum/general-discuss ... ade-super8

Thanks for posting the config and report above. I didn't see anything strange here. Although this helped reproduce the behaviours, the only true bug within the scope of the engine is the vertical squishing. Some further explanation is on github.

History- The engoo Quake engine introduced colored lighting in an accurate and flexible way. Super8 introduced a faster but more limited method... and also a bit different, which some have enjoyed. Plus it would have been boring just to copy the same thing. The colored lighting is immediately palettized from 24-bit color to 8-bit, which is fast but leaves little room for adjustment or subtlety after-the-fact. Over a few years engoo got faster, computers got faster, super8 got only a little faster but added features like big map support. Frankly the color limitations aren't worth any remaining speed difference for someone seeking faithful color, but it would be a major project to combine the best of the two engines (plus recent Makaqu developments) at this point.

The advantages of super8 color processing are still useful to older computers or DOS, there was an active DOS port on Vogons forum a few months ago. Also a few get into the palette bending or fisheye.

Rather than rebuild Q1, recent dev community effort was put into Q2 ref_soft. A much more satisfying engine, largely due to features like texture flags that make it easier for the renderer. Others have recently picked up this baton for both DOS and Windows including new colored lighting ASM(!) Again on Vogons.

The creator of Makaqu was building core engine and render improvements (with yet different goals than super8 or engoo) and perhaps may return to it.
Welcome to Rivendale, Mister Anderson.

Woolie Wool
Posts: 16
Joined: Sun Aug 30, 2015 12:17 am

Re: Overbrights do not render properly in super8

Post by Woolie Wool » Mon Sep 07, 2015 12:35 am

So are overbrights broken because you use some kind of GLQuake-like method to light everything in 24-bit color and then smash it down to 8-bit color in real-time? Doesn't that mean you could model overbright code after the way QuakeSpasm or FitzQuake Mark V does it?

As for the major project, I'm getting the developer of the ECWolf source port a copy of Visual C++ 6.0 so he can port Engoo to modern compilers. Then I'll probably have to find a new coder/maintainer since Blzut3 likely has too much on his hands (Zandronum, ECWolf, paid work for Google) to work with "Engoo++" after that and I can't code, but at the very least I hope to find a way to get Engoo to a state where the music works and the limits are raised (hell, if it's just "find the numbers for the limits and replace them with bigger numbers", I could even raise the limits myself if someone told me where to find the numbers).

Sorry to hear that our goals are just not aligned. It's hard being a fan of the original look nowadays, with the leading ports all being GL, WinQuake Mark V being capable of loading big maps like super8 but very incomplete and with no usability features like interface scaling, and Makaqu 1.4 being extremely crash-prone. If I knew C++ I'd be working on a fork of one of these engines right now, trying to bring together Engoo's graphics, super8's interface (your crosshairs are the best Quake crosshairs period--better than QuakeSpasm's and better than any QuakeWorld client's), and QuakeSpasm's stability.

Image
Image
Image
Honey in WinQuake Mark V. Unfortunately the status bar is not very useful at this resolution without scaling. The lack of fog extremely dark shadows combined with the intense overbrights make Honey very gloomy and unsettling in this renderer!

I did try Honey in Engoo--the hub level runs, but with serious rendering errors. The two main maps crash because they exceed Engoo's limits.

And just because this is all getting a little depressing, something fun! :D
[bbvideo=560,315]https://www.youtube.com/watch?v=N2a0jD4kze4[/bbvideo]

User avatar
func_qbism
Posts: 76
Joined: Tue Aug 04, 2015 1:51 pm
Contact:

Re: Overbrights do not render properly in super8

Post by func_qbism » Mon Sep 07, 2015 10:06 pm

Engoo and the Q2 ref_soft do it that way, compute in 24-bit and downsample, but Super8 does everything in 8-bits. Super8 reads the colored lighting data and converts each patch into a brightness byte (like regular uncolored Quake) and an indexed colored byte (which is nuts but very fast). I chose to pursue newer 'bigmaps' which have brighter lighting and usually fog, and the lighting formulas were constantly tweaked to optimize that combination. ''Honey' is the benchmark. Shots like this are very close the appearance in QuakeSpasm:
Image

I thought about a more faithful fork a few years ago and realized it would be a 'reboot'. The first step was http://super8.qbism.com/2011/09/bjp-enh ... index.html which should handle big maps up to the Marcher Fortress era (no fog IIRC). Really got zero feedback on it, and at the time there were 3 other faithful-ish projects going on- QuakeForge, Engoo, and Makaqu.
Welcome to Rivendale, Mister Anderson.

Woolie Wool
Posts: 16
Joined: Sun Aug 30, 2015 12:17 am

Re: Overbrights do not render properly in super8

Post by Woolie Wool » Mon Sep 07, 2015 10:27 pm

If you can provide me with Windows binaries I will be glad to try that fork (I also daresay you would have gotten more feedback if you had provided such binaries too!). If it works better than WinQuake Mark V I might end up using it fairly often.

I just don't see loading "big maps" and being faithful to the original renderer as mutually exclusive. Those Honey screenshots I made in WinQuake Mark V--what do you think of them? Obviously the shadows are a lot darker than QuakeSpasm (but that's mostly down to the lack of ambient light in DOS Quake/WinQuake) and the engine doesn't support fog but I like them. The sense of overwhelming darkness and morbid desolation is what draws me to Quake.

Actually I have a screenshot of that exact room, a bit further down the hall:

Image

Honey's start map in Engoo (the other maps crash it). The fog could use some work, I think software does better with lower fog densities than GL, one change I'd endorse for "Engoo++" would be an r_fogdensity cvar:

Image (large: http://www.ultraimg.com/images/QUAKE02.png)

A bit of fun--apparently since the first map of Honey is named "start", Engoo tries to load the original start map's lighting data for it if colored lights are turned on and the MH 2009 colored light pack for ID1 is installed, and gets confused.

User avatar
func_qbism
Posts: 76
Joined: Tue Aug 04, 2015 1:51 pm
Contact:

Re: Overbrights do not render properly in super8

Post by func_qbism » Tue Sep 08, 2015 1:10 pm

It's not packaged well... the exe is in the 'Release' folder!

Usually I'd prefer lighting to indicate depth rather than fog. Honey for example relies on the fog to give definition to shapes and to provide depth. That's OK, and clearly intentional, but without the fog we see that lighting is very basic and some detail lies in complete darkness. WinQuake Mark V does do a great job of picking up subtle lighting between almost-dark and totally dark.

Going back in time to around 2008 or 2010, we'd be in much better shape if magically the Q1 community all adopted the Q2 map format and backported it. Real built-in colored lighting and surface flags. Then we wouldn't have these protocol/ hack issues with colored lighting, transparent surfaces, and proper directory structure. But it's always been like herding cats.
Welcome to Rivendale, Mister Anderson.

Post Reply