jdc said:

@Domarius Don't understand the post or you work for Unity 3D, Unreal engine, or some kind of other engine. To make this posts. What kind of interest have you in people using this engines?

They are paid, they consume many resources, you need a top machine to work in them, since they are very heavy.

Don't have the money to paid for this engines, nor do i have a computer to work in them, nor interest in not accessing the source code. And not interested in working in frameworks which do not have automated projects, functions or code.

Do we understand which other?

Not at all, it seems. Dude - I'm just trying to help, one developer to another.

What I linked you were four, totally free, open source, lightweight engines (with the excption of Unity, which is still free) the fact that you haven't even given them enough of a passing glance to know they're all free says to me you're diving into a big project with no research on what already exists and reinventing the wheel in a big way.

Like, I have just released a low-spec pixel art game commercially on Steam, completely made using Godot (for free), on Linux (also free) and it runs on Windows Mac and Linux and making sales on all three platforms but what do I know?

But hey, go for gold. For sure, it will be a good learning experience. We've all been there.

VoxycDev said:

bzt said:
Recently I keep seeing this non-sense. Can you prove it? Is there anything to back up that claim?

No, I can't prove it. This was the stack overflow consensus a while back when I contemplated getting into assembly. I really wanted to find an excuse to re-learn it and use it to optimize something cool, but googling this completely discouraged me. I hope you're right and it's not true. As a kid I remember looking through C code and then finding assembly blocks and thinking “crap! black magic… wish I could do this.” What would be a compelling case for doing this today? Since it's CPU-dependent, you'd still have to have fallback C/C++ slow version in case CPU doesn't match. But I'd love to optimize something critical with it such as line of sight or collision or occlusion detection or voxel mesh generation. If I took the machine code for these functions, would there be a way to to humanly do this? I guess I'd have to find the bottlenecks and remove them, right?

No, it's not black magic :-) For the stack overflow consensus, I can only say what Euclid said thousands of years ago: “Never believe anything just because someone said so”. The key is get empiric proof for yourself, do profiling.

About your question, the best way to humanly do this and optimize would be to start with C/C++. Use its optimizer, then disassemble the function. This is the easy part. Then read all the CPU specs, learn all the instructions, read all the manufacturer's spec on the optimization, and finally find faster and more compact solutions replacing the instructions in the disassembly one by one. You'll be surprised how many things can be replaced easily with a more efficient instruction in a -O3 disassembly! But for that first you have to learn which instruction are available for your disposal of course.

About being CPU dependent, that's true. Having a C fallback is not a must, but certainly a desired feature, a good-to-have alternative. Keep in mind that CPUs are getting extinct, so these days there's basically only two CPU family to code for: Intel and ARM. The overall market share of the rest (MIPS, SPARC, PowerPC etc.) is insignificant and it's shrinking rapidly. The good news is, both Intel and ARM has intrinsics interface, so you don't have to go down to Assembly level if you don't want to (although ARM's far less mature than Intel's, but it's getting there).

Juliean said:
Not only does the compiler a lot of neat things that are faster than what you can do by hand

Then why is pixman written in Assembly and with intrinsics if not for speed? Please show me a compiler optimized pure C/C++ version of the linked pixmap-ssse3.c which is faster than the current, hand-optimized version. If you do so, then you'll have a proof and I'll admit I was mistaken. Until then no video can tell you if an actual implementation is better or not!

Juliean said:
In any case, you can use https://godbolt.org/ to if your assembler/Intrisics are really doing anything. After watching the video (and trying some things out on the site), you'll see that this is not as much as you might think.

I don't “might think”, I always measure. I know exactly how to do profiling, thank you. That's why I'm 100% certain that my manually optimized code is far better than any compiler optimized version. I give you that I'm not the general case, I've many decades of experience with low-level and bare metal programming, and an average C++ programmer can't do what I can (and unlike me, they would probably watch the video instead of profiling the actual code ;-) ).

Cheers,
bzt

bzt said:
I don't “might think”, I always measure. I know exactly how to do profiling, thank you. That's why I'm 100% certain that my manually optimized code is far better than any compiler optimized version. I give you that I'm not the general case, I've many decades of experience with low-level and bare metal programming, and an average C++ programmer can't do what I can (and unlike me, they would probably watch the video instead of profiling the actual code ;-) )

@juliean @voxycdev like a lot of things, this is a “yes… and” scenario. Yes, compilers will be way more efficient at generating assembly for pretty much everyone, AND there are people who, because of their years of experience, can still benefit from writing their own assembly.

But in any case, the only reason I brought it up was to illustrate the folly of just chasing “performance” without any context.

@Domarius

You ppl can continue the debate at long you don't bother me lol.

Tutorial on objects interaction

I delegated stuff to file.h and now using it with texture.h and ligh.h.

Our file.h is written in a way that work with other objects. in here see interaction with texture.h.

It can be done in many more places. It's a matter of separate thing in to parts, so it can be re used. If you program with objects in C++ or PHP, this file objects seems very alike. The difference is the includes are objects.

file.h
texture.h
light.h
model.h

model_load(); 
texture_type = "GL_FALSE";
texture_mode = "background";
light = 93; // %

file_name “background”,
file_extension = "jpg";
file_path = "textures/background.jpg";
file_open(); // file
texture_load(); from file
 

Tutorial on objects interaction part 2

If we where not using a file object or file abstraction we can't reuse code, which means which function will have the same functionality to work with files.

Ended up by repeating many code, that's why procedural code in un maintainable not because the code is bad, is because of repetition, if you remove repetition from code, with abstraction, procedural code become, usable.

Tutorial on objects interaction part 3

Forget to explain bite better.

The abstraction is achieved with configuration. If you add enough configuration is possible to abstract in procedural. For example what abstracts here is the file_extension, so the other side always knows what kind of file is. That's why we don't pass any thing.

file_name “background”,
file_extension = "jpg";
file_path = "textures/background.jpg";
file_open(); // file
texture_load(); from file

In the other side, we have declared a File pointer only once. In other projects, if you read quake engine 3 it have a File pointer declared 200, to 300 times or more. In this code, is declared only one time in file.h, and is never declared again. Is reused.

*Since i start it to written it PHP some parts i'm still seeing how can be done in C, but once the style is understand think it can be done in any language.

jdc said:

file.h
texture.h
light.h
model.h

model_load(); 
texture_type = "GL_FALSE";
texture_mode = "background";
light = 93; // %

file_name “background”,
file_extension = "jpg";
file_path = "textures/background.jpg";
file_open(); // file
texture_load(); from file
 

Good luck ensuring thread safety with a design like that! What good can come from using globals to pass parameters rather than using parameters for their intended purpose? What happens when I want to load a file referenced by another file? Is this kind of design reentrant? I doubt it.

If you have lots of parameters and configuration, but still want to be thread-safe, you can just pack all of your parameters into a struct that is passed into the function. This is both highly flexible, robust to future changes, efficient, reentrant, and thread safe. Like this:

struct FileRequest
{
	//… put file parameters here
};

struct TextureRequest
{
	FileRequest file;
	//… put texture parameters here
};

TextureRequest tex;
tex.texture_type = "GL_FALSE";
tex.texture_mode = "background";
tex.light = 93; // %

tex.file.file_name “background”,
tex.file.file_extension = "jpg";
tex.file.file_path = "textures/background.jpg";
texture_load( &tex ); from file

Ignorance is a bliss, or so they say….

Anyway please also post your benchmark comparing your approach and the common approach. Without numbers to back things up, it's hard to swallow that this is the better method. It would be nice if you can also share the source code so we can learn something from it :-).

Edit: just noticed that you're going to open source it anyway. Sorry about that.

Where is a git repo ? ?