Converting png/jpg to KMG - garbled output when pvr updates
- ThePerfectK
- Insane DCEmu
- Posts: 147
- https://www.artistsworkshop.eu/meble-kuchenne-na-wymiar-warszawa-gdzie-zamowic/
- Joined: Thu Apr 27, 2006 10:15 am
- Has thanked: 27 times
- Been thanked: 35 times
Converting png/jpg to KMG - garbled output when pvr updates
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:
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?
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:
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!~~
- ThePerfectK
- Insane DCEmu
- Posts: 147
- Joined: Thu Apr 27, 2006 10:15 am
- Has thanked: 27 times
- Been thanked: 35 times
Re: Converting png/jpg to KMG - garbled output when pvr upda
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:
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.
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:
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!~~
- ThePerfectK
- Insane DCEmu
- Posts: 147
- Joined: Thu Apr 27, 2006 10:15 am
- Has thanked: 27 times
- Been thanked: 35 times
Re: Converting png/jpg to KMG - garbled output when pvr upda
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:
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:
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?
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);
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]
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!~~
Re: Converting png/jpg to KMG - garbled output when pvr upda
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
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
- ThePerfectK
- Insane DCEmu
- Posts: 147
- Joined: Thu Apr 27, 2006 10:15 am
- Has thanked: 27 times
- Been thanked: 35 times
- ThePerfectK
- Insane DCEmu
- Posts: 147
- Joined: Thu Apr 27, 2006 10:15 am
- Has thanked: 27 times
- Been thanked: 35 times
Re: Converting png/jpg to KMG - garbled output when pvr upda
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).
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!~~
Re: Converting png/jpg to KMG - garbled output when pvr upda
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.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).
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
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
Re: Converting png/jpg to KMG - garbled output when pvr upda
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 :
You must convert to 4bpp
in the function, change with :
For the palette, I use this (0-15, 16-31, ...):
In the draw_sprite function :
And I think, I doesn't forget anything.
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;
}
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]);
}
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));
...
}
- ThePerfectK
- Insane DCEmu
- Posts: 147
- Joined: Thu Apr 27, 2006 10:15 am
- Has thanked: 27 times
- Been thanked: 35 times
Re: Converting png/jpg to KMG - garbled output when pvr upda
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).tonma wrote:You're working on a real game or you just testing the kit ?
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
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!~~
Re: Converting png/jpg to KMG - garbled output when pvr upda
Great, can't wait to see your futur game.
I never try to draw only half of a sprite/texture but maybe be with u,v part of pvr_vertex_t
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.
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
};
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.
- ThePerfectK
- Insane DCEmu
- Posts: 147
- Joined: Thu Apr 27, 2006 10:15 am
- Has thanked: 27 times
- Been thanked: 35 times
Re: Converting png/jpg to KMG - garbled output when pvr upda
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?
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!~~
Re: Converting png/jpg to KMG - garbled output when pvr upda
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()
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 :
And in your function draw (), you need to draw transparent polygone bfore the PT_poly:
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 },
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 },
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();
Re: Converting png/jpg to KMG - garbled output when pvr upda
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.
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
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
- ThePerfectK
- Insane DCEmu
- Posts: 147
- Joined: Thu Apr 27, 2006 10:15 am
- Has thanked: 27 times
- Been thanked: 35 times
Re: Converting png/jpg to KMG - garbled output when pvr upda
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?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.
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!~~
Re: Converting png/jpg to KMG - garbled output when pvr upda
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.ThePerfectK wrote: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?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.
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 [...]
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
Please post code, I don't want to guess. tonma suggested some probable fixes already.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?
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
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
- ThePerfectK
- Insane DCEmu
- Posts: 147
- Joined: Thu Apr 27, 2006 10:15 am
- Has thanked: 27 times
- Been thanked: 35 times
Re: Converting png/jpg to KMG - garbled output when pvr upda
My code is identical to this: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).
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);
Code: Select all
pvr_list_begin(PVR_LIST_TR_POLY);
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);
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!~~
Re: Converting png/jpg to KMG - garbled output when pvr upda
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()In the documentation, you have :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 },
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 :And in your function draw (), you need to draw transparent polygone bfore the PT_poly: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 },
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
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
- ThePerfectK
- Insane DCEmu
- Posts: 147
- Joined: Thu Apr 27, 2006 10:15 am
- Has thanked: 27 times
- Been thanked: 35 times
Re: Converting png/jpg to KMG - garbled output when pvr upda
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!bogglez wrote:TheSpecialK: So you haven't done this yet?
snip
On the subject of rendering to a texture:
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?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
Thanks again for the help, btw. It's pretty crazy that this board is still so active!
Still Thinking!~~
Re: Converting png/jpg to KMG - garbled output when pvr upda
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.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'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.
You're welcome. I hope you help out some newcomers in the future as well to keep the scene alive and kickingThePerfectK wrote: Thanks again for the help, btw. It's pretty crazy that this board is still so active!
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
- ThePerfectK
- Insane DCEmu
- Posts: 147
- Joined: Thu Apr 27, 2006 10:15 am
- Has thanked: 27 times
- Been thanked: 35 times
Re: Converting png/jpg to KMG - garbled output when pvr upda
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 nowbogglez wrote: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.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'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.
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 postedYou're welcome. I hope you help out some newcomers in the future as well to keep the scene alive and kickingThePerfectK wrote: Thanks again for the help, btw. It's pretty crazy that this board is still so active!
Still Thinking!~~