Random Programming Questions

[Liamardo]

Hey people.

 

So basically I have been modding for a while now but only at a basic level.

Ive used Img Tool, SAMI, TXD workshop, GGMM, Ped Editor and Obviously Cleo.

Ive designed vehicles, peds, buildings, etc. (3ds Max, Photoshop & Flash)

 

But I feel this is becoming small fry for me.

I've started looking into C++ and Direct x programming and finding it all a little overpowering.

The eventuality is that I want to be able to write my own codes and build my own games.

 

So this is kinda a request really, could anybody help me out with the basics of code writing?

and general advise?

 

I do realise there are plenty of resources out there to help me on my way but I would like the opportunity to

liaise with some one on the matter, say if I run into any problems or have questions I cant find answers to.

 

Cheers for now!

 

Liamardo.

 

[Barguast]

I've started looking into C++ and Direct x programming and finding it all a little overpowering.

I'm not surprised, you're jumping in the deep end!

 

If you're just starting out with C++, you're best off writing some small programs to teach yourself the basics of the language. I mean text-based console applications that perform very basic tasks like adding numbers. You'll probably find this a lot more rewarding than it sounds, and you'll inevitably end up creating more and more complex programs and indirectly learning good habits.

 

Once you've nailed the basics of programming, the big bad scary world of DirectX will seem a little less daunting and a little more accessible, but again, you'll need to start with the basics. Your first Direct3D application will probably be a tricoloured gouraud triangle - but you'll look at it thinking that you're GOD.

 

In summary, take it slow, start from the beginning, and have patience.

 

 

 

 

[Swoorup]

I started out with C a month ago, should I go with C++ at the same time?

I looked at making a window-based app from C++ and really its too complex process going on! What I meant to say is, how long will an average programmer be fluent in these languages?

 

EDIT:Liamardo, I would suggest you take a look at cprogramming.com site. They contain the basic stuffs of C/C++ and explain very well.

Also you have any problems then there is always the forum.

 

Edited November 25, 2011 by Swoorup

[Liamardo]

If you're just starting out with C++, you're best off writing some small programs to teach yourself the basics of the language. I mean text-based console applications that perform very basic tasks like adding numbers. You'll probably find this a lot more rewarding than it sounds, and you'll inevitably end up creating more and more complex programs and indirectly learning good habits.

 

 

 

Cheers for the info dude!

I'm assuming your already adept at using c++.

 

so far Ive covered the basics but in the stuff I've read, it doesn't really explain too well how to create codes, if that makes sense. basically I understand how to make codes work and what processes have to happen before a basic application can work but what I don't get is, How do I know what codes to use... is there a list of data I should learn? for example Data works in binary witch is basically 1's & 0's witch is the computers native language (so to speak) but there is the other language witch is in text.... so does this mean for a specific number sequence there is a preset text equivalent? or is that over simplified? lol!

 

 

 

 

[K^2]

I started out with C a month ago, should I go with C++ at the same time?

You should keep learning C until you get hang of structures, linked lists, and trees. That's a good point to switch over to C++.

[Swoorup]

I am learning from the site you told me, but with slower pace, applying each and every chapters into practical by just programming some useful things.

But how can I apply those linked lists and binary trees in practical. I mean for which problems.

 

Thank you though for all the information!

[K^2]

Any time you want to have an "array" of objects, where you might want to take out or add an element, especially somewhere in the middle of the "array", linked lists might be a good solution. Their only downside is that they aren't easy to search. If you need the Nth element, you have to start with the first, jump to second, then to third... But sometimes, you only need the array to be processed in that order, and then there is simply no better option.

 

Lists can also save you a ton of time on memory allocation. Imagine that you have a bunch of objects that you keep creating and destroying. If you had to allocate memory every time and the delocate it, it can become rather slow, not to mention fragmentation issues. Instead, create a linked list of unused objects. Since they don't have to be ordered in memory, you can take and add objects to that list as you please. Just make sure you check its length every once in a while, and delocate unused objects if you ended up with too many. If the list is empty, and you need more, you allocate memory then.

 

 

And trees... It's a broad topic. There are search trees. Just about any AI will involve a search in a tree. Directory structure is a tree, so if you want to represent one in your program you'll have to have a tree of some sort. For rendering and graphics, there are partition trees. In particular, there is binary space partition (BSP - might sound familiar) and there are octrees. Octrees are used for everything from graphics, to physics, to AI for all kinds of neat optimization tricks. BSPs are absolutely brilliant for rendering. If you're going through NeHe tutorials, they do have one on BSPs later on. But basically, whenever you get to transparency, do realize that order in which you render things is important. BSP makes ordered transparency an absolute breeze, but there are some limitations.

 

So yeah, lists and trees are extremely important in programming. And you will cuss and want to throw things while learning them, because when writing pointer-chasers, the fact that your program compiled means absolutely nothing, and trying to find an error in a program that compiles and just crashes can be a pain.

[Saggy]

I hate lists and trees, mostly because I can never find a good way to actually practice using them, so always find myself going back to reference manuals when trying to do something with them, never really getting a complete understanding since I seldom use them.

[Swoorup]

I have not seriously gotten into game programming now, because I am just covering some windows programming with C++. And honestly, I feel kind off empty doing linked list and trees now.

[bartoc]

Linked lists are nice to know, but I don't find myself using them that often, just because for most applications a flexible length array or some kind of good deque implementation (usually a linked list of little arrays actually) work better. Linked lists are CRITICAL structures though because they are how the memory allocator that enables all the nice things like flexible length arrays, hash tables, and easy to use strings possible actually works. To be honest once you understand graphs and trees you will probably understand how linked lists work pretty much intuitively.

[Mr.Arrow]

Is assembly language worth learning for a programmer like me? Me and my group of friends are planning to write an operating system once I'll finish my degree in the next 4 years.

[trip]

Is assembly language worth learning for a programmer like me? Me and my group of friends are planning to write an operating system once I'll finish my degree in the next 4 years.

Sure. Back in school we actually had to produce a simple OS in assembly. And I do mean simple.

 

Call -151

[K^2]

Is assembly language worth learning for a programmer like me? Me and my group of friends are planning to write an operating system once I'll finish my degree in the next 4 years.

Knowing Assembly will make you a better programmer, period. If you are going to attempt writing an OS, it is absolutely vital to know.

[lpgunit]

 

Is assembly language worth learning for a programmer like me? Me and my group of friends are planning to write an operating system once I'll finish my degree in the next 4 years.

Knowing Assembly will make you a better programmer, period. If you are going to attempt writing an OS, it is absolutely vital to know.

 

Well since that'll certainly give you access to the bare metal. 'Tis a pain to master though, and I heard that part of the reason why the Sega Saturn failed was that programmers were forced to write things in assembly for them to get better performance in games.

[K^2]

Seems dubious. Writing assembly code for optimized performance was a still a common thing back then. A lot of DOS games would have bits of assembly code for graphics and audio performance. It's only with emergence of protected mode and operating systems using it that APIs became the only way of dealing with environment, and so the assembly use began to wane.

 

On the other hand, Saturn did have a weird architecture. It's possible that programming it in assembly was just that much harder than other systems.

[lpgunit]

Seems dubious. Writing assembly code for optimized performance was a still a common thing back then. A lot of DOS games would have bits of assembly code for graphics and audio performance. It's only with emergence of protected mode and operating systems using it that APIs became the only way of dealing with environment, and so the assembly use began to wane.

 

On the other hand, Saturn did have a weird architecture. It's possible that programming it in assembly was just that much harder than other systems.

They didn't come up with the likes of DirectX or OpenGL for nothing. Most held on to DOS simply because you have bare metal access to things, unlike with Windows where layers upon layers of abstraction add up to a programmer's woes. Chris Pirih, the programmer behind SkiFree, recalled as to how hard it was to get reasonable performance off an average 386 with an ISA video card. GDI wasn't exactly oriented for animation-intensive stuff like games, hence why Microsoft initially came up with WinG. But along with it came The Lion King and the PR disaster Disney, Microsoft and Compaq got, though it was more on part of Compaq's video card supplier who didn't thoroughly test their drivers.

 

Yeah the Saturn was an oddball in most respects. Adding a second CPU was a knee-jerk reaction (much like Sony's choice of using the Cell in the PS3), along with quad-based geometry. They got a fan in the name of Nvidia who implemented a similar quads-based scheme with the NV1, which led to a number of games ported to said graphics chip, but alas, both the NV1 and the Saturn didn't bode well.

[K^2]

You can do direct-to-buffer writes with Windows just like you did with DOS and skip nearly all the GDI nonsense. For a good implementation see Quake II, which had both OpenGL for hardware rendering and completely custom software renderer that ran on machines without 3D acceleration. You didn't have any dynamic lighting in software, but it still looked rather impressive for its time. Although, one should keep in mind that it was created by people who weren't afraid to use techniques like Fast Inverse Square Root.

 

But yeah, it pales in comparison to what people pulled on DOS titles, where you could hijack the interrupt table.

 

If either of you feel like taking on a small assembly challenge, a really good one is writing your own SoundBlaster driver. It will only take a few functions in assembly, and you can write a C/C++ program that plays .wav files around it. Naturally, I strongly recommend using DOSBox rather than an actual DOS machine, and you can use DJGPP to compile an MS-DOS compatible binary. See my signature for hints.

[Mr.Arrow]

^ I really like that source code for Fast inverse square root , the comments in particular

 

 

 

 float Q_rsqrt( float number ){    long i;    float x2, y;    const float threehalfs = 1.5F;    x2 = number * 0.5F;    y = number;    i = * ( long * ) &y; // evil floating point bit level hacking    i = 0x5f3759df - ( i >> 1 ); // what the f*ck?     y = * ( float * ) &i;    y = y * ( threehalfs - ( x2 * y * y ) ); // 1st iteration//    y = y * ( threehalfs - ( x2 * y * y ) ); // 2nd iteration, this can be removed    return y;}

 

Edited August 22, 2016 by Mr.Arrow

[lpgunit]

You can do direct-to-buffer writes with Windows just like you did with DOS and skip nearly all the GDI nonsense. For a good implementation see Quake II, which had both OpenGL for hardware rendering and completely custom software renderer that ran on machines without 3D acceleration. You didn't have any dynamic lighting in software, but it still looked rather impressive for its time. Although, one should keep in mind that it was created by people who weren't afraid to use techniques like Fast Inverse Square Root.

 

But yeah, it pales in comparison to what people pulled on DOS titles, where you could hijack the interrupt table.

 

If either of you feel like taking on a small assembly challenge, a really good one is writing your own SoundBlaster driver. It will only take a few functions in assembly, and you can write a C/C++ program that plays .wav files around it. Naturally, I strongly recommend using DOSBox rather than an actual DOS machine, and you can use DJGPP to compile an MS-DOS compatible binary. See my signature for hints.

Besides being that game programmers back then were loyal DOS fanboys, and wouldn't easily give up their system of choice.

[Shmoopy]

Making games with plain C++ and Directx is so 2006, you'll just gonna waste your time, you better start using tools that target all platforms (mobile-console-desktop), Choose between : Unity 5 and Construct 2, I recommend the latter ( HTML5 and WebGL ).

[K^2]

Depends on what you are making and why. There are a lot of legitimate reasons to write a custom rendering engine. You just have to realize that it's a huge time investment. If you are the only programmer on the team, or worse, the only person, it's probably an unwise use of time. But if you're working with a team of 5-10 people, then it's a matter of priorities. Do you want to have 2-3 people spend development time just writing rendering engine, or do you want them working on other systems?

 

As for platform compatibility, you can target PC and XBOne with almost identical code, and PS4 can run on the same core rendering code with a wrapper around its native graphics calls. So if you are making a "serious game", which you don't expect to run on the web anyways, the benefits of using stock engine for cross-compatibility are greatly diminished. I'm telling you this as someone who has actually developed PC/XBOne/PS4 games on a completely custom engine. Our graphics team consisted of 3 people.

[lpgunit]

Depends on what you are making and why. There are a lot of legitimate reasons to write a custom rendering engine. You just have to realize that it's a huge time investment. If you are the only programmer on the team, or worse, the only person, it's probably an unwise use of time. But if you're working with a team of 5-10 people, then it's a matter of priorities. Do you want to have 2-3 people spend development time just writing rendering engine, or do you want them working on other systems?

 

As for platform compatibility, you can target PC and XBOne with almost identical code, and PS4 can run on the same core rendering code with a wrapper around its native graphics calls. So if you are making a "serious game", which you don't expect to run on the web anyways, the benefits of using stock engine for cross-compatibility are greatly diminished. I'm telling you this as someone who has actually developed PC/XBOne/PS4 games on a completely custom engine. Our graphics team consisted of 3 people.

That accounts for why Unreal Engine is so popular, as it's been on over 9000 games from M-rated FPSes to even children's games. Heh, it has also been used on LazyTown as well as a CGI platform of choice for their virtual sets.

 

And besides, some developers choose to do a bespoke renderer either as an exercise/hobby or since an off-the-shelf framework is out of the question due to specific demands.

 

On the subject of doing a wrapper for the PS4, wouldn't that add up to the overhead like Wine's Direct3D-to-OpenGL implementation did, or is it possible to mitigate such issues?

[K^2]

You lose time on actual translation with WinE, which you have to do if all you have is a compiled binary. If you are working from source code, you don't need to do that. As a toy example, imagine that you want to render a mesh. Hardware dictates that you need to have a vertex buffer and index buffer then make a draw call. (I'm ignoring shader for the moment.) Specific ways that is implemented will be different in different graphics libraries, but all of them have to go through these steps. So you write a function, say, RenderMesh(const BaseMesh& mesh). You will write a DirectX version of that function for Windows/XBox and GNM/GNMX version for PS4. (Or OpenGL, Vulkan...) You might also derive DirectXMesh and PS4Mesh from BaseMesh to have additional information available for each version, but BaseMesh would have interface your rendering engine can use regardless of platform. Now your rendering engine just needs to call RenderMesh and not worry about which platform it's running on. So the hard part of the rendering system, which is sorting meshes, doing culling, maintaining draw list, handling LODs, and so on, remains platform-independent. And only the wrappers around low level stuff have to be written for each platform.

 

This still involves doing some extra work. But it's nowhere near the same amount of work as writing a rendering engine from scratch. So if the later doesn't scare you, former certainly shouldn't.

[Swoorup]

I have been looking into this language called D after my insanity is going higher with C++. I still don't understand why doess C++ still have header files or not introduced modules yet?

[K^2]

Modules are a part of modern C++. Try CLang or MSVS 2015. (Edit: To clarify, modules aren't part of language standard yet, and won't make it in even by C++17. They are targeted for C++20. However, modules are widely supported by modern compilers.)

 

Honestly, while C++ was in a very long rut, with C++03 being outdated back when it was released already, if you learn to use C++14 features, it s perfectly functional modern language. There are still a few things missing, but they are being addressed. C++17 and C++20 should bring it completely up to date. At this point, I see no reason to switch to D. The few things that language provides that C++ doesn't can be achieved with template programming.

 

And yes, I know, there were days when C programmers said the same thing about C++. And a day may come when C++ will be entirely superseded by another language. But that day isn't here yet.

[Swoorup]

I found the template features of D much more compelling. This makes things like this compile time regex engine possible. Other example is:

http://h3.gd/ctrace/

 

It is possible to write just one code path that executes in both compile-time and run time. This should get rid of ugly macro hacks we'd see around in C++. Also constexpr isn't there yet.

 

The only problem I find is, the lack of tooling and interfacing with C++, although the latter might have been improved. Another problem which they are addressing is, they are trying to get the std library free of GC allocations, so GC would be optional.

 

Yes, it might not ready for production (possible internal compiler bugs) but I greatly prefer its design in comparison to C++

Edited September 4, 2016 by Swoorup

[K^2]

You can easily write a compile time regex parser in C++. Not only is it possible, it's part of Boost library. So you don't have to write it. You just grab an industry standard library that gives you regex, reflection, and many other features you could possibly want. All driven through templates under the hood. All things you, as a programmer, don't even have to worry about.

 

constexpr is in C++ since C++11. Since C++14, you can have loops in constexpr functions. So long as the loop can be evaluated at compile time, it will still be a compile time constant. And yes, constexpr functions support both compile time and run time execution through the same code path.

 

The only practical features of D I'm aware of that aren't in C++14 are coming in C++17, including the compile-time conditionals.

 

But if you really want to mix D with C++, there is at least one project for D LLVM compiler. Grab that, and use it with CLang. Then you'll have all of the C++14 features, modules, and ability to cross-link C++ with D and a number of other languages.

[Mr.Arrow]

And yes, I know, there were days when C programmers said the same thing about C++. And a day may come when C++ will be entirely superseded by another language. But that day isn't here yet.

 

Im pretty sure Python will take over soon considering its the closest thing to human language (as in human-readable)

Edited September 17, 2016 by Mr.Arrow

[K^2]

Im pretty sure Python will take over soon considering its the closest thing to human language (as in human-readable)

Python is in a completely different class of languages. It is complementary to languages like C/C++, rather than a replacement. A program written in Python runs on an interpreter. This is usually going to be something like CPython, which is written in C. Additional libraries you will use to do anything that requires high performance will also be written in C/C++. It is not a stand-alone language, because it will always rely on binaries written in other languages.

 

Byte-interpreted languages, like C#, are a more interesting category. Because while you still need to run it on top of a CLR, which is written in C++, all of the executed code can actually come purely from C# thanks to JIT compiler in CLR. But even the fact that CLR has to be written in something other than C# tells you that it inherently cannot completely displace a language like C or C++.

 

In contrast, if you look at C++, it can be a total replacement for C. In practice, some low level libraries are still traditionally written in C, because C code can be better optimized and is easier to debug. So OS kernels and drivers are very frequently pure C projects. But that's matter of practical choice, not an outright limitation. You can write an operating system, drivers, and all the programs in C++ and nothing else. Same goes for D, which is why it's being discussed as possible replacement for C++. This is not something you can do in C# or Python, because these inherently require an operating system to run on top of.

 

One final note of interest. Java can go either way. Usually, when we talk about Java running on something, we are talking about Java bytecode running on JVM on top of an operating system. In this case, it behaves the same way as C#, including JIT compilation to native code in many cases. That's how Java runs on your PC or Android phone. However, there exist Java Processors. Hardware implementations of JVM that run Java bytecode natively. Such a processor would have OS and every piece of application code written in Java and nothing else.

 

Could you build hardware that runs Python natively? Sure. But that would be a huge waste of resources. In the world where the performance is measured in flops per watt, a language that doesn't compile to binary of some sort is never going to replace languages that do.

[Mr.Arrow]

Good point.Python acts more like an interpreter rather than a compiler,I can see why most programmers would often choose C/C++ as their optimal choice.

 

Regarding D, it's a great language but that would require a lot of convictions for the gaming industry.Im saying this because most game developers have these weird mindset where they want something better than C++, but they don't seem motivated enough to use anything that doesn't solve all their problems overnight. It also must be done via some ludicrous gimmick, or else,people would just ignore it even though it's clear that D's advantage over C++ is obvious. These kind of people are just too addicted to C++ IMO.I'm not sure if this is due to lack of content from D, or some people are just too damn lazy to change something that's not familiar to them.....

Edited September 18, 2016 by Mr.Arrow