InsideQC Forums

Downsider wrote:

ceriux wrote:i probably dont know what im talking about , but have you tried making them sample down ?

The main problem is that I have to store the palette somewhere and I'm not sure how exactly I should go about doing that, and when it needs to be loaded, but most importantly, when to revert to the original Quake palette.

but the thing is the pallets are already stored into the texture when you make the wad file (if im actually right, which im pretty sure i am.) my best suggestion would be to stick to the quake bsp format and build a custom pallet for your maps and base the maps around it and only use pcx or tgas when they're absolutely needed. i dont think theres any solution to your problem because the pallet your trying to store some where im pretty sure is stored with in the texture its self.

edit: or if its possible why not just make a pallet for each map the similar to how quake has 1 pallet for the entire game. but have the pallet change upon loading your maps? if thats at all doable.

No.. The idea is to:

1) When loading the texture, return the paletted data instead of thr unpaletted data. (1 byte per pixel)
2) Store the palette in miptex_t.
3) Modify GL_loadTexture to take a palette as a parameter.
4) Use GL_loadTexture instead of GL_loadTexture32.
5) Store the palette in texture_s.
6) Load the palette if it exists in GL_Bind.

Should work, but I'm pretty sure the palette has to be converted into a different format for it to be used by OpenGL, and I don't know how to convert it.

Unless your OpenGL implementation supports uploading textures directly from a palleted format then you're just going to have to upsample to 32 bit I'm afraid. The documentation for any palleted format you can upload in should be sufficient to deduce conversion steps from.

mh wrote:Unless your OpenGL implementation supports uploading textures directly from a palleted format then you're just going to have to upsample to 32 bit I'm afraid. The documentation for any palleted format you can upload in should be sufficient to deduce conversion steps from.

Format is GU_PSM_T8, it's on the PSP, and there's sufficient information on it, but I don't know about how Half-Life's palette is stored. I know how the end product should look, and the steps in the middle, but nothing about the ingredients themselves

From looking at the code in the first post is just the same as Quake's palette; 768 bytes laid out RGBRGBRGB etc with palette index 255 being translucent for some textures (depending on the name). You'll probably need to expand this to 1024 bytes with an RGBARGBARGBA layout but this should be utterly trivial to code (look at VID_SetPalette in classic GLQuake for a similar way of translating any input palette to this format and layout).

mh wrote:From looking at the code in the first post is just the same as Quake's palette; 768 bytes laid out RGBRGBRGB etc with palette index 255 being translucent for some textures (depending on the name). You'll probably need to expand this to 1024 bytes with an RGBARGBARGBA layout but this should be utterly trivial to code (look at VID_SetPalette in classic GLQuake for a similar way of translating any input palette to this format and layout).

Thanks, this is exactly what I neded to know

Downsider wrote:

mh wrote:Unless your OpenGL implementation supports uploading textures directly from a palleted format then you're just going to have to upsample to 32 bit I'm afraid. The documentation for any palleted format you can upload in should be sufficient to deduce conversion steps from.

Format is GU_PSM_T8, it's on the PSP, and there's sufficient information on it, but I don't know about how Half-Life's palette is stored. I know how the end product should look, and the steps in the middle, but nothing about the ingredients themselves

Downsider, do you have a link to information on the PSP graphics API?

I have a PSP 1000 series now (need to order a Pandora battery, don't have that yet) ... and since I can compile for the PSP now, odds are strong that I will be writing some PSP engine tutorials.

eriux, this looks awesome! I'm glad to see someone is taking advantage of the hl bsp support by making a map exclusively Quake!

Baker wrote:

Downsider wrote:

mh wrote:Unless your OpenGL implementation supports uploading textures directly from a palleted format then you're just going to have to upsample to 32 bit I'm afraid. The documentation for any palleted format you can upload in should be sufficient to deduce conversion steps from.

Format is GU_PSM_T8, it's on the PSP, and there's sufficient information on it, but I don't know about how Half-Life's palette is stored. I know how the end product should look, and the steps in the middle, but nothing about the ingredients themselves

Downsider, do you have a link to information on the PSP graphics API?

I have a PSP 1000 series now (need to order a Pandora battery, don't have that yet) ... and since I can compile for the PSP now, odds are strong that I will be writing some PSP engine tutorials.

Overall it's very similar to OpenGL, really. Documentation is abundant compared to other platforms that can run homebrew (Couldn't find shit when I was dabbling in Rockbox apps for the Sansa).

http://www.ghoti.nl/PSPtutorial1.php - Setting up the PSP SDK and doing some stuff few with the PSP GU.

http://www.psp-programming.com/forums/i ... 24.msg7214 - First 10 or so of Nehe's OpenGL gamedev tutorials ported to the PSP.

There's a bunch of samples in the PSP SDK's folder once you install it, and the header file for the lib has a bit of documentation in it, too.

Downsider wrote:

Baker wrote:

Downsider wrote: Format is GU_PSM_T8, it's on the PSP, and there's sufficient information on it, but I don't know about how Half-Life's palette is stored. I know how the end product should look, and the steps in the middle, but nothing about the ingredients themselves

Downsider, do you have a link to information on the PSP graphics API?

I have a PSP 1000 series now (need to order a Pandora battery, don't have that yet) ... and since I can compile for the PSP now, odds are strong that I will be writing some PSP engine tutorials.

Overall it's very similar to OpenGL, really. Documentation is abundant compared to other platforms that can run homebrew (Couldn't find shit when I was dabbling in Rockbox apps for the Sansa).

http://www.ghoti.nl/PSPtutorial1.php - Setting up the PSP SDK and doing some stuff few with the PSP GU.

http://www.psp-programming.com/forums/i ... 24.msg7214 - First 10 or so of Nehe's OpenGL gamedev tutorials ported to the PSP.

There's a bunch of samples in the PSP SDK's folder once you install it, and the header file for the lib has a bit of documentation in it, too.

Thanks!

Another problem with Half-Life maps is the number of makestatic entities. A solution for that, very simple but lame, is to limit the number of makestatic entities, ignoring all beyond the limit.

The basic quake beavior for quake after the limit is broken, is to crash, that is a non-nice result

There's actually no real reason to have a limit on the number of static entities in Quake. Forget about the static entities array, just pull some more memory off the hunk, and you have a new static entity. Magic!

If you go above the efrags limit you'll need to find a way of extending that, but that's the only real challenge.

Hmmm - I feel a tutorial coming on...

Hope theres no law against bumping oldish topics.
How does someone achieve this HLBSP on PSP (Main Reason I have been learning engine stuff)

I did this succesfully on PC Though Great Tut.

Everything is the same except the video related stuff.

I am not allowed to make a specific tutorial (Along with external texture support and hud related things.) for this, there are reasons that I shouldn't say to avoid makeing people look bad.


I will offer suggestions.

I suggest going here: http://bladebattles.com/forums/viewtopi ... &start=90 And downloading the modified Kurok Engine the person is working on, which is made to simulate a Half-Life experience on the psp.

It includes Half-Life BSP and other things.

That should give you a good direction and a solid example to follow for your engine.

Team Xlink wrote:I am not allowed to make a specific tutorial (Along with external texture support and hud related things.) for this, there are reasons that I shouldn't say to avoid makeing people look bad.

Hmm? How would that make me, I assume you mean me, since I wrote the HLBSP support in Solitude's engine, look bad?