Real Flash Quake

[Baker]

OK so the tally is in. Haxe is fuckin hard! That's not discouraging me but, it is very true. The complexity comes in that, even with openfl, it is not as "simple" as porting flash code to haxe. Mainly this has to do with loading external files. I have to write the c++ way, the neko way, keep the flash way for flash and I'd be willing to bet I have to write an android way. There is no one-script-to-rule-them-all for file management. At least none that I can find.

That's the trade-off when using something that tries to shield you from the internals.

You could try using something that doesn't shield you from the internals --- but then you have to learn the internals, which is very nasty. And if you are going to learn the internals, you also need a reason --- and "making a game" isn't really a strong enough of a reason.

So it's damned if you do, damned if you don't.

But "flavor of the day programming language" that shields you from the terrible things going on underneath --- there will always be more of those languages and they never last all that long. And they always will have compromises because each platform has it's own limits and stupidity and even worse things you don't want to think about.

Like you probably didn't know Android doesn't even really guarantee a place a to write files, for example ...

[MadGypsy]

@never last that long

I bet you are right in a general sense but, Haxe even works on PSVita, tvs and all kinds of other stuff. There is talk of using haxe for steam and other talk of no-matter-what it is possible. It has also been around for over a decade. It's the less popular (yet) Java of things, so to speak. It is a very powerful environment. Mastering something like haxe means your products will work on everything capable. OpenFL is just one API of haxe. There are many, many more. I typed "lime setup windows" and it downloaded, installed, configured and used vs2010exp, successfully on the very first try, to build a c++.exe from haxe code with the inclusion of an entire haxe 3d engine. It took that same code to neko,flash and html5. That's pretty impressive in my book. One of the awesomest things is how it targets differently per platform. When I use flash/c++/neko I get Away3D engine, when I use HTML5 I get three.js engine. I don't even tell it anything. It's automatic.

Actually, there is the perfect testament, Away3D. Written in haxe and works on everything in their own native language. It's a pretty nice engine, too. It can do most of what people expect DP to do, maybe even all. I've never compared side by side.

@...like you probably
android does not seem to provide an easy method to retrieve files outside your namespace either. For instance: try getting someone's music library. I have had major issues with similar attempts.

[MadGypsy]

I just had a thought about something, which if I am correct, it will mean I can open very large maps. It struck me that I am placing all of the map data in one geometry object, each leaf representing a piece of subgeometry. What if geometry was split up by vis? This should add more vertex buffers with a lot less in them, hopefully giving me a much greater amount of vertices to play with. Vis would also be different. Instead of looping through all the possible leaves it would just determine which chunk of geometry you are in.

This sounds right to me. Why not precalculate and segregate entire vis geometry? I could do this once.

[Baker]

Why not precalculate and segregate entire vis geometry? I could do this once.

Because it is essentially impossible.

Are you going to create a database with one entry for every possible combination of X, Y, Z? 8192 x 8192 x 8192 is a 12 digit number and you computer doesn't have that much memory. (ignoring that it is worse than because your position is floating point not integer so the number of combinations per dimension far exceeds 8192 anyway).

So vis is a test based on where you are at and it is a series of YES/NO tests based on your current position and returns a (rough) set of what you can see.

And it's more than just what parts of the map you can see. It includes "can you this Ogre" based on where the ogre resides, AFAIK.

This is why if you load up a normal engine and set r_wateralpha to 0.5 and r_novis 1 and go to (non-water vised) level e4m4 and look into the big water with the fish you can't see the health boxes underneath. Because the sv visibility test still says you can't see the health box entities.

[MadGypsy]

I see. Well, then each leaf needs to be it's own geometry. One way or another the geometry needs to be split up so I don't overflow the vertex buffer.

[Baker]

Vis might let you do it in less "areas" because it limits the possible combinations. But the number of combinations would still be large.

Short version: I think if it were realistically feasible, MH would have done it in DirectQ or Spike or LordHavoc would have done that.

Considering that MH ...
1) wrote DirectQ more or less from the ground up
2) Understands BSP (i.e. wrote the BSP2 format, writes lighting tools like MH light)
3) Likes rendering optimizations and DirectQ is full of them
4) AND didn't come up with something you suggest, but certainly would have thought if there were a better way ...

It's fairly safe assumption there no obvious or efficient way to do what you are suggesting within the confines of what BSP allows if MH didn't come up with something.

[MadGypsy]

I hear ya. It's all part of the discovery process. I throw ideas out there based on where I am and I get answers back based on where you and others above me are.

On a side note, since I started from the ground up, grabbing a "pak", getting the assets...etc. I was able to code together some texture replacement. How I did it though is barely better than the original textures . I have it redraw the replacement against a scale matrix as an alternative to getting the original. I know I should scale the uvs instead but I like this way. It's like somewhere in the middle of original and qrp.

The runes on the wall are just so I can be positive of where I am regarding wherever it's supposed to be xyz and wherever I put it xzy.

[Spike]

I just had a thought about something, which if I am correct, it will mean I can open very large maps. It struck me that I am placing all of the map data in one geometry object, each leaf representing a piece of subgeometry. What if geometry was split up by vis? This should add more vertex buffers with a lot less in them, hopefully giving me a much greater amount of vertices to play with. Vis would also be different. Instead of looping through all the possible leaves it would just determine which chunk of geometry you are in.

This sounds right to me. Why not precalculate and segregate entire vis geometry? I could do this once.

you're thinking along the right sort of lines, but forgetting that the pvs isn't maleable enough for that to be practical.
SO COME UP WITH A HYBRID SOLUTION!

if you want good performance, you need to submit geometry in large batches. you cannot (normally) batch between multiple textures, so you need to subdivide the world into per-texture batches.
if you have per-texture batches, its fairly trivial to move the batchid into your face struct instead of your texture struct. then you can easily split it so you have multiple batches for texture with over 65k verts in surfaces that use them.
if you do that, then you find that you have only a few vertex buffers. with that done, you don't have to shuffle any more verticies around at all. all that then remains is the index/elements buffer. this is significantly cheaper to update, its just a few shorts. you can also calculate the maximum index count for each batch.
this means you can then easily loop through the surfaces and just add their indexes to that face's batchgroup's list of indexes.
then just submit each set of dynamic indexes along with their static vertex buffers.
if the pvs hasn't changed then you can just reuse your dynamic indexes from the previous frame. even if it has changed, you can usually get away with using the last frame's indexes anyway while you have a thread working out the new indexes (aka: temporal coherance).

really, the only complication is lightmaps, although you're ignoring lightstyles in a q3-esque way anyway, so that'll trivialize it for the most part. the only remaining problem there is splitting your batches according to both the texture and lightmap-atlas-texture, as well as vertex overflows.

ignoring the frustum and using only the pvs is easy enough. you'll end up with a load of geometry behind the camera, but the gpu can cope with that more easily than you can via checking if leafs are actually onscreen - assuming at least one surface from that batch is onscreen anyway.

you're running inside a VM, so its fairly safe to assume that the gpu will be noticably faster than the cpu.

[MadGypsy]

I have 2 major problems.

1) I can not get this vislist to work. I would seriously pay you to fix it for me. It's better but still not right. What I thought I understood is not correct cause I went back to a copy and paste way (sort of) and I got better result. One thing I can be positive of is that I am finding the right leaf that I am in. When I am in water leaf.type is -3. There is only one spot of water. All the rest of the time I am -1.

2) I haven't gotten this far yet but, clipnodes. I just know this is going to drive me crazy.

If I could get past vis and clipnodes, I know I could fly. That would pretty much be the end of invisible data that is really hard to check. I'm about to give vis a break and try getting something else to work. Maybe I will finally parse models. I really really wish I could figure out what is wrong with my vis. I have done everything from straight out of the specs to straight out of various quake source codes and a ton of misunderstood variations of all that. I even considered that maybe some nutty way my leaves were out of order. They are not.

I even rewrote the struct parser to be a vector of Objects instead of a vector of vectors. This way I am directly using a name instead of numbers.. face_t[0].plane_id vs face_t[0][0/*plane_id*/] and I don't have to worry about the case where Vector.<Number> contains an int and decides 2 is 1.99999999998

@ but forgetting that the pvs isn't maleable enough for that to be practical.
psssh, I can't forget something that I don't know what the fuck I'm doing LMAO. It was cool that you didn't assume that I don't know, though.

[Baker]

When I first heard of the project that isn't made from scratch but somehow still uses the word "Handmade" --- much to the confusion of Daniel Webster or whoever wrote the dictionary --- in combination with the word Quake, I made a comment on Func_Msgboard:

That guy is going to get totally and absolutely owned.

He is terribly underestimating and doesn't have the foggiest idea of the internal systems involved (collision, bsp, the QuakeC virtual machine, etc.) and seems to have no clue how complex things like a sound mixer are.

He's in for rude awakenings upon rude awakenings."

I didn't repost this comment in the news thread here because I wasn't trying to be too down on that project -- but I guess I kind of came across that way anyway to some -- my critique was the misleading name.

However, in hindsight, this comment I made @func but didn't post here is very educational.

[Mindf!3ldzX]

When I first heard of the project that isn't made from scratch but somehow still uses the word "Handmade" --- much to the confusion of Daniel Webster or whoever wrote the dictionary --- in combination with the word Quake, I made a comment on Func_Msgboard:



I didn't repost this comment in the news thread here because I wasn't trying to be too down on that project -- but I guess I kind of came across that way anyway to some -- my critique was the misleading name.

However, in hindsight, this comment I made @func but didn't post here is very educational.

All good Baker, Phillip Buuck probably has a better grasp on game development than is alluded to in a simple tutorial video series title. I was like, wow dude you worked on MKX. <NERD3

[MadGypsy]

@baker... I hear all that and raise you a "no doubt" but, this is all just problems and solutions. Sure, I'm getting owned in some respects but, I know what I am doing is possible. The answers can't allude me forever. If I have to, I will sit down and rewrite quake one line at a time.

If I keep spinning my wheels on this part, I will for real hire someone to bang it out and the answers will be mine forever. Especially if it gets coded like I code.... directly to the point.

[Baker]

All good Baker, ... probably has a better grasp on game development

I was critiquing the project name and pointing out the steep cliff challenges, not trying to hurt the guy personally.

If your goals are noble as well, you should edit your post and remove the gentleman's name, unless you are trying to poison the search engine well against the guy.

[MadGypsy]

upper left
Practically verbatim from quake specs and I have seen functionally identical code in quake sources.

upper right
mini walkthrough of the leaf I am in straight out of the vislist

bottom hilighted
marked leafs are exactly what I would expect from the walkthrough

The bottom line is, it's not right. leaf 16 definitely needs to be marked but the bit isn't there. Leafs 12, 13 and 14 should also be marked but the bits aren't there. How can I be doing something wrong when I am copying and pasting the specs (basically)?

I am dead positive I am finding the correct leaf that I am in. I go in sky, it tells me I am in sky. I go in water, it tells me I am in water. My skys and water do not sit on equal levels in the map. There is no way it is telling me I am in sky but it actually thinks I am in other sky. There is only one water. This vis shit is the problem. It's all right there in that one function. Something is wrong but it's almost identical to what everyone swears is right, including the specs. My only difference is syntax and chosen variable letters it's functionally identical.

Edit: my map has no leaks or any other problems and runs perfectly in any regular quake engine... or at least it runs fine in fte and proquake there is no reason to believe any other engine would be different.

I'm gonna grab and oldschool compiler and see what happens.

[MadGypsy]

I went full on BSP shredding. This is my conclusion. Although not at all obvious in my script, somewhere it is pushing the wrong faces into a leaf. I say this because I'm immersed in water "2 feet" from the surface but I can't even see the water texture. It knows I'm in a water leaf, but I can't see the face of water? The faces of the water brush I am inside of? It has to be the faces (i hope).

I am going to figure this out! I've built half of a BSP analysis tool and I'm gonna build the other half if that's what it takes to fix this problem.