qbismSuper8 builds

[mh]

Just looked at gcc syntax - yuck.

It's not worth the hassle for 1%.

[qbism]

Just looked at gcc syntax - yuck.

It's not worth the hassle for 1%.

The syntax would be appropriate for a Monty Python sketch about writing code. It's almost as pretty as php. But the asm could go into it's own separate assembly file .S
I'm using the latest gcc via mingw via Codeblocks Advanced which rocks with mmx optimization.

[mh]

Removed ASM. Not much speed improvement anymore, if any, with build optimized for at least Pentium/ MMX.

MMX is not appropriate for Quake, by the way. Spike hinted at this earlier, but the reasons why are:

MMX is an integer-only technology. No floating-point capability, which means it's screwed from the beginning as Quake is so heavily dependent on floating-point.

MMX operates on pairs of integers, so you need your integer data pre-arranged in a format that's suitable for this.

The MMX registers overlap with the floating-point registers; so long as a piece of code is using MMX it can't do any floating-point at all. Again, this breaks Quake.

There are some areas where it may be useful. The copy-to-backbuffer code in my vid_win replacement could be usefully accelerated with it, although SSE would be better again. The lightmap stuff could benefit - that's all integers too, but the performance gain is so marginal that it's dubious.

But in general terms, just forget about the idea of MMX-anything in Quake. Anything it could benefit is already plenty fast enough to begin with, and the downsides are just not worth it.

[qbism]

MMX is not appropriate for Quake, by the way.

I presume that refers to hand optimization in C or asm?

What I'm doing is compiler option -march=pentium2 which is advertised as adding mmx instruction set. What it's actually doing I don't know, but it is a speed improvement that does not contribute to bugs as far as I've observed. The only sacrifice is no 486 which really is going to require a DOS build anyway.

[mankrip]

Any luck porting features from Makaqu 1.5 to Super8?

[qbism]

Any luck porting features from Makaqu 1.5 to Super8?

I've pulled the blended drawspans functions to support transparent brushes. I didn't go "all-in" with the complexity of full alpha attribute support like 1.5 does. Instead, the intent is to support "func_glass" and similar to Pox's extras. That means I need a skip brush on either side of the glass. Often there's a clip brush over a window, anyway, so in that case the clip is replaced with skip. Requires skip processing step on bsp.

Glass and func_water are implemented in an alpha state, so I haven't really promoted it much. Glass appears to be working (transparent, solid, non-turbulent). I’ve noticed a vis glitch in one test but it wasn’t near the glass. Also need to test if it works on a func_train. Moveable water is working (func_water and func_water _train) but the demo from Pox’s extras would occasionally glitch water transparency. Hopefully will do a test map in near future.

I'll post a couple screenshots when I get a chance.

BTW, I've ripped a few things off 1.4 also including better particle calcs and LoadTGAas8bit. It's getting tougher to find easy stuff to steal as source code diverges... actually have to comprehend changes instead of direct cut-and-paste.

[qbism]

Pox made customized mapping tools for custents, which I've adapted to hmap2 (unreleased for now but see code in svn). Relatively minor changes. Seems to work so far. I couldn't find a good shot of it, but one drawback is that multiple layers of glass (transparent brushes) are not supported at the moment. A window behind a window just looks like a hole in the wall. Although, transparent entities and particles are still layered.

This first shot is confusing but it is a window looking out onto a rather ugly skybox.

[mankrip]

func_glass sounds like something that isn't supported in Makaqu 1.5. A test map would be useful indeed.

Porting all of Super8's improvements to Makaqu shouldn't be easy either, you've done a lot. Congrats.

[qbism]

func_glass sounds like something that isn't supported in Makaqu 1.5. A test map would be useful indeed.

Porting all of Super8's improvements to Makaqu shouldn't be easy either, you've done a lot. Congrats.

func_glass is may not be needed for Makaqu, which I think is supporting func_walls with alpha? Anyway it would be easy to implement. Also, I don't know if multiple layers of func_glass could be supported or not. But I thought it was worth a try since I was already looking at doing func_water.

Thanks! Super8 introduced only a few original features, most are lifted from other engines. Hopefully the code comments are good enough to track down the source if desired.

Thinking about Quake's reliance on floats, there is a floating point implementation: PocketQuake. The main limitation is 320 max screen res. Code ported to super8

Code: Select all

void D_DrawSpans16_FP (espan_t *pspan)  //qbism from PocketQuake
{
	int count, spancount, spancountminus1;
	unsigned char *pbase, *pdest;
	fixed16_t s, t;
	int zi, sdivz, tdivz, sstep, tstep;
	int snext, tnext;
	pbase = (unsigned char *)cacheblock;
	//Jacco Biker's fixed point conversion

	// Recalc fixed point values
	UpdateFixedPointVars16( 1 );
	do
	{
		pdest = (unsigned char *)((byte *)d_viewbuffer + (screenwidth * pspan->v) + pspan->u);

		// calculate the initial s/z, t/z, 1/z, s, and t and clamp
		sdivz = sdivzorig + pspan->v * sdivzstepv + pspan->u * sdivzstepu;
		tdivz = tdivzorig + pspan->v * tdivzstepv + pspan->u * tdivzstepu;
		zi = d_ziorigin_fxp + pspan->v * d_zistepv_fxp + pspan->u * d_zistepu_fxp;
		if (zi == 0) zi = 1;
		s = (((sdivz << 8) / zi) << 8) + sadjust;	// 5.27 / 13.19 = 24.8 >> 8 = 16.16
		if (s > bbextents) s = bbextents; else if (s < 0) s = 0;
		t = (((tdivz << 8) / zi) << 8) + tadjust;
		if (t > bbextentt) t = bbextentt; else if (t < 0) t = 0;

		//End Jacco Biker mod

      // Manoel Kasimier - begin
      count = pspan->count >> 4;
      spancount = pspan->count % 16;
      // Manoel Kasimier - end
//count = pspan->count;
		//	if (count >= 16)
			//	spancount = 16;
			//else
				//spancount = count;

      while (count-- >0) // Manoel Kasimier
      {
			// calculate s/z, t/z, zi->fixed s and t at far end of span,
			// calculate s and t steps across span by shifting
				sdivz += sdivzstepu_fix;
				tdivz += tdivzstepu_fix;
				zi += zistepu_fix;
				if (!zi) zi = 1;

				snext = (((sdivz<<8)/zi)<<8)+sadjust;
				if (snext > bbextents)
					snext = bbextents;
				else if (snext < 16)
					snext = 16;	// prevent round-off error on <0 steps from causing overstepping & running off the edge of the texture

				tnext = (((tdivz<<8)/zi)<<8) + tadjust;
				if (tnext > bbextentt)
					tnext = bbextentt;
				else if (tnext < 16)
					tnext = 16;	// guard against round-off error on <0 steps

				sstep = (snext - s) >> 4;
				tstep = (tnext - t) >> 4;

         pdest += 16;
         pdest[-16] = pbase[(s >> 16) + (t >> 16) * cachewidth]; s += sstep; t += tstep;
         pdest[-15] = pbase[(s >> 16) + (t >> 16) * cachewidth]; s += sstep; t += tstep;
         pdest[-14] = pbase[(s >> 16) + (t >> 16) * cachewidth]; s += sstep; t += tstep;
         pdest[-13] = pbase[(s >> 16) + (t >> 16) * cachewidth]; s += sstep; t += tstep;
         pdest[-12] = pbase[(s >> 16) + (t >> 16) * cachewidth]; s += sstep; t += tstep;
         pdest[-11] = pbase[(s >> 16) + (t >> 16) * cachewidth]; s += sstep; t += tstep;
         pdest[-10] = pbase[(s >> 16) + (t >> 16) * cachewidth]; s += sstep; t += tstep;
         pdest[ -9] = pbase[(s >> 16) + (t >> 16) * cachewidth]; s += sstep; t += tstep;
         pdest[ -8] = pbase[(s >> 16) + (t >> 16) * cachewidth]; s += sstep; t += tstep;
         pdest[ -7] = pbase[(s >> 16) + (t >> 16) * cachewidth]; s += sstep; t += tstep;
         pdest[ -6] = pbase[(s >> 16) + (t >> 16) * cachewidth]; s += sstep; t += tstep;
         pdest[ -5] = pbase[(s >> 16) + (t >> 16) * cachewidth]; s += sstep; t += tstep;
         pdest[ -4] = pbase[(s >> 16) + (t >> 16) * cachewidth]; s += sstep; t += tstep;
         pdest[ -3] = pbase[(s >> 16) + (t >> 16) * cachewidth]; s += sstep; t += tstep;
         pdest[ -2] = pbase[(s >> 16) + (t >> 16) * cachewidth]; s += sstep; t += tstep;
         pdest[ -1] = pbase[(s >> 16) + (t >> 16) * cachewidth]; s += sstep; t += tstep;
         // Manoel Kasimier - end

         s = snext;
         t = tnext;
         // Manoel Kasimier - begin
      }
      if (spancount > 0)
      {
         // Manoel Kasimier - end
			// calculate s/z, t/z, zi->fixed s and t at last pixel in span (so
			// can't step off polygon), clamp, calculate s and t steps across
			// span by division, biasing steps low so we don't run off the
			// texture

				spancountminus1 = spancount - 1;
				sdivz += sdivzstepu * spancountminus1;
				tdivz += tdivzstepu * spancountminus1;
				zi += d_zistepu_fxp * spancountminus1;
				//if (!zi) zi = 1;
				//z = zi;//(float)0x10000 / zi;	// prescale to 16.16 fixed-point
				snext = (((sdivz<<8) / zi)<<8) + sadjust;
				if (snext > bbextents)
					snext = bbextents;
				else if (snext < 16)
					snext = 16;	// prevent round-off error on <0 steps from causing overstepping & running off the edge of the texture

				tnext = (((tdivz<<8) / zi)<<8) + tadjust;
				if (tnext > bbextentt)
					tnext = bbextentt;
				else if (tnext < 16)
					tnext = 16;	// guard against round-off error on <0 steps

				if (spancount > 1)
				{
					sstep = ((snext - s)) / ((spancount - 1));
					tstep = ((tnext - t)) / ((spancount - 1));
				}


         pdest += spancount;
         switch (spancount)
         {
            case 16: pdest[-16] = pbase[(s >> 16) + (t >> 16) * cachewidth]; s += sstep; t += tstep;
            case 15: pdest[-15] = pbase[(s >> 16) + (t >> 16) * cachewidth]; s += sstep; t += tstep;
            case 14: pdest[-14] = pbase[(s >> 16) + (t >> 16) * cachewidth]; s += sstep; t += tstep;
            case 13: pdest[-13] = pbase[(s >> 16) + (t >> 16) * cachewidth]; s += sstep; t += tstep;
            case 12: pdest[-12] = pbase[(s >> 16) + (t >> 16) * cachewidth]; s += sstep; t += tstep;
            case 11: pdest[-11] = pbase[(s >> 16) + (t >> 16) * cachewidth]; s += sstep; t += tstep;
            case 10: pdest[-10] = pbase[(s >> 16) + (t >> 16) * cachewidth]; s += sstep; t += tstep;
            case  9: pdest[ -9] = pbase[(s >> 16) + (t >> 16) * cachewidth]; s += sstep; t += tstep;
            case  8: pdest[ -8] = pbase[(s >> 16) + (t >> 16) * cachewidth]; s += sstep; t += tstep;
            case  7: pdest[ -7] = pbase[(s >> 16) + (t >> 16) * cachewidth]; s += sstep; t += tstep;
            case  6: pdest[ -6] = pbase[(s >> 16) + (t >> 16) * cachewidth]; s += sstep; t += tstep;
            case  5: pdest[ -5] = pbase[(s >> 16) + (t >> 16) * cachewidth]; s += sstep; t += tstep;
            case  4: pdest[ -4] = pbase[(s >> 16) + (t >> 16) * cachewidth]; s += sstep; t += tstep;
            case  3: pdest[ -3] = pbase[(s >> 16) + (t >> 16) * cachewidth]; s += sstep; t += tstep;
            case  2: pdest[ -2] = pbase[(s >> 16) + (t >> 16) * cachewidth]; s += sstep; t += tstep;
            case  1: pdest[ -1] = pbase[(s >> 16) + (t >> 16) * cachewidth]; s += sstep; t += tstep;
            break;
         }

		}
	} while ((pspan = pspan->pnext) != NULL);
}

[mankrip]

Yes, Makaqu supports any BSP entities with .alpha translucency. But also supporting other methods to trigger BSP translucency would make the engine more compatible with already released maps.

For creating new maps, the current BSP translucency support in Makaqu seems good enough.

PocketQuake's source maybe could be useful for making a Dingoo A320 port, but my Dingoo got broken several months ago.

[qbism]

I was looking at PocketQuake because it ran at playable speeds on old pocketpc phones. These bricks are cheap on ebay and many have wifi, play youtube, and have nice slide-out keyboards. But the optimizing compiler was proprietary and at a certain point wasn't available online (or I guess for a price...) Another issue was that max memory is 64Mb on the model I had and the OS took a big chunk, so no big maps or that sort of thing.

[dreadlorde]

I've found some bugs with qbismS8 0109 (I'm on windows 7 sp1 x64). The bug where if the window is moved partially off screen it becomes stuck is back, in windowed mode I can't bind mouse buttons in 'customize controls' menu, my tv's native resolution (1300x768) also isn't listed in the video modes menu. I'll edit this post if I find anymore.

[qbism]

I've found some bugs with qbismS8 0109 (I'm on windows 7 sp1 x64). The bug where if the window is moved partially off screen it becomes stuck is back, in windowed mode I can't bind mouse buttons in 'customize controls' menu, my tv's native resolution (1300x768) also isn't listed in the video modes menu. I'll edit this post if I find anymore.

I've been looking into the stuck window bug, and tried improvement posted by Mankrip and Baker, but nothing has worked yet. It may be something outside the code. The next thing I will try is an older version and/or newer version of the compiler.
Is the native resolution of your laptop still detected correctly? (If you still have it, based on older post.)

[dreadlorde]

I've been looking into the stuck window bug, and tried improvement posted by Mankrip and Baker, but nothing has worked yet. It may be something outside the code. The next thing I will try is an older version and/or newer version of the compiler.
Is the native resolution of your laptop still detected correctly? (If you still have it, based on older post.)

I believe my laptop resolution is still detected correctly, i'll be able to check tonight to make sure.

edit: how can I checkout the source to qbism? `svn checkout svn://svn.code.sf.net/p/qbism/code/trunk qbism` returns `svn://svn.code.sf.net/p/qbism/code/trunk doesn't exist,` the same goes for http. Could you provide a zip of the source?

[qbism]

sourgeforge svn has some issues after their site upgrade. Try this:
EDIT: https://code.google.com/p/super8/