Inside3D!
     

Half Life maps all black
Goto page Previous  1, 2, 3
 
Post new topic   Reply to topic    Inside3d Forums Forum Index -> Mapping
View previous topic :: View next topic  
Author Message
Dr. Shadowborg
Inside3D Staff


Joined: 16 Oct 2004
Posts: 726

PostPosted: Mon Jul 05, 2010 10:37 pm    Post subject: Reply with quote

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)
_________________
"Roboto suggests Plasma Bazooka."
Back to top
View user's profile Send private message
Baker



Joined: 14 Mar 2006
Posts: 1538

PostPosted: Tue Jul 06, 2010 3:08 am    Post subject: Reply with quote

Spike wrote:
http://www.khronos.org/registry/gles/extensions/OES/OES_compressed_paletted_texture.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:
        eaglLayer.drawableProperties = [NSDictionary dictionaryWithObjectsAndKeys:
                                        [NSNumber numberWithBool:NO], kEAGLDrawablePropertyRetainedBacking,
                                                                                //kEAGLColorFormatRGBA8, kEAGLDrawablePropertyColorFormat,
                                                                                kEAGLColorFormatRGB565, kEAGLDrawablePropertyColorFormat,
                                                                                nil];


Spike wrote:
http://www.khronos.org/registry/gles/extensions/OES/OES_compressed_paletted_texture.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:

/*
===============
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.
_________________
Tomorrow Never Dies. I feel this Tomorrow knocking on the door ...
Back to top
View user's profile Send private message
Baker



Joined: 14 Mar 2006
Posts: 1538

PostPosted: Tue Jul 06, 2010 4:06 am    Post subject: Reply with quote

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:
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.
_________________
Tomorrow Never Dies. I feel this Tomorrow knocking on the door ...
Back to top
View user's profile Send private message
Downsider



Joined: 16 Sep 2008
Posts: 478

PostPosted: Tue Jul 06, 2010 4:06 am    Post subject: Reply with quote

My PSP engine renders in 16-bit, it's faster, less RAM usage for the screen, and the difference in visual quality is negligible.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    Inside3d Forums Forum Index -> Mapping All times are GMT
Goto page Previous  1, 2, 3
Page 3 of 3

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2004 phpBB Group