Bsp loader bits from windows to code to linux

not even sure if this is the part of the code thats doing this but i read somewhere that it might be
i am porting over the quake 3 bsp loader from windows code to linux
which i know works on windows because i have tested it in DEVC++
and my new linux version of this code works as well because i can load a simple map of verticees from a text file texture it and move around in it
but when i try to use the bsp loader code
all i see is a bunch of messed up textured and messed up positioned pointy triangles
that i can move around in

so can some one pls help me then? plz

i think this is the part where it is and i have no idea how this part would be difrent on windows7 than on my new ubuntu10

// This resizes our bitset to a size so each face has a bit associated with it

void Resize(int count) 

{ 

	// Get the size of integers we need

	m_size = count/32 + 1;



	// Make sure we haven't already allocated memory for the bits

    if(m_bits) 

	{

		delete m_bits;

		m_bits = 0;

	}



	// Allocate the bits and initialize them

	m_bits = new unsigned int[m_size];

	ClearAll();

}



// This does the binary math to set the desired bit

void Set(int i) 

{

	m_bits[i >> 5] |= (1 << (i & 31));

}



// This returns if the desired bit slot is a 1 or a 0

int On(int i) 

{

	return m_bits[i >> 5] & (1 << (i & 31 ));

}



// This clears a bit to 0

void Clear(int i) 

{

	m_bits[i >> 5] &= ~(1 << (i & 31));

}



// This initializes the bits to 0

void ClearAll() 

{

	memset(m_bits, 0, sizeof(unsigned int) * m_size);

}

:eek:

This is a simple bit array and it’s plain code with no platform dependant code. Linux usually don’t make crazy stuff on the code.
The only thing you need to care when you work directly with bits is the size of the int that can vary from platform. In MS visual studio int is 32 bit even on 64 bit machine, http://msdn.microsoft.com/en-us/library/s3f49ktz(v=vs.80).aspx

while on Gcc int is 64 bit on 64 bit machine (if you compile with 64 flags, that is the default).

Even if I suggest to use the more secure int32_t the implementation seem robust to 64 bit int size. So I don’t think the problem is here.

By the way, did you already checked this?
http://ioquake3.org/get-it/

hey thanx a ton i really hate bits and << those things i have no idea what is hapening here
m_bits[i &gt;&gt; 5] |= (1 << (i & 31));

but yea i was just debug printing all the info from the bsp parsing code and i noticed that all the x y z vertices are totaly off like
x: -262217583139129982033677847482282803200.000000
y: 40.000000
z: -184.000000
x: 0.000000
y: -182151148635946720901512157250631761920.000000
z: 40.000000

here is my modified code for that
do you see anything wrong here
cause i cant
also im trying to look at the Level.bsp as text lol
im a php/sql/javascript person lol
and it wont let me open it in gEdit
plz help im so close here
and i cant find any bsp loading for linux

// Check if the .bsp file could be opened

if((fp = fopen("maps/Level.bsp", "rb")) == NULL)

{

	

	printf("cant open bsp file");

	

}



// Initialize the header and lump structures

tBSPHeader header = {0};

tBSPLump lumps[kMaxLumps] = {0};



// Read in the header and lump data

fread(&header, 0, sizeof(tBSPHeader), fp);

fread(&lumps, kMaxLumps, sizeof(tBSPLump), fp);







printf("strID: %s

", header.strID);

printf("version: %d

", header.version);

printf("kMaxLumps: %d

", kMaxLumps);

// Now we know all the information about our file.  We can

// then allocate the needed memory for our member variables.



// Allocate the vertex memory

m_numOfVerts = lumps[kVertices].length / sizeof(tBSPVertex);

m_pVerts     = new tBSPVertex[m_numOfVerts];



// Allocate the face memory

m_numOfFaces = lumps[kFaces].length / sizeof(tBSPFace);

m_pFaces     = new tBSPFace [m_numOfFaces];



// Allocate the index memory

m_numOfIndices = lumps[kIndices].length / sizeof(int);

m_pIndices     = new int [m_numOfIndices];





printf("verts: %d

", m_numOfVerts);

printf("faces: %d

", m_numOfFaces);

printf("indices: %d

", m_numOfIndices);

// Allocate memory to read in the texture information.

// We create a local pointer of tBSPTextures because we don't need

// that information once we create texture maps from it.

m_numOfTextures = lumps[kTextures].length / sizeof(tBSPTexture);

tBSPTexture *pTextures = new tBSPTexture [m_numOfTextures];



// Seek to the position in the file that stores the vertex information

fseek(fp, lumps[kVertices].offset, SEEK_SET);



printf("o: %d

", lumps[kVertices].offset);

// Since Quake has the Z-axis pointing up, we want to convert the data so

// that Y-axis is pointing up (like normal!) :)



// Go through all of the vertices that need to be read

for(i = 0; i &lt; m_numOfVerts; i++)

{

	// Read in the current vertex

	fread(&m_pVerts[i], 1, sizeof(tBSPVertex), fp);

	

	

	//printf("x: %f

", m_pVerts[i].vPosition.x);

	//printf("y: %f

", m_pVerts[i].vPosition.y);

	//printf("z: %f

", m_pVerts[i].vPosition.z);

	// Swap the y and z values, and negate the new z so Y is up.

	float temp = m_pVerts[i].vPosition.y;

	m_pVerts[i].vPosition.y = m_pVerts[i].vPosition.z;

	m_pVerts[i].vPosition.z = -temp;



}	

plz plz plz im gona jump
off this rooftop
its really high

I WILL DIE :frowning:

Check initialization of your data. I noticed that often under msvc, primitive data are stored to 0 whereas it is not under gcc (default iso c/c++ behavior).
And as said, ensure the types are the same sizes, this is very important for doing bit manipulation.
For the int size, I have 32 bits by default on my debian 64 gcc 64 (with no specific option used) but ensure this point.

ok i guess something was wrong with the the bsp parsing code from that one tutorial
like all my bsp objects were all messed up and rearanged
i am not sure why it would be like that since its a tutorial
but i found another bsp loading code and got it to start showing the right data in my debugging and it even came with a lil log file that the script makes which made it easy for me to see what is where and bsp now kinda looks like xml to me and got it to load the bsp
so im like way past that now
and got collision detection almost working
except when i enable it all it does a segmentation error
so now im doing early returns to see where its crashing wtfff :eek:
im thinking about putting a paper clip to the back side of the motherboard and just burning the dam computer
cause lets face it computers are WORTHLESS
but if someone can help me
the crash is somewhere in checkbrush code
or the checknode code
but it was working just fine with checknode only code
or if i do checkbrush and exit the checknode before it checks node sides
but not all together
friken sux okay
u dont just spend days building something just to find out its friken retarded and wont work
i am sitting on a 8 core xeon cpu but its only nvidia gt220
but still iono
jus help me again i gues someone

ok i jus end process on some dbus-thingy
now i cant do anything but press the computer restart button
fuk lol

ok can some one plz tell me what the inputEnd should be
right now i have inputStart the camera position xyx vector
and input end is the rendered face normal from the bsp
like i loop thru the faces being rendered
then do the traceray thing with the camera and face normal
is this even right

INPUTS
This is the information that the game will be passing to the function: our parameters.

* inputStart (vector)
  The point in the world where the trace will begin.
* inputEnd (vector)
  The position we are trying to reach in the BSP.

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.