Half Life maps all black

SamUK · Post by **SamUK** » Sun Jul 04, 2010 9:13 pm

Doesn't he just have to swizzle the textures?

Nevermind, not on the PSP -.-

Baker · Post by **Baker** » Mon Jul 05, 2010 1:27 am

Ghost_Fang wrote:stock GLquake iphone port

Um?

Maybe I haven't been paying attention, but there is an iPhone GLQuake port *with source code*?

Anyways, the iPhone uses OpenGL ES and not regular OpenGL. There are some differences.

Maybe that is your problem.

Baker · Post by **Baker** » Mon Jul 05, 2010 1:40 am

I guess I haven't been paying attention...

I guess you posted this in another thread:

http://code.google.com/p/quake1-iphone/source/browse/

Well ... be sure to look at the changes marked "#ifdef ESQUAKE" as that is what the iPhone is going to be using.

When I have more time, I'll see if I can spot anything obvious in particular in what the GL_LoadTexture32 might need to do differently to work.

Baker · Post by **Baker** » Mon Jul 05, 2010 1:44 am

Eh? Well initially it looks like bad news ...

It is using GL_Upload8_EXT and PALETTE8_RGBA8 so it looks you've got a 256 color palette limitation in the port as-is.

Ghost_Fang · Post by **Ghost_Fang** » Mon Jul 05, 2010 6:09 am

would it be too difficult to change it so it doesnt have that limitation?
I see them, #ifdef ESQUAKE. Would i get some terrible results if i just got rid of them or replaced GL ES's texture load method with normal GL texture method?

Baker · Post by **Baker** » Mon Jul 05, 2010 10:55 am

Ghost_Fang wrote:would it be too difficult to change it so it doesnt have that limitation?
I see them, #ifdef ESQUAKE. Would i get some terrible results if i just got rid of them or replaced GL ES's texture load method with normal GL texture method?

No, because browsing through this ..

http://code.google.com/p/quake1-iphone/ ... EAGLView.m

It looks like it is requesting a 8-bit video mode (but it isn't quite clear to me where it is doing this).

Now what you could do is (in theory) is compare and contrast with the Quake 3 port to the iPhone and get it to set, say, a 32 bit video mode.

But then you are going to have mess with a lot of stuff in the iPhone GLQuake gl_draw.c to get it to channel the texture upload process through a 32-bit one.

I say this because I noticed the code is using a *GLOBAL* 256 color palette (it says this in comments) rather than a texture indicated 256 color palette.

Depending on whether or not you want to fight that fight, you might consider a custom 256 color palette and use Q1BSP. There *is* quite a bit you can do with 256 colors.

http://www.youtube.com/watch?v=JfIx7efqvf4

Downsider · Post by **Downsider** » Mon Jul 05, 2010 2:51 pm

You should sit down and learn about OpenGL ES

frag.machine · Post by **frag.machine** » Mon Jul 05, 2010 4:34 pm

Ghost_Fang wrote:would it be too difficult to change it so it doesnt have that limitation?
I see them, #ifdef ESQUAKE. Would i get some terrible results if i just got rid of them or replaced GL ES's texture load method with normal GL texture method?

I suspect that, if it's using such limited mode, there must be some hardware limitation.

Downsider · Post by **Downsider** » Mon Jul 05, 2010 4:50 pm

frag.machine wrote:
Ghost_Fang wrote:would it be too difficult to change it so it doesnt have that limitation?
I see them, #ifdef ESQUAKE. Would i get some terrible results if i just got rid of them or replaced GL ES's texture load method with normal GL texture method?
I suspect that, if it's using such limited mode, there must be some hardware limitation.

There's no global 8bbp palette limitation on the iPhone's OpenGL ES, silly.

Spike · Post by **Spike** » Mon Jul 05, 2010 5:33 pm

using regular textures instead of paletted textures will work, it'll just cost you 4 times as much memory.
the original glquake paletted textures is buggy.

I may be wrong on this, but GL_EXT_paletted_texture has a separate distinct palette for each texture, there are no shared palettes, you have to upload one for each texture.

WTF? that quake-iphone project uses glCompressedTexImage2D in GL_Upload8_EXT. That's... not right
It uses 5551 or 565 for quake-paletted images.
I suggest you do the same. :)

Downsider · Post by **Downsider** » Mon Jul 05, 2010 5:37 pm

Spike wrote:I may be wrong on this, but GL_EXT_paletted_texture has a separate distinct palette for each texture, there are no shared palettes, you have to upload one for each texture.

I was under this impression as well, and Google agrees with you and I.

Spike · Post by **Spike** » Mon Jul 05, 2010 6:07 pm

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).

Ghost_Fang · Post by **Ghost_Fang** » Mon Jul 05, 2010 6:39 pm

I apologize, but after reading all the posts many times, it is still unclear to me what needs to be done (it may be my lack of engine coding knowledge). Maybe there is an alternative to what i want? I did HLBSP for the individual texture palettes for each texture. Baker, when you said "you might consider a custom 256 color palette and use Q1BSP" did you mean make my own 256 color palette or modify Q1bsp so the textures can have their own palette? If making Q1bsp texture have their own palette is easier I'm all for it.
Like i said, im not any good with engine yet and you guys are naming off all these functions and stuff and telling me thats the problem and i have no idea what you guys are trying to tell me and then i look like im retarded or something.

So, recap. Now that some of you did some research, what is the problem and how would i fix it? Or whats my alternative?

frag.machine · Post by **frag.machine** » Mon Jul 05, 2010 8:19 pm

Ghost_Fang wrote:I apologize, but after reading all the posts many times, it is still unclear to me what needs to be done (it may be my lack of engine coding knowledge). Maybe there is an alternative to what i want? I did HLBSP for the individual texture palettes for each texture. Baker, when you said "you might consider a custom 256 color palette and use Q1BSP" did you mean make my own 256 color palette or modify Q1bsp so the textures can have their own palette? If making Q1bsp texture have their own palette is easier I'm all for it.
Like i said, im not any good with engine yet and you guys are naming off all these functions and stuff and telling me thats the problem and i have no idea what you guys are trying to tell me and then i look like im retarded or something.

So, recap. Now that some of you did some research, what is the problem and how would i fix it? Or whats my alternative?

I guess Baker suggested to you create a custom color palette and stick with the regular Q1BSP format, avoiding the hassle of implementing HL1BSP support. And I second that.

Ghost_Fang · Post by **Ghost_Fang** » Mon Jul 05, 2010 8:41 pm

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.

InsideQC Forums

Half Life maps all black

Re: Half Life maps all black