Real Flash Quake

[MadGypsy]

@spike - you are the man! reverse winding order did the trick. Fuck Yeah! Now I just need to work on my texture/uv code so the floor and ceiling display properly. Everything is run through the same process, I'm not really sure why horizontal planes are flipped. It doesn't matter yet. My method for resizing the texture is not right. I had some ideas though. I'll get it right.

This is way more fun than any other Quake thing I have ever done. I have obtained a fair amount of fun from my Quake related projects but, this takes the cake. It took 10 or 12 days to get this far but 4 to 6 of those days were work ones. Technically, if I would have had 5 or 6 straight days off I could have done all of this in 5 or 6 days. My stated days aren't precise because I started this thread a couple of days (maybe 2, maybe even 3) after I actually started this project but, I don't remember exactly how many.

[MadGypsy]

I hate being at work when it's slow. I don't need the money and there are better things I could do with this time. I have one hell of a gameplan when I get home (in 6 hours... sigh). I think I have numerous issues solved. I just need to get behind a computer to start solving them.

[MadGypsy]

I finally got my map to render properly. I had to exactly remove one minus sign that was converting a number to negative. Voila'. There is still a whole fuckin lot to do. I'm on it though. I love this project.



I've passed phase one. I said I would get a bsp to render. That is a bsp and it's rendering... properly even (and at a blazing 62fps). The next phase is getting leafs to work as intended. I haven't done anything at all regarding leafs. Well, that's a little bit untrue. My code breaks all the leafs into meshes but, I never told it to determine if I am in any given leaf and/or whether that leaf should be displayed.

extra:

When I first started this project my method was to redefine EVERY struct (I mean even Vec3_T, BBoxShort_T, all of them) as an entire class. Each class had a read method that would populate it's vars from the data that was fed it. Let's assume we have a map with 5000 planes, this means I would have 5000 plane_t class instances. There are technically 16 lumps in a BSP if you want to count the header.... Let me just put it like this, there are exactly 10 gazillion and 4 classes for a map doing it that way. There is also like 20 summin classes that you have bloating up the code to make this happen. My second method was to parse everything straight into Vectors. My thinking was (and is) it doesn't matter if I can read the code as long as it works. For instance someLump[e][v] says nothing. What is e? what is v? However, if I just get e and v right then it's right and I may never even go back to that code again. So, who cares if I can't read it. This way is very fast. As fast as I can expect flash to be, which is quite fast at some things. Racing through vectors in a loop is one of them.

I got to a point where my (now) 1 class was getting huge and hard to navigate. I broke it down to 3 classes and these 3 classes are all I will need to completely parse a BSP. I have BSP, BSPStructs and QuakePalette. QuakePalette is fairly obvious it's a big Vector of hex that represents the actual QuakePalette. You can see from my pics that's it's correct. I also stole it from Quake Forge so... BSPStructs invents the vector nightmare and BSP parses leafs,faces,vertexes,edges,the visible lightmap & uvs from said nightmare, into the final mesh which is also itself (BSP). I personally feel it's pretty solid and clean.

[Baker]

It looks like you are making some good progress and unraveling some of the hard mysteries and learning some great stuff in the process.

[MadGypsy]

Hah...no mistake shall escape. I found one looking at my screenshot. That room is 256x256. The ceiling tile is 64x64. There are 5x5 ceiling tiles in that image. I know exactly why this is happening. I squared up the final image but I didn't up the size on the miptexs (at all) by the same ratio. I just need to stretch the mips and they will get properly squashed into place when displayed on the face.

@Baker - Thank you! What you say is true. It's fairly apparent this is happening from the ground up. All there is to do is learn.

[gulliver-trans]

This is cool.

That said (and pardon my ignorance), but why do this in Flash and not HTML5? Is WebQuake a true port, or just another "wrapper", but for HTML5?

Mozilla is trying to kill Flash, and Youtube has been defaulting to HTML5 for a year now. Adobe doesn't even update Flash on Linux anymore.

Just curious.

[MadGypsy]

well, this won't really be flash when I compile it. I can port to any OS, wrapped in that OS's executable type. I can also export as AIR and anyone that installs the AIR runtime (any os) could use my AIR port. I chose flash because AS3 is my favorite flavor of syntax and I know flash inside out. I could also almost take my exact AS3 script and treat it like HaXe. From there I could export to all kinds of native system languages, as well as, html5 and a number of other possibilities.

Most people think flash is flash only. I can't remember the last time I made something that was actually flash. I generally export my projects as AIR captive for android.

@webQuake - I don't know anything about it's inner workings. I have never looked at the code or researched it in any way. However, now that you bring it up, I understand/program in all the most obvious web languages. I should probably look at the webquake source for some extra clarity regarding mine.

Thank you for posting and stay tuned.

PS if I don't collapse from exhaustion I am going to bang out an mdl parser tonight. I read the specs. I think I could do it in an hour.

[gulliver-trans]

That makes a lot of sense. Didn't realize you could port/export to any executable type or language, although I guess I do remember seeing flash executables back in the day.

Have fun

[MadGypsy]

I wanted to give y'all some visuals.


the things I'm trying to note with this image:
1) The drop down list shows all my compile types. Simply change the type and click build
2) The .hx script is almost identical to AS3. The HaXe language takes it a step further than as3 and adds stuff like typedef and structs but primarily the languages are identical.
3) My lil tester script only has one line but on my first build it built the entire OpenFL C++ Library. It then compiles using only what is necessary.

That's about it. I just wanted to illustrate the options AS3 provides. I could make the same 4 or 5 syntactical changes to all my pure AS3 and have a working HaXe project out the box. The changes are pretty microscopic too

package;
to
package { all your code }

public function new()
to
public function Main()

import openfl.
to
import flash.

I could write a macro to do that. Woops my example is backwards. Heh. That would be HaXe to AS3.

If I remember correctly HaXe was invented by AS3 programmers who wanted a more C(summin) approach to programming. That's why instead of Object, Number, int, uint... HaXe is more inclined to Struct, Int, UInt, Float, Double. Basically the base types are more C-like. Hah, I'm stuck in a world where I have learned every kind of fake C and I still can't necessarily program in any real C's. I think I am going to make it a point in my life to learn every language except one with C in it. I have a pretty solid working knowledge of about 20 languages so, I am well on my way. Believe it or not BAT script is one of my favorites. It's fucking impossible to get anything done in that language with any sanity. I had to invent arrays for one project cause BAT has like number and character types and that's about it. That's the best part though. Anything is possible you just have to be real determined and crafty to make it happen. It's a challenge, and I love those.

Maybe one day I will attempt to parse a bsp with batscript. Understanding it in AS3 means I can bring it to any other language I understand which can do anything at all with the file.

[Baker]

Hah, I'm stuck in a world where I have learned every kind of fake C and I still can't necessarily program in any real C's.

C is like a minefield.

It's quite powerful, but the bullshit you have to deal with from platform to platform is mind-blowing.

Once you have all of that beaten down, it's pure bliss.

But I can't really recommend anyone actually walk that path.

To walk that path, you need to have a Spider-Sense to detect the 93 out of 100 people that are idiots and will give you bad advice or terrible advice. For every awesome C coder, there are 20 idiots --- and 19 of those 20 don't know it.

It's quite a shame. Plus, you don't really want to have to learn memory management do you? And memory alignment. And the 10,384 crazy little nuances of C. Word length on different platforms? The crazy bullshit you have to use as glue to use the same code between 2 different compilers?

C is insane. However, if you master it, there literally are no hard limits beyond available time and productivity.

Ironically, it is in many ways also one of the least productive languages possible (until you achieve a high level of mastery --- where it just becomes a bit onerous).

But it's quite a bit of overhead just to reach the point of being reliable decent at it.

[MadGypsy]

@Baker - Ya, Imma stick to AS3/HaXe. I can establish my ideas quickly in these languages. I am also very experienced with the entire AS3(including AIR) API. AS3 is here to stay forever. It's far too versatile to ever be killed. Even if every browser and operating system killed flash, they can't kill AIR or stop me from publishing straight to their platform. There ya go, the flash is dead myth is completely debunked unless you want to speak specifically about browser flash players and even that isn't true yet. It also may never be. FLEX is ALSO "flash" (lol). There is FLEX Apache. Fuck the browser, I'll come at ya from the server.... There is no way to defeat Adobe. Oh and guess what language FLEX is almost identical to? If you said AS3 you are totally paying attention.

I didn't parse the entire model but I started the work. I was crazy to say an hour. When I said that I literally meant just the model and texture (ie no animations) but that was still unrealistic. This part was really damn easy. The QuakePalette.as file needs to be moved now though. It's in bsp but now mdl is using it too. Time to move it to an assets folder. My code doesn't care but I do.



I think I'm going to go down the entire quake specs and make all the parsers, even wad. It doesn't matter if I need it. I'm a parsing maniac. I don't know what my afinity with taking one form of data and changing it to another form of data is but, I'm pretty good at it.

[MadGypsy]

In 6 measley hours I am off for 3 days straight. I am goung to pound the fuck out of some engine development in that time. I technically have 88 hours. I intend to spend about 50 of them making progress. Stay tuned, this may become very interesting, very quick.

[MadGypsy]

@spike or anyone with answers- I had a problem with old maps where expected lightmap index exceeded lightmap length. I thought this was due to old compilers but, my gyp1m1 map is doing the same thing. Currently my script passively ignores it (see my lightmap post a few back for exact example). What am I really supposed to do here? Ignoring it just seems wrong but, I don't know how else to handle it.

edit... so you don't even have to find the post. Basically lines 734 to 738.

[MadGypsy]

I would like to add that I realize that being out of lightmap index is tied to blocks(s * t) being too high. The only problem is, lightmap data is calculated BEFORE I apply a scale matrix to pow2 the image. So, distS & distT are the original sizes and therefore blocks is the original surface extents w*h product.

There is also no reason to believe I am producing inaccurate surface extents because out of 5000+ lightmaps (e1m1) a whopping 4 exceed lightmap length and the resultant textures all look correct to me (well, the 100 or more that I clicked through, anyway)

[Baker]

The map compile tools use double precision calculations and in some circumstances the use of mere floating point (single precision) will calculate the extents wrong.

ericw fixed this with 64-bit Quakespasm in 2014 with when a lightmap anomaly was discovered in a func mapjam map that affected 64-bit clients (exclusively, I believe).

(No idea why it didn't affect 32-bit clients, but it didn't.)

Short version: using double may solve if the issue is extents not matching expected values.