Polygon point data type with Arrays

Er...this may be a major point I'm missing, but if my arrays are dying when the function ends, wouldn't a casted malloc-ed memory block go out of scope as well?

Actually, I guess not, since the actual pointer data is casted and then assigned to the Model structure, which wouldn't go out of scope...right? In my code, the pointers to the temp_arrays don't go out of scope (because they're part of the model structure), but the actual data and memory structure do, right? Something like that? And that's why I would need to do a malloc and cast in a single assignment to "model", to preserve that memory, right?

Thanks for the response though. I didn't even think of that...I figured if I just saved the pointers, the arrays wouldn't go out of scope, but I guess I was wrong...still new to C :)
 
When you use malloc(), memory is freed when you use free(), whatever the scope is. That said, I wouldn't use the standard malloc on the saturn (there is another thread here showing related problems).
 
Originally posted by Omni@Fri, 2005-01-21 @ 07:12 PM

Does that mean there's no way to do what I'm trying, and I should look for something else?

[post=128179]Quoted post[/post]​


No, of course not. Just try to do it like in the SGL demos: constant values.

Here is a part of the file SGL/SAMPLES/DRIVING/MAP/MITI.MDL

Code:
POINT	point_ZERO[]={

};

POLYGON polygon_ZERO[]={

};

ATTR attribute_ZERO[]={

};

PDATA	PD_ZERO={

	point_ZERO,0,

	polygon_ZERO,0,

	attribute_ZERO

};

POINT	point_0006[]={

	POStoFIXED( -3303.0000,  -32.0000,  44.0000),

	POStoFIXED( -3376.0000,  -44.0000,  44.0000),

	POStoFIXED( -3370.0000,  -67.0000,  32.0000),

	POStoFIXED( -3296.0000,  -54.0000,  32.0000),

};

POLYGON polygon_0006[]={

	NORMAL(0.076840784,-0.451823808,0.888791731),VERTICES(  0,  1,  2,  3),

};

ATTR attr_0006[]={

	ATTRIBUTE(Single_Plane,SORT_CEN, 3+texno,No_Palet,No_Gouraud,No_Window|MESHoff|HSSon|ECdis|SPdis|CL32KRGB,sprNoflip,No_Option|UseNearClip|UseLight),

};

PDATA	PD_0006={

	point_0006,sizeof(point_0006)/sizeof(POINT),

	polygon_0006,sizeof(polygon_0006)/sizeof(POLYGON),

	attr_0006

};

As I told you, there are tools on antime's page which create this stuff automatically.
 
Originally posted by Omni@Fri, 2005-01-21 @ 10:12 PM

Does that mean there's no way to do what I'm trying, and I should look for something else?

That depends on what you're really trying to do, since you're not saying it. Creating polygons at runtime from constant data is pointless, as you'll just end up storing all your data twice. I would therefore assume the point of the whole excercise is to programmatically generate geometry which is of course possible. You just have to make sure you have space reserved for your data, either through preallocating some buffers or through dynamic memory allocation.
 
Yes, the idea was just to make some functions to create and manage the objects, since the idea of typing all of the data into arrays manually didn't quite appeal to me. I don't really know what to do from here in terms of preallocating buffers, since I now hear that using Malloc in Saturn C isn't the smartest idea, and I haven't yet looked at the SGL library to see if they have a Saturn specific implementation (did I hear someone mention that somewhere?...), and the fact that I'm not sure of what to do next is probably indicative of my inexperience in programming C. At any rate, besides using Malloc(), I don't quite understand how I can allocate buffers or use memory dynamically. Any hints? :)
 
It's not malloc as such which is the problem, but mixing malloc (provided by the C library) with Sega's MEM_Malloc etc.

By preallocating I meant reserving space at compile time, eg. by creating a big array into which you will create your geometry. Since you can calculate the largest amount of space you will need during execution you can make your array that big and reuse parts for objects whose life span don't overlap. You can also calculate the maximum number of a certain object type you will need at one time and create that many objects which you reuse as needed, and so on. There's lots of different ways to handle this, but if you actually want to have a static geometry it is much easier to make a program to export your data into the format needed by SGL.
 
OH. Er...so I'd have my giant array allocation and use parts of it for geometry, as well as any exported data files that I use in my code?

Now, the PDATA object requires the pointer pntbl to point to an array of POINT values. So technically I'll need to predefine a giant array of POINTs (like, 10x3, with 3 POINTs for X, Y, and Z, and 10 possible coordinates). But I can't have pntbl point to a position within the giant 10x3 array, can I? I mean, PDATA requires pntbl to be an array of POINT values and not an array of pointers to POINT values, right? Or will this actually work? Do I even know what I'm talking about?

----In other words.

1. Make a giant array of POINTS. IE, allmypoints[100];

2. Set some of them. IE, allmypoints[0][X] = toFIXED(1.0), allmypoints[5][Z] = toFIXED(1.0);

3. Create a quad array of 4 vertices (to pass to a PDATA object) that has pointers to four entries within the allmypoints[] array.

Is this possible? I know I could copy the data from allmypoints[] to the vertex array pntbl for PDATA, but can I actually tell the vertex table pntbl to point to a value in allmypoints[] so that I only have to alter the allmypoints[] table to change coordiantes?
 
Originally posted by Rockin'-B@Sun, 2005-01-09 @ 08:19 PM

You got the option to convert existing .DXF 3d models to C include files(named .SGL on Mac and .MDL on Windows).

[post=127390]Quoted post[/post]​


Hey, I followed some Blender tutorials and modelled the castle and winter scene :) .

But I could not display them on Saturn, because the conversion with DXF2SG3.EXE fails!

I compared the DXF files from blender with other from the net which worked. They contain different keywords. As the DXF fileformat has evolved since 1996 I suppose the SEGA tools support only older DXF formats.

There are DXF libraries on the net: dime or dxflib.

Maybe I'll have a look at those and try to convert new DXF to older DXF format or even SG3 format(is there info about that?).
 
I made such a DXF converter which makes modern DXF files compatible with DXF2SG3.EXE from the SS-SDK for Windows 95.

Two different methods are implemented, but my next problem is the Blender export / import scripts.

Some of them are shit, including DXF. If you reimport an exported DXF model, it doesn't look like the original! Seems like they are only meant for single objects, because exporting breaks the hierarchies.

This bugs me :angry: , my converter seems to be usable, but for blender I will have to write my own export script...

So I still can't use my selfmade little 3D models on Saturn...
 
Back
Top