Shaders
- Newbie
- 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
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.
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.
- BlueCrab
- The Crabby Overlord
- Posts: 5665
- 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
Unfortunately, the PVR in the Dreamcast does not support any sort of shaders whatsoever.
- Corbin
- DC Developer
- Posts: 121
- Joined: Fri Dec 14, 2007 1:56 am
- Location: California
- Has thanked: 0
- Been thanked: 0
Re: Shaders
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.
- BlueCrab
- The Crabby Overlord
- Posts: 5665
- 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
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.
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.
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.
-
- DC Developer
- Posts: 968
- Joined: Tue Feb 11, 2003 4:12 pm
- Location: In a Dream
- Has thanked: 5 times
- Been thanked: 6 times
What is a shader? technically speaking...
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.
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
inspired by Dreamcast
Re: Shaders
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 .... .
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 .... .
- BlueCrab
- The Crabby Overlord
- Posts: 5665
- 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
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.
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.
- MisterDave
- DCEmu Freak
- Posts: 58
- Joined: Mon Apr 08, 2013 1:16 pm
- Has thanked: 0
- Been thanked: 0
Re: Shaders
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.
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.
Re: Shaders
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.
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.
- MisterDave
- DCEmu Freak
- Posts: 58
- Joined: Mon Apr 08, 2013 1:16 pm
- Has thanked: 0
- Been thanked: 0
Re: Shaders
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.
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.
- PH3NOM
- DC Developer
- Posts: 576
- Joined: Fri Jun 18, 2010 9:29 pm
- Has thanked: 0
- Been thanked: 5 times
Re: Shaders
Great work keep it up!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.
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.
- BlueCrab
- The Crabby Overlord
- Posts: 5665
- 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
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.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.
- MisterDave
- DCEmu Freak
- Posts: 58
- Joined: Mon Apr 08, 2013 1:16 pm
- Has thanked: 0
- Been thanked: 0
Re: Shaders
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.
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.
Re: Shaders
Thanks a lot i translate it and read !
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.
Well if it's not SH4 making the transformation what is it ?
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.
- MisterDave
- DCEmu Freak
- Posts: 58
- Joined: Mon Apr 08, 2013 1:16 pm
- Has thanked: 0
- Been thanked: 0
Re: Shaders
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.Well if it's not SH4 making the transformation what is it ?
- PH3NOM
- DC Developer
- Posts: 576
- Joined: Fri Jun 18, 2010 9:29 pm
- Has thanked: 0
- Been thanked: 5 times
Re: Shaders
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":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.
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?.
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 driverBlueCrab 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.
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.
- BlueCrab
- The Crabby Overlord
- Posts: 5665
- 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
Or, for me to get a chance to actually look at the code and find the issue to fix it.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
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.
- MisterDave
- DCEmu Freak
- Posts: 58
- Joined: Mon Apr 08, 2013 1:16 pm
- Has thanked: 0
- Been thanked: 0
Re: Shaders
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.
- PH3NOM
- DC Developer
- Posts: 576
- Joined: Fri Jun 18, 2010 9:29 pm
- Has thanked: 0
- Been thanked: 5 times
Re: Shaders
Most Excellent.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.
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 ).
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 ).
- BlueCrab
- The Crabby Overlord
- Posts: 5665
- 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
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.
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.