Half Life maps all black

Discuss the construction of maps and the tools to create maps for 3D games.
Dr. Shadowborg
InsideQC Staff
Posts: 1120
Joined: Sat Oct 16, 2004 3:34 pm

Post by Dr. Shadowborg »

Ghost_Fang wrote:I do agree that would be the easiest. But instead of HLBSP support, why not just Q1BSP with the textures having their own pallette, or is that basically the same thing? Cause thats all i was aiming for was the richer colors you get out of maps.
That is the same thing.

If what I gather is correct, the problem is that your Quake Port can only use an 8bit video mode, which means that it can only display a maximum of 256 colors on screen at any given time. (meaning, HL1BSP can and WILL break for obvious reasons)

To do what you want to do, you need to have your quake port use a video mode that supports 32bit. (and hence, millions of colors)

Alternately, do what Baker and frag.machine have suggested and just make a custom 256 colormap and stay within the confines of that colormap. (compared to the 32bit route, this will be easier because you don't need to do anything with the engine, just stay within the confines of 256 colors)
Baker
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am

Post by Baker »

Spike wrote:http://www.khronos.org/registry/gles/ex ... exture.txt
aha, that's what the GL_Upload8_EXT thing is about.
internalformat = PALETTE8_RGB8_OES
data = palette,mip0,mip1,etc, concatinated without padding
level = (numberofmiplevels-1) * -1 (or 0 if you cba generating mips)

the issue with mip levels will probably result in it looking horrible though, its not really convienient to generate 8bit mips on the fly.

So yeah, just use 565/5551 for your halflife textures (see GL_Upload16).
I have a bit of time right now and I'm looking at this some more.

It looks like I am _wrong_ and it isn't setting an 8-bit "video mode" but rather a 16-bit one. The problem still effectively persists, but setting the color depth is no longer something that has to be addressed.

Code: Select all

        eaglLayer.drawableProperties = [NSDictionary dictionaryWithObjectsAndKeys:
                                        [NSNumber numberWithBool:NO], kEAGLDrawablePropertyRetainedBacking,
                                                                                //kEAGLColorFormatRGBA8, kEAGLDrawablePropertyColorFormat,
                                                                                kEAGLColorFormatRGB565, kEAGLDrawablePropertyColorFormat,
                                                                                nil];
Spike wrote:http://www.khronos.org/registry/gles/ex ... exture.txt
aha, that's what the GL_Upload8_EXT thing is about.
internalformat = PALETTE8_RGB8_OES
data = palette,mip0,mip1,etc, concatinated without padding
level = (numberofmiplevels-1) * -1 (or 0 if you cba generating mips)

the issue with mip levels will probably result in it looking horrible though, its not really convienient to generate 8bit mips on the fly.

So yeah, just use 565/5551 for your halflife textures (see GL_Upload16).
And more good news ...

Code: Select all

/*
===============
GL_Upload8
===============
*/
void GL_Upload8 (byte *data, int width, int height,  qboolean mipmap, qboolean alpha)
{
        //static        unsigned        trans[640*480];         // FIXME, temporary
        int                     i;
        qboolean        noalpha;
        int                     p;

        int s = width*height;
        GLubyte trans[s];
        
        // if there are no transparent pixels, make it a 3 component
        // texture even if it was specified as otherwise
        if (alpha)
        {
                noalpha = true;
                for (i=0 ; i<s ; i++)
                {
                        p = data[i];
                        if (p == 255)
                                noalpha = false;
                        //trans[i] = d_8to24table[p];
                }

                if (alpha && noalpha)
                        alpha = false;
        }
        else
        {
                if (s&3)
                        Sys_Error ("GL_Upload8: s&3");
                /*for (i=0 ; i<s ; i+=4)
                {
                        trans[i] = d_8to24table[data[i]];
                        trans[i+1] = d_8to24table[data[i+1]];
                        trans[i+2] = d_8to24table[data[i+2]];
                        trans[i+3] = d_8to24table[data[i+3]];
                }*/
        }
        
        GLint scaled_width;
        GLint scaled_height;
        for (scaled_width = 1 ; scaled_width < width ; scaled_width<<=1)
                ;
        for (scaled_height = 1 ; scaled_height < height ; scaled_height<<=1)
                ;
        
        //scaled_width >>= (int)gl_picmip.value;  // don't allow scale-up option
        //scaled_height >>= (int)gl_picmip.value;
        
        if (scaled_width > gl_max_size.value)
                scaled_width = gl_max_size.value;
        if (scaled_height > gl_max_size.value)
                scaled_height = gl_max_size.value;
                        
        if (scaled_width != width || scaled_height != height)
        {
                scaled_width >>= 1;
                scaled_height >>= 1;
                GL_Resample8BitTexture (data, width, height, trans, scaled_width, scaled_height);
                data = trans;
        }
        
        GL_Upload16(data, alpha, scaled_width, scaled_height);

        /*if (VID_Is8bit() && !alpha && (data!=scrap_texels[0])) {
                GL_Upload8_EXT (data, width, height, mipmap, alpha);
                return;
        }
        GL_Upload32 (trans, width, height, mipmap, alpha);*/
}
There is the GL_Upload16 that appears to be active.

So ... get your hands dirty and rewire the part of the HLBSP tutorial that uses GL_Upload32 and rewire it to use GL_Upload16 and you have an "ok" shot at doing this yourself.

There will be some dirty work, offhand I'm not sure how you convert 24-bit color to 16-bit color in an image ... one way would probably be to build a d_24to16table or more likely start Googling away.

The RGB565 in the 16 color mode means that there are 5 bits for red, 6 bits for green and 5 bits for blue. A 24-bit color palette uses 8 bits for red and 8 bits for green and 8 bits for blue.

Googling around, I'm sure you can find established code to this common conversion.

Maybe more work than what you'd like to do, hell there might be an easier way I'm not thinking of.

Still ... the fun of walking down the unbeaten path ... you have to plan to clear some brush out of your way because you are the first guy walking down that path.

You could also experiment and try to enable GL_Upload32 ... but since that isn't used in the port, the code can't be relied upon to work for certain without modification and it might be a no-go for some reason related to the platform.
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
Baker
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am

Post by Baker »

More information for you ...

RGB888 (24 bit color where red, green and blue have 8 bits of information in 3 bytes where byte 1 = red, byte 2 = green, byte 3 = blue) to RGB565 (16-bit color 5 bits for red, 6 bits for green, 5 for blue) ...

Code: Select all

NewR = R >> 3;
NewG = G >> 2;
NewB = B >> 3;
I figure this is slightly out of your zone of comfort, but I'll aggregating some raw information for you.
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
Downsider
Posts: 621
Joined: Tue Sep 16, 2008 1:35 am

Post by Downsider »

My PSP engine renders in 16-bit, it's faster, less RAM usage for the screen, and the difference in visual quality is negligible.
Post Reply