Possible sequence break of DOOM! (escape TRO w/o high jump?)

2004-09-12 03:21:09 am

interesting point about how the games are programmed. i know there's no possible way the older games were written in c, though who knows about the gba stuff. "event++" was just an analogy, anyway, how it might be done if it were c, something i think people would find easier to understand ... it was based on reality just a tad, though.

Phazon Siphon

2004-09-12 04:04:56 am

I highly doubt anyone's going to have the patience to try this.

It's just too hard/annoying. Although you can try all you want.

If you DO do it, think they're be another secret message?

Jigglysaint

2004-09-13 01:19:13 pm

Most likely the data is written in Assembly. because it runs much faster than other programs.

I'll try a few things today and see what I get.

elyscape

2004-09-14 08:05:31 pm

Quote from Jigglysaint:

Most likely the data is written in Assembly. because it runs much faster than other programs.

I'll try a few things today and see what I get.

Most likely the data was written in C/C++, then compiled into Assembly, actually. Maybe it was optimized once made into Assembly, but I am 100% positive that it was not originally coded in Assembly. Assembly is the machine code, and there's only about 20 (probably not even that many) different commands. They're along the lines of:

add something to memory location X
subtract something from memory location X
flip bits in memory location X
send bits in memory location X to data bus Y
input bits to memory location X from data bus Y
jump to the command at line X and start doing stuff there

There might even be multiplication and division as well, and I'm not even sure if the data bus commands are even handled like that, as compared to just adding to a specific location that the hardware treats as a bus.
Either way, coding in Assembly is one big, freaking PAIN in the ASS. Not only that, but debugging it is even worse.
In conclusion, it's very, very doubtful at BEST that the code was originally Assembly. Most programs you use on a computer were written in C/C++. Of course they've now been compiled into assembly; that's the only code that the system will run, unless it has an interpreter in between, as is done with Java.

And, uh, yeah.

[quote="Jigglysaint"]Most likely the data is written in Assembly. because it runs much faster than other programs.

I'll try a few things today and see what I get.[/quote]
Most likely the data was written in C/C++, then compiled into Assembly, actually. Maybe it was optimized once made into Assembly, but I am 100% positive that it was not originally coded in Assembly. Assembly is the machine code, and there's only about 20 (probably not even that many) different commands. They're along the lines of:
[list][*]add something to memory location X
[*]subtract something from memory location X
[*]flip bits in memory location X
[*]send bits in memory location X to data bus Y
[*]input bits to memory location X from data bus Y
[*]jump to the command at line X and start doing stuff there[/list]
There might even be multiplication and division as well, and I'm not even sure if the data bus commands are even handled like that, as compared to just adding to a specific location that the hardware treats as a bus.
Either way, coding in Assembly is one big, freaking PAIN in the ASS. Not only that, but debugging it is even worse.
In conclusion, it's very, very doubtful at BEST that the code was originally Assembly. Most programs you use on a computer were written in C/C++. Of course they've now been compiled into assembly; that's the only code that the system will run, unless it has an interpreter in between, as is done with Java.

And, uh, yeah.

GreenMamba

2004-09-14 08:18:50 pm

What luck, there's french fry stuck in my beard.

Yep. My brain broke.

JaggerG

2004-09-14 08:20:50 pm

Shifty Leader

That M2k2 guy

I find it interesting that my topic about sequence breaking became somebody else's topic about programming before the second page.

elyscape

2004-09-14 08:22:24 pm

Quote from JaggerG:

I find it interesting that my topic about sequence breaking became somebody else's topic about programming before the second page.

GO ME!
By the way, that was your 666th post.

JaggerG

2004-09-14 08:42:41 pm

Shifty Leader

That M2k2 guy

Does that mean that we'll be stricken down by Satan or something?

Captain N

2004-09-15 12:42:50 pm

When you write in a higher level language (C++, Visual Basic, Pascal, FORTRAN, and the like) it's compiled to Assembly for the processor it is being compiled for, then it is sent through the assembler which creates the object file and the listing file that are then used by the linker to grab necessary references from the link library to create the executable file, which is machine code.

High-Level Language->Assembly->Machine Code

Assembly is closer to machine code, but it is not actually directly interchangeable.

Also, even the 6502/2A03 processor used in the NES had almost sixty instructions. Once you considered that almost every instruction had two or three (or more) address modes it could use, the 256-choice opcode matrix begins to fill rather quickly.

And that's the 6502 and its NES variant. Want to take a look at the IA-32 instruction set used in Intel-based processors? The manual covering the instructions is split into two volumes; they're over 1000 pages together. Twenty? Hardly.

The ARM7, which is the GBA's processor's core, uses the ARM instruction set. There's also the THUMB instruction set on the GBA, so these reference cards below give you a bit of an idea.

ARM
THUMB

Assembly is fast. Assembly is love. o_o

When you write in a higher level language (C++, Visual Basic, Pascal, FORTRAN, and the like) it's compiled to Assembly for the processor it is being compiled for, then it is sent through the assembler which creates the object file and the listing file that are then used by the linker to grab necessary references from the link library to create the executable file, which is machine code.

High-Level Language->Assembly->Machine Code

Assembly is closer to machine code, but it is not actually directly interchangeable.

Also, even the 6502/2A03 processor used in the NES had almost sixty instructions. Once you considered that almost every instruction had two or three (or more) address modes it could use, the 256-choice opcode matrix begins to fill rather quickly.

And that's the 6502 and its NES variant. Want to take a look at the IA-32 instruction set used in Intel-based processors? The manual covering the instructions is split into two volumes; they're over 1000 pages together. Twenty? Hardly.

The ARM7, which is the GBA's processor's core, uses the ARM instruction set. There's also the THUMB instruction set on the GBA, so these reference cards below give you a bit of an idea.

[url=http://www.arm.com/pdfs/QRC0001H_rvct_v2.1_arm.pdf]ARM[/url]
[url=http://www.arm.com/pdfs/QRC0001H_rvct_v2.1_thumb.pdf]THUMB[/url]

Assembly is fast. Assembly is love. o_o

elyscape

2004-09-15 06:51:42 pm

Actually, Assembly is just Machine Code with the binary instructions given names in English. The compiler takes the high level language into Assembly in an object file, then puts the data from that into a file with the Assembly in whatever libraries are needed into the executable.

Captain N

2004-09-16 08:12:32 pm

Actually, I disagree with that. It's very much *like* that, but it isn't that exactly. Because of the different addressing modes, one mnemonic can actually be turned into one of multiple opcodes based on the context of other non-mnemonic data around it. Because of this, Assembly is not simply "binary instructions given names in English", but rather closer to coding in machine language than is coding in a high level language. However, it is not coding in machine language precicely.

Additionally, once you throw in concepts such as labels and variables, it becomes even less like it since you're able to add new data and change data sizes at any time during the programming process with little requirement for changes elsewhere in the program (excepting changes from things like AL to AX, AX to EAX, and so on and so forth). Adding a single operation in machine code after you have coded jumps later in the program is a hellishly distasteful task to have to deal with.

It is much like programming in machine code, but programming in English-readable machine code Assembly is not.

Actually, I disagree with that. It's very much *like* that, but it isn't that exactly. Because of the different addressing modes, one mnemonic can actually be turned into one of [u]multiple[/u] opcodes based on the context of other non-mnemonic data around it. Because of this, Assembly is not simply "binary instructions given names in English", but rather closer to coding in machine language than is coding in a high level language. However, it is not coding in machine language precicely.

Additionally, once you throw in concepts such as labels and variables, it becomes even less like it since you're able to add new data and change data sizes at any time during the programming process with little requirement for changes elsewhere in the program (excepting changes from things like AL to AX, AX to EAX, and so on and so forth). Adding a single operation in machine code after you have coded jumps later in the program is a hellishly distasteful task to have to deal with.

It is much like programming in machine code, but programming in English-readable machine code Assembly is not.

Kharay1977

2004-09-16 08:28:14 pm

Google is your friend... :-)

A little... Google-ing into GBA development:

http://www.loirak.com/gameboy/index.php
http://www.devrs.com/gba/files/gbadevfaqs.php
http://www.mdh165.pwp.blueyonder.co.uk/docstuts/Chapter1_Hardware.pdf
http://www.jm-basic.com/dragon/

By the way, I agree... Fusion was most likely done in C/C++. Any other language is unpractical. Assembly would be a horrendously fiendish task to debug. Try coding something in Assembly and then don't touch it for a month. Then return and try and figure out what it is you are doing in a certain location of the code. You'll have a hard time just figuring out what it was you were doing.
And, most C++ compilers these days have been optimized so much that their output is as fast as you're gonna get it (not counting your own C++ skills... or lack thereof), they generate VERY highly optimized machine (binary) code.

Wassup Dawgs

2004-09-16 10:29:13 pm

Quote from Kharay:

Try coding something in Assembly and then don't touch it for a month. Then return and try and figure out what it is you are doing in a certain location of the code.

That could happen with a lot of languages. It happens to me with Basic.

Yoshi348

2004-09-16 11:00:49 pm

PAGE BREAKER

Ready and willing.

Then use comments. I don't think Assembly allows comments.

Ekarderif

2004-09-17 12:04:56 am

Yes assembly uses comments. I'm currently taking Computer Architecture so we're learning assembly for MIPS (which is going to die in 5 years anyways so what I'm learning is a waste). Oh well...

Captain N

2004-09-17 11:43:54 am

I just ordered a book for 6502 architecture last night. How's that for dead? ;P (Well, since I'm applying it towards knowledge on the 2A03, at least...)

We did IA-32 in an Assembly course I took in the past, also in the one I'm taking now. Architecture was fun, however. We had to code a simulation of a simple theoretical processor. It actually had more individual instructions than the NES does. :P

And thank the gods that you can comment in Assembly. If you couldn't, it actually *would* be hard. With comments, it just becomes the creator of very, very long programs. (My boredom project for my current Assembly class was to add a simple Rock Paper Scissors game to what otherwise represented a pointless program that served no purpose but to teach Assembly. The program itself was 34 lines of code with another 100 or so for nice little cleanups to the crap that the program actually required. From there I managed to add about four more printed pages of code (more than the entire rest of the program) just to add the simple game of Rock Paper Scissors. Oh, how much fun the grader will have. :P)

I just ordered a book for 6502 architecture last night. How's that for dead? ;P (Well, since I'm applying it towards knowledge on the 2A03, at least...)

We did IA-32 in an Assembly course I took in the past, also in the one I'm taking now. Architecture was fun, however. We had to code a simulation of a simple theoretical processor. It actually had more individual instructions than the NES does. :P

And thank the gods that you can comment in Assembly. If you couldn't, it actually *would* be hard. With comments, it just becomes the creator of very, very long programs. (My boredom project for my current Assembly class was to add a simple Rock Paper Scissors game to what otherwise represented a pointless program that served no purpose but to teach Assembly. The program itself was 34 lines of code with another 100 or so for nice little cleanups to the crap that the program actually required. From there I managed to add about four more printed pages of code (more than the entire rest of the program) just to add the simple game of Rock Paper Scissors. Oh, how much fun the grader will have. :P)

Jigglysaint

2004-09-17 01:19:40 pm

You should re-program metroid for an ASM project. I dunno if you would get credit or anything.

elyscape

2004-09-17 02:01:25 pm

Quote from Jigglysaint:

You should re-program metroid for an ASM project. I dunno if you would get credit or anything.

Well, maybe not credit, but definately a mental condition.

Xin

2004-09-17 09:19:15 pm

Most games for the NES, SNES, and such were programmed entirely in their respective assembly languages and a standard assembler, but there were a few companies that made (usually) really ghetto C compilers that sometimes generated code that made no sense at all. Fusion was most likely made in C/C++.

edit: erm, Fusion, not Zero Mission.

tomatobob

2004-09-18 04:50:24 am

One shall stand, one shall ball.

I think my brain just melted from reading this topic. Without doubt the most programming talk I've seen outside a book dedicated to the subject.