🎉 Celebrating 25 Years of GameDev.net! 🎉

Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!

C code games & tool development

Started by
55 comments, last by jatamron 2 years, 3 months ago

That's all good solutions but as I got it rigth, OP wants to have a hybrid something game something tool which allows users to manage assets and provides editor capabilities. I don't think this exists in any way as a production ready solution.

JoeJ said:
Their HW seems some years ahead, currently.

I don't think so, especially if they continue abandoning established hardware and still resist to market standards. They can start developing their own GPUs but AMD and Intel are miles ahead before they could launch something useful

Advertisement

Shaarigan said:
I don't think so, especially if they continue abandoning established hardware and still resist to market standards.

We suffered a lot at work because Apple switched CPU architectures like pants.
On the other hand, we also suffer from still using x86, which is an ISA from the 70's(?).
I did some ARM assembly once. This felt totally nice and convenient (more registers overall, and less special purpose registers). Almost like C code. I'd actually like to replace x86 for something more modern. (Jut don't do it every 3 years ;D )

They can start developing their own GPUs but AMD and Intel are miles ahead before they could launch something useful

I did not take them serious, years ago, when they announced to make their own GPU.
But they did it already. M1 has GPU designed by Apple. It's not just a licensed architecture. And from what i know so far, it absolutely competes NV/AMD. Normalized by power draw it even wins.

Personally i'm convinced NV (and AMD as well) are on wrong track with pushing 70TF GPUs at premium prices to games market (next gen). This will only hurt us. Sure, with raytracing it's easy to burn all the cycles for little benefit, but we want affordable gaming first, not high end hypes.
However, AMDs Rembrandt looks really good. iGPUs make sense i think. It should be just a bit more powerful maybe, which would require some new standard on memory and mainboard, like consoles do. Or put the memory on the APU package, like Apple does.
PC feels stuck in legacy standards and a fallacy of expected ever growing performance for free. Game devs should counteract by keeping minimum specs low, imo.

In the back of my mind, it resurfaced now, I have thought about using a game engine only for UI, rendering, and deployment ( I hate nodes for the most part because I like to know what is happening underneath in real time or in quick order ). This would obviously require my digging into such libraries, but I can see how such engines might be too integrated to allow this. There are also licensing issues.

Thoughts?

By the way, GODOT team is in alpha with Godot 4 and I am waiting for at least beta release to see if it can be used by me.

All hail C, Alfather of the Codes

Edit: IMGui for tools and simple games until I find better solutions seems like a good place to start

All hail C, Alfather of the Codes

Found another css alike GUI lib: https://github.com/mikke89/RmlUi

JoeJ,

Is CSS GUI / UI creation primarily retained mode, immediate mode, or both? I have read in the last few days on the WWW that games typically use immediate mode, engines often use retained mode for tools and editors, and there are sometimes advantages and disadvantages to having both retained mode and immediate mode in a game UI

All hail C, Alfather of the Codes

C-Research said:
Is CSS GUI / UI creation primarily retained mode, immediate mode, or both?

Must be primarily retained, because you have to make the design in a css file, which is then loaded and interpreted. So the GUI is in parts an asset, and likely what you have in mind for a GUI heavy game.

Immediate mode means you create the GUI directly in code, in the place where you need it. That's very convenient for debugging / testing. For example, using ImGui, we can crate a static variable, and one line of GUI code to adjust its value. When running the app we can then easily test various value using GUI, and see how the code behaves with those values. When we are done with testing it out, we likely remove the debug variable and GUI from the code and use real data instead.
That's the big advantage i see for immediate mode GUI - quickly testing stuff without a need to design a GUI setup / script / asset elsewhere, which would be annoying.

So, to make a GUI heavy game, i would indeed use a retained GUI (either some lib or done myself) for game UI, and i would also keep using ImGui during development for debugging / testing. But i would remove ImGui from the final release build.
I also use ImGui for my tools, because does not need to look great so it's good enough.

Regarding css, personally i did not like it when i worked on web development. It's writing scripts, running web browser to see how it looks, edit script and try again. Not really artist friendly. Also, different browsers generate slightly different layouts, so i could not use it for pixel perfect design which i needed in my case. Further, to generate animations, popups, transitions and such stuff, you have to write JavaScript code as well. It's a widely used standard, but not something efficient game developers aim for.
That's probably the kind of problems game GUI libs based on css address - making it efficient and pixel perfect so we can rely on it.
And there are also visual tools to generate css / html code. Never used those, but i guess this way it becomes artist friendly.

JoeJ said:
which would require some new standard on memory and mainboard, like consoles do. Or put the memory on the APU package, like Apple does. PC feels stuck in legacy standards and a fallacy of expected ever growing performance for free. Game devs should counteract by keeping minimum specs low, imo

I'd agree before I needed to think about a new PC setup as mine has reached end of it's lifetime in late 2020. I can't say anything except AMD has reached a very good position between the CPU and GPU market. They don't need expensive hardware at all (letting the fact rest that we suffer from increased hardware prices in every section, not just gaming and the crypto hype is still ongoing) to even beat NVidia. Their newly released Ryzen CPUs (2020) and theyr Radeon RX 6XXX GPUs work together so that you can bypass usual bus limits and instead access the GPU directly. It's like blocking an entire highway to let an ariplane start. While you can get a CPU/GPU package of a very good quality for less than 700$ (listed). And sorry but raytracing makes games look a lot more impressive than usual shadding can do.

I also think standards are ok as long as they're reveiwed regularly. It doesn't matter if the standards are from the 70s or the 80s (C++ ?) if they make sense. I guess this is also somehow Intel's fault and Microsoft's lazynes to not support any platform they don't have to. Sure a generic hardware standard would be useful for doing some tricks like on the Console hardware by just typing some strange magic numbers into your code to address certain parts of the hardware but you should't forget that we live in a mixed environment and not just on a gaming only ecosystem.

I agree with minimum specs but I also want to see my games become impressive if I have the power to do so.

C-Research said:
This would obviously require my digging into such libraries, but I can see how such engines might be too integrated to allow this. There are also licensing issues. Thoughts?

I've worked with a lot of projects using either Unreal or Unity past 10 years. My thoughts on them is that most modern game engines (and this also includes Godot) are monolythic honeypots that trap you with their promise of simplicity but become very fast very resistant to requirements that lay outside of the intended design flow. Use them if you have to, if you're at the beginning of a journey and don't have time and/or budget preasure, try to find alternatives or start making your own one. There are a lot of different open source projects on GitHub, Urho3D for example.

This is a personal opnion but none of the existing solutions fulfill my requierements to modern game development or development at all. That's why we started to develop our SDK and custom tools and keep everything in building blocks like a good Lego set.

JoeJ said:
Regarding css, personally i did not like it when i worked on web development. It's writing scripts, running web browser to see how it looks, edit script and try again. Not really artist friendly. Also, different browsers generate slightly different layouts, so i could not use it for pixel perfect design which i needed in my case. Further, to generate animations, popups, transitions and such stuff, you have to write JavaScript code as well. It's a widely used standard, but not something efficient game developers aim for.

Sounds like you used some legacy CSS, isn't it!? In current web standard HTML5 and CSS3, everything is aimed to work similar on all platforms. Also CSS Animations are supported since at least 10 years without JavaScript.

That's why we added CSS to our UI framework as a style option. The standard is pretty good and I also wrote a custom parser for HTML/CSS to be added to the framework.

C-Research said:
IMGui for tools and simple games until I find better solutions seems like a good place to start

Game UI and GUI (which are 2 different topics indeed) are very complicated topics. Everyone has their own requierements but as long as it works for you and isn't too complicated to implement and maintain in your game, everything is a good solution as long as it fulfills your needs ?

There are also very good commercial solutions: Noesis GUI for example implements standard WPF (Microsofts XAML based GUI solution for .NET). So once you got into WPF, you could not just write GUI based tools but also game UI and it is already used in prominent games. I came across this when I was doing research into UI frameworks and their concept is quiet good

Shaarigan said:
Sounds like you used some legacy CSS, isn't it!? In current web standard HTML5 and CSS3, everything is aimed to work similar on all platforms. Also CSS Animations are supported since at least 10 years without JavaScript.

Yeah, my web dev work was more than 10 years ago. Idk what has changed since that.

Shaarigan said:
While you can get a CPU/GPU package of a very good quality for less than 700$ (listed).

You mean i could get a CPU + dGPU for that? Where? Here i'd need to pay 700 for an entry level GPU alone, which would perform way worse than the Vega56 i got for 220 two years ago.
Or does ‘listed’ mean MSRP, combined with the assumption we would get back to normal after chip crisis is over?
It this regard i doubt we ever get back to normal. For example, as far as we know, the smallest RDNA3 GPU will have 5000 cores. There will be no entry level at all anymore. Why should they even need one, if people buy all GPUs which can be produced regardless? Better focus on high end, which gives higher margins.
The poor kids which can't afford such monster dGPUs can use APUs, right? That's the plan.
But there is something missing: With current standards, memory bandwidth is too low to build powerful iGPUs such as consoles have. That's what i meant with legacy standards. Smart Access Memory features won't help this.
Future landscape seems to look like this: iGPU with 3.5 teraflops, smallest RDNA3 dGPU 25 tf. (numbers are personal estimates)
Notice the huge gap in between, and if you want some raytracing and cutting edge graphics, the thing you want is exactly within that gap.
So we have a problem. The sweet spot does not get covered (i somehow doubt other companies will fill it with affordable stuff in a satisfactory manner).
Beside that, it's also rather difficult to cover performance scaling ranging from 1.6 tf (SteamDeck) up to 70 tf (dGPU next gen). Former is a bit too low, latter is much to high.
Varying screen resolutions alone will not do the scaling for us. We'll have to continue with making multiple render engines per game, as currently seen with Metro or Cyberpunk and their optional raytracing.
Which means: The raytracing revolution won't make things easier for us. It doubles our work, it increases the compromises we have to make, at the cost of efficiency, work and money. I do not even want to mention again how the limited RT APIs prevent dynamic LOD, which would be the primary choice to deal with scaling.
Who pays the bill?

To me, the PC platform looks like totally out of control and lacking any sense.
Imagine Apple changes mind about gaming, makes a M1 alike gaming chip and cute little gaming Macs. Affordable, power efficient, reasonable performance, good looking. Could they take over the PC platform?
I'm sure they would.

Shaarigan said:
I also think standards are ok as long as they're reveiwed regularly. It doesn't matter if the standards are from the 70s or the 80s (C++ ?)

C++ did evolve. x86, not so much.
Simd is nice, but current CPUs still translate legacy instructions into a internal RISC instruction set. That's redundant work, and can't compensate the issues imposed by the legacy set.
Then, looking at things like current Intels EC/PC fiasco, where they disable AVX-512 on PCs because ECs don't have it… that's really the most ridiculous chip design flaw i've ever heard about. At least the wasted die area gives nice cooling pads.
Maybe, next time they are smart enough to remove AVX-512 before they produce a whole line up chips. But i won't applause them on their ‘reviewing process’ ;D

JoeJ said:
You mean i could get a CPU + dGPU for that? Where? Here i'd need to pay 700 for an entry level GPU alone, which would perform way worse than the Vega56 i got for 220 two years ago

AMD Radeon 6600 XT is available regularly (at least in europe) starting at 430$ from different vendors, sometimes MSI, sometimes Gigabyte. The matching Ryzen CPU is somehow around 300$

JoeJ said:
Who pays the bill?

I guess most gamedevs will use third-party engines anyways, so Unreal pays for it at least and you get it without any additional effort, especially if you think about Nanite and Lumen. For me as engine dev, this is an somehow interesting topic that shouldn't be missing in our code

This topic is closed to new replies.

Advertisement