Advertisement

Game engine in C and open source, The Box, structural programming

Started by December 22, 2019 10:49 AM
129 comments, last by alex4 4 years, 8 months ago

@VoxycDev was posting new stuff and din't see the post.

Yes the best thing is to have all kind of stuff made by us. But that is dependent on how much work can we do. Experience show that if you work in humility people will pay you back lather. Blender received 1 million dollars from Unreal. Because they now are depended on them. Since the Indie market probably represent a large part of their sales, and they (indies) don't have money to pay for large scale 3D editors/animation. Not only Unreal, Blender now have many partners.

What can i say on objectives?

I do not know much in C, but i first deed my research and people say it is best to do stuff in C. So started from there.

Now looking at Open GL , is a kind of library which have their own style of coding which is not 100% compatible with other stuff. For example a library to work with the Box will be much better.

A example on texture.h dependency

If it was linked with color.h it does not needed to declared much of it's stuff.

when you are using textures, colors for alpha, or particles, or effects, they all use color. So that's a good amount of code which is repeated.

But we have to realistic, though this project is large a could take some time to be working is realistic. Maybe with a couple of partners. A large library like Open Gl, may not be so much realistic. But in other side, don't know how things will evolve.

I will post my work on version 0.0.2 was soon was possible.

@VoxycDev Toke look at the VoxieBox seems very nice, need to improve it more. It could have therapeutic aspects; since or brain is more used to 3D. It may fell more natural to use technology

The modules in C, is more or less equal to what we are doing, Grapp App for example uses more the modelus. I have to see what is better. For now using both, large structure and modules.

VoxieBox maybe need a partnership for arcade, where are the investment in this things.

Private users may be to large investment for a multi user platform.

Talking in supporting something like that? Ya it seems a nice challenge i could get the founding to re factor some libraries and reuse in there.

Advertisement

VoxycDev said:
Because modern C/C++ compilers optimize the machine code they generate so well that unfortunately it ends up faster than any human-written assembly.

That was actually the point of the rest of my post. The opening statement was sarcasm, the insinuation is yes, we have largely moved beyond the need to program in assembly. The point being; as technology progresses, there is less and less use case to program at a lower level.

jdc said:
C++ can do all that? Yes, but is very depend on library's if you chance or want to work in another OS you need to do things in windows first. Which means even if performance is not affect which it is. Can't play a game i made with Unity 3D but can play world of warcraft. And is very big, a simple map 4 wall and 2 characters 400 mega. Most web games for unity 3D can't play them.

What do you mean by “need to do things in Windows first?” I didn't, I compiled a basic project using Tilengine on Linux (C++), and then got it cross-compiling on Windows as a second step. And I know this is basic stuff, because I was just doing it as a learning experience because everyone else already can do this. Surely this is a miscommunication and you must mean something else?

As for performance, wouldn't that be more dependent on the scope of the game than if it was made with Unity or not? If you make a Warcraft clone using Unity, you still use the same low res textures, the same amount of objects on screen, the same computing power for AI, etc. etc. And the game could easily be 400mb, a blank Unity project is about 40mb worst case but with the lightweight engine options you can cull that down to around 8mb.

And even if you need to target super-low end video hardware and optimise for 2D you could use the Godot engine or LÖVE , these 2 engines are very very fast and lightweight and are great for making pixel art games, and they easily deploy to Windows, Mac or Linux. Love can deploy to the mobile platforms too.

Maybe this is just a communication issue. When you replied with how you will handle dynamic variables when someone pointed out files aren't the best choice for your objects… it all just makes it really hard to understand what the goal is here. But hey it could be something really unique and it's being lost in communication, so more power to you. Time will tell.

For local multiplayer retro themed games, visit Domarius Games.

@Domarius Why should i have a 40 mega project when i can have a 300 kbits compiled project?

VoxycDev said:

Because modern C/C++ compilers optimize the machine code they generate so well that unfortunately it ends up faster than any human-written assembly.

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

On the other hand, what I see is, for high performance things people are still using Assembly, if not inline assembly then lately more and more intrinsics. Why is that if optimizers are so great? Can you answer this question?

Can you explain, why is for example the pixel manager (used by X among many other projects) mainly written in Assembly and in C full with intrinsics, if not for speed?
https://github.com/servo/pixman/tree/master/pixman

How would you rewrite pixman-ssse3.c for example in C/C++ without any _mm* and keeping the same performance? If C/C++ optimizer are as good as you claim, better than the human-written version, then this shouldn't be a problem for you, right? I'm serious, I'm interested in your implementation.

But if you think that's a too big task, here's a simpler one: implement memcpy in pure C/C++ that is faster than a manually written Assembly version.

Domarius said:
why stop at C, why not program in assembly?

Maybe because C is portable and Assembly isn't? Have you ever though of that?

For the OP:
Don't listen to these guys, if you want to write your engine in C, then you should do it in C. Show them!

Check out Allegro5, it's not really an engine, rather a collection of useful libraries you can build upon, all implemented in C (and provides a C++ wrapper). This could be very useful to you.

Orx is another project written in C (not C++), and this is a game engine, could be useful.

Cheers,
bzt

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?

Advertisement

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

Yes, have a watch:

Not only does the compiler a lot of neat things that are faster than what you can do by hand, it even has to go out of its way to undo some of the stupid anti-optimisation that “clever” programmers try to implement from the 1980s.

SIMD/Vectorization is another topic, on line with multi-threading. There is even an auto-vectorizer (and even an auto-parallelizer) in most modern compilers, so even that is going to become even more automated over time.

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.

jdc said:
Why should i have a 40 mega project when i can have a 300 kbits compiled project?

Not 40mb - I said as low as 8 with Unity, and even less with Godot and Godot engine or LÖVE , especially the latter, you will get very tiny project sizes in the order of kilobytes. As for “Why?”, well for this minimal overhead you get portability to other platforms and essential game features that will take you years to re-create yourself.

There are use cases for C, yes, but from your posts I get the feeling that you're new to this. If you're after lowering performance, overhead, and high compatibility, you should really check out some of the lightweight, retro style engines out there and see how they perform.

For local multiplayer retro themed games, visit Domarius Games.

@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?

@jdc You seem to be pretty misinformed in general when it comes to game engines. Godot UE4 and Unity are all free to use, and except maybe UE4 you don't need a “top machine” to use them. Even UE4, I am using it on a laptop with 8 gigs of ddr4 ram, 2 2.9 ghz cores and amd Radeon r4 graphics card. Not exactly a top machine and I can make games with it, I can even run some of the more graphically intensive game projects that you can download from the Epic Games launcher.

But if you're really worried about not having a powerful enough computer then Godot might be for you, since it runs well on lower end hardware and also the entire engine is inside a small executable (around 50 mb I think). It is small because it was made for consoles originally. The source code is also under the permissive MIT license, which means you can modify it and use any part of it as you please without limitation. You also don't have to pay royalty for the games you sell. It is really great for indie game devs.

This topic is closed to new replies.

Advertisement