qbismSuper8 builds

[qbism]

Build 194 is up.

This fixes a save game bug related to filenames. Code was recently added to restrict file names and locations to prevent accidental or malicious code from server overwriting files. Savegames are restricted to “.sav” extension. Unfortunately I forgot that savegames were enumerated .S01, .S02, etc.

To preserve existing save games created by super8, rename them like this example:
QBS8____.S03 becomes QBS8_S03.sav

Thanks to 1path0gen1 for reporting the bug, and quakespasm file safety code via JoeQuake. Also thanks to Spirit for raising the issue in the "save pak0.pak" post.

[cubanraul]

Build 193 is up. It should be an improvement. I can still replicate this crash... but only at one resolution setting!

On my Phenom II x6 system I am getting crashes with 1152x864, 1280x720, and 1280x800 so far. Everything below 1024x768 is fine as well as 1280x768. Appear to be having the same result with the same resolutions on my Phenom II x4 system. Same result with watcom build.

EDIT: No issues with 1920x1080

[qbism]

I assume it's crashing with the default cvar value vid_ddraw 0. Does it crash with vid_ddraw 1? Must restart super8 for this setting to take effect.

Another bug was reported- models drawn behind skyboxes. Away from dev box at the moment. Possibly replaced one drawspan function too many with asm replacement (drawspans?)

[mankrip]

It occurs in both TDM-GCC and Watcom builds so it's not a compiler quirk. I've found that it happens even at a different initial r_wateralpha setting. The key is to change it before jumping in the water.

Maybe it's a problem with my translucent water code.

All versions of Makaqu since 1.4 were plagued by memory corruption, but I've checked all my changes exhaustively and couldn't figure out the source of the problem. Your engine is based on Makaqu 1.3, so, maybe the problem is in my previous code and we were just lucky that it didn't affect anything back then.

[cubanraul]

I assume it's crashing with the default cvar value vid_ddraw 0. Does it crash with vid_ddraw 1? Must restart super8 for this setting to take effect.

Another bug was reported- models drawn behind skyboxes. Away from dev box at the moment. Possibly replaced one drawspan function too many with asm replacement (drawspans?)

Yes, everything is perfect with vid_ddraw 1 as with build 190 and later. Would testing previous versions be of any benefit?

[qbism]

This may fix the skybox bug. Just the exe is in this 'beta':
http://super8.qbism.com/wp-content/uplo ... 95beta.zip

At some point yes, it will be good to look at an older build pre-crash and pre-threading. Sometimes so much has changed that it is still a needle in a haystack.

Cause of bug: in a zeal for type correctness of variables, depth buffer pointers were set to ‘unsigned’. However the depth buffer can be negative such as for skyboxes to simulate infinite distance.

[cubanraul]

With 'vid_ddraw 0' I am experiencing the crash as far back as build 166. I don't think I noticed it until more recent builds because I wasn't deleting my config between upgrades. So, I was left with the old default of "vid_ddraw 1".

Earlier builds from 140 through 162, with 'vid_ddraw 0', all crash upon load with the message "Insufficient free memory for Q_malloc"

With the current build and the beta I see a line in the water where the water isn't drawn. I see it both above and under the water: http://diphenhydra.mine.pt/line.png

[qbism]

This line is big clue. I notice it now on a resolution that crashes. If I change r_wateralpha it disappears and the crash does not occur, even if it's switched back to the original value. It also does not appear when vid_ddraw 1.

[qbism]

Maybe it's a problem with my translucent water code.

I think this is the cause, and waterwarp is just where it manifests. The culprit may be in stipplealpha code. Removing it worked on my machine. Another test build: http://super8.qbism.com/wp-content/uplo ... 96beta.zip

[cubanraul]

Wonderful! No issues at all on any resolution. With or without the stipple alpha option enabled the earlier builds had a strange distortion while under water. It looked like semi transparent rectangles scrolling horizontally. Almost resembles noise on an analog video signal. Didn't really think anything of it until it was suddenly gone. Anyway, all gone now and no more crashes.

[qbism]

so-called release build 197 is up. Fixed vid_nativeaspect cvar behavior, a manual override to auto-detect screen aspect ratio.

[Baker]

I have "fixed" stipple water code, when I get the opportunity I'll post it.

I changed it in a funny way --- I changed the way to generate the stipple to the (pointer address & 3 ) and only draw when values are 0 or 2.

(If you still have problems with the stipple water. There are so many posts in this thread, I can't be sure but I hear people say it still does ...)

Code: Select all

		if (*pz <= (izi >> 16))
		{
			sturb = ((r_turb_s + r_turb_turb[(r_turb_t>>16)&(CYCLE-1)])>>16)&63;
			tturb = ((r_turb_t + r_turb_turb[(r_turb_s>>16)&(CYCLE-1)])>>16)&63;
			
			temp = *(r_turb_pbase + (tturb<<6) + sturb);							
			temp2 = ((int)r_turb_pdest & 3);  // Take pointer address and get the last 2 bits.
			if (temp2 == 0 || temp2 == 2) // If the last 2 bits = 0 or 2, draw it, creates a stipple effect.
				*r_turb_pdest = *(r_turb_pbase + (tturb<<6) + sturb);
		}

[qbism]

Stipple was used for 50% wateralpha, but it was replaced with a true 50% alpha lookup table. It was also used for 25%, which now just kicks up to the 33% lookup table. If is is fixed and anyone actually prefers this look it could be added back. I wonder if it is even a noticable FPS increase except for DOS and Dreamcast.

The problem is that it has a strange artifact line + crashes with vid_ddraw 0 for some undiscovered reason.

Stipple remains in truth5678's DOS fork on Vogons. Might be interested in a faster version.

Start a new thread --> posting continues in both threads --> even more confusing

[qbism]

Map Jam 1 shots with build 212. New palette, honey.lmp http://super8.qbism.com/wp-content/uplo ... lettes.zip

[goldenboy]

I really like the palette thing.