Converting png/jpg to KMG - garbled output when pvr updates

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.
User avatar
ThePerfectK
DCEmu Freak
DCEmu Freak
Posts: 95
Joined: Thu Apr 27, 2006 10:15 am
Has liked: 6 times
Been liked: 13 times

Converting png/jpg to KMG - garbled output when pvr updates

Post by ThePerfectK » Mon Jul 25, 2016 2:41 pm

I'm trying to follow the modifier_volume_tex example and get the included fruit.jpg to display. The crate.pcx file displays fine, but I believe the rest of the demo isn't working correctly. Best I can surmise is that it's supposed to select a region of the screen, and for that region it's supposed to draw the fruit texture instead of the crate texture. I don't get that at all, instead I just get a small, dim square that goes in front of the crates.

If I try switching the textures around, so that the pointer that used to hold the texture that was loaded from crate.pcx instead points to a kmg created at make from fruit.jpg, I get this:

Image

Yeah, I know, nullDC. But it does the same thing on real hardware, too. What is the nature of this error? is the conversion to KMG going wrong, or is it something else?
Still Thinking!~~
User avatar
ThePerfectK
DCEmu Freak
DCEmu Freak
Posts: 95
Joined: Thu Apr 27, 2006 10:15 am
Has liked: 6 times
Been liked: 13 times

Re: Converting png/jpg to KMG - garbled output when pvr upda

Post by ThePerfectK » Mon Jul 25, 2016 2:53 pm

LOL god dang it, everytime the same pattern -

1) struggle with small error for hours on end
2) finally give up and make a topic asking for help
3) seconds after making topic, try "one more thing" that winds up fixing it all

lol in this case, it was a KMG encoding error. I was using vqenc, when I saw there was a specific KMGenc in /kos/utils/

using KMGEnc fixed the problem, and the textures encode correctly. I guess it's ultimately a twiddling error?

Anywho, problem solved!

EDIT: Well, kind of. I can display the kmg texture, but the demo still doesn't behave correctly (unless I've misjudged it's behavior). I'm still just getting a small, dimmer square among the crate texture like so:

Image

Is that how the program is supposed to behave, or is something going wrong? I'd expect that dim square to instead be drawing from the other texture.
Still Thinking!~~
User avatar
ThePerfectK
DCEmu Freak
DCEmu Freak
Posts: 95
Joined: Thu Apr 27, 2006 10:15 am
Has liked: 6 times
Been liked: 13 times

Re: Converting png/jpg to KMG - garbled output when pvr upda

Post by ThePerfectK » Mon Jul 25, 2016 5:51 pm

Doing more reading, it seems the above indeed is a simple shading program, kind of a bummer.

But I'm stick trying to modify the above program. it loads two textures into VRAM and i want to know how to change between drawing the two per polygon. It's drawing 10 polygons in the scene, and thus far I can only get it to draw with either one or the other. I'm guessing I need a good primer on how binding textures actually works in PVR.

Am I to understand that, once I have a texture loaded into VRam, I first bind it to a polygon context like so:

Code: Select all

[code loading an image into VRAM, and pointing it to txr1]
[code loading a different image into VRAM, and pointing it to txr2]

int w1, h1, w2, h2;	//width and height of textures
uint32 fmt1, fmt2;	//format of textures
pvr_poly_cxt_t cxt;	//PVR Polygon context

pvr_poly_cxt_txr(&cxt, list, fmt1, w1, h1, txr1, PVR_FILTER_BILINEAR);
//compiles a polygon context into phdr (hardware context) that is affected by modifier volume
pvr_poly_compile(&phdr, &cxt);
and then, from that moment on, any polygons I actually draw to the screen will be drawn using txr1. So let's say I draw some polygons, then want to change to another texture. would I do this:

Code: Select all

pvr_poly_cxt_txr(&cxt, list, fmt1, w1, h1, txr1, PVR_FILTER_BILINEAR);
//compiles a polygon context into phdr (hardware context) that is affected by modifier volume
pvr_poly_compile(&phdr, &cxt);

[draw a few polygons]

pvr_poly_cxt_txr(&cxt, list, fmt2, w2, h2, txr2, PVR_FILTER_BILINEAR);
//compiles a polygon context into phdr (hardware context) that is affected by modifier volume
pvr_poly_compile(&phdr, &cxt);

[draw some more polygons]
That's what i've been trying to do with no success. All the polygons are drawn with either texture. I'm trying to draw 5 with 1 texture, and 5 with the other. Any help?

To give context to what I'm trying to ultimately accomplish - I want to develop a tile-based 2D engine using hardware to blit to the screen as fast as possible. I figure I can store tiles as 8x8 textures and blit them to 8x8 quads onto the screen which would assuredly be quicker than building a software renderer. Naturally, this means I need to be able to select which texture to draw for which tile. I can draw multiple polygons of one texture, how do I switch the textures up?
Still Thinking!~~
User avatar
bogglez
Moderator
Moderator
Posts: 576
Joined: Sun Apr 20, 2014 9:45 am
Has liked: 0
Been liked: 0

Re: Converting png/jpg to KMG - garbled output when pvr upda

Post by bogglez » Mon Jul 25, 2016 6:13 pm

Check out the wiki in my signature and look for the spritesheet tutorial. There is a comprehensive spritesheet tutorial in there using the pvr including example code. Good night
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
User avatar
ThePerfectK
DCEmu Freak
DCEmu Freak
Posts: 95
Joined: Thu Apr 27, 2006 10:15 am
Has liked: 6 times
Been liked: 13 times

Re: Converting png/jpg to KMG - garbled output when pvr upda

Post by ThePerfectK » Mon Jul 25, 2016 10:00 pm

^^ Much appreciated!

Image

:D
Still Thinking!~~
User avatar
ThePerfectK
DCEmu Freak
DCEmu Freak
Posts: 95
Joined: Thu Apr 27, 2006 10:15 am
Has liked: 6 times
Been liked: 13 times

Re: Converting png/jpg to KMG - garbled output when pvr upda

Post by ThePerfectK » Mon Jul 25, 2016 11:41 pm

Forgive a ridiculous question - followed the guide, I've changed it to use 4bpp palettes which I prefer over 8bpp. Just about everything is as I want it, except I can't seem to figure out how to change the resolution. It's displaying at 640x480 mode, and I want it at 320x240. Am I missing something obvious?

EDIT: Jeeze, I'm all over the place lol. So, got it backwards - turns out I was running an old build by accident, so going from 8bpp mode to 4bpp mode didn't work. Meanwhile, adding a vid_set_mode(DM_320x240, PM_RGB565); command at the beginning of main pretty easily let me change the resolution.

I know I've been firing questions off all day and I apologize if this is flooding the board. I just am extra inspired at the moment. If anybody has time, would they mind helping me change the PVR Sprite tutorial from using 8bpp sprites to 4bpp sprites? I thought I had changed all the right values, but when I run the program, I get nothing but a black screen (I set the pvr background color to black).
Still Thinking!~~
User avatar
bogglez
Moderator
Moderator
Posts: 576
Joined: Sun Apr 20, 2014 9:45 am
Has liked: 0
Been liked: 0

Re: Converting png/jpg to KMG - garbled output when pvr upda

Post by bogglez » Tue Jul 26, 2016 11:13 am

ThePerfectK wrote: f anybody has time, would they mind helping me change the PVR Sprite tutorial from using 8bpp sprites to 4bpp sprites? I thought I had changed all the right values, but when I run the program, I get nothing but a black screen (I set the pvr background color to black).
I helped somebody with this in the Programming Discussion forum in the past. I think the name of the person who successfully did this was called mario or newbie, not sure. Search for it, I'm on the run right now. :)
BTW if you're using 4bpp you could use a much larger palette, but the tools assume you're using 8bpp right now. So everything will work with 4bpp, but you will use less colors in the palette than possible. You can ping the author of texconv to petition for that feature. He said he'd be willing to implement it if people show interest, if I remember correctly.
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
tonma
DCEmu Freak
DCEmu Freak
Posts: 82
Joined: Thu Mar 10, 2016 7:14 am
Has liked: 0
Been liked: 0

Re: Converting png/jpg to KMG - garbled output when pvr upda

Post by tonma » Tue Jul 26, 2016 12:26 pm

It's maybe me.

I'm in holidays and come back at the end of the week. I'll look if I have some code on my key.

You're working on a real game or you just testing the kit ?


Ok. I've found something. But I'm using Windows for the spritesheet, because I don't have a 64bits linux (for TexturePacker Software).


Well for this part :

Code: Select all

romdisk/%_sheet.dtex romdisk/%_sheet.dtex.pal: build/%_sheet.png
	$(info Converting $@ < $<)
	texconv -i $< -o $@ -f PAL8BPP -p build/$*_preview.png

You must convert to 4bpp

Code: Select all

romdisk/%_sheet.dtex romdisk/%_sheet.dtex.pal: build/%_sheet.png
	$(info Converting $@ < $<)
	texconv -i $< -o $@ -f PAL4BPP -p build/$*_preview.png

in the function, change with :

Code: Select all

static int spritesheet_load(
....
/* Only allow 4 bit palette dtex files */
	if(memcmp(dtex_header.magic, "DTEX", 4) || dtex_header.type != 0x28000000) {
		result = 3;
		goto cleanup;
	}
For the palette, I use this (0-15, 16-31, ...):

Code: Select all

void setup_palette_pal4(uint32_t const * colors, uint16_t count, uint8_t palette_number) {
	pvr_set_pal_format(PVR_PAL_ARGB8888);
	for(uint16_t i = 0; i < 16; ++i)
	pvr_set_pal_entry((palette_number * 16)+i, colors[i]);
}
In the draw_sprite function :

Code: Select all

void draw_sprite(struct spritesheet const * const sheet, char const * const name, float x, float y, uint8_t palette_number) {
...
pvr_poly_cxt_txr(&context, PVR_LIST_PT_POLY, PVR_TXRFMT_PAL4BPP | PVR_TXRFMT_4BPP_PAL(palette_number), sheet->width, sheet->height, sheet->texture, PVR_FILTER_NONE);
	pvr_poly_compile(&header, &context);

	pvr_prim(&header, sizeof(header));
...
}

And I think, I doesn't forget anything. :mrgreen:
User avatar
ThePerfectK
DCEmu Freak
DCEmu Freak
Posts: 95
Joined: Thu Apr 27, 2006 10:15 am
Has liked: 6 times
Been liked: 13 times

Re: Converting png/jpg to KMG - garbled output when pvr upda

Post by ThePerfectK » Tue Jul 26, 2016 6:50 pm

tonma wrote:You're working on a real game or you just testing the kit ?
story time! Back in 2007, I started writing a Sonic game in SDL for windows and linux, and I've been working at it ever since. My original goal was to create a cross-platform engine that could also run on the dreamcast, as a friend of mine had created something similar. Over the past almost-year the PC version of this game has progressed quite a bit (in my spare time, mind you - I do entirely different type of development as my full-time job).

So, back in 2014, I sat down and decided to give my engine a real attempt at running at the dreamcast... when I found out the Dreamcast SDL port runs entirely in software and doesn't use any of the hardware, and thus was way too slow. I talked to bluecrab about it, and then talked to Taxman, the guy who wrote Retro Sonic and is currently making Sonic Mania, and they both gave me the same answer - you gotta use hardware, software is too slow. Tax actually used WindowsCE (all he had available at the time) and thus had never worked with KOS, so I was sort of stuck. And the game has kind of been in limbo ever since.

A few days ago, I got hit with a burst of inspiration, and decided to give a second real attempt at porting the stuff over to the dreamcast, and this time things are going much smoother. Got KOS all set up and can render to the screen. Once I get the basic video stuff down, porting over the logic of the physics engine is the easy part and the rest of the game, and what I have done on PC, will come faster.

So, tl;dr: yeah, real game :P

I just saw down at the PC after work to try and follow your suggestions. At first glance, it looks those are all the changes I'd already made to the code, but I'll go through and see if I missed something. Either way, thanks very much for the help!

on the subject of further goals down the line - the Sonic games, and my PC engine, all use a few raster effects, namely for mid-line palette swapping to simulate water transparency. I'm guessing this will be quite a problem on the dreamcast. This is one of the reasons I want to use 4bpp mode, as I can devote half of the 64 palettes to being "under water palettes" that I can easily switch between. My idea is that, if any sprite needs to change palettes mid-draw, what i can do is manipulate the UV coordinates so that only half of the texture draws, then draw a second sprite directly on top of the first, this time with the second texture, and, again messing with the UV coordinates, draw only the missing half of the sprite, so that the two sprites appear as one that is changing palettes midway through the draw. Is there any obvious reason this won't work, or a smarter solution to doing this?
Still Thinking!~~
tonma
DCEmu Freak
DCEmu Freak
Posts: 82
Joined: Thu Mar 10, 2016 7:14 am
Has liked: 0
Been liked: 0

Re: Converting png/jpg to KMG - garbled output when pvr upda

Post by tonma » Wed Jul 27, 2016 3:27 am

Great, can't wait to see your futur game. :mrgreen:

I never try to draw only half of a sprite/texture but maybe be with u,v part of pvr_vertex_t

Code: Select all

/* Common attributes of the 4 vertices/points of the sprite. */
	pvr_vertex_t vert = {
		.argb = PVR_PACK_COLOR(1.0f, 1.0f, 1.0f, 1.0f),
		.oargb = 0,
		.flags = PVR_CMD_VERTEX, /* This is not the last point */
		.z = z
	};
If my code doesn't working, I'll can send you a sample next week.

Two things to test :
- Normaly you can see debug information with nullDC if the palette is not good for example.
- The z value of the vertex. Not the same as the background and try with another emul like Demul. With NullDC, lot of my sprites never displayed because the value of z.
User avatar
ThePerfectK
DCEmu Freak
DCEmu Freak
Posts: 95
Joined: Thu Apr 27, 2006 10:15 am
Has liked: 6 times
Been liked: 13 times

Re: Converting png/jpg to KMG - garbled output when pvr upda

Post by ThePerfectK » Wed Jul 27, 2016 6:52 am

tonma, your suggested changes worked! The difference between what I had been trying and what you suggested was in your palette loading routine - I was iterating through the palette up to the number of colors in the source image, regardless of whether or not it had less than 16 colors.

Another question - is it possible to draw transparent sprites using the code in the spritesheet example? If I change all the instances of PVR_LIST_PT_POLY to PVR_LIST_TR_POLY, nothing at all draws. Take the same code and change it back to PVR_LIST_PT_POLY and the sprite shows up fine.

Any ideas?
Still Thinking!~~
tonma
DCEmu Freak
DCEmu Freak
Posts: 82
Joined: Thu Mar 10, 2016 7:14 am
Has liked: 0
Been liked: 0

Re: Converting png/jpg to KMG - garbled output when pvr upda

Post by tonma » Wed Jul 27, 2016 7:26 am

That's weird. I thought that the PT "punch-thrus" use transparency, you're have a picture with transparency ? But I do not remember, I'm afraid.

If you want to use TR you need two things :

change the value in the function init()

Code: Select all

pvr_init_params_t pvr_params = {
		.opb_sizes = { PVR_BINSIZE_8, PVR_BINSIZE_0, PVR_BINSIZE_0, PVR_BINSIZE_0, PVR_BINSIZE_8 },
In the documentation, you have :
Bin sizes.
The bins go in the following order: opaque polygons, opaque modifiers, translucent polygons, translucent modifiers, punch-thrus

So change the translucent poltgons value :

Code: Select all

pvr_init_params_t pvr_params = {
		.opb_sizes = { PVR_BINSIZE_8, PVR_BINSIZE_0, PVR_BINSIZE_8, PVR_BINSIZE_0, PVR_BINSIZE_8 },
And in your function draw (), you need to draw transparent polygone bfore the PT_poly:

Code: Select all

static void draw() {
	pvr_wait_ready(); /* Await v-blank */
	pvr_scene_begin();


/* opaque and transparent */


    pvr_list_begin(PVR_LIST_OP_POLY);
    pvr_list_finish();

    pvr_list_begin(PVR_LIST_TR_POLY);

    draw_TP();
    pvr_list_finish();

	/* Start sending punchthru polygons. */
	pvr_list_begin(PVR_LIST_PT_POLY);

...
pvr_scene_finish();
User avatar
bogglez
Moderator
Moderator
Posts: 576
Joined: Sun Apr 20, 2014 9:45 am
Has liked: 0
Been liked: 0

Re: Converting png/jpg to KMG - garbled output when pvr upda

Post by bogglez » Wed Jul 27, 2016 8:09 am

Tonma: pvr_list_finish() will be called for you implicitly, you can just leave it out.

Theperfectk: for intricate full-screen effects, you will probably want to use the pvr's feature of drawing the whole scene to a texture instead of the screen. Just change the pvr_scene_begin call.
Then bind the texture you drew the screen to and draw a grid of triangles over the whole screen. You can then change the coordinates, texture coordinates and color of each vertex on the grid. Basically a shader for poor people.
You can also perform some effects using modifier volumes. Sprites that lie within those volumes will have their vertex attributes modified (you might need to draw sprites as grids instead of rectangles to get finer control over the effect).

Bumpmapping could also provide you with pseudo-3d effects. Or multitexturing with blending in general.
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
User avatar
ThePerfectK
DCEmu Freak
DCEmu Freak
Posts: 95
Joined: Thu Apr 27, 2006 10:15 am
Has liked: 6 times
Been liked: 13 times

Re: Converting png/jpg to KMG - garbled output when pvr upda

Post by ThePerfectK » Wed Jul 27, 2016 9:30 am

bogglez wrote:Tonma: pvr_list_finish() will be called for you implicitly, you can just leave it out.

Theperfectk: for intricate full-screen effects, you will probably want to use the pvr's feature of drawing the whole scene to a texture instead of the screen. Just change the pvr_scene_begin call.
Then bind the texture you drew the screen to and draw a grid of triangles over the whole screen. You can then change the coordinates, texture coordinates and color of each vertex on the grid. Basically a shader for poor people.
You can also perform some effects using modifier volumes. Sprites that lie within those volumes will have their vertex attributes modified (you might need to draw sprites as grids instead of rectangles to get finer control over the effect).

Bumpmapping could also provide you with pseudo-3d effects. Or multitexturing with blending in general.
You're going to need to go into more detail, I'm afraid. Change the pvr_scene_begin call to what exactly? Is there a demo that is doing this to begin with?

I was told by bluecrab and tax that this method of drawing is slow and inefficient, and to use hardware drawing features as much as possible and avoid direct memory manipulation. Really, the only effect I need is something to replace water transparency, hence my last question - after following the sprite sheet tutorial you linked me, how can I modify that to draw the sprites transparently? Following all the code, changing my poly list to PVR_LIST_TR_POLY results in nothing drawing, when it works fine if my poly list is PVR_LIST_PT_POLY. Any clues?
Still Thinking!~~
User avatar
bogglez
Moderator
Moderator
Posts: 576
Joined: Sun Apr 20, 2014 9:45 am
Has liked: 0
Been liked: 0

Re: Converting png/jpg to KMG - garbled output when pvr upda

Post by bogglez » Wed Jul 27, 2016 9:57 am

ThePerfectK wrote:
bogglez wrote:Tonma: pvr_list_finish() will be called for you implicitly, you can just leave it out.

Theperfectk: for intricate full-screen effects, you will probably want to use the pvr's feature of drawing the whole scene to a texture instead of the screen. Just change the pvr_scene_begin call.
Then bind the texture you drew the screen to and draw a grid of triangles over the whole screen. You can then change the coordinates, texture coordinates and color of each vertex on the grid. Basically a shader for poor people.
You can also perform some effects using modifier volumes. Sprites that lie within those volumes will have their vertex attributes modified (you might need to draw sprites as grids instead of rectangles to get finer control over the effect).

Bumpmapping could also provide you with pseudo-3d effects. Or multitexturing with blending in general.
You're going to need to go into more detail, I'm afraid. Change the pvr_scene_begin call to what exactly? Is there a demo that is doing this to begin with?

I was told by bluecrab and tax that this method of drawing is slow and inefficient, and to use hardware drawing features as much as possible and avoid direct memory manipulation. Really, the only effect I need is something to replace water transparency [...]
That's the thing, this is all in hardware. The graphics chip will render the scene to a texture (= an image in video memory, not main memory), without intervention by the CPU. Drawing triangles with a texture bound to them is also done by the PVR. The only thing you do is change texture coordinates etc. on the triangles you submit. This does not interfere with the graphics chip's work.

It also seems you haven't found the PVR documentation yet. Please bookmark this page and gloss over the function names and the corresponding constants that you may provide as arguments:
http://gamedev.allusion.net/docs/kos-cu ... vr_8h.html
ThePerfektK wrote: [..]hence my last question - after following the sprite sheet tutorial you linked me, how can I modify that to draw the sprites transparently? Following all the code, changing my poly list to PVR_LIST_TR_POLY results in nothing drawing, when it works fine if my poly list is PVR_LIST_PT_POLY. Any clues?
Please post code, I don't want to guess. tonma suggested some probable fixes already.
BTW punchthru mode provides you with translucency (alpha masking, transparency on/off), so it should be good enough for most of the drawing you do.
Transparency mode is meant for blending (70% sonic's sprite, 30% fire shield effect over him).
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
User avatar
ThePerfectK
DCEmu Freak
DCEmu Freak
Posts: 95
Joined: Thu Apr 27, 2006 10:15 am
Has liked: 6 times
Been liked: 13 times

Re: Converting png/jpg to KMG - garbled output when pvr upda

Post by ThePerfectK » Wed Jul 27, 2016 10:05 am

bogglez wrote:Please post code, I don't want to guess. tonma suggested some probable fixes already.
BTW punchthru mode provides you with translucency (alpha masking, transparency on/off), so it should be good enough for most of the drawing you do.
Transparency mode is meant for blending (70% sonic's sprite, 30% fire shield effect over him).
My code is identical to this:

http://dcemulation.org/?title=PVR_Spritesheets

I've taken the example you provided me, and changed exactly two lines:

from:

Code: Select all

pvr_list_begin(PVR_LIST_PT_POLY);
to

Code: Select all

pvr_list_begin(PVR_LIST_TR_POLY);
and from:

Code: Select all

pvr_sprite_cxt_txr(&sprite_context, PVR_LIST_PT_POLY, PVR_TXRFMT_PAL8BPP | PVR_TXRFMT_8BPP_PAL(palette_number), sheet->width, sheet->height, sheet->texture, PVR_FILTER_NONE);

Code: Select all

pvr_sprite_cxt_txr(&sprite_context, PVR_LIST_TR_POLY, PVR_TXRFMT_PAL8BPP | PVR_TXRFMT_8BPP_PAL(palette_number), sheet->width, sheet->height, sheet->texture, PVR_FILTER_NONE);
everything else is the stock example you linked me to. If the PVR list is PT_POLY, it runs just fine. if it's TR_POLY, I get nothing on the screen. I understand the difference between punch-through and transparent polygon, in this instance I'm trying to draw a blended sprite. Do I need provide an opaque sprite behind it to blend with? Again, all I get is the PVR background color when I use the TR list and nothing else, where the sprites display fine if I use the PT list.

EDIT: I actually missed Tomma's post entirely! Going through and reading now.
Last edited by ThePerfectK on Wed Jul 27, 2016 10:16 am, edited 2 times in total.
Still Thinking!~~
User avatar
bogglez
Moderator
Moderator
Posts: 576
Joined: Sun Apr 20, 2014 9:45 am
Has liked: 0
Been liked: 0

Re: Converting png/jpg to KMG - garbled output when pvr upda

Post by bogglez » Wed Jul 27, 2016 10:13 am

TheSpecialK: So you haven't done this yet?
tonma wrote: [...]
If you want to use TR you need two things :

change the value in the function init()

Code: Select all

pvr_init_params_t pvr_params = {
		.opb_sizes = { PVR_BINSIZE_8, PVR_BINSIZE_0, PVR_BINSIZE_0, PVR_BINSIZE_0, PVR_BINSIZE_8 },
In the documentation, you have :
Bin sizes.
The bins go in the following order: opaque polygons, opaque modifiers, translucent polygons, translucent modifiers, punch-thrus

So change the translucent poltgons value :

Code: Select all

pvr_init_params_t pvr_params = {
		.opb_sizes = { PVR_BINSIZE_8, PVR_BINSIZE_0, PVR_BINSIZE_8, PVR_BINSIZE_0, PVR_BINSIZE_8 },
And in your function draw (), you need to draw transparent polygone bfore the PT_poly:

Code: Select all

static void draw() {
	pvr_wait_ready(); /* Await v-blank */
	pvr_scene_begin();


/* opaque and transparent */


    pvr_list_begin(PVR_LIST_OP_POLY);
    pvr_list_finish();

    pvr_list_begin(PVR_LIST_TR_POLY);

    draw_TP();
    pvr_list_finish();

	/* Start sending punchthru polygons. */
	pvr_list_begin(PVR_LIST_PT_POLY);

...
pvr_scene_finish();
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
User avatar
ThePerfectK
DCEmu Freak
DCEmu Freak
Posts: 95
Joined: Thu Apr 27, 2006 10:15 am
Has liked: 6 times
Been liked: 13 times

Re: Converting png/jpg to KMG - garbled output when pvr upda

Post by ThePerfectK » Wed Jul 27, 2016 10:16 am

bogglez wrote:TheSpecialK: So you haven't done this yet?

snip
I actually didn't even notice he had replied until I was reading your reply, lol. Tomma is on fire here lately! Totally did the trick, what I was missing was changing the binsize in the PVR_init, thanks so much man!

On the subject of rendering to a texture:
That's the thing, this is all in hardware. The graphics chip will render the scene to a texture (= an image in video memory, not main memory), without intervention by the CPU. Drawing triangles with a texture bound to them is also done by the PVR. The only thing you do is change texture coordinates etc. on the triangles you submit. This does not interfere with the graphics chip's work.

It also seems you haven't found the PVR documentation yet. Please bookmark this page and gloss over the function names and the corresponding constants that you may provide as arguments:
http://gamedev.allusion.net/docs/kos-cu ... vr_8h.html
Very interesting. Is it an expensive operation to manually tweak a texture already in VRAM? Say I want to do a line scroll so that every row is pushed over by an increasing amount, i.e. row 1 is pushed over by 0, row 2 is pushed over by 1, row 3 is pushed over by 2, etc. I'd render my sprite to a texture, then manually edit each row; is this something that'll dramatically slow down my program?

Thanks again for the help, btw. It's pretty crazy that this board is still so active!
Still Thinking!~~
User avatar
bogglez
Moderator
Moderator
Posts: 576
Joined: Sun Apr 20, 2014 9:45 am
Has liked: 0
Been liked: 0

Re: Converting png/jpg to KMG - garbled output when pvr upda

Post by bogglez » Wed Jul 27, 2016 10:27 am

ThePerfectK wrote: Very interesting. Is it an expensive operation to manually tweak a texture already in VRAM? Say I want to do a line scroll so that every row is pushed over by an increasing amount, i.e. row 1 is pushed over by 0, row 2 is pushed over by 1, row 3 is pushed over by 2, etc. I'd render my sprite to a texture, then manually edit each row; is this something that'll dramatically slow down my program?
If you refer to what I said above by "tweaking a texture in VRAM" then: you're not tweaking the texture, just some parameters how it's rendered and that's basically free.

If you're asking about that line-effect you mentioned: It depends a lot on what you're doing and you'll need to benchmark.
While you can write to the VRAM to do anything you want, it will probably be too slow. I'd try to achieve the same effect somehow else, but it's very effect-specific.. You might draw to the same texture twice with a different "stride" (gap), abuse depth tests, alpha masking and so on.. you'll have to be a bit creative.

Something you must be aware of is that the PVR uses tiles (32x32 rectangles in a grid on the screen). When you draw a triangle strip (the only understood polygon drawing mode), the PVR will calculate the bounding box of it (aligned to the screen axes X and Y). It will use this bounding box to find out which tiles need to be drawn to. So if you're going to draw a line (thin triangle strip of one triangle) from the top left to the bottom right of the screen for some effect the PVR will think it needs to update the whole screen.
ThePerfectK wrote: Thanks again for the help, btw. It's pretty crazy that this board is still so active!
You're welcome. I hope you help out some newcomers in the future as well to keep the scene alive and kicking :)
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
User avatar
ThePerfectK
DCEmu Freak
DCEmu Freak
Posts: 95
Joined: Thu Apr 27, 2006 10:15 am
Has liked: 6 times
Been liked: 13 times

Re: Converting png/jpg to KMG - garbled output when pvr upda

Post by ThePerfectK » Wed Jul 27, 2016 10:38 am

bogglez wrote:
ThePerfectK wrote: Very interesting. Is it an expensive operation to manually tweak a texture already in VRAM? Say I want to do a line scroll so that every row is pushed over by an increasing amount, i.e. row 1 is pushed over by 0, row 2 is pushed over by 1, row 3 is pushed over by 2, etc. I'd render my sprite to a texture, then manually edit each row; is this something that'll dramatically slow down my program?
If you refer to what I said above by "tweaking a texture in VRAM" then: you're not tweaking the texture, just some parameters how it's rendered and that's basically free.

If you're asking about that line-effect you mentioned: It depends a lot on what you're doing and you'll need to benchmark.
While you can write to the VRAM to do anything you want, it will probably be too slow. I'd try to achieve the same effect somehow else, but it's very effect-specific.. You might draw to the same texture twice with a different "stride" (gap), abuse depth tests, alpha masking and so on.. you'll have to be a bit creative.

Something you must be aware of is that the PVR uses tiles (32x32 rectangles in a grid on the screen). When you draw a triangle strip (the only understood polygon drawing mode), the PVR will calculate the bounding box of it (aligned to the screen axes X and Y). It will use this bounding box to find out which tiles need to be drawn to. So if you're going to draw a line (thin triangle strip of one triangle) from the top left to the bottom right of the screen for some effect the PVR will think it needs to update the whole screen.
Indeed, very interesting suggestions. To be truthful, the types of raster effects I'm talking about are pretty specific and I could probably avoid them all together without much consequence. This entire port is very much a learning exercise for me, so I'm trying not to get too caught up on any one problem. I figured if I could do 4 things quickly - draw sprites, change palette entries, and perform transparencies, and accomplish rotation, that I'd have all the basic tools to port my sonic engine without problem. Thanks to this thread, I can do all that now :D
ThePerfectK wrote: Thanks again for the help, btw. It's pretty crazy that this board is still so active!
You're welcome. I hope you help out some newcomers in the future as well to keep the scene alive and kicking :)
Very much plan on it, actually. I keep notes as I work that help me recreate the steps, and I'm in the habit of turning those notes into tutorials, as I find that's the best way to learn. So eventually, I'll compile everything I'm doing into a guide to be posted :D
Still Thinking!~~
Post Reply