wtf is up with the player-colors randomly changing and glitching out

It's a color change bind.

bind y "color 4 13; wait; color 12; wait; wait; color 11; wait; color 4"

Part of the test is making sure the player's skin properly updates colors when the player is in the mirror. In the engine, this is normally done when the network receives the entity information. With mirror support, you don't know if you will be drawing the player when the entities are received -- you only know that later on if there is a mirror (same is true in any engine when drawing underwater entities too). Engines are all about optimization and only doing things when they are necessary. Otherwise Quake would get like 0.03 frames per second.

Wicked cool!

ah i see.... i kinda assumed it was a glitch and you were still testing the mirror code

kinda neat-ish to see support for reflections in a software engine.

will it also support reflect-maps so that you can only make small parts of the texture be reflecting?

It's Open GL. There is a software renderer build, with about 85% of the features (mirrors won't be one of them), including skybox support.

The mirror effect isn't a property of the texture, it is more like the alpha masked texture support recently added to DarkPlaces (the "{" textures) or water where it is mostly property specified by the texture naming.

Mark V is mostly in the category of engines like Quakespasm, with similar capabilities.

awesome work, baker!

@it's all about optimization
I have probably spent more time optimizing my engine than anything and everything else I did combined. I made numerous optimizations to the away3d API even...to the point where I then ripped it out and canned away3d altogether for those parts. That's actually how I wound up with my own view, scene, camera and geometey functions.

anyway, you are never lying about the importance of optimization. I opine that the same penchant for optimization should be applied to the game code, as well.

Yeah, optimization is pretty much everything.

No one likes doing it. I do it, but I don't like it!

It's just something that you have to do. And if you don't do it while the iron is hot, it will take 25 times as long to do it right in the future. Just pray that your head is clear and you have considered everything when doing it.

I actually like optimizing code. It's actually one of the exercises that will make anyone a much better programmer. If you think about it, even just one optimization is no different than admitting you didn't do it right the first time. However, if you hold fast to how, what and why you changed something you can start writing the optimal code to begin with. I'm getting close to that level where it's as good as it's gonna get the first time but, this is after maybe 5 or 6 years of writing things over and over and over. My first content manager was robust and awesome and like 5000 lines too long. My newest content manager is even more robust and you could put it in your pocket. EVERYTHING has been considered even down to the fastest data types to use for any given thing, mostly Vector<T> (or List<T> in your language) but not always a Vector. Lately there are numerous things that I just leave as bytes or maybe store broken up in bytearrays...depends what the "thing" is.

@ And if you don't do it while the iron is hot, it will take 25 times as long to do it right in the future

I call that "losing scope" and it is my worst nightmare. I've been off my engine for a couple weeks now. I need to get back on it really damn soon before I need to run my entire source in my head to rescope. This is why I switch projects often. I have 3 major projects (content manager, object based ui and my engine) every time I leave the object based ui too long I end up rewriting the whole damn thing. At least it gets better though. It's doubly hard that all this shit is mirrored in another language. Whatever I do in flash, I redo in Haxe. Honestly I don't know how much longer flash even has with me. I need my typedefs and enums and flash has neither. My haxe code is always better than my flash code based on typedefs and enums alone. The alternative in flash is Objects that don't give a fuck what you put in them and constants. I can live with the constants but I'm totally fed up with Objects. It is really hard to keep track of the massive objects I make without some typedefs to force some kind of structure.