Dear friend In marketplace JauneLapin sold it Outrun 2 Debug version 21/08/04 Outrun 2 Review Build 9/10/04 Unfortunately, I missed it, and I m very sad I have some questions: Can I see the complete code game inside with debug or Review? Can I debug himself in C++ with my Debug kit? Nobody have one to copy one for me and send me the image Please. thank you
No, with a debugger you cannot see the C++ code. The best you're going to get is with IDA decompiling it into assembly, and you could do the same thing with the retail version of the game.
A leak of Sega and AM2's Outrun2 source could would spark major controversy for whoever is hosting it and this website IMHO. I doubt anyone would have it here either. Btw, I also doubt that Outrun2 was written with C++. Knowing the Japanese and how they prefer to code, I'm pretty sure they used C (my hypothesis).
Debug symbols reveal it's C++ in very large parts. They can't get around C++ anyway on the Xbox because most of the XDK code is designed for C++. Also they used C++ middleware, making a full C version of the game impossible. The game code seems to be mostly C++ too. Also with a very large company like SEGA, they probably try to do software engineering quite a bit. So it's very unlikely that they use hardly reusable C code when they can write clean C++ classes.
I think like JayFoxRox. I never code with Visual C++ 2003 (the sdk for XBOX) but with 2008 and 2010 the C instruction are recognizing, but the compiler sometimes indicate warning sometimes error. You can codes some struct in C like classes in C++, but it's more complicate and less powerful. I think the bigger differrence between C++ and C it's not the code (simplier in C++ in reality like pointer) but the powerful object algorithm, and I don't know if japanese are familiarize with, but I don't saw not.
Well, forgive me if I'm missing something obvious, but I've written multiple apps in pure C with the XDK, and upon disassembling them out of curiosity, I do still get many C++ references. Not that it really matters, as long as things just work. Personally, I dislike the way the XDK was written. Too many C++ wrapper classes in the lower level code. IMO, openxdkman's low level pushbuffer code, although not nearly as advanced, was more efficiently written then Microsoft's. Which middleware did AM2 use? Was it ADX, like most SEGA titles? Didn't know that was a C++ middleware. You're probably right and I won't argue with you there since I've only disassembled it a few times for Cxbx's sake. Also, I don't see what makes C so "un-reusable". I do it all the time. I have a tendency to think very differently from the norm. I like C++, but I use C more often. Considering that Visual C++ is called Visual "C++" for a reason, it's really better for the compiler when you think about it. Preferably, unless the project is large enough, I'll stick to C-like features while using a few useful C++ features, like maybe a class here and there and templates where it makes things more efficient and saves me time.
C, per-definition, is not less portable or reusable. However, C is more low-level than C++. Hence you usually use it while writing performance critical parts of your code. This usually means: OS, Drivers (Including the rendering stuff), Kernel, .. The C code is usually clean and fast, but will most likely loose speed when porting over to other systems, it might not even port because it uses inline assembly or even compiler extensions. Normally, when you write C code, you care about speed, not portability. If you need more advanced math or want to represent real objects you probably have different types and want overloading too. So for larger projects, especially games, you choose C++. As C++ is build on top of C most C things can be done in C++. A lot of people hence use C++ as "C with classes". This is fine, but won't give you many advantages over C. More advanced uses of objects and templates however, can save you a lot of time while coding AND they can improve readability and maintainability of code. Also, the C++ class prototypes (which are checked by the compiler at compile time!) give a well defined interface, while a collection of C functions (Operating on pointers / structs which represent objects) is rather loose (and not checked (very well) by the compiler). The pushbuffer code of the original xbox was not just a simple pushbuffer but a full blown D3D stack which also optimizes out redundant operations, does draw call batching etc. The pushbuffer code by MS (actually nvidia) hence performances somewhat faster than any alternative I have seen. The C++ part of it is mostly the use of classes, while the C/C++ part would be the extremly tightly packed, cacheline-optimized classes. Not only did any non-XDK pushbuffer drivers perform worse, but they are all nearly impossible to debug, use more memory in the cache (or the same with fewer features) and are less complex / feature-packed. Not sure what C++ wrapper classes you are talking about. D3D is object oriented (and provides a C wrapper, but the actual driver is still C++) and the other parts of the API are just a set of imports, not object-oriented, and will work in both C and C++. As you already mentioned yourself, Microsoft has its own variation of C++ called "Visual C++" which is basicly C++ with a couple of extensions. It's just very obvious that they would use their own language on their own console. Not to mention the fact that the D3D SDK were also written in "Visual C++" at that time. C++, because of the technical interfaces, makes it easier to work in a team, parts of the code can be replaced at later points by use of these interfaces. More importantly code quality will improve because of features such as overloading, better memory management, big std-libs, etc. which are not supported in standard-C. Outrun 2 was a multi-platform game. It uses SEGAs custom sound API which was designed by creative at that time (which is partly in C++). They also used Criware middleware including file-streamers which are also in C++ (Though, most of them might be just wrappers because Criware is actually a C library with internal C++ code afair). Then they used their arcade force-feedback API which was probably designed by the hardware team - also in C++. Further they used Direct3D (Desktop and Xbox) and OpenGL (at least Lindbergh) which both share an abstract renderer - also in C++. Nearly every object-type in the game has its own class. SEGA, with all of their stylish game-menus, animations etc. Can (probably) hardly use anything non-object orientated I believe. It's just way easier to write a class for every menu animation / item. Information hiding and interfaces just work so much better in C++. You can have a look at the IDA list of functions (if you have those binaries, not sure which of them included the symbols, but at least Lindbergh) - way more than 80% of it will be C++. The myth that C++ is slower than C is weird in my opinion. C++ code is slower as soon as you start writing code without respecting your platform. But: The same applies to C! However, if you keep your platform in mind you can count on your optimizing compiler, especially with C++. With Visual C++ you even get LTO which means you will get rid of many nasty C++ function frames. The worst part about C++ is probably the larger memory footprint which is necessary for the vtable, memory management etc. (Visual C++ has options to help you with optimizing your classes / structs from what I heard and saw, normal C++ doesn't) Personally, I also prefer C over C++ (not sure about Visual C++ - only used it years ago. I remember that I liked the inline assembly and pragma features. Didn't like the linker though). I just had to do C++ at university. I also had to do lots of java. I see the positive aspects of proper object-oriented software in terms of software engineering, however, for my projects C was normally better. Most of my projects are emulators or simple drivers which don't have many objects you could abstract too easily without adding overhead or making the design ugly. As gamerdude already mentioned, if you want to see the C-representation of the code your best bet is a disassembler (Personal weapon of choice: HexRays disassembler). Why you would want to debug the game is unclear to me though. Last post, I don't want to hijack this thread further with C/C++ debates.
I pretty much agree with everything you said (especially concerning the differences between Visual C++ and standard C++). I'll also quit while I'm ahead; I don't like derailing threads either.
Thank you No guys, thread is code too (debug). I m'not sure, I thnik it's same level, because when we use pointer, a C pointer and C++ pointer it's the same think. However for use C++ pointer you need the new command. New command it's a macro call C command (sizeof, ...) Could you help me, how to decompiling with HexRays disassembler in C/C++ format please?
I'm sorry, I don't understand what you're saying. JayFox is right. C++ is indeed higher level than C. We'll use the new/delete commands as an example. The new command, as you stated, calls the C command somewhere down the line. It eventually calls calloc(). C++ is built on top of C for the most part. So when you use those fancy C++ features, there's more code going on than just that line alone (i.e. inheritance polymorphism, friends, singletons, etc.), hence why it's more high level and more overhead.
