Index | FAQ | Search | Memberlist | Usergroups | Profile | Log in to check your private messages | Log in | Register

Half Life maps all black Goto page Previous 1, 2, 3 Next

| Inside3d Forums Forum Index -> Mapping

View previous topic :: View next topic
Author | Message
--- | ---
SamUK Joined: 17 Dec 2008 Posts: 98 Location: United Kingdom |

Posted: Sun Jul 04, 2010 9:13 pm Post subject: |

Doesn't he just have to swizzle the textures? Nevermind, not on the PSP -.- _________________ Working on Solitude

Back to top |

Baker Joined: 14 Mar 2006 Posts: 1538 |

Posted: Mon Jul 05, 2010 1:27 am Post subject: Re: Half Life maps all black |

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.
_________________
Tomorrow Never Dies. I feel this Tomorrow knocking on the door ...

Back to top |

Baker Joined: 14 Mar 2006 Posts: 1538 |

Posted: Mon Jul 05, 2010 1:40 am Post subject: |

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.
_________________
Tomorrow Never Dies. I feel this Tomorrow knocking on the door ...

Back to top |

Baker Joined: 14 Mar 2006 Posts: 1538 |

Posted: Mon Jul 05, 2010 1:44 am Post subject: |

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. _________________ Tomorrow Never Dies. I feel this Tomorrow knocking on the door ...

Back to top |

Ghost_Fang Joined: 12 Nov 2009 Posts: 162 |

Posted: Mon Jul 05, 2010 6:09 am Post subject: |

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?

Back to top |

Baker Joined: 14 Mar 2006 Posts: 1538 |

Posted: Mon Jul 05, 2010 10:55 am Post subject: |

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/source/browse/trunk/Classes/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
_________________
Tomorrow Never Dies. I feel this Tomorrow knocking on the door ...

Back to top |

Downsider Joined: 16 Sep 2008 Posts: 478 |

Posted: Mon Jul 05, 2010 2:51 pm Post subject: |

You should sit down and learn about OpenGL ES :O

Back to top |

frag.machine Joined: 25 Nov 2006 Posts: 728 |

Posted: Mon Jul 05, 2010 4:34 pm Post subject: |

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.
_________________
frag.machine - Q2K4 Project
http://fragmachine.quakedev.com/

Back to top |

Downsider Joined: 16 Sep 2008 Posts: 478 |

Posted: Mon Jul 05, 2010 4:50 pm Post subject: |

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.

Back to top |

Spike Joined: 05 Nov 2004 Posts: 944 Location: UK |

Posted: Mon Jul 05, 2010 5:33 pm Post subject: |

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. :)
_________________
What's a signature?

Back to top |

Downsider Joined: 16 Sep 2008 Posts: 478 |

Posted: Mon Jul 05, 2010 5:37 pm Post subject: |

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.

Back to top |

Spike Joined: 05 Nov 2004 Posts: 944 Location: UK |

Posted: Mon Jul 05, 2010 6:07 pm Post subject: |

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).
_________________
What's a signature?

Back to top |

Ghost_Fang Joined: 12 Nov 2009 Posts: 162 |

Posted: Mon Jul 05, 2010 6:39 pm Post subject: |

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?

Back to top |

frag.machine Joined: 25 Nov 2006 Posts: 728 |

Posted: Mon Jul 05, 2010 8:19 pm Post subject: |

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.
_________________
frag.machine - Q2K4 Project
http://fragmachine.quakedev.com/

Back to top |

Ghost_Fang Joined: 12 Nov 2009 Posts: 162 |

Posted: Mon Jul 05, 2010 8:41 pm Post subject: |

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.

Back to top |

Display posts from previous:

| Inside3d Forums Forum Index -> Mapping | All times are GMT Goto page Previous 1, 2, 3 Next
Page 2 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