vqenc/Opaque/Transluscent Polys (Zsortingt

If you have any questions on programming, this is the place to ask them, whether you're a newbie or an experienced programmer. Discussion on programming in general is also welcome. We will help you with programming homework, but we will not do your work for you! Any porting requests must be made in Developmental Ideas.
Post Reply
User avatar
AtariOwl
DCEmu Freak
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

Post by AtariOwl »

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

I am guessing therefore that z is not currently being considered. Perhaps this is related to my fogging question?
Last edited by AtariOwl on Tue Jan 24, 2017 6:35 pm, edited 2 times in total.
User avatar
BlueCrab
The Crabby Overlord
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

Post by BlueCrab »

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?
User avatar
AtariOwl
DCEmu Freak
DCEmu Freak
Posts: 96
Joined: Fri May 23, 2008 5:57 am
Has thanked: 0
Been thanked: 2 times

Re: vqenc and Opaque Polys

Post by AtariOwl »

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?
User avatar
bogglez
Moderator
Moderator
Posts: 578
Joined: Sun Apr 20, 2014 9:45 am
Has thanked: 0
Been thanked: 0

Re: vqenc/Opaque/Transluscent Polys (Zsortingt

Post by bogglez »

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.
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
Post Reply