3D Observation and My 1st App

[mikorians]

I found out that my graphics card is capable of 67.5M Verts/Sec (Vertex Fill Rate - Ideal speed) = 22.5M Tris/Sec = 900K Tris @ 50FPS
My unoptimized scene in Visual Basic 6 =  140K Tris @ 50FPS

Since Assy seems about 70x faster than VB6 on my machine, then a rewrite (and me learning) in assembly language would seem to be in order.

I wanted to learn more about the many permutations of the Mov command and wrote my 1st procedure/program called 'ReplaceString'
It is modeled on the VB Replace function and replaces all of 1 byte with another byte in a string.
There is probably already a library function for this, but I thought I'd see if I could do it.
Starting simple and all that...  It's very sloppy and poorly written, but I got it to work.
I had noted a lack of notation about the mov [addr],reg function perhaps because it is dangerous???

I would like to hire someone to help me by writing/providing a library of 3D functions that will push my 3D card to its limits
by bypassing the API calls, since perhaps they are too slow.

Advice and Comments are welcome now.

[qWord]

hi,

I would like to hire someone to help me by writing/providing a library of 3D functions that will push my 3D card to its limits
by bypassing the API calls, since perhaps they are too slow.

communication with the Graphic card goes through the corresponding buses, which are controlled by windows. Setting up a driver requires knowing the hardware and used protocols (manufacture specific). In fact, there is no alternative to DirectX and OpenGL, if want to use all features of the GC.
For example, with Japheth's WinInc you can easily write D3D9 applications.

EDIT: there also an OGL example in masm32's example folders

[MichaelW]

mikorians,

You procedure code is not accessing the parameters correctly. I used the printf macro to display the addresses and strings because I don't have much time to do this. The important part is not the macro calls but what they are displaying.

Code Select Expand


;===================================================================================
    include \masm32\include\masm32rt.inc
;===================================================================================
    .data
        MyStr       db "This. is my. test .text.",0
        repFind     db ".",0
        repString2  db "-",0
    .code
;===================================================================================

;-----------------------------------------------------------------------
; Added "p" prefix to indicate that the string parameters are pointers.
;-----------------------------------------------------------------------

ReplaceSt proc RepStart:DWORD, pRepString1:DWORD, pRepFind:DWORD, pRepString2:DWORD

    lea ebx, pRepFind
    printf("LEA pRepFind          : %Xh\n", ebx)
    mov ebx, pRepFind
    printf("MOV pRepFind          : %Xh\n\n", ebx)

    lea ebx, pRepString2
    printf("LEA pRepString2       : %Xh\n", ebx)
    mov ebx, pRepString2
    printf("MOV pRepString2       : %Xh\n\n", ebx)

    mov ebx, pRepString1
    printf("%s\n", ebx)
    mov ebx,pRepFind
    printf("%s\n", ebx)
    mov eax,pRepString2
    printf("%s\n\n", eax)

    ret

ReplaceSt endp

;===================================================================================
start:
;===================================================================================

    printf("Address of repFind    : %Xh\n", OFFSET repFind)
    printf("Address of repString2 : %Xh\n\n", OFFSET repString2)

    invoke ReplaceSt, 1, Addr MyStr, Addr repFind, Addr repString2

    inkey
    exit
;================================================================================
END start



[jj2007]

Adding to Michael's observation:

invoke ReplaceSt,1,Addr MyStr, chr$("."), chr$("-")
..
mov ebx,RepFind           ;Ebx=varptr(RepFind)   -- set dl to hold the find string for replace, don't touch dl or edx
..
mov eax,RepString2        ;Eax=RepString2

You pass addresses on the stack, i.e. the strings are passed ByRef in VB speak. From the stack, you retrieve them with a simple mov. In fact,
mov eax,RepString2
is in reality, i.e. seen through the eyes of OllyDbg:

00401046      .  68 24404000       push offset ??0021                                ; ÚRepString2 = 4210724.
0040104B      .  68 20404000       push offset ??0020                                ; ³RepFind = 4210720.
00401050      .  68 04404000       push offset MyStr                                 ; ³RepString1 = 4210692.
00401055      .  6A 01             push 1                                            ; ³RepStart = 1
00401057      .  E8 2E000000       call ReplaceSt                                    ; ÀReplaceSt
...

ReplaceSt     $ À55                push ebp       ; create a stack frame, step 1
0040108B      .  8BEC              mov ebp, esp       ; create a stack frame, step 2
0040108D      .  33D2              xor edx, edx
0040108F      .  8B5D 10           mov ebx, [ebp+10]       ; access the pointer on the stack

[mikorians]

Liked the looks of MichaelW's code.

But I wasn't able to use the entire register Eax because my values weren't 32 bit, but rather, a byte.  Had to use AL
Whilst I was diagnosing my app, the assembler seemed to ignore such requests and using 'Print' either gave the address of, or the entire string
(minus the 1st letter because of adding the Repstart value)
I found the behavior peculiar and frustrating.

So, if I put procedures first, then no proto is necessary?
His pre-definitions of the parameters would be definitely safer, yes.

VB programmers are in the habit of passing string parameters in an undefined manner (Hence the in-line quoted strings in the invocation of the procedure)
So the macro calling stuff pushes that stuff onto the stack then, so I needn't have tried to find their addresses anyway...   ???

I must assume you've all read the books that I haven't.  I never got into the x86 because of the weird addressing and gave up, but now with the 'flat' model and MASM32...
But I learned what little I know from the Apple II 6502 which was very straightforward indeed.  My view is therefore simplistic.

I only noticed that the output looked correct.  But I was probably abusing the stack, then...
Oh.  The push ebx was followed by a pop ebx at the end of the proc because I wanted to use the register, and this was advised by the help files.