.data?

fVertexPtr DWORD ?

;for structures, need to have the following:
; texture [file0]... [file(n)]
; type=GL_TRIANGLES Or GL_QUADS, or GL_WIREFRAME(?)
; v1,v2,v3,v4 (v4 is used if type says it's QUADS)
; n1,n2 normals
; f1,f2,f3,f4 (f4 if is quad)
; u,v mapping coords

FVERTEX struct
glV1 REAL4 0.0
glV2 REAL4 0.0
glV3 REAL4 0.0
glV4 REAL4 0.0
FVERTEX ends

FNORMAL struct
glN1 REAL4 0.0
glN2 REAL4 0.0
FNORMAL ends

FUV struct
glU REAL4 0.0
glV REAL4 0.0
FUV ends

FFACE struct
glF1 dd 0
glF2 dd 0
glF3 dd 0
glF4 dd 0
FFACE ends

FOBJ struct
glType dd 0
glVX FVERTEX 4096 DUP (<?>) ;up to 4096 vertices
glVN FNORMAL 4096 DUP (<?>) ;will change later
glFU FUV 4096 DUP (<?>) ;will change later
glFACE FFACE 4096 DUP (<?>) ;will change later
FOBJ ends

tObj FOBJ 255 DUP (<?>) ;<==== error A2177: nested structure improperly initialized
;<======= hoping to have up to 255 'objects'




My ultimate goal is to have this struct(s) set up to go through each tObj as needed and initialize the memory for it. Probably will use heapalloc. My problem is in initializing the thing. Any help would be appreciated, thanks.

I'm not really initializing it as more I am trying to create a sort of typedef? or reference to the structure? There went another braincell, ouch.
Posted on 2004-01-03 11:36:22 by drarem
thanks Donkey but I get the same error.

I am probably trying to think in C when it should be asm..
Posted on 2004-01-03 12:23:12 by drarem
You can't use DUP for nested structures. Just allocate enough bytes then use other addessing methods. Good luck with the compile time :) MASM has a bug with large structures like this one.

FOBJ struct

glType dd 0
glVX db (SIZEOF FVERTEX *4096) DUP (?)
glVN db (SIZEOF FNORMAL *4096) DUP (?)
glFU db (SIZEOF FUV *4096) DUP (?)
glFACE db (SIZEOF FFACE *4096) DUP (?)
FOBJ ends
Posted on 2004-01-03 12:30:33 by donkey
Well,

It's been a little over an hour, MASM should have just finished compiling that structure :grin:
Posted on 2004-01-03 13:45:49 by donkey
Really? I tried ML 6.14.8444 and it compiles the structures above in a twinkle... even though it has in other cases the same problem... Or am I doing something wrong?
Posted on 2004-01-03 15:26:10 by MazeGen
Don't know I gave up trying after about 3 minutes on 7.10, I'm not sure how the bug progressed, whether it got worse in newer versions of ml.exe. Anyway, a structure of that size is not a good idea, better to just use runtime memory allocation than add about a meg of empty data to the executable.
Posted on 2004-01-03 16:04:04 by donkey
I don't too.
As I use large arrays in my project, I have had the same problem using DUP. After replacing it with method using $ - location counter, compiling time is about half. I know it's not much clean method, but compiling time is for me more important.


MyArray DWORD MyConst DUP (?)

may be replaced with

MyArray LABEL DWORD
ORG $+4*MyConst

It's only small sugestion, I know LABEL can't be used inside a struct.
Posted on 2004-01-03 17:24:54 by MazeGen
C'mon you guys,
C'mon darem,
The error from MASM directly tells you exactly what is wrong. darem, you are trying to assemble initialized code in a unitialized segment. MASM does not like that. No assembler worth its salt should. Now look at what we get when I change from .DATA? TO .DATA. I have never run into a problem with large nested STRUC's-- as long as I followed the rules. You probably won't either if you do the same. Don't put initialized data into a unitialized segment. Ratch
  00000000			.data


00000000 00000000 fVertexPtr DWORD ?

;for structures, need to have the following:
; texture [file0]... [file(n)]
; type=GL_TRIANGLES Or GL_QUADS, or GL_WIREFRAME(?)
; v1,v2,v3,v4 (v4 is used if type says it's QUADS)
; n1,n2 normals
; f1,f2,f3,f4 (f4 if is quad)
; u,v mapping coords

00000010 FVERTEX struct
00000000 00000000 glV1 REAL4 0.0
00000004 00000000 glV2 REAL4 0.0
00000008 00000000 glV3 REAL4 0.0
0000000C 00000000 glV4 REAL4 0.0
FVERTEX ends

00000008 FNORMAL struct
00000000 00000000 glN1 REAL4 0.0
00000004 00000000 glN2 REAL4 0.0
FNORMAL ends

00000008 FUV struct
00000000 00000000 glU REAL4 0.0
00000004 00000000 glV REAL4 0.0
FUV ends

00000010 FFACE struct
00000000 00000000 glF1 dd 0
00000004 00000000 glF2 dd 0
00000008 00000000 glF3 dd 0
0000000C 00000000 glF4 dd 0
FFACE ends

00030004 FOBJ struct
00000000 00000000 glType dd 0
00000004 00001000 [ glVX FVERTEX 4096 DUP (<?> ) ;up to 4096 vertices
00000000
00000000
00000000
00000000
]
00010004 00001000 [ glVN FNORMAL 4096 DUP (<?> ) ;will change later
00000000
00000000
]
00018004 00001000 [ glFU FUV 4096 DUP (<?> ) ;will change later
00000000
00000000
]
00020004 00001000 [ glFACE FFACE 4096 DUP (<?> ) ;will change later
00000000
00000000
00000000
00000000
]
FOBJ ends
Posted on 2004-01-03 21:58:00 by Ratch
Hi Ratch,

I saw that but it is not the cause of the problem here, how would you do this:

.data?

blah STRUCT
tester RECT 256 DUP (<?>)
blah ends

junk blah 256 DUP (<?>)


I have always had problems with large uninitialized structures in MASM, I just don't use them any more.
Posted on 2004-01-04 00:47:22 by donkey
I'm trying to avoid adding 70k+ size to my exe when we all got 256Mb at least nowadays to play with along with virtual storage. I should change the 0.0 to ? for the above stuff. For the small stuff I never sweat it.

The error states 'nested structure improperly initialized' - thought it was the nesting causing the error. Initialized?

And I haven't gotten back to it yet, it was a saturday night y'know. Will continue in a few.
Posted on 2004-01-04 03:36:00 by drarem
Donkey,
MASM structures appear to define and reference OK, it's the initializing parser that seems to be hosed up. Fortunately there are other ways to initialize data. Ratch



00001000 blah STRUCT
00000000 00000100 [ tester RECT 256 DUP ({})
00000000
00000000
00000000
00000000
]
blah ends

; ------------------------------------------------------------------------------

00000000 .DATA
00000000 junk LABEL DWORD
00000000 00000100 [ RECT 256 DUP ({1,2,3,4})
00000001
00000002
00000003
00000004
]

; ------------------------------------------------------------------------------
00000000 .CODE
00000000 MAIN:
00000000 A1 0000011C R MOV EAX,[junk.blah.tester[17*RECT].RECT.bottom] ; "bottom" field of 17th RECT element of "tester" of
; structure "blah" at label junk
Posted on 2004-01-04 03:43:57 by Ratch
ok I think I might have a workaround - I guess working with nested structures (like REAL4/8/etc) is difficult..



:: :: :: ::
:: :: :: ::
FOBJ struct
glType dd 0
glVX FVERTEX 4096 DUP (<?> ) ;up to 4096 vertices
glVN FNORMAL 4096 DUP (<?> ) ;will change later
glFU FUV 4096 DUP (<?> ) ;will change later
glFACE FFACE 4096 DUP (<?> ) ;will change later
FOBJ ends


vOBJ DWORD 256 DUP (?) ;when running program, allocate 256*4096 each of blah and set
; vOBJ[n]=&glVX[n*4096];
fOBJ DWORD 256 DUP (?) ;when running program, allocate 256*4096 each of blah and set
; fOBJ[n]=&glVN[n*4096];
nOBJ DWORD 256 DUP (?) ;when running program, allocate 256*4096 each of blah and set
; nOBJ[n]=&vlFU[n*4096];




256*4096*4 (from my original structure) is roughly 4Mb file, which is what I am trying to avoid on the .exe file. When program run, heapallocate 4096 for each glVX,glVN, etc.. then allocate 256 for each vOBJ,fOBJ,.. and then set each 0thru256 address of vOBJ,fOBJ equal to value of address in glVX,glVN, etc.. which could be used thruout the program.

So instead of typing:
tObj[5].glFU[213]
it would be:
fOBJ[213]

in the .code section of the program. How does that sound?

I will try it later on tonight and post here my results, which may take a bit.
Posted on 2004-01-04 10:02:38 by drarem
drarem,
ok I think I might have a workaround - I guess working with nested structures (like REAL4/8/etc) is difficult..

Look at the code below. Easy to do, no tricks, work arounds, and straight forward. Just allocate the space when you need it and free it when finished. Ratch


;for structures, need to have the following:
; texture [file0]... [file(n)]
; type=GL_TRIANGLES Or GL_QUADS, or GL_WIREFRAME(?)
; v1,v2,v3,v4 (v4 is used if type says it's QUADS)
; n1,n2 normals
; f1,f2,f3,f4 (f4 if is quad)
; u,v mapping coords

00000010 FVERTEX struct ;Define these STRUCTs outside of any segment definitions.
;It just works better that way.
00000000 00000000 glV1 REAL4 ?
00000004 00000000 glV2 REAL4 ?
00000008 00000000 glV3 REAL4 ?
0000000C 00000000 glV4 REAL4 ?
FVERTEX ends

00000008 FNORMAL struct
00000000 00000000 glN1 REAL4 ?
00000004 00000000 glN2 REAL4 ?
FNORMAL ends

00000008 FUV struct
00000000 00000000 glU REAL4 ?
00000004 00000000 glV REAL4 ?
FUV ends

00000010 FFACE struct
00000000 00000000 glF1 dd ?
00000004 00000000 glF2 dd ?
00000008 00000000 glF3 dd ?
0000000C 00000000 glF4 dd ?
FFACE ends

00030004 FOBJ struct ;big elaborate structure containing arrays of other structures
00000000 00000000 glType dd ?
00000004 00001000 [ glVX FVERTEX 4096 DUP (<?> ) ;up to 4096 vertices
00000000
00000000
00000000
00000000
]
00010004 00001000 [ glVN FNORMAL 4096 DUP (<?> ) ;will change later
00000000
00000000
]
00018004 00001000 [ glFU FUV 4096 DUP (<?> ) ;will change later
00000000
00000000
]
00020004 00001000 [ glFACE FFACE 4096 DUP (<?> ) ;will change later
00000000
00000000
00000000
00000000
]
FOBJ ends

; ------------------------------------------------------------------------------

00000000 .DATA

00000000 .DATA?
00000000 00000000 fVertexPtr DWORD ? ;storage for dynamic pointer

; ------------------------------------------------------------------------------
00000000 .CODE
00000000 MAIN:
INVOKIT LocalAlloc,LMEM_MOVEABLE,FOBJ ;dynamically allocate some bytes
00000000 68 00030004 4 PUSH FOBJ
00000005 6A 02 4 PUSH LMEM_MOVEABLE
00000007 E8 00000000 E 1 CALL LocalAlloc
;EAX=address of those bytes
;Let MASM figure out how many bytes you need
0000000C A3 00000000 R MOV [fVertexPtr],EAX
00000011 8D B8 00018004 LEA EDI,[FOBJ.glFU+EAX] ;Use FOBJ STRUCT as template to reference
;FUV structure array position within.
;Let MASM figure where that address is.
00000017 B8 00000001 MOV EAX,1
0000001C B9 00002000 MOV ECX,4096*FUV/DWORD
00000021 F3/ AB REP STOSD ;Initialize FUV structure array with ones.
;More elaborate initializations can be done
;with multiple and complex loops.
;Let MASM figure how many times to loop
;-------------------------
;USE AND ABUSE ALL THOSE BYTES HERE
;-------------------------

INVOKE LocalFree,[fVertexPtr] ;Then free all those bytes.
END MAIN
Posted on 2004-01-04 11:55:20 by Ratch