C in game development

Started by
35 comments, last by frob 10 years, 8 months ago


worse thing is that they are static sized tables and i do not know how achive flexibility in such static array approach,

soft code array size in data file.

read in array size from data file at program start. then malloc entire array at once at program start, and free at program end. set array size big enough to get the job done.

the speed of static arrays, and the variable size of malloc'd arrays.

But what with large c projects (such like windows/linux/gcc)

Are they internally static array based, what is their main containers for data? As I said if this is static arrays it is prone to overflows (mallocked to), static arrays with realloc? If this is something like linked list of structures it would be much slower...

Advertisement


c in game development (in relation to c++ usage) ? In big games?

i've been writing games in C since 1989 or so. I've done a number of large titles in C. my current project is in C (in a c++ compiler) and tips the scales at about 70,000 lines of code so far. a typical big game for me is about 100,000 lines of code.

I would say 100k-lines are medium size not big. I belive any big title commercial game shipped to shops is much larger (how much?)

My own home framework with some unfinished prototypes

of 2d games has 100k-lines by now. Big game is probably about 1M-lines and more

This has devolved into a language flame war.

You say that as if it were a surprise :)

Granted, this was a zeitgeist topic about, what, 15 years ago but when have these threads ever ended well? Still, if anyone needs any more gasoline to throw onto the fire I'm here all day (or at least until the inevitable lock).


if anyone needs any more gasoline to throw onto the fire I'm here all day

now i got your first comment on that^^


You are not making the CPU think in any particular way at all, to even consider that is frankly stupid.

I'm not talking about the physical CPU. I'm talking about the CPU from the vantage point of purely the language. If I could express my point more clearly in the previous post, what I was trying to say:

Computer instructions are roughly the same either way on the physical machine for similar C and C++ programs, but C++ offers a different way of organizing your data and methods. The computer, however, runs instructions one by one (for the most part) in programs, and does not concern itself with objects and the like. The computer just runs a sequence of instructions. C, however, is more closely based off of the linear organization and execution path that an actual computer follows. The underlying computer does handle functions and memory addresses and data types. The underlying computer does not have class/object manipulation instructions or private/public this and that.

I wasn't trying to make it sound like I thought the CPU architecture was dynamic based on the language used to program it, although you may find this post equally stupid.

C dominates the world of linear procedural computing, which won't advance. The future lies in MASSIVE parallelism.

Computer instructions are roughly the same either way on the physical machine for similar C and C++ programs, but C++ offers a different way of organizing your data and methods. The computer, however, runs instructions one by one (for the most part) in programs, and does not concern itself with objects and the like. The computer just runs a sequence of instructions. C, however, is more closely based off of the linear organization and execution path that an actual computer follows. The underlying computer does handle functions and memory addresses and data types. The underlying computer does not have class/object manipulation instructions or private/public this and that.


And the private/public nature of fields and functions has zero impact on the instruction stream the CPU sees, they are just a human abstraction, so what is your point again?

More importantly why is that abstraction 'bad' yet structures, which a CPU has no concept of either, fine?

Also CPUs don't "handle functions"; they have jump instructions but the whole 'function call' concept is, again, a human abstraction. A CPU has no more idea about a calling convention or a flow than a hamster does.

It sees a stream of instructions; coming from C or C++ makes zero difference in the grand scheme of things.
I was hoping the gentle reminder about it becoming a language war would be enough to push it back toward a topic. As we all know, language wars are not constructive. Closing.

This topic is closed to new replies.

Advertisement