Path: chuka.playstation.co.uk!news From: James Russell Newsgroups: scee.yaroze.programming.3d_graphics Subject: Re: Dynamic TMD Prob Date: Wed, 07 Oct 1998 10:47:37 +0100 Organization: Sony Computer Entertainment Europe Lines: 34 Message-ID: <361B38B9.74C88355@scee.sony.co.uk> References: <361AB7CB.4141075E@datasys.net> NNTP-Posting-Host: mailgate.scee.sony.co.uk Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.5b2 [en] (Win95; I) X-Accept-Language: en Darco wrote: > > Because the creation process is dynamic, I will not know going into the process > how many vertices, normals, and primitives I will need. Thus, I will > need to dynamically re-allocate the vertex space, normal space, and > primitive space as I add more vertices, normals, and primitives. The TMD data doesn't have to be contiguous in memory - you can create one big area for verts, one for normals, and one for objects, and use the pointers in the header area to reference the lot. Different objects can share the same vert/normals area. This way, you're not being incredibly space-efficient, but it makes life a lot easier. > The realloc() command (Green manual, page 212) seemed perfect for > reallocating the memory blocks. Yeeeeeees. I wouldn't trust the PSXs malloc/free/realloc functions. I think malloc is alright, but free has definitely got some problems. > What I eventually hope to have is a game that dynamically creates it's > playing environment. Randomly. So there is NO way to know how many > vertices, normals, and primitives there will be going into the process. But there must be some limit - and since you're game is going to have to be constrained by that limit, you might as well figure out what it is and pre-allocate a large blob of space. Cheers, James -- == James_Russell@scee.sony.co.uk +44 (171) 447-1626 == Developer Support Engineer - Sony Computer Entertainment Europe At the border: "What's in the trunk?" "Oh, nobody!"