WorldSpawn official WIP thread

[Baker]

Spike pointed me to quakespasm patch collision system. I've read it a couple of times and I get it for the most part. I'm just not feeling that right now. I'm not in calculator mode right now.

I get that.

You'll need to be in calculator mode when you take that on.

Collision is hard as hell. All kinds of situations you never thought of before exist, like a "sliding collision".

[MadGypsy]

@ Nahuel

I went to a song meaning site and read up on it. I don't remember what it said but, I do remember thinking "that don't sound good at all". It must mean something else to Phenom, and that's fine.

@ Baker

Yeah, it's probably a next-week situation. My off days end tonight. I need to wait til next (Sun evening)Mon-Wed. I'm working on making bullets way better.

[MadGypsy]

.8 diffuse (ie dark on purpose)

[MadGypsy]

And there ya go, Nahuel. You asked why I don't make some gl stuff. I said I would do rocket trails. I did rocket trails, rtl's and all. I guess my "rocket" is more like an entire meteor but, whatever.

[MadGypsy]

I added screenshot capability. It works well except semi-transparent textures (water/slime/etc) are captured a little shitty. THis was more complicated than I thought this would be. In flash, any display object (ie even the Stage) can easily be drawn to bitmapdata. (bmd.draw(stage)). However, 3d stuff is not actually in the display list so trying to do it that way just draws a white bitmap. I basically had to stop swapping buffers, render and draw the backBuffer and then start swapping again.

but hey, no more prtscn, paste in paint, see if I like it, paste in imgur or go back and try it again....
now I can just rapidly nail screenshot and find the pic I like.

Also, now it doesn't matter if my engine is full-screen or whatever. Whatever size it is, is the size and clipRect for the image. No window borders, background stuff if I'm not fullscreen or any other garbage. It doesn't even capture the stats panel and to make it do that would actually be a pain in the ass. I would have to capture 2 images and practically use a quake sky method to merge them.



I am going to see if premultiplying the alpha for liquid fixes my issue. If it does, I am going to write an mp4 recorder. Actually I'm going to write an MP4 recorder even if liquid isn't fixed. I chose MP4 cause it is super small and perfect for youTube upload. I'm going to plug the audio channel directly into my stream player.

[MadGypsy]

This s awesome. I was just reading the AGAL specs and I noticed anisotropic(2x|4x|8x|16x). I went to the AGAL mini assembler for away3d and noticed that anisotropic was not in it. Starling, is a 2d framework for flash that is still being updated on a regular basis. I looked at Starlings AGALMiniAssembler. AnisotropicNx was present. I replaced away3d mini assembler with the starling one, crossed my fingers and did a build. It did not break anything. I went to EffectMethodBase (ie the most generic shader root) in away3d and created an exception in the ?mipmapping portion to utilize anisotropic filtering. I made the appropriate change in my Lightmap method, crossed my fingers and built the project. Nothing broke. Unfortunately, adding anisotropic to regular lightmaps doesn't look any different than linear so, the only reason I know it worked is because it didn't break and the lightmaps obviously have a filter on them. I'm gonna parse lit files tomorrow.



woops, that should be clamp, not wrap and it also doesn't actually matter. It would only matter if there was more face area than lightmap area and there is never that. It's probably inheriting the repeat from the overall material. It would take about one second to go tell QLightmapMethod that vo.repeatTextures is false so EffectMethodBase will write clamp.

[Spike]

anisotropic filtering only makes sense for textures that have mipmaps.
mipmaps make atlasing really messy, so I doubt you're using mips on lightmaps.
so yeah, that won't have any visible effect at all.

[MadGypsy]

...but I need anisotropic for lit files, right? I could swear that was said in my real flash quake thread...by you.

goes back to double check.

[MadGypsy]

ah, I found it. You weren't referring to lightmaps when you said to use anisotropic BUT the conversation was while I was trying to get .lit replacement to work before (my memory applied one to the other). Ok no problem. You did say that I should ideally use anisotropic instead of linear for mips...done.

[MadGypsy]

Brief Update:

I got lit files working. It was really easy to do but, it took me a minute to find the best spot in my code to overwrite the bsp lightmaps bytestream. In the end, I decided to go all the way to the root and get the lit file bytes (if they exist) instead of the bsp lightmap bytes. I also convert the byte results into final color uints while they are being read. This way, lit file or not, the result is a 32 bit UInt and nowhere beyond that point in my code do I need to make special exceptions for whether or not there was a lit. I stopped applying "invented" math to the results and instead apply a ColorMatrix filter to them, which is visually doing pretty much the exact same thing...but I'm doing it properly with a matrix transformation on each channel.

There's more stuff but, I'm sick of typing.

[MadGypsy]

I externalized the entire current particle effect system


The right side is a descriptor for the map. It has a few values like fog and skybox but the worldlight field is where the real magic happens. I got rid of all color transformations in my script and settled on this method. If I had values like

diffuseColor: 0xFFFFFF //white
ambientColor: 0xFFFFFF
diffuse:1
ambient:1
specular:0

It would be my engines "natural" render state. However my engine likes to make things dark so, you end up with this


But by working with the values a bit you can get results like these


The left side (of my very first image) is an externalization of everything I can currently do with particles, including adding light. There are probably a zillion possibilities with just those properties alone. I'm not going to explain my script but, it works very well. Now, particle effects can be created this way.

[MadGypsy]

I'm waiting for something to finish compiling so I'll take a moment and explain my particle script.

First of all, the syntax is absolutely vanilla JSON (javascript object notation). JSON accepts 4 data types Number, Array, Boolean and String. Those are the only 4 types I have to work with and the only 4 types I actually need.

Let's go down the line
"wait":500, //wait time before you can fire again
"speed":100,//speed the bullet moves away from you
"life":1500, //life-span of bullet
"trail":true,//allow this effect to leave a trail
"trans":true,//use UV transformation - to be removed due to other indicators
"lcnt":3,//number of lights to cache - life/wait = suggested number

//offsets of particle effect from cameras current origin. All these values get added but NUM + -NUM2 is subtraction so...

"offsets":
{	"x":0,
	"y":-30,
	"z":0
},

//light properties, more exist and can be used, note that this is "init" values and due to how light works and is applied it should be "init" as off (ie ambient:0, diffuse:0)

"light":
{	"color":"0xaa3300",
	"ambientColor":"0xff8866",
	"specular":0.4,
	"diffuse":0,
	"ambient":0
},

//render light properties - ie the math that happens every render tick to give the effect.

"rlight":
{	"fallOff":[400,"+~",20  ],
	"radius": [30 ,"+~",5   ],
	"diffuse":[1  ,"*~"     ],
	"ambient":[1  ,"--",0.05]
},

Let's talk about how this works. It's quite simple

ex1:
property:[400,"+",20]

that would do nothing but 400+20 every render tick, which is absolutely useless. You could just set that property to 420 in the init light.

ex 2:
property:[400,"+~",20]

Tilde(~) means (Math.random() * ) (cause I said so). Since the tilde is on the right this expression would expand to:

property = 400 + (Math.random() * 20);

ex 3:
property:[100, "~-", 50]

The tilde is on the left this time so this would expand to

property = (Math.random() * 100) - 50;

ex 4:
property:[1, "--", 0.05]

this would expand to

property -= 0.05;

where "property" was initially set to 1. "++" can also be used for the opposite operation. And that is all there is to my simple syntax. Currently supported operations are
~(+,-,*,/)~ and (--,++)

omitting property[2] will default it to 1 so...
property:[1,"*~"] would expand to
property = 1 * (Math.random() * 1);
which is the exact same result as
property = Math.random();

//entire particle descriptor

"particle":
{	"pcnt":256,//number of particles
	"row":2,//my image is 2 rows and 2 cols of smaller images, this sets off random UV transformations
	"col":2,
	"itransform":[1,1,1,0.5], //beginning color transform properties (r,g,b,a)
	"otransform":[1,1,1,0],//ending color transform properties
	"animator"://particle animation properties
	{	"startTime":[1.1,"*~"],//emission tick
		"duration":[0.5,"+",0],//particle life
		"x":[100,"~-",50],//spread x
		"y":[100,"~-",50],//spread y
		"z":[100,"~-",50]//spread z
	},
	"plane": //plane values, more values exist (yUp, bothSides, segments), these were all I needed for this effect
	{
		"width":30,
		"height":30
	}
}

Earlier I said "trans" would be taken out due to other indicators. col and row are those indicators if((col*row)>1) then we have a "sprite" and uvs need to transform.

Getting all of this to work was actually pretty complicated and took me an entire day.

[MadGypsy]

I did a bunch of research last night and my particle thingy is about to get a complete make-over. A number of things will be no different but, a new number of things will be added. I'm pretty sure that I know every possibility that I need to hit to make this externalization of the particle system full-featured.

On a side note. In an earlier post (a couple of them actually) I expressed how there was something wrong with bounds and that is why particle trails were broken - when the camera was within the map bounds. My fix was to completely null the bounds of the particle emitter, and that worked but, the problem is, that's just a hack. That's just taking something broken and completely breaking the broken feature to fix the rest. That is not good enough for me.

A few times I have had to rewrite small parts of the Away3D source to fix minor bugs that existed. I have already dug deep into the particles and traced the problem back to MeshNode. The problem was (this) was not always the (this) it appeared it would be due to inheritance. I simply got way more specific and now particle trails fully work without having to null their bounds.

--

I use (for flash) Away3D Gold 4.16 (cause it's the final final version and there wont be another...for flash). If I keep having to modify the source to fix bugs, I should probably release it officially as 4.19 or summin. My Away3D already fixes some necessities regarding mesh construction. Also, if this particle system thing works out like I see it in my head, that could be a whole nother mini-package for the Away3D lib. Technically I am just writing a middle-man between the JSON and the Away3D particles API. The alternative is to not do that and EVERY particle effect will have to be hard-coded into the engine. So, say I refuse to code fire into the engine. There would be no fire. This JSON thing is necessary...and completely in my wheelhouse. I've been parsing things since before you were born, uphill, both ways...

*@fixes necessities - "fixes" may be a strong word. I should have said "allows for more flexibility" - which is a necessity when dealing with highly complex models.

[MadGypsy]

Well, this is how things currently stand. I am ditching JSON (eventually) for a completely compiled scripting language...much like QC but far more powerful and flexible. I currently have a friends efforts towards that set up in a project. His stuff is very broken and I will need to go class by class over thousands of lines of codes to fix it. When I say "very broken", I mean that only lower level stuff works, like simple data types and math operations. Functions, classes, loops, etc are all programmed in but in a nooby way that is inefficient and buggy. I give my bro an E for effort but, this shit is VERY crappy at the moment. I can make it a lot better and with the general groundwork laid I really just need to gain the scope of his code and I can fix everything.

When I am done, my game language will be (sort of) every language and no language. What I mean by that is, you can do this

public class Main():SomeType
{
private function doStuff(var:OtherType):RType
{

}
}

ie...classes with return types and specific accessors, yadda yadda

or you can do this

function doStuff(var)
{
return ACompletelyUndeclaredReturnValue
}

from shitty gisty code to classes with all the bells and whistles, it will all work. It already does just REALLY shitty. I'm gonna "unshitty" it.

[MadGypsy]

For the record, creating this qc/progs replacement is not something I am working on right now. I have other things that I want to happen in my engine and before I go crazy "inventing" an entire language I need to brush up my parse skills. Right now I am basically sticking with my JSON method but writing a Math parser that will allow any damn math problem you can perceive to be parsed from a string into a stack. As much as I would like to simply parse the string into math results I can't do it this way. These formulas need to be run clean on every tick so, instead of parsing to results, I create a stack and run the stack on every tick. The string parsing will only happen once and the stack of math functions retrieved from that string basically just sit around and wait to be called.

a gist is this
"sin(random * pi)"

where
arr[0] = Math.sin; //notice no (), that means I am storing the actual function
arr[1] = Math.random;
arr[2] = "*";
arr[3] = Math.PI

makes
result = arr[0](parseFloat(arr[1]()+arr[2]+arr[3]))

to some degree this isn't even going to work and my system needs more thought but, this is the starter kit concept to get something working. I can work on making it not shitty after I at least make it shitty. Ideally, I would actually spin the byte equivalent of the math expressions and run that. That is getting more into how my QC/progs replacement is going to work and I'm not ready to wrap my head around that yet. Mostly because I would completely lose scope of my engine in the process and I'm not at a point where that would be trivial. I have a few things in my engine that need to be addressed and finalized before I completely switch projects. And let's be real clear... inventing a language, compiler and reader, regardless of how much my engine may use it, is a completely different project. A completely different mindframe. I have to turn into a Vampire before it makes sense to go biting people. I am anxious to get working on it though. Inside me is taking one running step towards it but, I looked down long ago and realized my shoes aren't tied and my pants are falling down so, I'm keeping that eagerness in check for a minute.