Well i have another vqenc question.
The code is working fine with ARGB4444 kmgs.
I am running an OP list and a TR list and both are displaying although frankly the banding on the kmg is poor.
I would like to do proper opaque texture on my OP polygon. However the option on vqenc seem to be restricted to ARGB1555 and ARGB4444.
I'm currently using pngs based on the dcvqtex demos.
When i run 4444 it looks ok but coarse
When i run 1555 i get messed up colours.
What shouldi be doing to improve colours?
This shows the OP Poly in the background with the messed up colours
On top of it is a TR poly with fog applied.
Interestingly despite the TR poly having a z < the OP poly, the TR poly is remaining on top.
I am guessing therefore that z is not currently being considered. Perhaps this is related to my fogging question?
vqenc/Opaque/Transluscent Polys (Zsortingt
- AtariOwl
- DCEmu Freak
- Posts: 96
- https://www.artistsworkshop.eu/meble-kuchenne-na-wymiar-warszawa-gdzie-zamowic/
- Joined: Fri May 23, 2008 5:57 am
- Has thanked: 0
- Been thanked: 2 times
vqenc/Opaque/Transluscent Polys (Zsortingt
Last edited by AtariOwl on Tue Jan 24, 2017 6:35 pm, edited 2 times in total.
- BlueCrab
- The Crabby Overlord
- Posts: 5658
- Joined: Mon May 27, 2002 11:31 am
- Location: Sailing the Skies of Arcadia
- Has thanked: 9 times
- Been thanked: 69 times
- Contact:
Re: vqenc and Opaque Polys
First off, VQ-encoded stuff will look "coarse" just based on how the compression works. Unless you're doing a lot of textures that are all going to have to be resident in vram at once, you might want to just use plain PNGs or whatnot and not VQ-encode them -- especially for 2D stuff (you probably won't notice the coarseness for 3d terrain textures and whatnot).
Second, are you sure you're using the right color format for loading the "opaque" texture with? I'd imagine that if it's meant to be opaque that it would be RGB565, not ARGB1555?
Second, are you sure you're using the right color format for loading the "opaque" texture with? I'd imagine that if it's meant to be opaque that it would be RGB565, not ARGB1555?
- AtariOwl
- DCEmu Freak
- Posts: 96
- Joined: Fri May 23, 2008 5:57 am
- Has thanked: 0
- Been thanked: 2 times
Re: vqenc and Opaque Polys
Hi
The coarseness is an issue, i was hoping the vq encoding would not look so bad, but the banding is quite severe. I'll see what it looks like on more representative textures. Or i may have to go to texconv and 8bpp. We'll see i suppose.
vqenc doesnt seem to offer an oprtion for RGB565... i am taking the format from the LoadVQ i had.. perhaps naively, assumed that the file returns the format. AHA it is set by the LoadVQ function to be ARGB444 by default. Easy to fix.
It won't be 2D.
Trying to figure out where i pass PVR_DEPTHCMP_GEQUAL, it seems as though PVR_CULLING_CCW is already set, perhaps a default setting?
OK applied as
p_cxt.depth.comparison = PVR_DEPTHCMP_GEQUAL;
p_cxt.gen.culling = PVR_CULLING_CCW;
Why is my TR poly always on top?
As z (i know it is actually 1/z) decreases shoulding it vanish behind the OP poly?
The coarseness is an issue, i was hoping the vq encoding would not look so bad, but the banding is quite severe. I'll see what it looks like on more representative textures. Or i may have to go to texconv and 8bpp. We'll see i suppose.
vqenc doesnt seem to offer an oprtion for RGB565... i am taking the format from the LoadVQ i had.. perhaps naively, assumed that the file returns the format. AHA it is set by the LoadVQ function to be ARGB444 by default. Easy to fix.
It won't be 2D.
Trying to figure out where i pass PVR_DEPTHCMP_GEQUAL, it seems as though PVR_CULLING_CCW is already set, perhaps a default setting?
OK applied as
p_cxt.depth.comparison = PVR_DEPTHCMP_GEQUAL;
p_cxt.gen.culling = PVR_CULLING_CCW;
Why is my TR poly always on top?
As z (i know it is actually 1/z) decreases shoulding it vanish behind the OP poly?
Re: vqenc/Opaque/Transluscent Polys (Zsortingt
VQ compression quality looks bad on pictures with very many colors. It's therefore more likely in images of large resolution.
Note that most of your textures will not span the whole screen, but just a smaller portion of it. It makes no sense to use a 1024x1024 texture if it's just going to be applied to the head of a 3D model which is rendered at about 100x100 pixels on screen.
When you need perfect colors for title screens for example you should use a paletted texture, if the amount of colors is low enough (up to 256 different colors), or a RGB565/ARGB1555 texture instead.
Sometimes it may also work to split the image into multiple parts, e.g. 512x512 + 512x32 below. This should especially work well if you can lower the amount of colors in each part and therefore use a more efficient color representation.
Note that most of your textures will not span the whole screen, but just a smaller portion of it. It makes no sense to use a 1024x1024 texture if it's just going to be applied to the head of a 3D model which is rendered at about 100x100 pixels on screen.
When you need perfect colors for title screens for example you should use a paletted texture, if the amount of colors is low enough (up to 256 different colors), or a RGB565/ARGB1555 texture instead.
Sometimes it may also work to split the image into multiple parts, e.g. 512x512 + 512x32 below. This should especially work well if you can lower the amount of colors in each part and therefore use a more efficient color representation.
Wiki & tutorials: http://dcemulation.org/?title=Development
Wiki feedback: viewtopic.php?f=29&t=103940
My libgl playground (not for production): https://bitbucket.org/bogglez/libgl15
My lxdream fork (with small fixes): https://bitbucket.org/bogglez/lxdream
Wiki feedback: viewtopic.php?f=29&t=103940
My libgl playground (not for production): https://bitbucket.org/bogglez/libgl15
My lxdream fork (with small fixes): https://bitbucket.org/bogglez/lxdream