PB V1.07 New Render Functions

[kevin]

Here's a quick shot of the new polygon rendering commands (in debug/testing).   So far i've got both Flat shaded and gouraud shaded fillers working.  Still need some tweaking with clipping, but it's all moving along much better now.

In the picture you can see a flat shaded tri, quad and quintuplet sided polygon, plus a tri & quad sided gouraud shaded polygons.   It's fairly fast even in this state, averaging about 4/5 ticks for the 5 polygons.  On my little duron 800 system.

In terms of PB, we'll prolly only have TRi and QUAD commands built in.  I might also build in a generic version also..  But,  We'll see :)

Next, get the texured version working.. until then, here's the pic

[kevin]

and here we have some (linear) texture mapping.  Everything seems to be working fairly well now after few LONG nights.   In this pic you can see I've added 3 textures polygons.   two quads and a triangle.  It's all the same code behind the scenes ( to do tri's and quads etc)...

 This code will replace the current sprite rotation code, as it's already faster than that.  Got one more mode on my mind to add to the tech demobefore I start moving this into PB.   And that's a combined shaded / textured poly.  

 I can do it two ways,  I can mix gourauded RGB's with the textured pixels (the texels), This would colour the textured pixels according the shading.  It'd be pretty hard to control I think.  Or calc an intensity level per pixel (linearly interpolated) and use that to light each pixel.


Anway, here's another pic

[kevin]

Been working on a Shaded texture mapped poly render.  While it's working there's an annoying oblivious by product of the edge interpolation and the shading.  If you look closely bellow you can see the darker strips that stretch form middle verts (the zero'd vert is the main problem).  It's pretty obvious in the intensity map version on the left, and equally visible on the shaded mapped version on the right.   It gives a banding effect at certain orientations.

 While I might as well leave it in, since it's working and could be useful, i'm not too sure how, of if it's possible to correct using this method.  Will have to think on that alittle more. :(

[kevin]

Well despite getting some annoying skewing and image movement when rendering odd shaped textured quads( you really should use triangles for those), the speed is certainly much better already, even from the debug version.   This picture has a screen full of transparent (colour masked), rotating, shaded, textured quad polys.  It takes about 35 ticks on my duron machine handle that ATM.   I'd say i should be able to half  that (or more) for the final.   That'll mean you can have a full screen of 640*480 rotating sprites without killing the frame rate, even on a 800mhz duron.   Well that's the goal anyway.  

So rotation, just got a whole lot more useful... :)

[kevin]

Polygon Render Modes

  So far we've got four new render modes. in the tech demo.  I can think of few others that certainly deserve a place, but the one's the come to mind immediately would be

* Textured + RGB Shaded   (so each vertex has a RGB value with is then interpolated and the RGB's are merged together)

* Textured + Shaded (uniformly shade all the rendered pixels) So you can dull a image.

* Colorize Texture  (replaces the pixels in the texture with a colour, so you can flash sprites to a colour upon impacts)

 * Texture + Blend modes. (I'e so you could alpha blend a texture sprite to the dest buffer)

anymore ideas ?

[kevin]

"Texture + Gouraud" Merge

This one's a texture and gouruad merge.  Sorta give a colouring effect to the image that's being textured... All the routines have cliping to the viewport edges now and a few  tweaks to ensure they finnish job a bit faster.  This is still test code and not the engine version, even so it's running pretty well already.  

The pic has gourauded quads, shaded/ textured quads &   Textured/gouraud quads.  All real time of course.  The Texture quards are transparent also.  


I've pretty much got all the code running smoothly now, so i'll start bring thign into PB later on today.   Will prolly release soem work in progress versions for registered members to play with as i go along..

anyway, here's a picture

[kevin]

Flat + Gouraud  Get a nice boost

 Spent tonight moving the previous test version of the polygon  fillers in PB's gfx library.  The results have been very pleasing.  As anticipated, it's happily 2 to 3 times quicker than previous the debug versions of code.    The picture bellow shows a screen full of gouraud quads,  running at a respectable 60 odd fps on the Duron 800mhz in 32bit mode.   So it's quick enough on this machine to gouraud full screen (640*480) polys.  

Flat shading is faster also,  it's somewhere between 3 to 4 times quicker. Although it depends on the size of the surface as to how much quicker it'll be.  I.e. As render lots of small polygons is a bit of bottleneck in polygon rendering ( lots of orientation and edge conversion for not a lot of pixels drawn).  

So it's progressing nicely at this point.  I'm hoping to get the texture mapping routines ported later today.   It definitely needs some hands on user testing.  So registered users will be able to have a mess around with these as soon as possible.  I'll  be posting you a beta (in whatever stage) as soon as i can over the weekend..   At this point, it'll prolly be sunday..

[kevin]

Flat / Gouraud & Textured

 Well, after a lovely afternoon of stretching my head looking for time bomb style crash in gouraud and fixing that,  I've finally now Texture Mapping working.  Previously, I was hopefully that it's be about twice as fast as the test code.  But's more like 2.5/ 3 times faster.   Bellow you can see a collection real time rotating/texture quads running a very nice 72fps on the 800mhz duron.   The old version was running in mid 20's on this system.

  It's basically fast enough to render a rotated/textured poly full screen (640*480) now.   Which certainly wasn't possible using the old method.  Again, i wouldn't expect miracles from it, (Nvidia i'm not!)  but it's certainly a lot faster than it was previously. !

[kevin]

Just in case your curious, here's a full screen rotating/ textured sprite..   :)

[kevin]

COmmand names ?

Ok, i'm patching in the new commands tonight, just wanted to get some feedback on what to call them.  


So far there's

Tri  x1,y1,x2,y2,x3,y3
TriC  x1,y1,x2,y2,x3,y3,RgbColour

Quad  x1,y1,x2,y2,x3,y3,x4,y4
Quad  x1,y1,x2,y2,x3,y3,x4,y4,RgbColour


So what about

GouraudTri  x1,y1,rgb1,x2,y2,rgb2,x3,y3,rgb3
GouraudQuad  x1,y1,rgb1,x2,y2,rgb2,x3,y3,rgb3,x4,y4,rgb4

TextureTri  TExtureImage,x1,y1,u1,v1,x2,y2,u2,v2,x3,y3,u3,v3,TransparentFlag
TextureQuad  TExtureImage,x1,y1,u1,v1,x2,y2,u2,v2,x3,y3,u3,v3,x4,y4,u4,v4,TransparentFlag


GouruadTextureTri  TextureImage,x1,y1,u1,v1,rgb1,x2,y2,u2,v2,rgb2,x3,y3,u3,v3,rgb3,,TransparentFlag

GouruadTextureQuad  TextureImage,x1,y1,u1,v1,rgb1,x2,y2,u2,v2,rgb2,x3,y3,u3,v3,rgb3,x4,y4,u4,v4,rgb4,,TransparentFlag

and finally

ShadeTextureTri  TextureImage,x1,y1,u1,v1,INt1,x2,y2,u2,v2,int2,x3,y3,u3,v3,int3,TransparentFlag

and there's a quad version of that also..  So there's a LOT of params

[tomazmb]

Hello Kevin,

If I should remember all of this "simple" commands, I should be Einstein! Ahh, it was all simpler in the days of Commodore 64.

Have a nice day,

Tomaz

[kevin]

C64 basic simpler, only if you knew the C64 memory map inside out.  :)

[kevin]

_24Bit Frame Buffers Suck_

 After a week end of site/promotion odd jobs, i've been back working on the gfx engine.    Namely building some buffer bliting routines and adding 24bit support to the various render routines.

 These behind the scene blit routines main purpose will be to blit(draw) FX images to the  screen or normal image in video memory.  This is so that once FX buffers can be rendered too, the buffers can also be drawn just like a normal image.  As expected, it's  slower than using the video cards blitter.      

 The blit a full 640*480, or 800*600 screen (32bit) is pretty costy and eats about 8/9 milliseconds (duron 800mhz).  The nice thing about this is that applying colour effects (only tried 1 or 2 at this point) buffer merges to the blit has minimal impact on the copy routines performance.  This is pretty much due to the wonderful bottle neck that writing to video memory presents.

  Rendering to FX images is necessary to improve alpha & draw mode performance.   So while the buffer blit is going to be a costly overhead, the improvement in alpha speed alone would make up for it..  

  Well, better get back to it.  There's some many combinations of routines to complete and no times to do it in.

[kevin]

24bit Finally Covered

      Just finally finished adding full 24 bit support to the all the render routines. The performance of 24bit version seems adequately in proportion to the other modes.  16bit is recommended for sheer throughput  (since your blitting 50% less data than 32bit modes..)

     Apart from that I've working on assembly versions of some of the key
fillers/copy routines.  Mostly to try and squeeze as much speed of them as possible.   Most are faster, but not by a staggering amount.  

     Added few speed up's to pixel/ strip drawing also.  Again, nothing massive, just stream lining the code a better.