Broquen

[MadGypsy]

...long way to go. Clockwise from upper-left: HTML5, Flash, Neko, C++

I wasn't even supposed to be rendering yet. I'm working on other stuff and I don't really need a renderer to do it. This is a slop together of minimal stuff. This is actually the first time I've been able to check my results in 3D. It's exactly everything it is supposed to be since the first compile. I knew it would be though. I've been real patient and astute about checking the results a different way.

All of these versions come from one HaXe base, and in my code (ie not including API code) there are no compiler conditions. In other words there is not one line of my code that has to make a special situation for any of the export versions.

[Dutch]

You're missing some things like lights, crosshairs, entities, and several other things in case you missed those...

Just fuckin with ya.

Good progress bro. Even more impressive you don't have compiler specific code. The pictures look damn near identical...have you noticed any differences that aren't readily apparent from the pics?

[MadGypsy]

The only reason the pics look different is because they are sized and oriented on the screen by hand so, all the ratios are different and in some cases part of the window isn't even on the screen. I'm also not at the exact same spot across versions. I flew to approx the same spot and moved a little til everything had the same poly count.

They look the same when everything is the same.

Neko gets better performance with no other versions running. I had it solo at a steady 60fps at fullsceen. HTML5 is pretty much what you get no matter what you do. The other 2 versions are already maxed out.

My earlier statement that everything was everything it was supposed to be, was wrong. Not one entity beyond worldspawn was being displayed. It was an easy fix but hard to track down.

totally unrelated:

On August 4th, Away3D was released for the latest OpenFL/HaXe. It was like a mini Christmas for me. OpenFL is currently 3.6.1. Away3D version before this release was for OpenFL 2.2.3. That old version of OpenFL was for Haxe 2.summin. Current Haxe is 3.summin. The point being that my tools are as good as you can get right now.

That's the entire thing that got me started on a 3d engine in Haxe. I've wanted to get moving on that again but, the away3d that was available was for an openfl that had performance issues on native targets. Apparently those have been fixed (or at least to some degree) and Away3D was updated to be compatible. Also, up to this point, everything I've learned about Haxe regarded Haxe/OpenFL 3+. I didn't want to teach myself how to be backwards compatible. I want to be forwards compatible. As soon as I caught the Away3D update I started "Hello Quake-like Engine". I ported most of my AS3 in no time but, at some point I got full scope of my code and decided to change things. I had to take a step backwards to do that.

@missing some things like...

Ha.
I'm not really missing all of those things, just half of them and all of the "several other things".

@differences that aren't readily apparent from the pics?

nope.

[MadGypsy]

question @ spike || baker || anybody that would like to answer with some facts.

I'm messing with sky and I'm stumped.

I have rendered enough BSPs to know that sky seems to keep the entire brush and I can assume sky texture left side should have transparent for the black and be placed on the "bottom" of the brush, whereas the sky texture right side should be placed on the remaining faces of the brush which are "behind" the "bottom" face.

If that much is correct then I don't need an explanation of that. I need the math/trick/whatever to determine what part of the brush I am referring to at any given time. I have looked and looked for this answer and I either can't find it or I am not recognizing it for what it is. Any help would be appreciated - even just pointing me to the spot in some source would be awesome.

..cause this is awesomely wrong.

[Baker]

I don't understand the question.

Sky brushes use texture coordinates just like any other surface. There is no special treatment of the surface when it comes to rendering.

Except that since a sky must be 256 x 128, it probably ends up being 128x128 in the end because one half is solid (and the other half is the blended part).

Think of it like this: Discard half the texture and pretend it doesn't exist.

Then if that looks right, then fix it to make the other half a separate texture that renders over it.

^^ The above is "as far as I recall". I'm about 98% certain.

[Spike]

sky surfaces have texture coords, but the renderer typically totally ignores them.
skys are really one giant hack in glquake.
in software rendering, they're drawn with some sort of per-pixel transform.
this obviously doesn't work too well for GL if you're alergic to GLSL.
glquake subdivided the sky polies until they were below a certain size.
this of course results in distortions that move with the camera.

there's three ways around this, of course.
1) skydome. draw the sky really far away and really big, as a sphere with a sufficiently high enough resolution. you can then disable colour writes retaining depth writes and mask off those areas so that it doesn't act as a cheat.
2) skygrid. another post processing thing. its heavier on the cpu, but easier on the gpu. basically your code needs to figure out which parts of the sky are actually onscreen and project the rest accordingly.
3) give up and just use glsl. its the most performant way, and needs the least crazy maths. it doesn't mess up any depth ordering either. it works just like software rendering. it has no issues with multiple skies visible at once. why the hell would you pick any other method?
https://sourceforge.net/p/fteqw/code...efaultsky.glsl there's some glsl that should match software rendering closely enough.

also, regarding the second layer, you should be using premultiplied alpha rather than traditional blending or alpha testing. you'll get a better result with the vanilla textures... and yet fte is guilty of not using it. *sigh*.

on the subject of blending, hideous blending looks like its additive rather than anything sensible.
premultiplied alpha is src=ONE, dst=ONE_MINUS_SRC_ALPHA.
this gives framebuffer = fragment + framebuffer*(1-fragment.alpha);
its called premultiplied because you need to remultiply your source rgb channels by your alpha channel. in the case of quake, that just means you set your transparent pixels to 0 for all four channels.
this is better than regular blending because it avoids skirts from texture filtering, which is common when using paletted textures.
of course, if your alpha channel is 1 everywhere (with black where invisible), then you get an additive blend instead. this can actually be quite handy with particle effects of course.
or something.
just make sure your texture is RGBA rather than just RGB maybe.

[MadGypsy]

thanks @ both of you.

I'm using shader scripts to assemble my sky. I'm probably going to get or dump this by tomorrow. I'm not married to original quake sky. I just wanted to support it if possible. My current game maps all use skyboxes. I was hoping to support quake skies for legacy reasons but, I'm not wasting my life on this.

Hmmm... maybe I should skip the original brushes and just paint a modified skybox with the sky texture. It would have to be a bit smart just in case it needed to switch to a different texture in some portion of the map. The up side to this is at least the entire sky will act as one.

@spike

I need to stew on what you said.

[MadGypsy]

OK, I read your code, Spike. I also ported it to AGAL. Before now, I seriously didn't get AGAL. With your GLSL example (which I also don't know) I was able to figure out what's going on in AGAL. It all started when I read the below line and realized xyzw in AGAL is your rgba. This all started to make a lot more sense. When I realized the opcodes were nothing more than math expressions and they could be applied per component... I get it. My AGAL is as close to identical to your solution as I am gonna get.

gl_FragColor = vec4(fog3((solid.rgb*(1.0-clouds.a)) + (clouds.a*clouds.rgb)), 1.0);



As you can see in the OVERLAY case I added, I am doing the same thing your are. I use sne (set not equal ?1:0) to flip the alpha on the overlay. I multiply my first register's "rgb" by the flipped alpha and then I add the second register's "rgb" to the results of the last operation. To be thorough, when first getting the sky texture from the palette I convert all black on the left half to fully transparent black.

I don't know why I have the white outline. Any ideas?

OH PS> I know my texture is way too big. I simply multiplied the UVs by .25 cause I thought it looked better big.

...hmmm maybe that's the whole damn problem...

nope that didn't make a difference

[Spike]

if you want to negate something, use a negation or subtraction.
don't use a boolean operator on something that isn't a boolean.
you just get weird interpolation from one pixel to the next with your weird solution.

[MadGypsy]

You so smart. I changed sne to sub and flipped the order of my registers for that operation.

essentially
// ( solid.rgb * (solid.a - clouds.a) ) + clouds.rgb



I'll port the moving part of your code tomorrow.

In defense of my weird solution, I wasn't really looking at it in simple math terms. It's my first code. I ported a language I don't know to a language I don't know.

[Spike]

there should also be a 'mad' instruction for multiply-and-add. for people that want to do nearly everything in a single operation... you could also precompute the 1-a part when uploading the texture too, of course. depends how extreme you want to be with it.

[MadGypsy]

I don't see a mad opcode (Adobe Flash Platform * AGAL bytecode format).

@precompute the alpha

That sounds good. I have 30 minutes before work. Lemme see if I can bang out something real quick.

[MadGypsy]

@sky dome

ok, I get it. Using a skybox isn't ideal because you will always end up with some face of it animating sky "against the grain". That being said, Making half a sphere and painting the underside of it with a sky is a doddle, figuring out where I'm supposed to put it and how big to make it is a whole nother issue.

Care to point me to an example or give me some clue where I'm supposed to be deriving the skydome dimensions and position from.

[Spike]

you already have some shader language. just project a sphere onto the surface fragments that you already have. there's no need for any dome/sphere mesh.
then you can just draw your skies the same way as any other surface, just with a specific shader.
interpolate the vertex position across the triangles, subtract the eye position inside your fragment shader, normalize it. you now have a normal that you can map onto a sphere / cubemap / 2d texture in whatever way you want, which is precise to the pixel.
the _only_ valid reason to not do it that way is if you want actual skyrooms (aka sky portals), with things actually moving around on their own within your sky, and even then you probably want something like a cubemap providing a backdrop within the 'room'.

[MadGypsy]

That was half french to me but, I'm gonna figure out what you said. I'm @ work til 4 so, I have a few hours to think about it.