WorldSpawn official WIP thread

[MadGypsy]

post header. albeit, not a very good one. It would be good if you could see how entirely different those things are in their seemingly sameness

I have been working with engine creation for around 7/8 months. I am not by any means trying to imply that I have it all figured out but, I do feel very capable. My Real Flash Quake thread was primarily a "get off the ground" thread. I perceive myself as being well "off the ground" at this point. All that being said, I want to bring a whole new perspective to my project. I intend to use this thread not only to illustrate changes and upgrades to my engine but, also to explain how some of these things work. I also intend to talk at some length about the direction of my engine, how it differs from a quake engine and why. These things can be as simple as just stating a fact or as complicated as to why I completely rewrote a chunk of original source, how my way is better/resultantly different and the future implications of such decisions.

In my time here (@ quakeone) I have tutorialized many things. In those tutorials I tend to explain everything down to the very alphabet that forms the words that I use to explain them. This thread is going to be a little more advanced. Instead of trying to speak in a way that hopefully even non-programmers can understand, I am just going to speak at whatever level the focus chunk of programming resides at. So if we are just looking at a bunch of loops and arrays it will be pretty simple. If we are looking at a bunch of abstract ideas in the form of an interface being implemented by concrete ideas within a design pattern...well, it's not gonna be simple at all to your average person.

I need a little bit of time to get my act together on some things that aren't quite ready to be put here but, you can expect that this thread will start filling up soon.

[MadGypsy]

old ram: 210ish
next ram:60ish
current ram: 30ish (actually starts at 32. It took me a "second" to fly to the cam pos in the image)

a 7th of the original ram (which was doing things a terrible way, though, so...)

I didn't cut any corners, chop out any of the map, none of that. And this is a completely novis situation. The secret isn't really a secret. I remembered that the whole reason I programmed my content manager the way I did is so I could dump the entire library after everything is complete. All of it...err except playlists. All of my data winds down to this one (not really all that huge) Object/Struct so, I was able to dump everything that led up to that as well. I bet I could get that number even lower.

Even in debug mode everything this is doing takes 4 seconds max to finish it all. IE max 4 second load, locally. Almost a second less in release mode. Some of that has to be flashplayer loading itself, too. So, IDK, maybe something around 2 seconds from init() to end. There is no way for me to ever know really.

[DeathMaster]

I'm not going to pretend that I understand any of this, but it looks neat-o.

[MadGypsy]

@DM

In the upper left of the image is a little stat panel. It says RAM is 34m. That number used to be 60m+ and before that a ridiculous 210m+. I'm just illustrating that things are improving. This improvement was simple. Every single thing that had already been processed into the final result, got deleted...except of course the final result itself.

And actually, not so obvious but I'm getting 58/60 fps in debug mode. All debuggers, for every language that has one, requires some overhead. I can remember back in the beginning of this getting around 30fps in debug mode. Things are improving.

oh: maybe my "novis situation" confused you
I just meant that the entire world is being rendered.

[MadGypsy]

pffft, what?


ok...


That'll never ever ever happen again. Now it doesn't matter what texture a trigger has, it will be invisible.


Also, I think I finally got allocBlock to stop complaining, forever while maintaining an acceptable optimization factor. I wonder if I should stop saving all black lightmaps and just color the vertices black. That's a thing right... vertex colors?

[MadGypsy]

That's probably as good as I am going to get it. Obviously red represents dead space. I wish there was less dead space in some of those but, I just end up trading width red for more height red.

Original allocBlock system (from actual quake source) defined 1 static number that represented the height and width of the final atlas.

I...
Math.sqrt( (total group width)*(maximum found height));

The original would throw an error if the best position + the current height blew out it's static number.

I...
(best > 204 throw Error(...)
which is also a static number but it is the absolute max that my platform can produce for image dimensions.

Also, I...

after every call to allocBlock
height = Math.max(lm.height + lm.y, height)

before I draw or even init the atlas
height = makePow2(height);

In essence:
I treat the lightmaps like one long singular row and square root the results.
That makes the width substantially less and allocBlock will position everything over many rows
I then let the height do whatever it wants all the way to my platform max.
I then find the highest used y value, make it power 2 and snip the rest.

Here is a code sample that illustrates everything I said. The left organizes and allocates everything before it is sent to the atlas. The right side is the allocation function itself.


------

I also changed the default for my fog to (0, 2000, 0x555555);
With such a large stretch between the origin and the max the gradient is much smoother. There are a lot of maps where this looks pretty good. Below is one.




I'm still going to make it to where these values can be overridden in worldspawn.

[MadGypsy]

IDK... I actually don't like the HD textures as much as I like the LD ones. My RAM is insane, too. I probably need to go look at how I'm dumping old info. I'll figure it out tomorrow or something, time for bed.

[MadGypsy]

Or I'll just figure it out right now. Thanks System.gc(); //gc = garbage collection. It's lucky that I'm using AIR. If I was using flash calling System.gc() only works in debug mode. Supposedly, calling System.gc() is a last resort and bad practice. All I know is this:

1) it works exactly as I hoped
2) I call it when I am done with everything
3) There are 600m of HD textures loaded in the ram and this map isn't using a 10th of them

fuck a best practice. Who knows how long it would take flash to recycle those resources. A minute? Never? It seemed more like a never...System.gc();

25 is a lot better than 700.

Edit: I ran a little test with e1m1 and no HD textures but leaving in System.gc(). My last score of 32m is now 22m and actually, after my last draft of allocBlock e1m1 went up to 34m (but now all maps work) and I'm down to 22. I don't think I can get it any lower than this.

woops I forgot to include the skybox images.... It went up 1m.

[MadGypsy]

And then this became a thing


idkwtf regarding 99% of that but, all entities seem to have the proper bounding box. Currently I can click entities and they alert their model index in the console. Entities that consist of more than one brush are perceived as being one.

[MadGypsy]

But, then this became a better thing


It helps when you get a little more specific about what reveals it's bounds... In this case, anything that has a lightmap and is not worldspawn.

[MadGypsy]

Let's goof off for a minute


Above is very obviously 2 brushes. I know from clicking it that it is model 7.



And there we have it. Multiple-brush entities have been unified.

Here is another example that achieves the exact same result. What this is meant to illustrate is that instead of modifying anything in the bsp creation script, the entity can be modified externally, and it's model index from entities_t serves as it's child position in the world.

[nahuel]

MadGIpsy, what about incorporate some gl stuff?

[MadGypsy]

@nahuel

I'm getting there.

I tell you what. I will give a good effort after I take a shower to pound out some kind of particle trail thingy that you can "fire" before I go to sleep. Keep in mind, I don't even know where to begin but, I'll figure something out.

:starts shower water::brews coffee:

[MadGypsy]

heads up:

I got pretty far with this last night but, I was unable to finish before bed. I didn't want to drop a big slop ball in my code just to make something work real quick. I had to go over other classes and consider how the code should be positioned within my source and then I started writing the code from the abstract idea end. I have a little bit of the concrete idea written but, there is more to do. I believe I should have this wrapped up in a "groundwork" way before the end of the night.

I haven't rounded off the code in a way that will allow me to test it either so, this is either gonna work or it's really not gonna work, lol. It'll work...probably.

[MadGypsy]

OK, It works and it doesn't work. I kept nailing the fire button til it crashed and got stuck in space so I could move around it and look at it. It totally fires away from you like you would expect. That's not the problem. The problem is, if you are inside of the map, you can't see it...???? Where you start in e1m1 the edge of the map is right behind you. I have fired my "rocket" and backed up real quick. Once I leave the map I can see the rocket, but while in the map I cannot. This makes no sense.

Here is a shot right after I fire. The 2 little hearts on the far left are from the other frozen rocket trail trying to complete it's animation. I'm not worried about those little issues that can be probably very easily tightened up. I need to figure out wtf is making this invisible if the camera is inside of the bsp.


one more with a little wait before hitting prtscn


I'm not trying to make "Poker Quake" or anything. This is just a hair better than "Hello Rocket". The particle trail slowly falls and fades out as it is being made.