There was a time when PHP had a reputation for hackability. Maybe its been addressed since and is fine now. I really don’t know. But when I was looking into it, about 7 or 8 years ago, it seemed like an awful lot of the code you had to write was explicitly protective measures such as counteracting code injection. Did that ever get fixed?
I’m pretty much happy with PHP 7 right now as we are using it for college project. I don’t know much about security as I’m a newbie in PHP. The point is that I’m happy enough with it.
In the weekend i got Droid Assault from puppy games. It is AWESOME and also rather close to what i am making. Easily their best game. And good to know it really is as much fun as i suspected. I may have lost a bit of time playing it… And always trying to capture that other droid… I got the emp one once. That didn’t end well.
But sigh… i work and work and get further and further behind! It is like a real job.
So I finally got time to sit down and play with my GLSL preprocessor. Got quite a bit on the way, but I realized halfway through that I’ll need to restructure the whole thing quite a bit. Regardless, it’s gotten fairly useful already.
Set/struct definition file:
$struct MyStruct{
vec4 structVec;
vec4 structVec2;
}
$struct My_Struct2{
MyStruct struct;
vec4 structVec;
vec4[3] blargh;
}
/*
Random star comment.
*/
$set MySet{
$uniform uniformBuffer std140 {
MyStruct myStruct;
vec4
testVec4;
}
//Comment.
$sampler2D randomTexture;
$subpassInput2D subpassInput;
}
Shader definition file:
//Random comment!
$importstruct MyStruct
$importset
//Another comment in the middle of a $ command (and this comment also has a special character in it!)
/*And a star comment as well!
*/
MySet
/**/
out vec4 fragColor;
//It really gets rid of all comments. >___>
/*
It can handle star comments now!
asdasdasd
*/
void main(){
fragColor = uniformBuffer.myStruct.structVec + uniformBuffer.testVec4 + texture(randomTexture, vec2(0)) + subpassLoad(subpassInput);
}
This input produced the following GLSL code:
#version 330
#define subpassLoad(x) texelFetch(x, ivec2(gl_FragCoord.xy), 0)
struct MyStruct{
vec4 structVec;
vec4 structVec2;
};
layout(std140) uniform uniformBuffer{
MyStruct myStruct;
vec4 testVec4;
} uniformBuffer;
uniform sampler2D randomTexture;
uniform sampler2D subpassInput;
out vec4 fragColor;
void main(){
fragColor = uniformBuffer.myStruct.structVec + uniformBuffer.testVec4 + texture(randomTexture, vec2(0)) + subpassLoad(subpassInput);
}
It compiles! This is meant for OpenGL, emulating certain features. Descriptor sets are broken up to “free” uniform samplers and uniform buffers, subpass inputs are changed to normal textures with texelFetch() to read from them. It’ll be easy to implement OpenGL ES and Vulkan support for the output writer, but I’ll need to restructure the system a bit. I forgot I need to output extra info about descriptor sets and other things as well (and that Vulkan will output SPIR-V instead of GLSL). xd
EDIT: Added support for star comments (/* */)
When you’re done, PM me a github link and I can port it to some standard text preprocessor for you, then put it in the shared code! This looks really useful, Ive always needed a better way of doing shader/client interoperability like checking for primitives and all.
Sure, that’d be lovely! I plan on integrating the whole thing with a couple of tools to write a binary shader file (char[] of GLSL source code + info about the shader for GL, byte[] SPIR-V code + descriptor set layouts for VK), so your port probably has to be written in Java. xd
If you were shrewd you’d basically implement Unity’s shader language… thereby having access to thousands of free and awesome shaders and a huge amount of amassed expertise…
Cas 
@theagentd You should definitely consider emitting the #line directives which allow you to get correct line numbers while debugging shaders.
Well, that’s why I started that discussion thread about this BEFORE I started coding it… That being said, I’m not entirely sure it’d work considering I’m aiming for emulating Vulkan’s descriptor sets in OpenGL.
That’s a good idea. Hmm, it’s a bit difficult though considering that $importset could be multiple lines in a different FILE… Hmm, actually the set-file structs and uniform buffers are verified completely when they’re parsed into memory before compiling shaders, so the chance that there’s a problem in there which passes into a shader when imported is fairly low. It might just be good enough to have it show the $importset line as the problem in those rare cases.
I have translated some of the unity shaders in the past. It is not hard to move them over to pure opengl ones, at least these ones weren’t. Often the hard part of a shader is the technique. Once you understand it, they are not such complicated pieces of code really.
I made a JavaScript version of my “game” Mazer. I couldn’t get images to work properly and it isn’t perfectly centered, but eh.
I just found that WebGL 2.0 arrived on android in experiments.
To enable you must also enable the draft extensions list. Here’s the link for quick access:
Played around with finicky details in my game and added mini animations for when blocks or mobs interact. Character also breathes bubbles out when underwater as well.
Fixed doors and added more mobs as well. Couldn’t help but take some screenshots as I marveled at the progress of this.
Notice that when there are no torches in a wood structure, light that is outside generally stays outside when doors are closed(and vise versa).
With all of this addition, I’ve been getting better at spriting too.
I’m currently sick so I guess this is all I’ll be doing for a while.
@TritonDreyja This is looking good so far! There are a few graphical elements that disturb me though, mostly in the background. I reckon you could desaturate your mountains and trees a little bit, for they are more colourful than the foreground; the fact that your sun bears #FF0000 red is also quite disturbing so I’d also change that; last thing is your day sky, you could really use some gradient there:
Not my pic
J0
I actually do use a gradient, but I think I need to look at the parameters again. It really isn’t noticeable until sunset at the moment.
Thanks for pointing out the mountains though! I never really took the time to look at their color compared to the foreground. I’ll be adjusting them accordingly pretty soon. As for the sun… it’s a sprite from when I was thirteen and I should probably change it now ;D.
I thought of combining large repeating meshes and push them to the GPU as a single mesh which improves performance, and I have created another constructor for my [icode]MeshRenderer[/icode] which takes an instance of the [icode]DynamicRenderer[/icode] instance so the same data can be reused again and again without uploading it every frame to the GPU.
DynamicRenderer dynRenderer = ...;
dynRenderer.begin(Primitive.TRIANGLES);
{
// Add vertex data, colors, normals and texcoords here.
}
dynRenderer.end();
This is how normally I render meshes. This renderer is a utility class which collects the data in a big VBO under the hood and streams it to the GPU, giving the ease of the immediate mode rendering with custom shaders. Now in case I want to store some meshes into a large meshes that I know they are static, I can combine them into a batch.
DynamicRenderer dynRenderer = ....;
// The RenderPolicy here prevents the renderer from calling glDrawArrays and
// clearing the data. The data will be cleared once the renderer begins again.
dynRenderer.begin(Primitive.TRIANGLES, RenderPolicy.NO_RENDER);
{
// Add the vertex data here now.
}
dynRenderer.end();
// Finally create a mesh renderer using this dynamic renderer to get a large Mesh
MeshRenderer meshRenderer = new MeshRenderer(dynRenderer);
That’s it, I can now freely render multiple static meshes in one go, and instead of streaming large meshes every frame, I can create them once into a batch, and call render as many times as I can do. It helps me as I can now reuse the dynamic renderer for rendering other entities or even dispose it altogether. It took me an hour, but is worth its time.
I used this article: http://www.java-gaming.org/index.php?topic=26885.0 to implement some cool particle effects for explosions. That’s a pretty good tutorial.
Used the text box engine found here: http://www.java-gaming.org/index.php?topic=25490.0
and also started up on the changes @J0 suggested before.
Completed my new GIF and JPEG texture loaders, decoding image formats may sound boring but its quite interesting how the different formats (I have quite a few other image decoders) differ from each other in terms of the technology they use Its also interesting to see how other types of formats (sound and video) share similar technologies with the image formats.
The biggest surprise was learning about colors, JPEG doesn’t decode to RGB but instead it decodes to the YCbCr format. Once in this format there are then various formulae to convert to RGB (For video there are different formulas for PAL vs NTSC and SDTV vs HDTV for example)