Most visitors online was 8830 , on 6 Feb 2024
PT programmation[+Ask]
- Thread starter rsxkilla5
- Start date
Over rock and under tree
- Joined
- Jul 20, 2011
- Messages
- 568
- Reaction score
- 347
I think it is C++, with 'LUA script'... But this is just an assumption...
- Joined
- Jan 28, 2009
- Messages
- 1,320
- Reaction score
- 616
You can mix both.
Last known (to me) game written nearly fully in assembler was RollerCoaster Tycoon. And it was rare even in '90.
In '80 NES games where written in assembler because console was terribly slow. Nobody was using C on NES.
I would say, write everything in C/C++ and optimize it in assembly.
Last known (to me) game written nearly fully in assembler was RollerCoaster Tycoon. And it was rare even in '90.
In '80 NES games where written in assembler because console was terribly slow. Nobody was using C on NES.
I would say, write everything in C/C++ and optimize it in assembly.
- Joined
- May 26, 2007
- Messages
- 5,545
- Reaction score
- 1,315
The game is written in C++, but far more of the code could compile on a C compiler than most C++ programs today. (ie. it doesn't use as many ++ features as it really should)
Most low level kernel routines, device drivers etc. have some element of Assembler, and since there really wasn't much of an "OS" on 8-bit systems, games included their own kernel and drivers. That's why there was so much machine code in them. Even at 16-bit code, games on the Amiga and Atari ST, as well as copy-protected floppies for the PC (A-10 Tank Killer etc.) would boot from the floppy, bypassing the slow bloat of a general OS and using a custom kernel with highly optimised machine code routines which directly interface between the game code and the hardware.
If you have a decent OS, and a powerful computer, you don't need to use machine code. (Assembler)
On the other hand, we don't have the source code, so everything we do requires us to reverse the compiled C++ back into Assembler, to work on it. It's helpful to have an idea what the C++ may have been which produced that, but it's also true that there is no reason why you should use C or C++ over Assembler, if you know what you're doing.
Higher-level languages are supposed to be easier to learn, read and maintain. However, well written x86 code, with extensive use of Macros and directives is (to my eye) as easy to understand, and easily as maintainable provided you don't change the target platform.
The point at which you can no longer maintain Assembler is the point where the CPU architecture of your target changes. It's hard to port x86 to x64, where it's just a compiler switch in C. It's so hard to port from x86 to ARM that you may as well start again from scratch... Again, in C it's just a compiler switch. ^_^ Beyond that, in .Net MSIL or Java you don't even need to re-compile when the CPU changes, because everything you do is executed in a Virtual Machine with a custom Virtual CPU.
Most low level kernel routines, device drivers etc. have some element of Assembler, and since there really wasn't much of an "OS" on 8-bit systems, games included their own kernel and drivers. That's why there was so much machine code in them. Even at 16-bit code, games on the Amiga and Atari ST, as well as copy-protected floppies for the PC (A-10 Tank Killer etc.) would boot from the floppy, bypassing the slow bloat of a general OS and using a custom kernel with highly optimised machine code routines which directly interface between the game code and the hardware.
If you have a decent OS, and a powerful computer, you don't need to use machine code. (Assembler)
On the other hand, we don't have the source code, so everything we do requires us to reverse the compiled C++ back into Assembler, to work on it. It's helpful to have an idea what the C++ may have been which produced that, but it's also true that there is no reason why you should use C or C++ over Assembler, if you know what you're doing.
Higher-level languages are supposed to be easier to learn, read and maintain. However, well written x86 code, with extensive use of Macros and directives is (to my eye) as easy to understand, and easily as maintainable provided you don't change the target platform.
The point at which you can no longer maintain Assembler is the point where the CPU architecture of your target changes. It's hard to port x86 to x64, where it's just a compiler switch in C. It's so hard to port from x86 to ARM that you may as well start again from scratch... Again, in C it's just a compiler switch. ^_^ Beyond that, in .Net MSIL or Java you don't even need to re-compile when the CPU changes, because everything you do is executed in a Virtual Machine with a custom Virtual CPU.
Last edited:
oh, really thank you. I thought PT was Assembly because when i openned it on OllyDBG, i saw lot of assembly codes, and i didnt know anything about programmation. It sounds like greek to me, i think write in C++ hard a lot, but reverse C++ to assembly and go to C++ again
its like WTF oO? to me.
its like WTF oO? to me.
- Joined
- May 26, 2007
- Messages
- 5,545
- Reaction score
- 1,315
If you write in C/C++/Pascal/Fortran/COBOL/etc. the executable you produce will have been "compiled" to x86 assembler (or x64 / ARM / PPC or whatever CPU you target) and that will be assembled and the binary will be linked to the OS.
Writing in Assembler in the first place skips a step in the process of going from a text file to an executable binary... but the part it skips is the part where your source is turned into something a specific processor can run.
Linux is available as C/C++ source, which is how you can run the same OS on x86, x64, ia64, PPC G4/G5 etc., ARM, C5 and so on and so fourth based systems and architectures. You can run Ubuntu on your iPad, if you like... can you do that with Windows 98? Nope... much of that was written in x86 assembler. ^_^
Writing in Assembler in the first place skips a step in the process of going from a text file to an executable binary... but the part it skips is the part where your source is turned into something a specific processor can run.
Linux is available as C/C++ source, which is how you can run the same OS on x86, x64, ia64, PPC G4/G5 etc., ARM, C5 and so on and so fourth based systems and architectures. You can run Ubuntu on your iPad, if you like... can you do that with Windows 98? Nope... much of that was written in x86 assembler. ^_^
- Joined
- Feb 22, 2008
- Messages
- 2,404
- Reaction score
- 724
Well, that's all about OllyDBG is... If you can find a program that produces C/C++ from the executable, please let us know
- Joined
- May 26, 2007
- Messages
- 5,545
- Reaction score
- 1,315
There are lots of those. Sadly, they will make C/C++ from your Pascal executables just as Olly will make x86 out of your C/C++ executables.If you can find a program that produces C/C++ from the executable, please let us know
Additionally, the only language which is universal to all programming languages which produce an executable is machine code. (assembly... and strictly speaking, BTW, Assembler is the assembly language of IBM PDP mainframe computers, and doesn't really apply to x86 PCs; but the terminology slipped XD)
Olly can only handle x86 machine code right now, so that's what you'll get out.
RaGEZONE Sponsor
