Shaders

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
Newbie
Insane DCEmu
Insane DCEmu
Posts: 171
https://www.artistsworkshop.eu/meble-kuchenne-na-wymiar-warszawa-gdzie-zamowic/
Joined: Sat Jul 27, 2013 1:16 pm
Has thanked: 0
Been thanked: 0

Shaders

Post by Newbie »

I want to know if in KOS in particular but in Dreamcast architecture in general, it's possible to make use of shader and how.

When I talk about shader, I did not mean the ones used actually in NVDIA/GEOFORCE/ATI cards with HLSL or GLSL precompiled fragments language.

I have read somewhere than Dreamcast (PowerVR CLX2) is shader 1 compatible but only in assembly language:

https://en.wikipedia.org/wiki/PowerVR

I talk about a very simple shader code sample acting in pixel color transformation (not vertex or 3D operations).

For example let's talk about a "dummy piece of code" which could transform all pixel colors of a texture by changing the red (or green or blue) part of it.

By the way, I want to make such transformation in the write process (as a shader make it in NVDIA/GEOFORCE/ATI cards) and not change the original texture data nor forced to used a back buffer texture to recalculate the new data (which is a common software approach).

Thanks.
User avatar
BlueCrab
The Crabby Overlord
The Crabby Overlord
Posts: 5652
Joined: Mon May 27, 2002 11:31 am
Location: Sailing the Skies of Arcadia
Has thanked: 9 times
Been thanked: 69 times
Contact:

Re: Shaders

Post by BlueCrab »

Unfortunately, the PVR in the Dreamcast does not support any sort of shaders whatsoever.
User avatar
Corbin
DC Developer
DC Developer
Posts: 121
Joined: Fri Dec 14, 2007 1:56 am
Location: California
Has thanked: 0
Been thanked: 0

Re: Shaders

Post by Corbin »

He's right. It's led to numerous problems (but solutions prevailed...after a year or so) with our game engine and having to rewrite the Q3 map format to use static textures rather than shaders that were built into them. The result was the Q3 map format supporting only Q2 extensions without shaders. Interesting beast. Not recommended.
User avatar
BlueCrab
The Crabby Overlord
The Crabby Overlord
Posts: 5652
Joined: Mon May 27, 2002 11:31 am
Location: Sailing the Skies of Arcadia
Has thanked: 9 times
Been thanked: 69 times
Contact:

Re: Shaders

Post by BlueCrab »

Just to start this off, none of this is meant to be mean or anything. It's more meant as a bit of a history lesson, without getting too deep into the subject. I just wanted to get that out of the way, because after writing this, I could see how it would be taken to be kind of in an rude fashion, and I don't want to come off that way with this post. :wink:

Considering when the Dreamcast was released, and the fact that even some graphics cards released 4 years after the release of the Dreamcast didn't support shaders, it really shouldn't come as that much of a surprise that it doesn't support shaders, if you think about it.

Figure that the PowerVR CLX2 design was probably finalized circa 1997. GLSL became part of OpenGL with OpenGL 2.0, which was released around 2002, if I recall correctly. DirectX didn't support any sort of shaders until DirectX 8, which was released in late 2000 (and that wasn't even HLSL shaders at that point). When the CLX2 was released, hardware transform and lighting wasn't even really an option in consumer-grade hardware, to put things in perspective. I think the first cards that supported programmable shaders were released in 2000, alongside cards that still didn't all support hardware T&L. :wink:
nymus
DC Developer
DC Developer
Posts: 968
Joined: Tue Feb 11, 2003 4:12 pm
Location: In a Dream
Has thanked: 5 times
Been thanked: 5 times

What is a shader? technically speaking...

Post by nymus »

Considering that the OP is inquiring about shaders at the most basic level, perhaps it would be useful to consider the question at a fundamental level?

I have little more than a basic theoretical understanding of shaders but from what I know, the actual shader language used in the high level APIs (OpenGL etc) is for human text and is compiled to target a particular GPU.

Shaders in essence simply mean that a GPU can alter its render pipeline according to a particular input. So for example, if the GPU can change the colour of a pixel in one texture based on the values in another texture, we could say that the second texture is, technically, the shader, couldn't we?

I recognize that modern shaders offer complete flow control but the earliest revisions of GLSL et al were pretty basic.

One could create a language to map "some" programmable features of Dreamcast's PVR to the shader approach of graphics programming... maybe...

Just a thought.
Last edited by nymus on Mon Mar 03, 2014 9:36 am, edited 1 time in total.
behold the mind
inspired by Dreamcast
User avatar
Newbie
Insane DCEmu
Insane DCEmu
Posts: 171
Joined: Sat Jul 27, 2013 1:16 pm
Has thanked: 0
Been thanked: 0

Re: Shaders

Post by Newbie »

It's exactly what i mean :

not to create a new shading language for Dreamcast or adapt a GLSL specialized version but a make very low level approach (ASM) to execute such transformation but like the shaders do in modern cards.

By "like the shaders do in modern cards" i mean not using temp buffers or software operations but register hardware call to process on the fly datas before displaying it : its the way shader 1.0 works.

If it's possible to create a snippet asm code that could make such operations then we are able to include it on C or C++ code ... if you know what i mean .... :).
User avatar
BlueCrab
The Crabby Overlord
The Crabby Overlord
Posts: 5652
Joined: Mon May 27, 2002 11:31 am
Location: Sailing the Skies of Arcadia
Has thanked: 9 times
Been thanked: 69 times
Contact:

Re: Shaders

Post by BlueCrab »

Could one design a shading language of some sort to reuse the fixed-function pipeline on the Dreamcast? Sure. It wouldn't do nearly what most people expect in a shading language, and it would pretty much have to break the normal flow of the pipeline, which would limit its usefulness.

That said, no such thing exists, and there's no easy way to make it happen in a way that acts at all like a normal shading language, so I stand by my earlier statement that there is and never will be a real shading language for the Dreamcast's video hardware. The hardware isn't programmable enough to make it happen in a sane manner. The closest you can really get to any sort of programmable pipeline is to use modifier volumes, which aren't really close at all.
User avatar
MisterDave
DCEmu Freak
DCEmu Freak
Posts: 58
Joined: Mon Apr 08, 2013 1:16 pm
Has thanked: 0
Been thanked: 0

Re: Shaders

Post by MisterDave »

Newbie is there a specific effect that you want to create on the Dreamcast (with shaders)? There are some which you can create using a fixed function pipeline (light bloom, depth of field), but they need to be integrated into the game engine and your frame-rate will take a hit, however, it can be done.

To give an example (any excuse :) ) the image on the right shows light bloom applied to a scene in my current engine build. All of this is fixed function including the dynamic shadowing.
Image
User avatar
Newbie
Insane DCEmu
Insane DCEmu
Posts: 171
Joined: Sat Jul 27, 2013 1:16 pm
Has thanked: 0
Been thanked: 0

Re: Shaders

Post by Newbie »

Impressive !
What frame rate you obtain with your Gloom shading ?

Well for a beginning i want to implement basic stuff like changing whole R or G or B value of a texture on the fly, making a texture "grey scale". After i will try to implement water effect like water drop ...

But before i need to know the most quick and efficient way to do this using the best of PVR hardware.
User avatar
MisterDave
DCEmu Freak
DCEmu Freak
Posts: 58
Joined: Mon Apr 08, 2013 1:16 pm
Has thanked: 0
Been thanked: 0

Re: Shaders

Post by MisterDave »

The frame-rate is always going to be half (or less than that) of the frame-rate without the effects as the DC has to render two frames each time. If your engine is running at a smooth 60fps, then you should be able get somewhere between 15 and 30fps depending on optimisations, so you have to be careful where you used the effect.

There is a good overview of how the Shadow of the Colossus developers did light bloom (and other effects) on the PS2 architecture here. It is in Japanese, but Google Translate should do the trick:
http://game.watch.impress.co.jp/docs/20051207/3dwa.htm

From that I learned that bloom is done by rendering the bright parts of a scene to a texture then shrinking it down then blowing it up again to create a blur. Originally I used two textures, but you can get away with only one if you use the glViewport twice. When rendering the texture, using a radial blur from Nehe lesson 36 makes the effect more vivid:
http://nehe.gamedev.net/tutorial/lessons_36__40/19005/

Hope that helps a bit.
User avatar
PH3NOM
DC Developer
DC Developer
Posts: 576
Joined: Fri Jun 18, 2010 9:29 pm
Has thanked: 0
Been thanked: 5 times

Re: Shaders

Post by PH3NOM »

MisterDave wrote:The frame-rate is always going to be half (or less than that) of the frame-rate without the effects as the DC has to render two frames each time. If your engine is running at a smooth 60fps, then you should be able get somewhere between 15 and 30fps depending on optimisations, so you have to be careful where you used the effect.

There is a good overview of how the Shadow of the Colossus developers did light bloom (and other effects) on the PS2 architecture here. It is in Japanese, but Google Translate should do the trick:
http://game.watch.impress.co.jp/docs/20051207/3dwa.htm

From that I learned that bloom is done by rendering the bright parts of a scene to a texture then shrinking it down then blowing it up again to create a blur. Originally I used two textures, but you can get away with only one if you use the glViewport twice. When rendering the texture, using a radial blur from Nehe lesson 36 makes the effect more vivid:
http://nehe.gamedev.net/tutorial/lessons_36__40/19005/

Hope that helps a bit.
Great work keep it up!
I am curious what resolution you are using? From the screens and the videos you have posted, it looks to me like you are using the 320x240 video mode.

I could be wrong since I have not enabled the FPS output on this example, but from what I can tell, render-to-texture does not mean the PVR drops to 30fps when rendering to a texture and then rendering to the frame buffer for display in one frame.
viewtopic.php?f=29&t=102836&start=20#p1042266
I will have to enable the FPS debugger in my code against my example, but it did not feel like the FPS took a hit when I enabled render-to-texture.
I have not looked at the source to the PVR driver in KOS, but the way I imagine it, I don't think a render-to-texture should have to wait for a Vblank to complete the render, so it should theoretically be possible to render-to-textures at much higher than 60FPS.

From what it sounded like, you are transferring the render-to-texture result back to the SH4 for tweaking before sending the texture back to the PVR to be rendered, that likely is the reason for the FPS taking a solid hit.

Also, thanks for that Shadow of Colossus link, when I get some time I will take a look at it.
I have not yet got to post-processing effects on the DC, aside from a simple light glare effect that is seen in the screens I posted.
This was achieved by transforming the light position by the render matrix stack. If the light is visible on-screen ( do a dot-product of light position and camera position, from there some occlusion code could be used ), then I render a 2D sprite at the lights position and color.
User avatar
BlueCrab
The Crabby Overlord
The Crabby Overlord
Posts: 5652
Joined: Mon May 27, 2002 11:31 am
Location: Sailing the Skies of Arcadia
Has thanked: 9 times
Been thanked: 69 times
Contact:

Re: Shaders

Post by BlueCrab »

PH3NOM wrote:I could be wrong since I have not enabled the FPS output on this example, but from what I can tell, render-to-texture does not mean the PVR drops to 30fps when rendering to a texture and then rendering to the frame buffer for display in one frame.
viewtopic.php?f=29&t=102836&start=20#p1042266
I will have to enable the FPS debugger in my code against my example, but it did not feel like the FPS took a hit when I enabled render-to-texture.
I have not looked at the source to the PVR driver in KOS, but the way I imagine it, I don't think a render-to-texture should have to wait for a Vblank to complete the render, so it should theoretically be possible to render-to-textures at much higher than 60FPS.
Actually, I'm pretty sure that the way that the render-to-texture code is in KOS, it does actually have to wait for a vblank. It has been a while since I looked at it, but I do recall that there were one or two outstanding issues with it to that effect. It shouldn't have to, but I'm pretty sure there's something that's not quite correct in the code that requires it to.
User avatar
MisterDave
DCEmu Freak
DCEmu Freak
Posts: 58
Joined: Mon Apr 08, 2013 1:16 pm
Has thanked: 0
Been thanked: 0

Re: Shaders

Post by MisterDave »

Hi Ph3nom and BlueCrab. The resolution is 640x480 rendered to a 1024x512 texture. It probably looks lower due to my somewhat lazy capture method through a camera pointed at the screen :)

Through trial and error I found that a forced vblank by calling pvr_wait_ready() was needed before drawing the 'render from texture' frame. This was the same when I was using the pvr/parallax APIs and later with KGL with my hacked in 'render to texture' function.

At the moment I'm not modifying the texture's pixels with the SH4, but I would like to experiment with that in the future.
User avatar
Newbie
Insane DCEmu
Insane DCEmu
Posts: 171
Joined: Sat Jul 27, 2013 1:16 pm
Has thanked: 0
Been thanked: 0

Re: Shaders

Post by Newbie »


The frame-rate is always going to be half (or less than that) of the frame-rate without the effects as the DC has to render two frames each time. If your engine is running at a smooth 60fps, then you should be able get somewhere between 15 and 30fps depending on optimisations, so you have to be careful where you used the effect.

There is a good overview of how the Shadow of the Colossus developers did light bloom (and other effects) on the PS2 architecture here. It is in Japanese, but Google Translate should do the trick:
http://game.watch.impress.co.jp/docs/20051207/3dwa.htm

From that I learned that bloom is done by rendering the bright parts of a scene to a texture then shrinking it down then blowing it up again to create a blur. Originally I used two textures, but you can get away with only one if you use the glViewport twice. When rendering the texture, using a radial blur from Nehe lesson 36 makes the effect more vivid:
http://nehe.gamedev.net/tutorial/lessons_36__40/19005/

Hope that helps a bit.
Thanks a lot i translate it and read !

At the moment I'm not modifying the texture's pixels with the SH4, but I would like to experiment with that in the future.
Well if it's not SH4 making the transformation what is it ?
User avatar
MisterDave
DCEmu Freak
DCEmu Freak
Posts: 58
Joined: Mon Apr 08, 2013 1:16 pm
Has thanked: 0
Been thanked: 0

Re: Shaders

Post by MisterDave »

Well if it's not SH4 making the transformation what is it ?
Oops, I may have given the wrong impression. The SH4 is doing the transformations through the KGL API as you would expect, but what I was suggesting was that in the bloom effect once a scene is rendered to a texture then it is the PVR that does the alpha blending on the quad (which gets drawn multiple times at increasing scale) rather than manipulating the pixels of the texture manually in code.
User avatar
PH3NOM
DC Developer
DC Developer
Posts: 576
Joined: Fri Jun 18, 2010 9:29 pm
Has thanked: 0
Been thanked: 5 times

Re: Shaders

Post by PH3NOM »

Corbin wrote:He's right. It's led to numerous problems (but solutions prevailed...after a year or so) with our game engine and having to rewrite the Q3 map format to use static textures rather than shaders that were built into them. The result was the Q3 map format supporting only Q2 extensions without shaders. Interesting beast. Not recommended.
I agree, the Q3 map format was an interesting beast, but Im pretty sure the "shaders" in Q3 should be able to be handled by the CPU. Makes sense when you consider the essence of a "shader":
nymus wrote:Shaders in essence simply mean that a GPU can alter its render pipeline according to a particular input. So for example, if the GPU can change the colour of a pixel in one texture based on the values in another texture, we could say that the second texture is, technically, the shader, couldn't we?.
BlueCrab wrote:Actually, I'm pretty sure that the way that the render-to-texture code is in KOS, it does actually have to wait for a vblank. It has been a while since I looked at it, but I do recall that there were one or two outstanding issues with it to that effect. It shouldn't have to, but I'm pretty sure there's something that's not quite correct in the code that requires it to.
Bummer. Would be nice to see that limitation removed, since it is not a hardware limitation. I guess we will have to wait for Tapamn to release his PVR driver :-)

I looked at my code and realized why I was under the impression that things were still at 60fps. I didn't consider that pvr_stats counts a frame rendered to texture as a frame drawn. I was running at 60fps, but only 30 frames actually rendered to the screen.
User avatar
BlueCrab
The Crabby Overlord
The Crabby Overlord
Posts: 5652
Joined: Mon May 27, 2002 11:31 am
Location: Sailing the Skies of Arcadia
Has thanked: 9 times
Been thanked: 69 times
Contact:

Re: Shaders

Post by BlueCrab »

PH3NOM wrote:Bummer. Would be nice to see that limitation removed, since it is not a hardware limitation. I guess we will have to wait for Tapamn to release his PVR driver :-)
Or, for me to get a chance to actually look at the code and find the issue to fix it. :wink:

Alas, work and my research project for the university are keeping me busy...

EDIT: Well, that was an easy enough fix. Test it out and make sure everything works correctly still with your render-to-texture stuff. It looks right to me, and works with the very simple pvr/texture_render example at least.
This is what happens when people actually start using code in KOS that nobody really ever uses. Things get noticed and I feel the need to fix them. :lol:
User avatar
MisterDave
DCEmu Freak
DCEmu Freak
Posts: 58
Joined: Mon Apr 08, 2013 1:16 pm
Has thanked: 0
Been thanked: 0

Re: Shaders

Post by MisterDave »

Thanks BlueCrab. I've been doing some optimisation to my engine lately and looking for any way to keep the main render loop at 60hz so that the overhead of the texture render doesn't hit the overall rate too hard. This patch would be very much welcomed as not needing to wait for a vblank means that this performance hit should be reduced significantly. I will post my results after trying this patch.
User avatar
PH3NOM
DC Developer
DC Developer
Posts: 576
Joined: Fri Jun 18, 2010 9:29 pm
Has thanked: 0
Been thanked: 5 times

Re: Shaders

Post by PH3NOM »

BlueCrab wrote:EDIT: Well, that was an easy enough fix. Test it out and make sure everything works correctly still with your render-to-texture stuff. It looks right to me, and works with the very simple pvr/texture_render example at least.
This is what happens when people actually start using code in KOS that nobody really ever uses. Things get noticed and I feel the need to fix them. :lol:
Most Excellent. 8-)

I had a go at updating KOS tonight with your patches. I had to modify my lib to adapt to the changes ( mostly due to the changes made to handle sequential frames rendered to texture that were not included in kos 2.0, not so much the change to allow skipping the v-sync interrupt for render-to-texture ).

Image

Anyhow, things seem to be working nicely, but the pvr_stats might be a little off?
Pvr_stats report ~71.43 fps, but recording the Frame Rate through CPU time, my code suggests ~120fps.
Here is a demo I put together tonight to test texture render.
Press 'A' to switch to Texture Render. Press 'B' To Disable Texture Render.
I have not ran on real hardware ( only emu ).
gltest-txrrndr.rar
OpenGL DC Render-To-Texture Example
(1.25 MiB) Downloaded 95 times
User avatar
BlueCrab
The Crabby Overlord
The Crabby Overlord
Posts: 5652
Joined: Mon May 27, 2002 11:31 am
Location: Sailing the Skies of Arcadia
Has thanked: 9 times
Been thanked: 69 times
Contact:

Re: Shaders

Post by BlueCrab »

If you're getting the frame rate from the "frame_rate" variable in the pvr_stats_t structure, that is based only on the last frame that was completed. You're probably seeing what you're seeing because of how the frames rendered to the screen still have to wait for the vblank interrupt before updating that value in the structure.

At least that would be my guess without looking at the program at all. I'll take a look at the program on the real hardware sometime after I get some sleep.
Post Reply