Real Flash Quake

[MadGypsy]

I see. I get the same result without the position field var. You're just running the same edge decision from calculate surf extents.

[MadGypsy]

OK! I have fucked with this uv,lightmap,surfExtents bullshit all day. My method was to compile the entire texture per face into one static facemap that has the lightmap drawn on it. In other words no blinky lights etc, the shadows are forever. I have come to the conclusion that I do not have the math to get all this shit scaled properly doing it that way.

So, fuck spitting out the all in one combo map. I backed up and treated the miptex as a repeat texture. The UVs are perfect. The repetition is perfect. Now I just need to take my lightmap and figure out how to add it as a second material to the face. This is driving me gazonkers but 1 of my 2 problems is fixed. I can't wait to get past this part.

[Baker]

The dynamic lights in Quake has so many components that is not easy to get a handle on them. It has a great number of moving parts that have to work together and even more to make it work at a reasonable speed.

[MadGypsy]

I finally did it. I have a real lightmap being applied on a completely different "channel" with completely different uv's. The repetition of textures is correct. My only problem now is there is a thin black line on all the seams. You can see it cutting through the first 8th of the ceiling and leading down the back wall, pretty well. That's small beans in comparison with today's accomplishment.

[Spike]

www.quaddicted.com/filebase/jam6_daya.zip
try that map.

[MadGypsy]

I finally got it to work properly...fuck smooth. Smooth is a sneaky dirty bitch that makes your life miserable until you eventually change it just to see...

fte for me vs real comparison


@spike - I will try that map but, I'm pretty sure it isn't going to work. My engine doesn't manage leaves yet. All geometry gets dumped to the buffer and 65k is my limit right now.

[MadGypsy]

hah. I added some zany FOV.


@spike, I can tell from the screenshot that came with the map that there is no way in hell my engine is going to load that. Baby steps, my friend. I've come a long way from dumping structs text. Not far enough to try and load maps like that though. Honestly, I may never be able to load a map like that. That's OK. I knew this engine was going to have some serious limits. That's why I chose BSP, so I could hide most of the geometry and maybe in that break some limits without actually breaking anything. I know this will never be an "FTE". Hell I would be happy if it's somewhere in the neighborhood of any low end quake.

[Baker]

You've done a good job getting that to render

[MadGypsy]

Heeeeeey, thanks, man! I'll tell ya, I got rid of calc_surf_extents, didn't make a uv method and handle lightmaps entirely different. My method does everything in face construction loop.

The code on the right is the rest of the code on the left. I had to duplicate and split screen so you can see all of it. This one method does all of the face construction just short of applying the material. That -vert[x] is not a typo. The map was completely flipped on the x. That minus popped it right into place. I could probably get rid of the autoDeriveVertexTangents part. I was just seeing what that would do. I do not get or use texmins at all.


And this script comes in right behind it, textures the faces and pushes them into the proper leaf. The reason why faces are textured here is because I have to put the faces into leafs as subgeometry first then derive a submesh from that which I can apply textures to. Hence .. _faceMesh[leaf[lface_id] + e] = _leafMesh[n].getSubMeshForSubGeometry(_faceGeom[leaf[lface_id] + e]);. If you think about it, this stipulation is going to work to my benefit when parsing entities. I just stick the proper "lookup" geometry for the entity into the proper leaf and it's going to return the submesh. At that point I can make that mesh "special" and apply some entity code to it for whatever it is.


That's pretty much the entire bsp constructor with the exception of my calculate_lightmaps method. If you do a little line number subtraction, I am constructing the entire bsp (except lightmaps) in 144 lines of code, and a lot of those lines are nothing but "}". Lightmaps is another 39 lines. 183 lines that I could probably shorten to half with some seriously unreadable optimizations.

[MadGypsy]

@I'll tell ya, I got rid of calc_surf_extents, didn't make a uv method and handle lightmaps entirely different.

I just realized that may sound like your help was useless. IT WAS NOT! You and Spike's help has been very valuable. Everything both of you guys have shown/told me has been either -

a) used in it's entirety. Pretty much all of Spike's answers to my "get off the ground" questions were used verbatim.
b) considered heavily and used piecemeal. calc_surf_exts is a good example. I'm doing all the same stuff but I keep it local to face construction
c) not used at all but, gave me info to write what I believe is a better way. Or at least better for my circumstances. Lightmaps are a good example of this. The Quake way is no good for me. Creating lightmap blocks just gives me more shit to construct and more UV's to consider. I just calculate the whole damn face in one, pow2 the result dimensions and be done with it.

Hey, since I am really making "Handmade Quake" (so to speak) does that mean I have to wear eyeliner and make videos?

[MadGypsy]

Okey doke. I ripped gyp1m1 down to a digestible amount of faces for my engine. There are numerous problems. That's OK, nobody ever said this was going to be easy. Baker specifically told me it was going to be very hard and I will need to work on my 1 finger death punch. Lightmaps are still overflowing. I already knew that was going to happen. I haven't figured out how to make it stop. Stopping on 255 did not solve my problem. That's OK too. My FPS's are terrible at this lod. However, if you look at my stats thingy it even says I'm using dx9. This is just some bargain laptop.

This has me thinking about conversion. I could add on top of what I already have to spit out a more results driven byte file that flash can read with nothing more than a readObject(). Also, I could write an algorithmn that rewrites the indices order and compresses the vertices array in order to share verts instead of stacking them. In essence I would be creating my own BSP format but, cheating by simply converting a regular one. AMF2BSP ... amf2 serialized bytes of bsp data. The gain here would be "instantaneous" parsing of the file and a 1/4 of the verts per map. The vertex buffer will thank me. I can also dump garbage data (texinfo.offset2,4,;

All in all, I'm not sweating the poor performance right now. I'll get better at this and things will improve.

I accidentally deleted a few texture lights, that's why the map is so dark.



edit: Of course the indices buffer would still overflow. Meh, I have no idea what I'm doing.

[Baker]

a) used in it's entirety. Pretty much all of Spike's answers to my "get off the ground" questions were used verbatim.

Without beating a dead horse, I did think you were in over your head. At least initially.

But you kept at it, and only stubborn people ever achieve victory so ..

[MadGypsy]

@Baker - funny thing, when I asked you the byte type and you told me it's a fuckin mystery (LMAO) I was determined to get you on my team. What I mean by that is to stop telling me that a,b,c is too hard, an enigma, etc... and just help me out with some real answers. I program in somethin like 20 languages. Trust me, I have the skills, or access to them for anything I decide to do. I'm not as bitwise as Spike or anything but I'm definitely not a noob.

I was pretty sure if I could stick some actual results in front of you, you would take me a little more serious.

[MadGypsy]

This is snore1m1. At this lod I'm averaging 45+/- fps. I'm also at fullscreen. I noticed windowed tests have a lil bump in FPS. I still haven't made leaves disappear yet. My first map was only one leaf. I'm going to need a map to test my engine stuff so... This is only going to be 3 simple rooms.



this is to show that my textures are definitely correct.
the side of that ramp... rotate: -22, vertical shift: 8


at the top of the stats, the number all the way to the right is my average FPS.

[Baker]

@Baker - funny thing, when I asked you the byte type and you told me it's a fuckin mystery (LMAO) I was determined to get you on my team. What I mean by that is to stop telling me that a,b,c is too hard, an enigma, etc...

Here is a thought for you:

If you want to convert what you have done into something useful in an intermediate sense ...

You might consider adding the ability to walk around the map.

I mean collision and movement.

If you merely made a map viewer that you could walk around the map with, say, the arrow keys, that would be something incredible by itself --- especially if Flash could do it.

(Obviously, doors and moving parts wouldn't work. And the player wouldn't have a model, etc.)

I'm just throwing an idea out there for a (somewhat) quick, stepping stone like victory.

Warning: Collision is hard. And physics --- even simple movement --- is a bit harder than you may think (gravity, frame rate, acceleration, friction, what happens if you walk forward into a 45 angle wall, move tests --- what if your current momentum x current frame time increment puts you past geometry ).

(And no I don't play head games, I didn't say "collision is hard" to motivate you or anything, I'm just pointing out that collision is -- in fact --- hard. Especially with Quake hulls. This is why although I think a few people have made bsp viewers and such, I don't think anyone has ever made a bsp viewer that you could navigate the map (i.e. not "noclip" around but actually walk on the geometry.)

/Anyway, it's just a thought --- not even a suggestion or anything. Only you know what you want to do.