half-life 1 software renderer (OMFG)[BB2D]

[Stonemonkey]

In the loops like this:

Code: [Select]

    For x = 0 To gw2
For y = 0 To gh1
PokeInt bnkVideo, y * w4 + x * 4, $00FF00
Next
Next

where the y loop is the inner loop.

[Devils Child]

this is faster anyway:

Code: [Select]

mi = GraphicsWidth() * GraphicsHeight() * 4
i = 0
While i < mi
PokeInt vglScreenBank, i, col
i = i + 4
Wend
i think jim really meant my fill triangle routine, where i should take vertical lines instead of horizontals...
but whatever, i cant do that because it would mean to completely redo the triangle fill routine
is it really faster using vertical lines instead of my horizontal? and if, how much faster is it?

[Shockwave]

I think Jim meant what Stonemonkey said.

Anyway, lots of people have said it here, I'll say it again.
You have outgrown Blitz. It is not capable of the sort of speedy pixel manipulation you need, no matter how you try and do it you need to learn another language.

I wrote two quick comparisons for you, both run in 800 * 600 mode (see attached zip for exes).

FPS is displayed in the console window (you may have to move the display window out of the way).

Firstly, if you were rasterising a solid colour you could use something like this;

Code: [Select]

' FAST PIXELWISE BLITTING USING SIMPLE RASTERISATION.
'
'---------------------------------------------------------------------------

    #DEFINE PTC_WIN
    #INCLUDE "TINYPTC.BI"
    #INCLUDE "WINDOWS.BI"   
   

    OPTION STATIC
    OPTION EXPLICIT

    CONST   XRES    =   800
    CONST   YRES    =   600

    DIM SHARED AS UINTEGER BUFFER ( XRES * YRES )
    DIM SHARED AS INTEGER Y,SLICE,TC,TICKS
    DIM SHARED AS UINTEGER PTR PP
    DIM SHARED AS DOUBLE GRAB
   
    IF( PTC_OPEN( "SPEED TEST", XRES, YRES ) = 0 ) THEN
    END -1
    END IF   

GRAB=TIMER
WHILE(GETASYNCKEYSTATE(VK_ESCAPE)<>-32767)   
    FOR Y=0 TO YRES-1
    SLICE = XRES
   
    TC = RGB(Y /4 , Y/3 , Y/5 )
    PP = @BUFFER(Y*XRES)   
    asm
        mov eax,dword ptr[TC]
        mov ecx, [slice]
        mov edi, [PP]
        rep stosd
    end asm   
   
NEXT
        PTC_UPDATE@BUFFER(0)
        TICKS=TICKS+1
IF TIMER-GRAB>=1 THEN
    PRINT "FPS : " + STR(TICKS)
    TICKS=0
    GRAB=TIMER
END IF

WEND

And to pick pixels out of a work buffer, it can be done as fast as this;

Code: [Select]

' FAST PIXELWISE BLITTING USING POINTERS.
'
'---------------------------------------------------------------------------

    #DEFINE PTC_WIN
    #INCLUDE "TINYPTC.BI"
    #INCLUDE "WINDOWS.BI"   
   

    OPTION STATIC
    OPTION EXPLICIT

    CONST   XRES    =   800
    CONST   YRES    =   600

    DIM SHARED AS UINTEGER BUFFER ( XRES * YRES )
    DIM SHARED AS INTEGER Y,SLICE,TC,TICKS,X
    DIM SHARED AS UINTEGER PTR PP
    DIM SHARED AS DOUBLE GRAB
   
    IF( PTC_OPEN( "SPEED TEST", XRES, YRES ) = 0 ) THEN
    END -1
    END IF   

GRAB=TIMER
WHILE(GETASYNCKEYSTATE(VK_ESCAPE)<>-32767)   
   
    PP=@BUFFER(0)
    FOR Y=0 TO YRES * XRES -1
   
    *PP = Y
    PP+=1
   
    NEXT

        PTC_UPDATE@BUFFER(0)
        TICKS=TICKS+1
IF TIMER-GRAB>=1 THEN
    PRINT "FPS : " + STR(TICKS)
    TICKS=0
    GRAB=TIMER
END IF

WEND

Or just invoke memcpy if you want to include crt.bi.

In any case, this is in another variant of Basic, you would find if fairly easy to port your code over and as you'll see from the axamples it runs about 6-8 times faster than Blitz on most computers for pixelwise stuff.

If you are software rendering, you can persist with Blitz but in the end, trust me, you will eventually get pissed off and switch to another language.

[Stonemonkey]

Just realised you're writing your pixels in vertical columns.  That's really bad for the CPU cache.  Much better to write in horizontal rows where possible.

It is much better to write with horizontal lines which makes better use of the cache (in any language). As I mentioned before, the tests you were doing to fill the screenbuffer had y for the inner loop which meant it was drawing in columns which is not as good.

[Jim]

why is your software renderer using wpf then?

I use banks/pokeint to do all the drawing, then wpf only the pixels that were written (by checking the wbuffer) to the screen.  Can you believe it's actually faster to do an if test for every pixel than it is to draw the pixel?!  And because I'd never seen this rtl stuff
The code's here if you want to play with it.
http://members.iinet.net.au/~jimshaw/Blitz/typetriw.zip

Jim

[Devils Child]

hmh. most of you would recognize this as the first DOOM level. except for the second screenshot...


this is written using the poke method.

1. all resolutions work with windowed mode
2. all resolutions work in fullscreen EXCEPT 400x300x32x2

[Stonemonkey]

That 2nd shot looks like it's a problem with the pitch, that the memory set aside for the screen is more than is required for the actual screen. Even though the visible screen is 400*300 the buffer might actually be 640*300 (or something else) with the left hand side not visible.

[Jim]

I'm surprised the driver/card actually accepts 400x300 as a fullscreen resolution.  It's way off standard.
Jim