Real Flash Quake

[Spike]

I'd give you a pointer... but I think you have too many already...

* in a definition means that its a pointer.
* outside of a definition dereferences it so the term refers to the value the pointer points to rather than the pointer itself.
-> also dereferences the pointer, while '.' can only be used on non-pointer types (or structs that were already dereferenced from a pointer...).

returning large structs is considered bad practise because a) it is slower. b) different compilers implement it differently, resulting in compatibility issues.

AllocBlock is the allocation part of glquake's lightmap atlasing. its a texel offset, and used when the engine repaints a surface's lightmap due to dynamic lights or lightstyle changes. as well as to work out the lm texcoords.
if you have no atlasing then logically light_s,light_t would always be 0,0

[MadGypsy]

good info! thank you!

@too many pointers
I don't know if this is a reference to how many tips y'all have given me but, if it is, I just want to say that all help is appreciated beyond measure. I am not dilusional or c_ocky that I could do this without you guys in a timely manner. Also, it will not go wasted as I hope it is clear by now that I am really doing this thing.

I even cut my days at work from 4 to 3 in order to have more time. Essentially, I have relinquished a quarter of my income cause I am dead serious about this.

In a year or less I will have a game on every device store, every platform and I will never flip another burger as long as I live. re: my signature.

[MadGypsy]

Hah, I just realized something. I technically have some of the greatest quake engine programmers, ever, helping me with my little engine. Right? Of course I'm right.

@light_s/t... 0 for no textels
so those are column/row vars

@passing structs != good
I can understand that. In flash there isn't really a struct, though Object is very similar. I'm currently using Objects but, instead of converting them into composite objects they are processed in their entirety within in one loop. Each iteration moving to the next type_t Object. So my method doesn't require passing anything. It's all a read, make, done system. I intend to get rid of my objects and go back to vectors. Now that vis works I don't have to worry about reading field names or storing them.

[Baker]

	int x = 10;
	int *ptr_x = &x; // & means address of
	*ptr_x = 11;  // Alter the memory where X is and set it to 11.

	// Variable x is now 11.

[Baker]

light_s and light_t come from

void GL_CreateSurfaceLightmap (msurface_t *surf)
{
	int		smax, tmax, s, t, l, i;
	byte	*base;

	smax = (surf->extents[0]>>4)+1;
	tmax = (surf->extents[1]>>4)+1;

	surf->lightmaptexturenum = AllocBlock (smax, tmax, &surf->light_s, &surf->light_t);
	base = lightmaps + surf->lightmaptexturenum*lightmap_bytes*BLOCK_WIDTH*BLOCK_HEIGHT;
	base += (surf->light_t * BLOCK_WIDTH + surf->light_s) * lightmap_bytes;
	R_BuildLightMap (surf, base, BLOCK_WIDTH*lightmap_bytes);
}

The line with AllocBlock is passing the memory address of surf->light_s, essentially turning it into a pointer --- if you follow it through AllocBlock is writing light_s, light_t (indirectly).

The & operator is the memory address of something, on the other side the reader is going to be pointer --- look at allocblock function.

[MadGypsy]

I fully understand, thank you. An extra thanks to Spike, too for pointing out 0,0. I'm not confident I would have put lights use together very quickly. I may have even wasted a bunch of time with it. Between you two not only is my little engine going to be decent, it appears I'm gonna learn whatever c this is all in, as well. I never forget and I'm a man of my word. Both of your help will not ride as a free expectation. Just keep racking up the bucks, you'll get them.

[MadGypsy]

I have accomplished a lot of things and my stuff works reasonably but, I know I can make it all better. I am going to "start over" (in a way). Obviously, reading structs and stuff like that doesn't need to be addressed, I read them and they spit out the correct data. My method for constructing the geometry is also probably fine. What isn't fine is anything regarding textures. They mostly look fine except for some lightmap anomalies but they run like shit. That stutter I spoke of in an earlier post is due to drawing textures. My method is too cumbersome and it makes it impossible for me to merge faces because everything has it's own texture. The texture system needs to be reconsidered in it's entirety. My engine is on pause while I create a tool that will turn a folder of images into a texture atlas with an accompanying data file that defines the UV offset of each individual image. When that is done, I will go back to my engine and reconstruct the entire texture system around the atlas and the accompanying data file.

At that point I will finally be ready to work on collision.

[Baker]

In FitzQuake and therefore Quakespasm, you can type "imagedump" in the console and it will download all the textures in memory from OpenGL and write them to file.

Probably easiest using this build

(Note: ALT-ENTER toggles full-screen)

After downloading the above:

Type: imagedump
Type: folder
Then find scrap0.png or look at the textures named lightmap001.png, lightmap002.png -- both of those are texture atlas textures.

So is this the Quake character set (conchars) which is named gfx.wad_conchars.png when doing an imagedump.

AllocBlock determines positioning of the lightmap s/t coordinates on load (the variables you asked about where they were written). Scrap_AllocBlock in gl_draw.c does the same for the tiny HUD pics.

And of course, Draw_Character uses texture coordinates obviously

void Draw_CharacterQuad (int x, int y, char num)
{
	int				row, col;
	float			frow, fcol, size;

	row = num>>4;  // Divide by 16 to determine row (i.e. 240 / 16 = 15)
	col = num&15;  // div 16 remainder for col (i.e. 14---> 14  15---> 15  16-> 0  17 ---> 1  18---> 2 etc.)

	frow = row*0.0625; // Multiply by 1/16 to get 0 to 1 range texture coordinate on X
	fcol = col*0.0625; // Multiply by 1/16 to get 0 to 1 range texture coordinate on Y
	size = 0.0625;

	glTexCoord2f (fcol, frow);
	glVertex2f (x, y);
	glTexCoord2f (fcol + size, frow);
	glVertex2f (x+8, y);
	glTexCoord2f (fcol + size, frow + size);
	glVertex2f (x+8, y+8);
	glTexCoord2f (fcol, frow + size);
	glVertex2f (x, y+8);
}

[MadGypsy]

how do I determine which way a face is facing? I'm about to rtl surface textures and I need to know which way the surface is facing so I can put the offset of the created light on the correct side of the surface.

Fun, sucky fact. Now that I'm using atf textures I cant do anything like blend.MULTIPLY unless the texture I am blending is also atf. This has some pretty big consequences. The ONLY way for me to do lightmaps from a bsp would be to export them all, convert to atf and grab that version when the map is loaded. There is no api for converting bitmaps (of any kind) to atf so this would be a "before release" thing. All that sounds stupid to me. I am going to continue to persue blinking lightmaps onto the surface via a rtl.

[Baker]

how do i determine which way a face is facing?

surf_planeback

[MadGypsy]

I have to be honest. I do not understand your answer. I went to the specs to try and derive the answer but, the closest I can find would be plane_t[ face_t[curr].plane_id ].type. Something tells me that's not what you meant.

[Spike]

'surf_planeback' is some flag that is set according to the 'side' boolean field of the dface_t structure.

the plane normal is a unit vector that faces either towards or away from the surface that references that plane, depending on whether that surface faces the front of the plane or the back of the plane (read: if the side field is set, negate the normal).

you can also take the first 3 non-degenerate points of the surface, subtract two from the other and then do a crossproduct on the two remaining points then normalise that. the winding order (you preserved that when picking the 3 points, right?) is always the same, so with that you've calculated the direction those 3 points face without needing to depend on the plane or anything. this is handy (albeit expensive) if you're dealing with trisoup.

the plane type is useless. its axial at best. and even then its either positive or negative.

[MadGypsy]

thank you.... all geometry elements are preserved. I can get any (sub)geometry elements back just as I used them.

fun fact about winding order... remember I had to do it backwards? I was doing x -y z rotX -90 (pppbbbt..lol, we learn right?). I switched to x,z,y and I had to rewind the proper direction. I have learned exactly 17006 things throughout my current project travels.

[MadGypsy]

My current plan is to establish most of the light data before face construction and when I get to face construction get the last data I need. This is only for surface lights. Basically any other light (but sun) has an origin for me to grab. While I am constructing faces I already have that face's texture information "open" so, it should be nothing to say:

private static var surfLight:Vector.<String> eventually ='s [/*surface lights name list*/];

...building faces
if(surfLight.indexOf(thisTextureName) > -1)
//do

you can also take the first 3 non-degenerate points of the surface, subtract two from the other and then do a crossproduct on the two remaining points then normalise that. the winding order (you preserved that when picking the 3 points, right?) is always the same, so with that you've calculated the direction those 3 points face without needing to depend on the plane or anything. this is handy (albeit expensive) if you're dealing with trisoup.

//and put a light in front of it, or at least get the coordinates to put the light there later.

[MadGypsy]

My before work question of the day.

What are edicts, and would eDict be more appropriate? ie... an edict is a law. An eDict is a dictionary of something e (?entities)
I see there are SV.edicts and PR.edicts. What should I expect these to contain? The code for these things is very abstracted and it is hard to trace down all the spots to try and make sense of them.