GP2X Trenki's Software Renderer Tutorial


You can't do swizzling, that is selecting arbitrary components from a vector and form a new one with them with the vector math library. Something like this would certainly be implementable most likely with the help of macros. Otherwise you simply have to select the appropriate components yourself and form a new vector.

But for performance reasons I strongly advice you not to keep the use of the vector math library withing the fragment shaders to a minimum and also avoid the SDL_MapRGB and other potentially costly functions.

If possible you should directly work with 16bit R5G5A1B5 or R5G6B5 color values and write some helper functions that directly work in this representation.

Still, there might be places where the vector math library is useful within the fragment shader, for instance when you interpolate the normal vector and want to normalize it. This is just an example, actually interpolating and normalizing the normal vector would certainly be too expensive for larger models on the GP2X
 
I'm having trouble with the textures. It was working but I don't know what I've modified that now I have dancing textures. All work okay, I even got dynamic lighting working, just for fun, but the textures are dancing like on a Playstation, but much worse. What do you think it could be the cause of the problem? I can't post all the source, but do you have any thoughts about what could be?

I'm comparing your sample codes and my code but can't see what's wrong :(
 
efegea said:
I'm having trouble with the textures. It was working but I don't know what I've modified that now I have dancing textures. All work okay, I even got dynamic lighting working, just for fun, but the textures are dancing like on a Playstation, but much worse. What do you think it could be the cause of the problem? I can't post all the source, but do you have any thoughts about what could be?

I'm comparing your sample codes and my code but can't see what's wrong :(
Well, I can't see how it looks or what you have modified for it to not work any more. Either it is something you modified directly in the fragment shader or it might have something to do with the precision of the texture coordinates. In what format are the texture coordinates beein interpolated? 24.8, 8.24 or 16.16 or maybe even something else. 8.24 might give a bit better precision for the texture coordinates. Still, in my NFS3 level renderer I use 16.16 and it works ok. I had some precision problems with texture coordinates there too, but scaling the scene down a bit (simply use a scaling matrix in the vertex shader to do that) helped a lot. Maybe you could try that out. Scaling can help as it affects the range of the w coordinate which is used for perspective correct texturing. I suppose the texture swimming is in perspective mode and doesn't show if you disable perspective correct texturing.
 
Last edited by a moderator:
If I disable perspective correction the effect dissapears


EDIT: it doesn't totally dissapear, but I think it's because the lack of perspective correction..
 
efegea said:
If I disable perspective correction the effect dissapears
EDIT: it doesn't totally dissapear, but I think it's because the lack of perspective correction..


Yep, it seems i had the same problem. Try scaling the scene down and/or play with the near and far clipping plane distances (especially the near distance) in your perspective transformation matrix. This will hopefully bring the post vertex shader values into a suitable range that minimizes errors. The nearer the post vertex shader w value is to one the less errors there should be as the w value is basically the distance from the camera.
 
Last edited by a moderator:
Hi,
I was looking into this, but when I compiled and ran the cow demo, it seems like the cow is rotating around a place in fron of the the camera, and its all distorted....

Also, in your texture mapping demo, you store texture coordinates with the vertices, how would you deal with a cube that had different texturs on each side?
 
zacaj said:
Hi,
I was looking into this, but when I compiled and ran the cow demo, it seems like the cow is rotating around a place in fron of the the camera, and its all distorted....

Also, in your texture mapping demo, you store texture coordinates with the vertices, how would you deal with a cube that had different texturs on each side?
This is weird, the cow demo runs fine and nobody else complained. What compiler did you use? It could possibly also be a problem with the SDL version. I tried it with the devkitGP2X on windows and also with the open2x devkit on Linux and it worked. Both have a gcc version > 4.

Texture mapping a cube with different textures for each faces is really simple. For each face you draw a single quad after setting the correct texture to use. This is exactly the same as in OpenGL or D3D.
 
Last edited by a moderator:
That's simple... I can't beleive I didnt think of it. But then you'd have upside down textures and stuff... I'm compiling on Windows with Mingw, since you said it compiled fije on pc i didnt check on the GP2X, ill test that, but even if its a pc problem, it would still be horrible for beta testing...
 
zacaj said:
That's simple... I can't beleive I didnt think of it. But then you'd have upside down textures and stuff... I'm compiling on Windows with Mingw, since you said it compiled fije on pc i didnt check on the GP2X, ill test that, but even if its a pc problem, it would still be horrible for beta testing...
I also compiled it on Windows with Visual Studio and GCC 4.1.2. AFAIK Mingw comes with a GCC 3.4.5 compiler on which I also tried it and I can remember that there were problems as well. This is most likely a compiler bug since it works fine on newer gcc compilers and also in Visual Studio. You can get a newer gcc for mingw by manually downloading the appropriate packages from sourceforge and copying (and maybe renaming) the contained files into the correct location.
 
Last edited by a moderator:
Back
Top