ASM Community

Work was begun today on my most complex and ambitious oopasm class to date.
The BSP Class provides all the functionality required for the Indoors Engine of a real game. I expect to use a separate terrain engine for outdoors scenes similar to the Fusion Engine.
It's a full-blown BSP Loader and Renderer which makes full use of the BSP Tree for Visual Surface Determination, LightMapping, HintBrushes, the whole lot. Oh yeah, it's for DirectX :)
I just wanted to let you guys know what I've been up to. I'll post something more concrete just as soon as I feel I have made some decent progress.
Have a nice day :)

Good :) It's huge, the translation work is not difficult, there's just a lot of it, I'll be looking for some help to ease to workload.
Very early days, here's the BSP Class barely began translation, obviously initially concentrating on the Loader, theres some smaller dependant classes that will need translating too, and one or two we can do without..

Following a suggestion by Ultrano, I changed away from using OVERLAPPED file access to use FileMapping instead. Progress was made in the Loader to the point where we can load the Vertex, Index, Surfaces and LightMaps, and enumerate the Texture FileNames but I stopped short of loading the Textures themself, or performing gamma correction on the LightMaps. I need to now stop and write the CTexture Class before I continue. At any rate, the current code is working to that point, and has been tested as such. Any progress is good progress :)

it was level.bsp not test.bsp you probaly mistmatched?

eh :( if i could upload my new version which loads lightmap

Heya :)
I think I've finally decided how to deal with the issue I was having with the CTexture Class.
The problem involved an ambiguous part of the c++ standard template library called "Map". It was used to keep a LinkedList of sorts which prevented us from loading a named texture more than once, but didn't stop us creating multiple class object instances that refer to the same texture.
The solution I have decided on is to use an external procedure to create instances of Ctexture, and keep the object pointers in a LinkedList which is referenced by name. Not only does this prevent us from reloading a loaded texture, but it prevents us from creating multiple instances of a class object that refer to the same loaded texture. w00t :D
In order to achieve this I've decided to use my OLD LINKEDLIST SUPPORT MODULE which Scronty helped me with very early in 2003.

Here is the proposed code, with no comments sorry.
I haven't even tested it out yet.
Attached is the LinkedList support module itself.


.data
TextureCacheRoot dd NULL ;ptr to the ROOT ENTRY of a LinkedList of TextureInfo structs
.code
include LinkedList.inc ;<--- This is the LinkedList Support Module I coded ages ago
CachedTexture struct
LO LinkedObject <> ;LinkedList header supports naming and linking
pCTexture dd NULL ;Pointer to instance of CTexture Class Object
Count dd NULL
CachedTexture ends


;The following code is used to keep a LinkedList of "CachedTexture" structs
;which in turn is used to ensure we only create ONE INSTANCE
;of a CTexture Class Object for a given Texture FileName.
;We CAN try to load a named Texture more than once,
;but it will only return a reference to an already existing instance.
;The return value is always a ptr to a CTexture object instance,
;and NOT an actual DX texture ptr, thats kept inside the class object.

NewTexture proc pName:DWORD, multipleLevel:DWORD, colorKey:DWORD
local pCachedTexture:DWORD
local pCTexture:DWORD
.if TextureCacheRoot
invoke FindEntryByName, TextureCacheRoot, pName
.if eax==NULL
mov pCachedTexture, $invoke (AddChildEntry, TextureCacheRoot,sizeof CachedTexture)
invoke NewName, pCachedTexture, pName
mov pCTexture, new CTexture
icall pCTexture, CTexture, Load, pName, multipleLevel, colorKey
mov ebx,pCachedTexture
m2m .CachedTexture.pCTexture, pCTexture
inc .CachedTexture.Count
return pCTexture
.else
inc .CachedTexture.Count
return .CachedTexture.pCTexture
.endif
.endif
mov pCachedTexture, $invoke (AddChildEntry, NULL ,sizeof CachedTexture)
mov TextureCacheRoot,eax
invoke NewName, pCachedTexture, pName
mov pCTexture, new CTexture
icall pCTexture, CTexture, Load, pName, multipleLevel, colorKey
mov ebx,pCachedTexture
m2m .CachedTexture.pCTexture, pCTexture
inc .CachedTexture.Count
return pCTexture
NewTexture endp

Here's the "mostly complete" CTexture class :)
Oh look, it's beer o'clock already :grin:
Priorities are : cold beer, then CBoundingBox, then CPrimitive.
After that I can finish up the BSP Loader and start on the Render code.
w00t :alright:

Well, converting C++ source at once and then compile didnt helpt me, when i tried to render simple vertex so im doing everything by BSP file specs, and almost no c++ source, I think you got more asm programming xp than I, and I think your Loader will be more successfull than my, Good Look!:alright:
Oh, and thanks for Gamma-Value-Correction snippet it works fine, my tiny version:

   mov esi,pImageBits

   mov ecx,128*128*3

   .while ecx

      xor eax,eax

      mov al,byte ptr [esi]

      [b]imul eax, r_gamma

      .if eax > 255

         mov byte ptr [esi], 255

      .else 

         mov byte ptr [esi], al

      .endif[/b]

      add esi,1

      dec ecx

   .endw

Work continues with CBoundingBox class which is about 50% completed.
I'll try to avoid CPrimitive altogether.
That means when CBoundingBox is completed, the Loader can be completed, and it will be time to start on the Render side of the code.
w00t :grin:

visSet & (1 << ((test) & 7))

=

mov eax, _test

and eax, 7

xor ecx, ecx

bts ecx, eax

and visSet, ecx

Here is 80% translated CBoundingBox class.
Be safe and see you all next year :)