COM is very easy in ASM:
and extract from my RTS game: Hostile Encounter calling DirectX COM interfaces:
Code:
Direct_Draw_Surface_Lock1 PROC
USES esi
ARG @@a_surface:dword
LOCAL @@tmp_result:dword
;------------------------------
; setup surface descriptor
;------------------------------
Call Zero_Memory_Byte, offset ddsd_all, SIZE DDSURFACEDESC2
mov esi,offset ddsd_all
mov [esi.ddsd2_dwSize], SIZE DDSURFACEDESC2
;-------------------------------------------
; params to IDirectSurface:Lock()
;--------------------------------------------
push 0
push DDLOCK_WAIT
push offset ddsd_all ;surface descriptor to get pointer in
push 0 ;full rectangle
push [@@a_surface] ; surface to lock
mov eax,[eax] ; find vtable address
call [eax + DDS_Lock] ; call the Lock method
.IF eax!=DD_OK
ODS1_fmt <"Ddraw:LockSurface Failed:%x">,eax
jmp Game_Finish
.ELSE
;ODS1 <"Ddraw:LockSurface:OK">
.ENDIF
;----------------------------------------
; return the pointer and pitch in eax,ebx
;----------------------------------------
mov esi,offset ddsd_all
mov eax,[esi.ddsd2_lpSurface]
mov ebx,[esi.ddsd2_lPitch]
ret
ENDP
Kind of old code as now I use is more like:
COM_Call [a_object],a_method, param1, param2,...
And if you programm in modern ASM it does not mean that you can not design and think in an OOP like fashion.
As you can see COM is simply reduced to:
Code:
push method_parameters
push object instance
call [object_instance_vtable+Method]
Hardly something to be considered very complicated.
Nevertheless using a simple text editor and RADASM (lately)...
I and one friend have been able to create a full RTS game of the magnitude of the Starcraft in less than 6 months in a team of only 2 full programmers working normaly (8hours per day). There is a functional demo available on the net... i guess you know.
The same project took the original comerciall highlevel company 3 years and 30 programmers and who knows how many tools and IDEs and management.
I have later created an Operating Sytem with GUI and reparent window objects, true translucency multiple desktops, controls and dynamic auto-aranging content in a little over 6 months of work (yeah only 3 months full and then 1 day per month once in a while fro the last years).
So my experience is that speed of development in ASM is 10x bigger than any modern HLL programming language.
The ASM problems are actually:
-------------------------------
-non portable code
-the need to be able to remove the programmers as you wish and pay them as low as possible
-experienced ASM programmers are hard to find today while yo can find a huge ammount of HLL programmers per day.
Non "art" like programmes in VC++/VB/Delphi/NET/Java whatever can be replaced very easy and payed wery low income.
You do not have to depend on algorithms, inteligence and "art" --> it is much more reasurring for the investors to be considereing "the programmer" a simple "machine" that uses and IDE and OOP tools to achieve the task of making them rich (the investors) as fast as possible and no matter the cost to the users.