Real Flash Quake

[Baker]

A single edict is all the available for information for a specific entity (health, location, model #, etc. etc.) with the fields being indicated in defs.qc

(To get that information, you will need to load a progs.dat. Loading a progs.dat is the most difficult thing you can do --- the Quake VM).

[MadGypsy]

ya, I'm not gonna be loading any progs. I can derive some of the info from entities_t and the rest can come from my progs.dat alternative.

It's actually kind of funny, I am a parsing machine and I have zero interest in parsing a progs.dat. I know I could do it. I also know I'm not going to bother.

[MadGypsy]

To keep everyone in the loop (so to speak). There is nothing dead or on hold about this project. I'm upgrading my skills, methods and all of my current work.

I have reread this entire thread and I got some laughs at some of my misunderstandings but, I feel like I am at a point now where I can produce a whole lot of results that contain no misunderstandings. I need to re(work/consider) some things first. I am in no way claiming there is nothing left for me to misunderstand. Anyway, the point is that I'm not posting about a bunch of reworking. I'll drop some kind of bomb here soon enough.

[Spike]

http://triptohell.info/moodles/junk/onedraw.zip
there's my crappy thing if you want a framerate-based pissing contest. baker might be interested in it too if he hasn't already seen it.

[MadGypsy]

thank you.

lol @ fps pissing contest. Flash max fps is 120. It's safe to say that your pee is streamier (lol) than mine.

I can tell you something that you will probably like to hear. I basically am implementing everything you said in this thread (or will when I get back to said part). So, regardless of my 10-steps-forward-12-steps-back method, I eventually get on the right track.

ATF textures screwed everything up but, I should definitely use them. I wish I would have known about them before I started. I could have designed this to play nice with them from the beginning.

I made a resource ripper for BSPs that does some cool stuff. It logs every struct lump in it's own file and formats the text with the proper labels/nesting (super easy to read). It also rips every texture to png and writes the atf conversion bat script. It dumps all of this to a zip (tidy). The next step is to mimic the textures dump for the lightmaps but with the added feature of atlasing them.

In essence, I am nearing the end of my preconversion tool. From there I start working on the actual conversion tool followed by getting my amf2bsp (the conversion) to run. Once I get that working, I should be back where I last left off (visually) but better/cleaner and hopefully a bit more proper.

[Mindf!3ldzX]

If an complete 8 slice pizza was Quake1, how many slices of pizza do you think you are at, and can we test your pizza when it only has 6 or 7 slices,maybe less?

[MadGypsy]

according to your method I would say I have not even started cooking the pizza. I know that is discouraging but, it's the truth. When I have maps converted to adobe serialized bytes and connect that into where I was before, I would say I will be at one slice. That slice could be played with in a it's-free-and-new-for-five-seconds-of-interest way. This is maybe the hardest thing I have ever attempted. It's doubly hard that I'm working in a VM with limitations that are not entirely clear. This is what you are seeing now. I built everything to work with "bitmaps" but, that method is too intensive. Unfortunately, I learn by being taught a lesson. It's a long road but, my engine is already substantially more solid than my first couple of attempts and I wont stop making it better til there is no better that it can be. I mean even shaving nanoseconds without regard to how trivial it may be.

I know my engine seems a little hokey and jokey but, I will destroy that perception eventually. Will I make an FTE/DP equivalent? In some regards, yes but, mostly no. In other regards I will have features that no quake engine supports (I think). Let's remember, this is flash. If it's possible on the internet it's definitely possible in flash. As an example, I could make p2p video streams and a number of other such things with flash supporting my efforts full throttle. I'm not claiming quake engines couldn't do this. I have simply never heard anything, ever, regarding it. I'm also not saying that I specifically intend to add p2p video streams.

I skinned a model with a movie (flv format). It worked awesome. I want to see if I can skin a model with an swf. If so, I could skin a model with an app. I'm not sure what I would use that for but, I'm sure a reasonable or entertaining purpose could be found. Edit: or an incredible reason could be found if you look at "app" more like "smart skin". Just changing the type perception opens up a lot of possibilities. Maybe some are stupid, I doubt all of them are.

[Mindf!3ldzX]

according to your method I would say I have not even started cooking the pizza. I know that is discouraging but, it's the truth. When I have maps converted to adobe serialized bytes and connect that into where I was before, I would say I will be at one slice. That slice could be played with in a it's-free-and-new-for-five-seconds-of-interest way. This is maybe the hardest thing I have ever attempted. It's doubly hard that I'm working in a VM with limitations that are not entirely clear. This is what you are seeing now. I built everything to work with "bitmaps" but, that method is too intensive. Unfortunately, I learn by being taught a lesson. It's a long road but, my engine is already substantially more solid than my first couple of attempts and I wont stop making it better til there is no better that it can be. I mean even shaving nanoseconds without regard to how trivial it may be.

I know my engine seems a little hokey and jokey but, I will destroy that perception eventually. Will I make an FTE/DP equivalent? In some regards, yes but, mostly no. In other regards I will have features that no quake engine supports (I think). Let's remember, this is flash. If it's possible on the internet it's definitely possible in flash. As an example, I could make p2p video streams and a number of other such things with flash supporting my efforts full throttle. I'm not claiming quake engines couldn't do this. I have simply never heard anything, ever, regarding it. I'm also not saying that I specifically intend to add p2p video streams.

I skinned a model with a movie (flv format). It worked awesome. I want to see if I can skin a model with an swf. If so, I could skin a model with an app. I'm not sure what I would use that for but, I'm sure a reasonable or entertaining purpose could be found. Edit: or an incredible reason could be found if you look at "app" more like "smart skin". Just changing the type perception opens up a lot of possibilities. Maybe some are stupid, I doubt all of them are.

Well, I was just curious whether a time would come for public testing, I like testing things the community works on, especially when its on the fringes.

[MadGypsy]

There will definitely come a time where people can test my fringey quake tech capable game engine. There will also definitely come a time where you can pay a buck or 2 to download and play my entirely no-ads games, on any conceivable and capable device (ie probably not smart watches). I know ads are the profitable business model but, I hate ads (especially in a game). I look at it like this, if I make enough to replace my shitty job dollar for dollar then I can replace my shitty job and that's a step up in this world. If by replacing my shitty job I am left with more time to make better stuff then maybe I will make enough to replace 2 or 3 shitty jobs and I can relax knowing that I work for myself doing something that I want to do, which will probably lead to even better games and the equivalent of more shitty job replacements. I'm going to build my future in chunks of shitty job replacements.

However I replaced my shitty job with nothing yesterday cause I don't give a fuck. I'll get some other shitty job after I have gotten a bunch done with this. YOLO!

[MadGypsy]

spike posted a link to the below image in this thread a month ago.



today I was doing some research on shadowmap methods within away 3d and I came across this

One reminded me of the other so, I posted it just to share. I'm not trying to do any comparisons or make any points.

[MadGypsy]

Check this out. The authors of Away3D are constantly saying that you should use baked shadows (ie textures that have the shadow baked in) as much as possible. I wanted to see what kind of performance I would get from this method so, I wrote a method that builds the properly offset texture map that is to be combined with the lightmap. The interesting thing is the formula to get that offset. I'm in a bit of disbelief that this is correct but, so far, no matter how much I shift textures it works perfectly. I have even shifted faces independently on a solitary brush and it is still correct.

It took me many hours to figure it out but, the formula seems to be as simple as texmins[n] % originalTexture.nDim. I then have to reverse the polarity of the result so the offset will go the right direction. The below image is the actual code and results. The studded texture on the column are faces of a solitary brush with independent tex offsets. You'll just have to take my word for it that the results are identical to any real quake engine (regarding visual offset).

The only reason I am apprehensive regarding the integrity of this formula is because, I am not using the distS, distT values at all. It's magically perfect offset without ever checking the actual offset values. In my experience, nothing is magically perfect. I'm expecting to eventually do something to a brush that breaks this.



This lil map chunk was not what I used to figure this out. I used a flat wall with a tech texture. I got that to work and then I made this new example test. It worked with no issue.

How did I figure out the formula?

I have a BSP utility which spits out all the bsp structs to independent txt files. I added texmins, extents and bounds to face_t results. I then opened up my face_t text file and looked at all the resultant numbers til I came up with one formula that gave me the results I need in every direction. I tried a lot of different combinations before I settled on my current one.



Here is a visual of what my converter is spitting out. The next step is to atlas this stuff.

[Baker]

the .bsp compiler (unlike Quake 3) chops up surfaces into smaller sizes for the software renderer (there isn't a way to reunite them --- unless someone like Spike came up with a clever method which seems unlikely).

You would probably need to create a texture for every triangle displayed in the map.



If using the method you suggest, you would need to prepare for having 10,000+ textures for a map like E1M1.

Short version: I don't think the engine you are using was meant to handle archaic Quake 1 type of maps.

[MadGypsy]

Nah, I won't have to do that and this will run fine when I'm done. At this point BSP is little more than the results my editor spits out. I rape it for all the juicy info and essentially convert the whole thing into something else. I've traded many leafs for fewer portals and numerous other things,... and things to come.

I have made a tool that converts BSP's to a "insta-file" of optimized results. "insta-file" meaning I don't parse shit. I readObject()...dump data into geometry, dump geometry into meshes, done. My bsp parser went from 1000+ lines to about 50.

[MadGypsy]

Ah, I see where you misunderstand what I am doing, Baker.

This is what is actually happening (note that this stuff is all for the conversion tool. The engine loads the product of this type of stuff)

1) face extents are established
2) lightmap is drawn and scaled to extents
3) texture offset is determined and repeat texture is drawn to fill extents dimensions, from offset, creating a "facemap"
4) lightmap is drawn with Multiply to facemap

My texture is a slave with offset to the dimensions of the entire face. All of my UVs are lightmap style. I won't have to consider individual polys because I am just offsetting the texture "behind" the lightmap. The next step is to start combining these into atlases. I would need far less than 10,000 textures with this method.

results:

[MadGypsy]

BSP lightmaps come in textels of 16*16. I must be missing something because:

lightmap length = 9625
9625 / 16 = 601.5625

How can lightmaps be 16*16 textels when the length of lightmap cannot be divided evenly by 16?

also:
face_t[93] = {
sts:13,13
lightmap:9456
}
9456/16 = 591 (ie the beginning of the 591st textel)
13*13 + 9456 = 9625 (ie the end of lightmap)

There would have to be 81 more bytes in lightmap to fulfill a 16*16 textel for the above face

so 16*16 based on what?