Real Flash Quake

[Baker]

I provided you an engine source that compiles. You confirmed it compiles.

gl_model.c has where Quake parses the .bsp.

You could use that as a reference, see how Quake does it. You even said that the code might work in your chosen deal with little to no modification.

[MadGypsy]

gl_model.c!!! lol.

The only problem I have with your source is, I can never find what I am looking for. I have opened the entire source and did source wide searches, and I either get no hits or so many hits that I don't know where to begin.

resyntaxing your c++ to be haxe wouldn't be incredibly hard but, I have all this source that I wrote and I am trying to move it forward. Stopping to port a whole quake engine is like absolutely last resort. I am not trying to build a quake engine, I just want some of it's tech. Maybe even a bunch of it's tech but, not enough for me to glue myself to a legit quake engine source. When I get past these trials, and I WILL, you will see my little engine for what I intend it to be. It won't be comparable to quake beyond how the world looks. When I get past this BSP part I won't even have to consider a quake engine source. Away3D already has more than I want. Hell, Away3D parses md5mesh and md5anim files out the box. Once I teach away3d to play with BSP files the entire rest of my travels with this will only contain Away3D considerations.

Here are some facts.

1) findLeaf finds me and tells me I am in a leaf that matches the proper contents. I'm going to say that findLeaf works...finding the leaf I am in is not the problem
2) upon further examination (assuming findLeaf does work) room 1 is made up of leaf 15 and 17 only. From 17 I can't see around any corners or anything so the vis results of tag~15,17 are correct...vis is not the problem and has probably been correct 100 or so times

Let's put that together - I can successfully find myself in the proper leaf and grab the correct vis results. However, lots of walls and stuff that you would expect to be in these leaves are not there. The ONLY answer that makes any sense to me (even though I can't figure out how it is happening) is, leaves are full of the wrong faces.

I am about to stack 2 rooms with no access to each other and compile. It should give me 2 leaves. 1 for each itty bitty room I'm gonna make. If I tell my program to ex "show me leaf 1" and there are ANY faces for room 2 in it....leaves are full of the wrong faces.

Fun fact aside:
Some of you may laugh at me but, it is actually a fact that I pray for answers. Just a little "take 5" with God reminding him that he helps those that help themself and whatnot but, much more sincere and less nonchalant than I just described it. I'm not going to say that I have had any miracle revelations or anything but, I believe that in some way my appeals make a difference. I cannot describe it, prove it or even defend it. All I can say is I believe and it's because I believe that I do not give up. It's because I don't give up that I am tracking a problem that I do not understand and closing in on it. It's seriously running out of script to hide in.... faceConstruction, leafConstruction, face_t, edge_t....where are ya gonna run problem? There's nothing left.

[MadGypsy]

Below is my map of 2 leaves. The entire bottom floor is leaf 2 and the entire top floor is leaf 1;


Let's look at leaf 2


Well, that doesn't look anything like the entire bottom floor, does it? That's what it's supposed to be... The entire bottom room. There you have it, problem solved. Leafs are full of the wrong faces. Now I just need to actually solve the problem.

There are some answers here, though if I can glean them. If I go to the other leaf it is just the walls. Maybe there are some answers in that symmetry. Unfortunately that's probably just telling me this happened in a loop but, everything is in a loop.

[MadGypsy]

And just like that, vis is fixed. Ya know, I was wondering what lfaces is for... Alrighty then. I am going to call this a benchmark. Here is my current achievements.

1) completely parse a bsp
2) assemble all of the bsp geometry
3) "improper" but sufficient lightmaps
4) almost useless texture replacement. It compresses high def stuff down to pixely stuff I love it.
5) transparent water _ EDIT: fixing vis broke water lol. That's ok, I'll figure it out.
6) palette color 255 is invisible
7) PROPERLY WORKING VIS!!!

oh
8] all game assets are stored in and loaded from a zip (not lzma yet)
9) manifest.xml is used to define game assets per level.
10) PROPERLY WORKING VIS!!!

[Baker]

Good job

[MadGypsy]

give the floor a once over. Not too bad right? All of that is QRP textures;


let's look up close to what my code does to those textures.


replacement textures indeed My engine forces you to be vanilla, no matter what you think you're replacing. Watch, Imma create abnormal maps. They're going to override the norms to be flat again.

[MadGypsy]

Quickie:

You're running around in a Quake map and you find yourself in a room with no ceiling, revealing sky. You hear the wind rushing around you as you make your way to an opening on the other side of the room. You rush the opening with guns blazing and it isn't til the fight has ended that you realize you do not hear the wind anymore...

PAS - potential audio set. I haven't tried it yet but this should work.

while(getting vis leafs N)
{	type = Math.abs(dleaf_t[N].type);
	if(type > 1)
		snd = vectorOfSounds[type]

	if(snd != Already playing)
		snd.play(0);
	
	//probably some diff(leaf_center, player) * amplify for volume based on distance
}

[MadGypsy]

directly @ spike - consider this a question.

n = model_t[0].node[1]
while n > 0
n = dot( self, plane_t[ clipnode_t[ n ].planenum ].normal ) - plane_t[ clipnode_t[ n ].planenum ].dist;
n = >-1 //keep looping this is a clipnode
n = -1 //no collision
n = -2 //check...

n = model_t[0].node[2]
while n > 0
n = dot( self, plane_t[ clipnode_t[ n ].planenum ].normal ) - plane_t[ clipnode_t[ n ].planenum ].dist;
n = >-1 //keep looping this is a clipnode
n = -1 //no collision
n = -2 //HIT

this is "findLeaf" all over again but I am checking clipnodes? [1] then [2] if [1] = -2? What am I checking for with the second node check? Another -2? The above is just me fleshing out the general concept. If it's right, great, but, I just followed PointInLeaf and changed some expectations and the focus node. I guess the real question is simply, is that right?

[Spike]

clipnodes skip leafs. they directly store contents values instead.

to find in a point is solid within a clipnode tree, just keep walking until your node value becomes negative. and when that happens you know that its a leaf. you can then test against CONTENTS_SOLID, and if equal, its solid. otherwise its non-solid (either empty or water).

if you want to implement a traceline, you'll need to walk lots of nodes.
to trace from the start to the end. you'll need to be aware of not just one point, but you'll need to determine the intersection points of any nodes, and walk down the tree at that point too.
remember that dotproduct reports the distance from the plane, hence negative/positive says which side you're on. frac = -startdist / (enddist-startdist); if you have the frac, you can then interpolate the two points to find the intersection point.
with the intersection point known, you can continue walking the nodes at that point. stop walking when the far side of a node is solid (presumably the near side will be empty, but you may have started inside a wall).

[MadGypsy]

hmmm, can you point me to the source file that has collision in it? Any source.... even FTE. I swear, with all the source code I have poured over and heavily considered, by the time this is over I will be able to make a quake source from memory... maybe that's bullshit but it feels true.

[Baker]

SV_Move in world.c

[MadGypsy]

Thanks Baker. I think I'm getting better at reading C(flavor). I just read all of world.c and I don't feel like I have any questions. Of course when I sit down to implement all of that things might change but, I'm actually pretty confident they wont.

I went over all of my scripts and made them insanely tight. If I go any further this is going to start to look like minimized javascript. I also added some optimizations. One optimization is only adding leafs that aren't already visible and only taking away leaves that aren't in the current vis. As opposed to removeAllCurrent, addAllNew.

I have one weird anomaly where the very first time you visit geometry it lags for a second but, then no matter what it runs smooth as ice. By no matter what I mean even if there are a lot of polys. I can actually get pretty brushy and my performance only dies on the very first call to vis for that geometry and just for a second. I do not like the little jittery lag but it is very promising that it completely goes away after the geometry has been added once. I hope I don't have to do anything weird like start the view, cycle the entire vislist, revis to current and then unlock the keyboard for gameplay. I tried something similar to this before the map gets added to the view and it didn't fix shit. By observation, the view is the problem or I should say, where the issue is born.

Anyway, I am going to knock out collision tomorrow, maybe start tonight. I'm probably going to align lightmaps to texmins too. I'm still not going to textel the lightmaps but hopefully I can get lightmaps on odd shaped faces to line up better.

I also thought about atlasing textures and decided that it doesn't make any sense for me to do that. Maximum image size in flash is 2048 by 2048 and that is all the reason you need not to make your life miserable managing multiple atlases. All images are stored in a vector. I don't understand how indexing out of an image is any better than indexing out of a vector.

I looked through the away3D docs and I can make my current lightmaps dynamic to away3d RTL's by simply applying a shadowMapMethod(). This gave me an idea where I can have semi-dynamic lights. For most of the lights I can just keep doing what I'm doing but I could use the entity list to find the most powerful lights and create a RTL from only those lights or maybe just add a field to lights that will serve as an RTL marker. I'm sure there are plenty of situations where I will find that this leaves much to be desired but, some trial and error should give me something decent.

Something hit me yesterday that made me smile huge. All this time I have been focusing on this engine I haven't thought much about around the engine. I always knew I would use radiant to make my games but it didn't hit me til yesterday that I can create an entire radiant gamepack for my engine in my sleep * infinity. I don't have to do anything the quake way, none of it. Completely new systems. Here is a small example but, not necessarily something I will include. What if lifts already knew where the next floor was and even knew if there was more than one floor to lift to? I could think of more stuff like this but my brain is thinking about world.c and I don't want to stop it.

[MadGypsy]

@anybody with an answer

why does quake source do

void func(in, out)

instead of

T func(in)

also what does the asterisk mean? By reference? Like &$quotient in php?
func(..., int *quotient)

______________
reminder to self: 164 to go

_________________
bang out list for sun - wed

1) collision detection
2) texmin lightmaps
3) troubleshoot first vis lag
4) capture and control a brush entity
5) parse mdl (I'm actually probably one func away already. I need to read about away3D's IAnimation interface before I can finish)

[MadGypsy]

	// lightmap texture coordinates
	...
	s += fa->light_s * 16;
	...
	t += fa->light_t*16;

Which one of these is light_s/_t ? light[2]/[3]...from my code (ie //light1, //light2)?

$face_t.forEach(function(na:Object, n:int, self:Vector.<Object>):void{
	self[n] = new Object();
	self[n] = {
		plane_id:$lumps[_faces].readUnsignedShort(),	//	plane_id
		side:$lumps[_faces].readUnsignedShort(),	//	side
		ledge_id:$lumps[_faces].readInt(),		//	ledge_id
		ledge_num:$lumps[_faces].readUnsignedShort(),	//	ledge_num
		texinfo_id:$lumps[_faces].readUnsignedShort(),	//	texinfo_id
		light:[
			$lumps[_faces].readUnsignedByte(),	//	typelight
			$lumps[_faces].readUnsignedByte(),	//	baselight
			$lumps[_faces].readUnsignedByte(),	//	light1
			$lumps[_faces].readUnsignedByte()	//	light2
		],
		lightmap:$lumps[_faces].readUnsignedInt()	//	lightmap
	};
});

[MadGypsy]

I get it, msurface_t is a composite of a couple/few bsp structs but an entire sourcewide search does not show anywhere that light_s/t is actually being set. How can you use a value that has never been told to equal anything? Surely there is some voodoo here. This is one of the reasons that C(whatever) is one of the only widely used languages that I can't claim to be a programmer in. Even tracking down vars does not always give any answers. I mean really, where the fuck is the source setting these values? According to np++, nowhere.... Line 769? Setting it via out? Lemme go search AllocBlock which I'm guessing isn't going to tell me shit cause it would have popped up in the search with some light_x =.


OK, I take it back. I see, light_s is passed by *reference to AllocBlock which is exactly what sets it. Unfortunately I don't understand at the moment what it is setting it to. I just need to read it a couple more times. And now I also know why void func(in out) is used instead of T func(in)... so you absolutely can't read or find shit. I mean, it's actually probably used to set more than one var at a time but it is breaking the readability of the code. You could just as easily send the whole struct through the process returning a modified struct.

I also noticed that the source is 50 million little functions that often have exactly repeating scripts in them. A lot of this could be done in one pass. Face/Leaf construction is broken into a retarded amount of steps and repeating code covering ?1000's of lines. I do the shit in 3 functions and 183 lines. Granted my way is not identical but I could make it identical without adding anymore functions and barely any more lines.