Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Thief^]

Professional game developers usually license an engine(that usually has a codebase that predates java). To assume the guts of those engines is not in assembly is absurd. It is hard to tell because the current code behind those engines is not open. Still, the source for engines id software has open sourced are full of assembly and those couldn't be ported to Java or C without a huge performance loss.

I am a professional game developer, with a shipped xbox360/ps3/pc game on my resume. Trust me when I say the only assembly I remember seeing in the engine (UE3 btw, we have a source code license to it) was in the vector/matrix operators.

You could write an engine from scratch. It would suck compared to what is out there, but lets ignore that. If you were starting from scratch, you might as well use Java with opengl bindings. You would finish the project faster and get free portability. The left-over time could be used to profile the code to run faster than the c++ version that just squeaked out the door. It happens all the time in the business world....

Starting from scratch isn't THAT hard. I don't really see much difference between using OpenGL+C++ and using Java (you can be cross-platform either way), except the C++ version is faster, easier to debug, uses less memory...

[ZCM]

Here is what it would look like in C as a virtual:

Spoiler (click to show/hide)

Code: [Select]

#include <iostream.h>
typedef struct {
 int Type; //added by compiler for virtual
} Object;
//C conversion of class method
void print0(Object* this) {fprint(cout, "Hello World!"); } //renamed by compiler for virtual
void print(void* this) { //added by compiler for virtual
 switch (this->Type) {
  case 0: print0(this);break;
 }
}

int main() {
 Object *obj = NULL;
 print(obj);
}

Real compilers use a pointer to a table of function pointers* (the vtable), not a switch on an int. But yours is close enough to get the idea.

* And assorted other info used by things like dynamic_cast.

[Thief^]

Incidentally, if you're wondering whether it'd be *possible* to write DF in assembly (regardless of any performance advantages it may bring), note that RollerCoaster Tycoon (http://en.wikipedia.org/wiki/RollerCoaster_Tycoon) was written 99% in assembly, with some C bindings to let the game interface with Windows.

Given that it's a sandbox game that gives the player considerable freedom to build and experiment just like DF, that's... incredible.

Based on the transport tycoon engine, though heavily modified. Both games are a huge favourite of mine.
There's a reason the openttd guys converted transport tycoon to c/c++ though...

[claer_runway]

man, rct3 sucked so hard. the first two could run on almost anything, but the third needed a modern (at the time) machine.

[devek]

Professional game developers usually license an engine(that usually has a codebase that predates java). To assume the guts of those engines is not in assembly is absurd. It is hard to tell because the current code behind those engines is not open. Still, the source for engines id software has open sourced are full of assembly and those couldn't be ported to Java or C without a huge performance loss.

I am a professional game developer, with a shipped xbox360/ps3/pc game on my resume. Trust me when I say the only assembly I remember seeing in the engine (UE3 btw, we have a source code license to it) was in the vector/matrix operators.

So you're saying that the part where speed matters, manipulating the actual wireframes, is done in assembly? The parts where speed doesn't matter is in C++? Color me surprised. Why don't they write those parts in C++? That is because it would be slow as shit.

Reminds me of the early days of ps2 development, where people were doing matrix transformations in C instead of using the facilities the ps2 gave you. Were people too stupid or too lazy to read the attached pdfs and source code examples? I don't know, but their games made the ps2 look bad.

My opinion: you know little about performance, assembly, or java.

[ZCM]

My opinion: you know little about performance, assembly, or java.

My opinion: John Carmack knows a lot about performance. And you know what he said back in 1994?

Although it has often been theorized that Id uses a lot of assembly language in its development, the main language used is ANSI C. “Assembly language is almost dead,” declares Carmack. “Doom has only two assembler routines: one to vertically stretch a column and the other to horizontally texture-map a row. Everything else is in C.”

If all of Doom was written in assembler and the programmer could manage the overhead correctly, Carmack theorizes it would only make the game 15 percent faster. And, although the main raycasting trace in Wolfenstein was written in assembly language, Carmack says he could write Wolfenstein faster in C because of today’s better algorithm technology.

Since then I hear that he's given up assembly coding entirely, but I can't find a good source for that.

[devek]

Oh really? Doom? That wasn't even a 3d game. It was a 2d game that simulated 3d. Additionally, doom predates SSE.

http://games.slashdot.org/comments.pl?sid=3040&cid=1454804

This all changed when John Carmack actually wrote a 3d game.

[Thief^]

So you're saying that the part where speed matters, manipulating the actual wireframes, is done in assembly? The parts where speed doesn't matter is in C++? Color me surprised. Why don't they write those parts in C++? That is because it would be slow as shit.

Just the implementation of the matrix multiply etc functions. Functions where using specific assembly instructions that aren't available as normal c++ operators (e.g. SSE) is beneficial. And even then I'm sure I saw compiler vector intrinsics instead of assembly being used for some of the platforms, I'll check on Monday.
And you're sadly mistaken if you think speed doesn't matter anywhere else...

And for the record, the matrix ops aren't used for "manipulating the wireframes". Transformation of mesh vertices is much better handled by the GPU.

[Sowelu]

AND VI IS BETTER THAN EMACS!!!!!!!

[h3lblad3]

Fastest language. Hands down.

And this is coming from a guy who knows nothing about programming at all. 

[devek]

Neat, it has been a few years since I had to work on a visualization project. I didn't know GPUs became  magic wands that handled all intensive tasks.

I should get rid of my i7 and get a p4 since there is no heavy lifting in graphics processing anymore that would benefit from assembly.

[ZCM]

I should get rid of my i7 and get a p4 since there is no heavy lifting in graphics processing anymore that would benefit from assembly.

You are begging the question. There's still heavy lifting, the dispute is whether it would benefit from assembly.

[Thief^]

Neat, it has been a few years since I had to work on a visualization project. I didn't know GPUs became  magic wands that handled all intensive tasks.

I should get rid of my i7 and get a p4 since there is no heavy lifting in graphics processing anymore that would benefit from assembly.

These days if you can do it on the GPU you do. The average GPU (excluding integrated chips) is an order of magnitude more powerful than the average CPU, so even if the GPU is less efficient at a particular task it'll likely still run faster. You save the CPU for complex branching problems.


I've found a reference page for SSE intrinsics for the MSVC++ compiler: http://msdn.microsoft.com/en-us/library/708ya3be%28v=VS.71%29.aspx
These largely make assembly (for the purpose of using SSE) redundant. Assembly for speed is debatable, but if you want a C++ vs assembly faceoff then name your challenge!

[sockless]

Well back in the day, people used to write basically all the games in asm. (Transport Tycoon, Roller coaster Tycoon etc.) This was because the C compiler couldn't make a program optimised enough to run on the current PCs. But now, with better compilers and better computers, the performance gain is far outweighed by the ease of using higher level languages, that's why I use python, because I don't do things too computationally intense.

[vlademir1]

Well back in the day, people used to write basically all the games in asm. (Transport Tycoon, Roller coaster Tycoon etc.) This was because the C compiler couldn't make a program optimised enough to run on the current PCs. But now, with better compilers and better computers, the performance gain is far outweighed by the ease of using higher level languages, that's why I use python, because I don't do things too computationally intense.

Really?  Funny, since when I was doing it in the early to mid '90s ASM was mainly used fo time critical and low level hardware access functions.  RCT was mostly written in ASM I admit, but that was mostly an exception.