Broquen

[MadGypsy]

I'm sticking with OpenFL but, I started a little side project last night. I created a Lime Project and started directly porting HTML5 Quake source. I'm not thinking about anything. I am literally porting everything line for line as is, with the exception of the stuff that is directly related to html... for that I have to think about the port a little. I'm still putting the majority of my energy into my OpenFl based engine. I figure I can work an hour a day (or so) for as long as it takes to port the 20ish classes.

If I can get a direct port to work on the Lime level, I would be highly tempted to enhance it. I can still compile to a shit load of platforms at Lime level, just not flash really, well, not for 3d anyway. No Stage3D at the lime level but the 2D stage and all related APIs are still available. The catch is those things are ONLY available to a flash compile. That's what OpenFl does. It compiler conditions it's way to a flash API for all platforms. It already sends all my opengl stuff to lime BUT it suppresses/breaks anything beyond opengl 2 cause opengl 2 is the max for Stage3D. Having this other source at the Lime level exposes me to current openGL and actually I believe more but I don't know what or where the more is yet. Also, I don't know what's up with this 60fps shit but, I know I get a hell of a lot more than that on a regular quake engine. I'm thinking Stage3D is governed and when I go to the lime level I should get whatever fps my system can handle.

I'm using the HTML5 port of the Quake source because the code is already very similar to what it needs to be in HaXe. He put everything in Objects which kind of sucks to undo but the meat and potatoes needs very little re-syntaxing and ironically his GL calls are identical to how I have to do it. I can pretty much copy/paste those parts.

I don't even intend to test it til I have rewritten every class. I'll get 50,000 errors on the first compile and I will go down the line and fix every last one of them. Generally fixing one error gets rid of 100's (maybe 1000's) more so, 50,000 errors might only really be 10... or 50,000 :/.

@no interest in making the tools

I call bullshit. I knew a welder that was always creating simple tools to be used in his craft. You'd be totally stoked to machine a proper tool. As a matter of fact, you'd do it on the fly in order to keep working when the shitty one you bought from harbor freight breaks.

::SHTAANKKk:: (ie the sound of "Oh Fuck!")
You: "Ugh, the gear."

[unscrewing, removing, measuring, cutting, grinding, measuring, replacing]

You:"Back to work."

However, I get and agree with everything you are saying.

[Dutch]

@tool

Haha yeah I've been there a few times! I meant the high volume tools, not the nifty trick tools you make to make life easier. Those can be fun. And the feeling of 'Fuck yeah' you get when you pulled off the job with an improvised tool.....ok, tools was a bad example. Come to think of it, every process involved before the part gets made would be interesting. But looking at it in a time/economic sense is what I guess I was getting at.

@openfl

This is purely out of curiosity, because I understand switching APIs would probly set you back almost as far as starting from scratch...but what would a comparable API to openfl be that you could use?

[MadGypsy]

@but what would a comparable API to openfl be that you could use?

Nothing. There is no other API that takes the entire flash API and makes it platform inspecific. There isn't even anything similar. You know what's funny? There is not one single competitor or even up-and-coming competitor to OpenFl and OpenFl works perfect. I have yet to come across a single class that breaks on a specific platform.

I had that one little indexOf() problem I told you about in a PM a long time ago but, that wasn't an openfl issue. That was an "all the way at the root" HaXe problem. It's fixed itself since I upgraded to Haxe 3.Newest

[MadGypsy]

@

varying vec3 pos;
void main ()
{
	pos = v_position.xyz;
	gl_Position = ftetransform();
}

uniform float e_time;
uniform vec3 e_eyepos;
varying vec3 pos;
uniform sampler2D s_t0;
uniform sampler2D s_t1;
void main ()
{
	vec2 tccoord;
	vec3 dir = pos - e_eyepos;
	dir.z *= 3.0;
	dir.xy /= 0.5*length(dir);
	tccoord = (dir.xy + e_time*0.03125);
	vec3 solid = vec3(texture2D(s_t0, tccoord));
	tccoord = (dir.xy + e_time*0.0625);
	vec4 clouds = texture2D(s_t1, tccoord);
	gl_FragColor = vec4(fog3((solid.rgb*(1.0-clouds.a)) + (clouds.a*clouds.rgb)), 1.0);
}

Where do v_position and e_eyepos come from? I'm finally back to this part since starting over.

[Spike]

v_position is a vertex attribute. equivelent to gl_Vertex.
e_eyepos is a uniform, passed over from the engine. it holds the position of the camera in modelspace.

the position is stored into a varying which is then interpolated across your triangles, with those the fragment shader can calculate the direction to the pixel being drawn. this is then projected onto a 2d (xy) plane based upon some kind of sphere thing. the rest is just a texture lookup or two and a blend.

[MadGypsy]

Thank you. I was pretty sure of v_position but, I wasn't sure if eyepos was simply the camera pos or something a little more complex.

Cool. When I get home from work tonight I'm going to finish this shader up real quick and move on to some more things, maybe water.