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
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:56 am

ThePerfectK wrote: 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
If you're going to write tutorials, |darc| will be happy to give you account for the wiki.
Also consider this thread for wiki feedback: viewtopic.php?f=29&t=103940

BTW if I wasn't elaborate enough about the grid effect before.. You could do such a line doubling/trippling effect with that. Instead of copying texels in VRAM you would instead create a very detailed grid of triangles on screen, some triangles being thicker than others (spanning multiple lines). If you left the UV coordinates the same, this would scale the line in one direction.
This would move the bottleneck from using the memory bus for accessing VRAM to sending more polygons to the screen. And in a 2D game you shouldn't have that many polygons to begin with. But I can't guarantee that it's the best way to do it :)
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: 94
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 11:15 am

bogglez wrote:
ThePerfectK wrote: 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
If you're going to write tutorials, |darc| will be happy to give you account for the wiki.
Also consider this thread for wiki feedback: viewtopic.php?f=29&t=103940

BTW if I wasn't elaborate enough about the grid effect before.. You could do such a line doubling/trippling effect with that. Instead of copying texels in VRAM you would instead create a very detailed grid of triangles on screen, some triangles being thicker than others (spanning multiple lines). If you left the UV coordinates the same, this would scale the line in one direction.
This would move the bottleneck from using the memory bus for accessing VRAM to sending more polygons to the screen. And in a 2D game you shouldn't have that many polygons to begin with. But I can't guarantee that it's the best way to do it :)
This would be effectively like mapping each texel to a quad (or rather, two triangles), correct? And treating an array of quads as a single sprite? That would make the UI scaling uniform across the entire shape, or would I be able to make certain 'pixels' appear thicker than others?

Liberal use of polygons was the suggestion Tax and BlueCrab gave me about how to speed up Dreamcast programming. You're correct that, even at the very most, I wouldn't be drawing more than a few thousand polygons at once.
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 11:21 am

No. Imagine a rectangle (=2 triangles) spanning each horizontal line. So you have 480 rectangles.
Remove every second rectangle. Make the remaining rectangles twice as high by increasing the y coordinate of their bottom points. Tada line doubling effect.
Again, not sure whether there are better ways, it's just an example for being creative while not resorting to software rendering. :)
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: 94
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 11:56 am

bogglez wrote:No. Imagine a rectangle (=2 triangles) spanning each horizontal line. So you have 480 rectangles.
Remove every second rectangle. Make the remaining rectangles twice as high by increasing the y coordinate of their bottom points. Tada line doubling effect.
Again, not sure whether there are better ways, it's just an example for being creative while not resorting to software rendering. :)
I see, that is pretty clever. I'll give that a try sometime in the future and hit you up with the results. As is, I'm pretty happy with my results for the day (I've been working at this since I sat down last night at around 8 pm... it's currently 11:50 am lol).

Screenshot of my results:

Image

Things it's doing:
-Drawing at 320x240 @ 4bpp
-Drawing one Sonic with one palette, drawing from TR_POLY list
-manually changing entries in second 16-color palette to green (all but entry 0, which is alpha color)
-Drawing second sonic at the same position, but rotated a couple of degrees, using the second palette

I've also got it running on the dreamcast in the other room just to make sure. On a CRT, the color reduction from 8bpp to 4bpp really isn't noticeable on this sprite (although on a monitor it is). I think my next immediate goal is looking into VQ compression so I can get the most out of VRAM :)
Still Thinking!~~
Chilly Willy
DC Developer
DC Developer
Posts: 414
Joined: Thu Aug 20, 2009 11:00 am
Has liked: 0
Been liked: 2 times

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

Post by Chilly Willy » Wed Jul 27, 2016 1:24 pm

Something to think about - rather than try to mimic mid-line color changes, draw everything except the water, then draw the water with alpha. It would actually look more like water that way as well as avoiding palette tricks.

Hmm - that would be on a per-layer basis, of course. That way if the water is in the background, the foreground would be in front of the water.
User avatar
ThePerfectK
DCEmu Freak
DCEmu Freak
Posts: 94
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 » Thu Jul 28, 2016 2:34 am

Chilly Willy wrote:Something to think about - rather than try to mimic mid-line color changes, draw everything except the water, then draw the water with alpha. It would actually look more like water that way as well as avoiding palette tricks.

Hmm - that would be on a per-layer basis, of course. That way if the water is in the background, the foreground would be in front of the water.
Well that is what I plan to fall back on if nothing else works, but thats my worst case scenario. The water in sonic games looks really distinctive, and an alpha blended layer looks nothing like the effect.

Beaides I sort of like bogglez idea and want to try my hand at it. Funnily enough, I sort of feel like all this was easier when I wrote the entire renderer from scratch in software on my PC, lol. That gave me very fine control over every single pixel draw. But part of the fun of taking up new hardware is thinking outside the box. I'll admit that I'm having loads of fun right now.

One problem with your suggestion, though - in order to blend all my sprites with a water alpha layer, that would mean I'd also have to draw all my sprites as translucent polygons, right? Looking at other topics, there is a debate about how much slower drawing translucent polygons is than drawing opaque or punch-through polygons, correct? Would I be getting a substantial performance hit by drawing water this way? If I did want to draw water as an alpha layer, I could cut it into smaller tiles and give the water a pattern to blend in, rather than just color (so I could, like, draw zig-zagging waves in the water). In that case, I'd be drawing more polygons than if I just did one giant polygon and stretch it over the field - is that slower as well? To give a rough estimate of the number of polygons I'd like to draw - I'd say, at most, Sonic has maybe 100 sprites on screen at once, counting forground objects and the background layers as sprites as well. That would be about 100 polygons drawn per frame.

I'm sort of paranoid about performance and want to do as much as possible to keep things running as fast as possible, haha. I'm using fmath, for example, because it's apparently optimized with sh inline assembly?
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 » Thu Jul 28, 2016 3:16 am

Translucent = punchthru. You mean transparent.
Punchthru is almost as cheap as opaque, so go wild
Drawing 2 transparent polygons for water doesn't even make the pvr sneeze. The layer below can be drawn opaque/translucent.
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: 94
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 » Thu Jul 28, 2016 3:25 am

bogglez wrote:Translucent = punchthru. You mean transparent.
Punchthru is almost as cheap as opaque, so go wild
Drawing 2 transparent polygons for water doesn't even make the pvr sneeze. The layer below can be drawn opaque/translucent.
Ah, thanks for the clarification.

What if I needed to cover the screen in, say, 16x16 polygons? Like, if I wanted to have a small pattern repeat over the water rather than stretch a single texture across the entire thing, I'd have to chop it up into smaller polygons, right? Would drawing an entire screen's worth of 16x16 polygons over the entire scene bring the PVR to its knees?
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 » Thu Jul 28, 2016 3:30 am

I doubt that, but you should base your judgement on benchmarks, not speculation. You should develop a habit of writing code in a way that you can measure it and easily replace it in the future if the time measurement looks bad. That code is easy to write so you shouldn't feel too bad about deleting it later.
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: 94
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 » Thu Jul 28, 2016 8:13 am

Just thinking outloud - if I render to a texture, I could achieve anamorphic widescreen, no? If im outputting a 320x240, I could render a 360x240 texture and just blit to a 320x240 quad, which would compress it horizontally. Any reason that wouldn't work?
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 » Thu Jul 28, 2016 8:30 am

ThePerfectK wrote:if I render to a texture, I could achieve anamorphic widescreen, no? If im outputting a 320x240, I could render a 360x240 texture and just blit to a 320x240 quad, which would compress it horizontally. Any reason that wouldn't work?
Read the docs http://gamedev.allusion.net/docs/kos-cu ... d40d5cdb8c
I haven't checked the implementation to see whether it would be possible to change the resolution in such a way.
I also think that filtering might look bad when you shrink pixel art that way.
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: 94
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 » Thu Jul 28, 2016 8:35 am

bogglez wrote:
ThePerfectK wrote:if I render to a texture, I could achieve anamorphic widescreen, no? If im outputting a 320x240, I could render a 360x240 texture and just blit to a 320x240 quad, which would compress it horizontally. Any reason that wouldn't work?
Read the docs http://gamedev.allusion.net/docs/kos-cu ... d40d5cdb8c
I haven't checked the implementation to see whether it would be possible to change the resolution in such a way.
I also think that filtering might look bad when you shrink pixel art that way.
On the contrary, it might work to my advantage. Many old genesis style games relied on dithering and alternating strips of stipple shading to fake transparency and generate more colors. Since I plan on using art straight from the genesis binary, this might work into my favor. I'll need to look at the filtering options available.
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 » Thu Jul 28, 2016 8:43 am

You won't get dithering, you'll get linear filtering or nearest neighbor filtering with missing lines
Attachments
point-vs-linear.png
point-vs-linear.png (20.85 KiB) Viewed 935 times
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: 94
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 » Thu Jul 28, 2016 9:28 am

bogglez wrote:You won't get dithering, you'll get linear filtering or nearest neighbor filtering with missing lines
Yeah, that's my point - the stretching will turn the dithering into what appears to be transparency thanks to linear filtering. I actually apply a linear filter to my SDL software renderer in the PC version of my program.

Unfortunately I'm at my office today (rarely have to actually go into the office) so I can't play around with this til tonight. I'm really curious to see what this will look like on a TV.
Still Thinking!~~
Chilly Willy
DC Developer
DC Developer
Posts: 414
Joined: Thu Aug 20, 2009 11:00 am
Has liked: 0
Been liked: 2 times

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

Post by Chilly Willy » Thu Jul 28, 2016 11:53 am

ThePerfectK wrote:
Chilly Willy wrote:Something to think about - rather than try to mimic mid-line color changes, draw everything except the water, then draw the water with alpha. It would actually look more like water that way as well as avoiding palette tricks.

Hmm - that would be on a per-layer basis, of course. That way if the water is in the background, the foreground would be in front of the water.
Well that is what I plan to fall back on if nothing else works, but thats my worst case scenario. The water in sonic games looks really distinctive, and an alpha blended layer looks nothing like the effect.
True, if you're trying to get the exact "Sonic" look to water, it's not quite the same. It is the easiest way to handle it, though.
Beaides I sort of like bogglez idea and want to try my hand at it. Funnily enough, I sort of feel like all this was easier when I wrote the entire renderer from scratch in software on my PC, lol. That gave me very fine control over every single pixel draw. But part of the fun of taking up new hardware is thinking outside the box. I'll admit that I'm having loads of fun right now.
That's good. Nothing keeps a dev on a project like enjoying the work they're doing. 8-)

One problem with your suggestion, though - in order to blend all my sprites with a water alpha layer, that would mean I'd also have to draw all my sprites as translucent polygons, right?
You would need to at least use the ARGB1555 mode (for the pixels or the palette entries if paletted sprites) to specify on/off for the pixels making the sprite. Over reasonable size and numbers of these type of objects, I've not noticed any performance problems on the DC.
Looking at other topics, there is a debate about how much slower drawing translucent polygons is than drawing opaque or punch-through polygons, correct? Would I be getting a substantial performance hit by drawing water this way? If I did want to draw water as an alpha layer, I could cut it into smaller tiles and give the water a pattern to blend in, rather than just color (so I could, like, draw zig-zagging waves in the water). In that case, I'd be drawing more polygons than if I just did one giant polygon and stretch it over the field - is that slower as well? To give a rough estimate of the number of polygons I'd like to draw - I'd say, at most, Sonic has maybe 100 sprites on screen at once, counting forground objects and the background layers as sprites as well. That would be about 100 polygons drawn per frame.

I'm sort of paranoid about performance and want to do as much as possible to keep things running as fast as possible, haha. I'm using fmath, for example, because it's apparently optimized with sh inline assembly?
I doubt you'll see any performance issues on a simple 2D game like this. At least on the rendering end of things. You'll want to watch the entity-ai side of things - remember the ring slowdown on hits as an example of how not to do that. :lol:

Fast math is fast because it ignores things like checking arguments for NaNs, signed zeroes, and other such ieee nonsense. It has nothing to do with assembly, per se. When compiling, during the optimization phase, nothing beats generating the assembly source to see what the compiler is actually doing. Just add "-S" to the compiler options to get the assembly for that file.
User avatar
ThePerfectK
DCEmu Freak
DCEmu Freak
Posts: 94
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 » Thu Jul 28, 2016 12:03 pm

Mm, I'm considering going towards a system that draws a grid of 8x8 tiles as polygons, with 5 layers drawn to the screen. Done some worse case scenario math, and in those instances I'd be drawing about 12000-13000 polygons on screen at once - surely that is well within the capabilities of the PVR, right? I know general benchmarks are hard to find, but the dreamcast could crunch over a million polygons with general ease, right? Even if I went to 640x480 mode, I'm still drawing south of 50,000 polygons at a worse case scenario (worse case being the entire screen covered in tiles, top to bottom, for all 5 layers = 640x480 = 307,200 / 64 = 4800 * 2 (quad = 2 triangles) = 9600 * 5 layers = 48,000).

Reason for wanting to render tiles this way is that my PC code is actually compatible with the Genesis binary - I can pull art in and out of the Sonic rom. The underlaying logic behind the game is generally in line with the original engine, allowing for a degree of interoperability. I'd like the dreamcast version to follow the same sort of logic, albeit rendering with the PVR for speed.

speaking of benchmarking, Booglez suggested I benchmark my own programs. I find that sort of hard to do on a real dreamcast without a console to output to, any general guidelines you guys use to bench mark your dreamcast projects? On a modern PC, most of my framerate code is limited to actually slowing down and making the program wait for the next frame because it runs at thousands of frames per second, where as it's conceivable I'll have the opposite problem on the dreamcast - where it might run below 60 fps. How can I measure how many frames I'm rendering in a second if it dips below 60?

As for enemy AI - the enemy AI in Sonic is actually sort of dumb. I have a LUA-based script system for enemy AI on the PC side of things. I'm generally well versed on the bottle necks of the Sonic Engine and how they tackled those problems on the genesis (lots of sin and cos look up charts, lol) so I don't think that stuff will be a problem. Really, my main concern has been video from the beginning.
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 » Thu Jul 28, 2016 12:55 pm

You haven't faced a single performance problem yet and you're getting hung up on performance details already, although you don't know the hardware.
For example you won't actually be drawing all those triangles. The pvr will submit them to an array in each screen tile they may be in and determine which triangles will actually be visible before it starts drawing them (so fillrate won't be a problem for example).
So i'd bluntly say stop thinking about how things might be and actually implement them.
As to benchmarking, if you have no serial access you'll have to draw text to the screen, run an emulator or send data over the network (and use netcat on the PC).
Gather timings for rendering and other stuff separately. Calculate min, max and median.
Check how long rendering the water takes vs particles etc. And as long as you're constantly below 60 fps it doesn't matter whether your water effect code is slow.
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: 94
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 » Thu Jul 28, 2016 1:10 pm

bogglez wrote:You haven't faced a single performance problem yet
Not quite true - I ported over my software rendering SDL engine back in 2014, and it ran like molasses lol
you're getting hung up on performance details already, although you don't know the hardware.
Not so much hung up, rather than wondering out loud. House of cards analogy - strong base first and foremost. Just want to make sure I don't start down a path that'll waste me time.
The pvr will submit them to an array in each screen tile they may be in and determine which triangles will actually be visible before it starts drawing them (so fillrate won't be a problem for example).
This is great to hear!
So i'd bluntly say stop thinking about how things might be and actually implement them.
I'd love to be implementing this stuff right now, lol. I'm stuck at the office filling out some dummy data for my actual paying project and it's mind numbing... hence my meandering postings this morning.
As to benchmarking, if you have no serial access you'll have to draw text to the screen, run an emulator or send data over the network (and use netcat on the PC).
Gather timings for rendering and other stuff separately. Calculate min, max and median.
Check how long rendering the water takes vs particles etc. And as long as you're constantly below 60 fps it doesn't matter whether your water effect code is slow.
Mm, no serial cable but I have a serial SD card adapter, can I write logs to that device?
Still Thinking!~~
Chilly Willy
DC Developer
DC Developer
Posts: 414
Joined: Thu Aug 20, 2009 11:00 am
Has liked: 0
Been liked: 2 times

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

Post by Chilly Willy » Thu Jul 28, 2016 1:22 pm

If you're running in fake cd mode off the SD, no writing the SD card. If you have either the serial cable or the BBA, you can use dcload/dctool to run the game and get feedback on the PC. If you don't have either, you can print messages to the screen (what I did for a long time), or boot from a cdr and write log files to the SD card.

And yes, I imagine fully software rendered was horrifically slow. :lol:

What I normally do for FPS is to advance a variable each time the screen is rendered, then read and reset that variable once per second. That's all the faster you want to update the FPS in any case, and it makes getting the FPS super-easy.
User avatar
ThePerfectK
DCEmu Freak
DCEmu Freak
Posts: 94
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 » Fri Jul 29, 2016 8:22 am

Took a stab at Booglez suggestion about chopping the screen up into thin, horizontal polygons, works great. Let's me imitate raster effects like line scroll:

Image

I can also change palettes mid-draw this way just like on the genesis :D
Still Thinking!~~
Post Reply