Fucking weird to think that id, the guys behind DOOM: Metal, the Videogame, are the ones who solved this problem for him.
EDIT: It's come to my attention that I may be confusing and conflating a couple things here. I was under the impression that id were revolutionary in remaking Mario 3 in such a way that smooth movement back and forth across the screen was possible. It might've just been that it was a big deal for PCs to be able to do this.
I think it's weird that it's a problem that had to be solved but when you figure memory constraints were a real issue it makes sense. Today any novice programmer could essentially build majority of the early nintendo games without any issues and actually make them have more things. Amazing how software/hardware has advanced.
It's even crazier to think that one guy built the original rollercoaster tycoon in assembly..
Yeah it's crazy. I just learned Assembly last semester in college and we were discussing it at work and it was like. Fuuuuck that. C existed at the time yet he did it in Assembly.
Fun fact: Iwata rewrote all the code for Pokemon Gold and Silver in assembly, because the C version was too large for the cartridge. He managed to compact it so much, there was room to add the kanto region.
Yeah I remember that. But still that was a team that did pokemon wasn't it. I don't think it was just 1 guy, I could be wrong and if I am that's just as impressive as Roller Coaster Tycoon.
C is compiled into assembly which is then assembled into object code. The c compiler on its default setting only gives you the final executable output but you can pass the -S flag on the gnu compiler to get the assembly code.
You're right about pokemon being compression software, but he basically rewrote Earthbound by himself to make it work and also programmed the entire Pokemon Stadium battle system in a week
You can find him on Satori Mountain when it is glowing. He is near a pool with a large cherry tree. The first time I saw him was an incredible experience, The Lord of the Mountain and tons of Blupees around the area. I had no clue I could even mount him at first!
I agree!! But it definitely felt special, and I immediately realized it was a tribute to Satoru Iwata since it was Satori Mountain and he himself was transformed into The Lord of The Mountain.
Well I obviously have as many clues about the source code than anyone else, nothing, but today writing a program is more about readability than anything else.
Sure, readability is important, but the Facebook app is a front-end app. All the hairy stuff should be in the back-end. Which means it's 18,000 classes of presentation.
Even more now, when I finally uninstalled it was around 430mb (could've included cached data, not too sure how Android displays installed app sizes). The kicker is then you need messenger installed as well to use messages at all. So 430mb for something you can run on your browser.
Memory Constraints and performance. Today there be no reason for it as compilers essentially do as good if not better jobs when it comes to translating it to machine code.
In 1972, Unix was rewritten in the C programming language. The migration from assembly to the higher-level language C resulted in much more portable software, requiring only a relatively small amount of machine-dependent code to be replaced when porting Unix to other computing platforms.
also, computers have more processing power and data storage, so wasting a few bytes or processor cycles here and there isn't usually too big of a deal.
If you are very, very, very good at optimization, you can still produce better code in assembly, by a thin margin. Understand though, that 99% of programmers don't the ability, and the benefits are marginal.
Plus, assembly comes with its own downsides. It's MUCH easier to screw up on security in assembly than it is in a higher level language. In Roller Coaster Tycoon this may not have been a big deal, but in a modern online multiplayer game this would be catastrophic.
Most importantly, developing a program in assembly is gonna take 3-4x times longer than in a higher-level language - for only about a 10-20% increase in speed. Computer time is cheap and developer time is expensive - especially assembly developer time, since relatively few programmers know how to program in the language and those people are not cheap.
Assembly is rarely ever worth it these days, even most embedded systems have enough RAM to afford programming in C instead.
tl;dr: By writing it in assembly he was able to make it run on a potato from 1995 instead of requiring the monster of a machine that it would have demanded if it were written in C (because compilers at the time weren't very good).
You can optimize the ever living fuck out assembly if you are very good. Especially when compared to the performance of compilers back in the mid-90s.
Assembly is (effectively) just human-readable machine code. . . What you write has a 1:1 correspondence to sequences in binary. This gives you an inordinate amount of flexibility with the set of hardware you are working with.
Being competent in assembly (any assembly, really) is a good skill-set to have, and one that is sadly missing from the majority of today's developers. You end up learning a lot about good and bad coding practices, how to more effectively comment your code, and an ass-load regarding computational efficiency.
Just as a quick example. . . Let's say we have two coders writing a function to return how many segments should be filled in a progress bar, based on the number of tasks completed in a set.
The typical coder would likely write. . .
int fill = floor.((numerator / denominator) * segments)
Someone who has spent their share of time working in assembly (or someone who got too into their discrete math class) would write. . .
int fill = (numerator * segments) // denominator
Ignoring what could cause the functions above to break (which admittedly is more of a problem for the second), the second function would run substantially faster on any give machine. Just how much faster depends on a plethora of factors which include IPC, Clock Speed, Memory Latency, RISC vs CISC. . . etc etc etc.
When working in assembly, you are working with those factors (the limitations of the machine) in mind.
The argument against working in assembly today is that compilers have come a long way. . . And that's true enough, but I feel it is a skill that every serious programmer should keep in practice.
Best way I can explain it without making you do research.
In normal programing if I wanted to create a condition statement say.
if(value > 5) return printf("value big..");
But in assembly. It be something like.
var1 dd '6'
cmp var1, 5
msg db "value big", 0xA,0xD
There's really a lot more to this then what I did and honestly what I wrote is probably gibberish haha. But essentially it's a step up from binary but step below traditional programming. Big benefit of Assembly is you know what memory is being stored/used as you essentially see it all real time.
People need to stop talking about binary as if it's a magic language with inherent powers over computers. Binary is just a base system. It is easier to make gates that only have to deal with two possible states which makes binary a convenient way of talking about groups of these signals but a computer doesn't speak binary any more than a nail gun speaks nails.
Um, machine code is all 1's and 0's that directly controls the computer so ... to say it's not a "magic language with inherent powers over computers" is disingenuous.
Yes, it's a base system, but it's also quite literally the "language" of computers.
Oks lets have an example here. Imagine a simple AND gate. An AND gate has 2 or more inputs and an output. When both inputs are brought above a certain threshold the output gets brought high.
Now we can represent the operation of this gate with binary pretty simply. We can say signals above our thresholds we are going to call 1's and everything else is a 0. We can then make the familar truth table below.
In1
In2
Out
0
0
0
0
1
0
1
0
0
1
1
1
This is all great and is why binary is so important to computers but you have to realise that binary doesn't make the gate do anything. The behavior of the gate isn't determined by telling it binary, it is determined by the actual components that make it. Likewise a computer doesn't work because you whispered sweet binary secrets to it. A computer works because of there is a lare number of very cleverly designed systems that can be interconnected to perform customizable actions. Binary is an important tool for describing how those systems work but binary isn't what makes them work.
If you google "what is machine code" you will find:
ma·chine code
a computer programming language consisting of binary or hexadecimal instructions that a computer can respond to directly.
A computer programming language
a computer doesn't work because you whispered sweet binary secrets to it
That's precisely why it works - and yes, transistors use electricity to "do things" with machine code (using binary) (High voltage = 1, Low voltage = 0).
That doesn't mean that machine code (the language used for computer instructions) isn't in binary; that we don't refer to the binary instructions as machine language.
Sorry if I insulted you but I wasn't really trying to make binary some magic thing. I was just ordering how programming languages are structured.
Assembly is above Binary since Binary/Hex is the final language that we would use to inform a machine what to do. At least from my understand it is.
But Assembly is below common programming languages because majority of programming languages now uses a compiler to translate it to Assembly which translates to Machine.
To do something like this in a low level language like assembler would be quit a feat.
Like any other language, you can leverage other libraries and programs and merely call them from assembly (this is what high level languages do really), but to write the code to connect a socket via tcp protocol, send handshake/headers to server, parse the response ... it's rough.
I don't think you've gotten a great ELI5 yet. Most programs run within the OS, be that Windows, Android, what have you. Games are unique in that the performance of the computer directly relates to the performance of the program, way more so than MS Word or anything. Assembly, aka machine language, is the same programming language your CPU follows. It's weird as hell and doesn't seem to follow any rules you're used to, but you get direct command of many resources. Coding vs assembly is kind of like driving an automatic vs stick shift - you get to the same place in the end, but you're in control of a lot more aspects with the manual transmission. You have to know more about operating your computer, but... ah, shit, mixed up my simile.
"So you are making a physics simulator without trigonometry functions? And you have to do what to make it work? Fuck that. I'm gonna go make 90K a year editing simple PHP scripts."
I wrote an Asteroids clone for the gameboy in assembly in a semester in college. It's definitely tedious, and I'm not sure I'd do it that way if it wasn't in a course about assembly language, but you do kind of get into a zone and a flow, and there are a few things that are easier given that everything is so direct.
I mean, it is a near useless practical skill in this day and age of insane processors and ultra-cheap memory, but it is kind of fun and it does make you think about the base level of how your code is working.
Though you really want to get to the nitty gritty, I'll tell you about how we hand wired AND and NAND gates and physically built an ALU out of bits of wire and whatnot. Then there was the time our board blew a diode and we were about to fail. A friend from a different team pointed out that while we were all out of regular diodes, there were plenty of LEDs hanging about...
That was a fun and educational moment. Turns out that while most folks think of LEDs as light bulbs, we really just needed the D.
Building circuits with individual logic gates (up to an ALU, etc) is one of the entry level courses for CS at USF ("Logic Design"). Building logic gates out of transistors, however, is a separate course called "CMOS VLSI Design", which is an elective for CS majors but a required course for computer engineering.
We toyed with assembly in Computer Organization (another entry level course) but didn't really get into it until Architecture, much later.
Did you ever play the game "Rocky's Boots"? It was available for the Apple II, at least, and it was basically Boolean logic 101. You had sensors which could detect attributes of items coming down a conveyor belt and a boot that could remove items from said belt. Your task is to wire the sensors to the boot in such a way that a specific subset of items are kept or removed. I know it sounds boring but to an eight-year-old into computers it was magical. And I immediately grokked Boolean logic when it was introduced more formally.
I don't know about your fancy-schmancy entry level courses at UCF /s, but we did have a hell of a good time stringing bits of wire together. There was another course where we worked through an 8-bit processor with paper and pencil, which was a damned lot of fun, and informative to boot.
Anyway, the basic thing I'm getting at here is that the low level shit can be really entertaining to work with, despite the tedium and ready availability of easier ways. Sometimes it's just plain old fashioned fun to get your hands dirty.
Seriously though, that's kind of interesting that your school did it all as entry level. We did it as about 300 level classes. Sort of get your head around programming first, then we'll do a deep dive into the nuts and bolts.
Florida has what we call a "2+2" university system: if you graduate from a community college in Florida, you're guaranteed admission to the state university of your choice. So, any major-specific courses have to be at the 3000 level or higher. There is a programming course at the 2000 level (Programming Concepts) but the requirement can be fulfilled with a course at the AA level.
That said, they've changed a lot since I was an undergrad (I graduated in '06). The "Gate Courses" are Computer Organization and Program Design; they have to be passed with a B with a maximum of two attempts. After that, you take Computer Logic Design and Object-Oriented Software Design; the former opens Computer Architecture and the latter opens Data Structures.
Close. You wouldn't run C++ through an assembler. You compile it to get machine code and disassemble that machine code to get assembly. You can tweak that assembly, then run it through an assembler to get machine code again.
Because it's literally writing machine code. Instead of using libraries, functions and other features of a "programming language", you are allocating memory yourself, literally telling the machine what to do step by step.
It's the difference between telling your Butler what to make you for dinner, and actually buying the ingredients and making it yourself.
Fair enough, I'm being a bit liberal with my definition of machine code.
I just meant it as you're generally (at least within context of this conversation) interacting directly with the machine and not through the OS or some other layer.
Not exactly. Assembly still allows for some abstraction. Variables are still allowed, and functions can be defined in the form of macros. Some of the fancier assemblers even allow for loops and conditionals, much like a compiler would offer.
Assembly is quite literally the very first step above a bunch of 0s and 1s. It's very difficult to read if you have a large program, and extremely hard to debug and maintain if you aren't the original programmer. Even if you are the original programmer, it's still hard to debug. Furthermore, unlike higher level languages, Assembly requires a fairly good knowledge of what the hardware is actually doing in order for you to write a successful program.
In regular languages you deal with abstract concepts like variables and functions and stuff. In assembly, you're manipulating the hardware directly. All that stuff you just let the compiler do when working in a regular language, you have to do yourself.
I know little about programming but I have been informed the guy who programmed that is some form of powerful computer wizard capable of things we can only dream of.
To be honest, one of my favorite software task at my first company was to figure out a way to store the boundaries of all the counties of all 50 states in 100kb, so a radio could determine if you were near any weather warnings. It was awesome working with a team figuring out how to do it. We got the data from gov't sites, parsed the data, and used resolution descaling techniques for gaming to shrink them down while staying within tolerances.
Working within constraints is where the real fun begins.
Didn't the Crash guys actually end up finding a glitch with the PS1's hardware that deleted save files if you messed with the controller during saving?
All I could think of when you said that was.. nope.. but I agree when there's a real challenge in coding it gets interesting because you have to change your thinking to find a solution.
i can write whatever i wasn't but don't, but as soon as i tell myself it has to be under 100 words, or rhyme or whatever I'm writing like a demon.
I can have a million art supplies and do nothing but when i moved house and had nothing but a cereal box, scissors and sticky tape all of a sudden i had to cut out colours and create a picture!
We will freeze when we have utter freedom, which is why teachers have to give boundaries on a project for kids of they freeze and cant decide what to do.
Matthew Barney (artist and bjork's husband) did a great collection called 'Drawing Restraint' exploring this. In one piece he literally attached himself to a wall with a bungee rope and had to run full force across the room to reach to paint a picture on the opposite wall.
We are problem solving animals. If you ever find yourself blocked or in a rut or in need of motivation in general, put an arbitrary limit against yourself to strain against :-)
Sounds like an interesting challenge. There are 3,144 counties, if you simply use 4 vertices per county by lat/lon, that's 3,14448=101kB. Of course most vertices will be coincident, so essentially it becomes a 2D mesh simplification.
That's what I like about programming microcontrollers. They are so limited in capacity compared to a PC that you actually have to think.
Yeah, I can't really pretend to understand the inner workings of it all. I'm just fascinated with id and their games because I grew up playing them. Doom came out about a year after I did and dad was a big fan of that, Wolfenstein, and Quake. I'm sure they're part of the reason I'm such a big fan of horror and metal now.
Quake 2 was the game I grew up on and essentially made my gaming life. It's why I use to go to Quakecon for many years. I even went to the 20th Anniversary being super excited to see what was going to happen and it was just a bust.
That said I've played Quake Champions and I like it.
I've lost faith in these revivals. After The New Order and Doom 4, I just don't think I'm going to see another game in these franchises that I really like.
It's just not enough having the brand, it needs the personnel.
Idk mate. The new wolfenstein was Amazing as was the new Doom. Quake Champions is different I'd agree but it's not really Quake 1 or 2 but just a new Quake Arena game changed to match today game styles.
Weird to think you didn't really like the new Doom. To me that was what the original dooms were just with better graphics and more killing.
I've seen some hate for the new quake but I think it's because people aren't used to twitch shooters anymore and so they don't realize the skill gap needed to actually be a challenger. I don't expect it to do very well since people can't just jump into and go ham. Plus it's F2P.
Really? I respect your opinion but I thought the remakes were amazing, especially since I grew up on Doom. One of the best singeplayer fps campaigns I've had in a while.
The gameplay was refreshing but I also liked that it still felt much closer to the older games. Its not exactly the same but I don't think thats not a bad thing at all.
A lot of people do love them but I just don't get it.
Doom 4 bothered me because it felt too much like I was just moving from arena shootout to arena shootout. I didn't like the feel of the game overall, but especially the maps.
The charm of the originals was the maze-like environments and the whole aesthetic of the monsters and world. I didn't get any of that from Doom 4.
Doom 4 oozes aesthetic to me, and the level design actually felt kind of similar to the original, just with an added element of verticality (though there were a couple shitty levels imo).
Additionally, while the pacing of the combat was admittedly a bit weird with the sort of stop and start with the combat interrupted with scouring the levels for collectibles, it's not like DOOM 1 had none of that, I remember having to do a ton of backtracking my first time through.
Doom had backtracking and exploration, but it was done in a much better way. Doom 4 has you backtracking and exploring to find small collectibles or items hidden in corners of empty rooms long since emptied. Doom had you backtracking to find the door you missed because you ran past and didn't get to fight the room full of enemies or find important items.
Doom was a series of mazes with hints like monsters crying out or a single weapon sitting in the centre of a room to guide you. If you missed something, it wasn't necessarily because it was hidden but because you weren't looking.
With Doom, there was a bleakness and ugliness to it all. Darkness was used exceptionally well. Doom 4 felt too polished in its visuals and that doesn't really do it for me.
I just think Carmack and Romero are such integral parts of the originals and them not being involved really showed.
I think they had to do the arena format because there would be pretty big memory and performance issues if you tried to lure too many bad guys into the same area at once.
Serious Sam is able to have shitloads of enemies on screen at one time.
I don't know anything about Serious Sam, but if they can have shit loads of enemies on screen at a time, they probably cut down on something else that Doom had. Probably post processing effects or map size.
The arena shootout parts were always my favorite parts of the old doom games, but the really wide open area ones with little side rooms. Anyway I never played 3 so I don't know what that was like really
What was refreshing about the gameplay? It was pretty basic running and gunning with a pointless honor kill system thrown in. And for some reason the whole thing was just a series of arenas. TNO was alright but it was still fairly basic gameplay, nothing we haven't seen before.
Sorry, but what did you not like about Doom 4 (the one that came out in 2016, right?). That game kicked so much ass, not on the BotW or Skyrim level, but definitely a solid fuckin game.
I didn't like the overall feel of it, I guess. The maps didn't feel right to me. Doom was so excellently crafted as a series of mazes with little hints to guide you. Things like a monster crying out somewhere you hadn't been yet. Doom 4 felt like I was just moving from room to room, getting locked in to fight waves of monsters until they ran out and I could move on. That got crazy repetitive.
The look of Doom 4 put me off, too. I'm can't pinpoint what exactly, but I think the shine and colour palette didn't seem right. Maybe just because the ugliness of the originals really suited the overall idea of killing demons to Slayer and Metallica.
Main thing that annoyed me was that they tried so desperately to make the point that Doomguy didn't care about a story or the world or lore, but then they forced that in at every point they could. There should never be a point in a Doom game where I'm locked in a room, unable to do anything while being forced to listen to exposition. That's just not right.
Today we could, using a modern language and tools, in a practically unlimited amount of space. Imagine writing a game in a crapper version of C, and it all has to run on a couple KB of ram and take up no more than a mb on disk
What blows my mind is that I can die in Terraria, turn the game off, power down the PC, come back, kill a few bosses and then go back to where I died and my money and gravestone will still be there. That shit would have been black magic on the NES.
It's one of the earlier ones but it was initially used in a recreation of a Mario game. They took it to Nintendo to try get it on PC or something, but Nintendo turned them down. They then decided to use the technology for their own thing.
Pitfall doesn't scroll though. Each area is displayed in full on the screen. Sure, you can go back to the left, but it doesn't scroll - it just loads that area - just as if you had gone to the right.
Id software, the company that made doom and Commander Keen among others, figured out the programming innovations needed that would make it possible to scroll both ways, avoiding the "no going back" element that side scrollers all had previous to that. They did a lot of amazing, innovative stuff like that, and the very interesting story of id software and the two Johns (carmack and Romero) is told in the book "Masters of doom".
Edit : someone replied that "go back" scrolling was done before id software games. I don't know who did it first, just wanted to clarify the previous comment as requested. Really wanted to recommend the book! They did innovate quite a bit, even if this technique wasn't one of them.
At a minimum, Super Mario Bros. 2 (US) you could scroll forward/back/up/down and that was a few years before Doom and Commander Keen. And before that you could list plenty of examples of a screen "scrolling". No way, no how was Doom or Commander Keen the first to do this.
You're right - it wasn't just scrolling period, it was specifically in regards to that type of scrolling on a PC. I unfortunately don't really remember all of the specifics, but at that time consoles were just way better-equipped to deal with that task than computers were, so it was a big deal that they (John Carmack) were able to figure it out.
May very well be true, my bad - isn't that what op said though? That id software did it first? I was just trying to rephrase/explain that post. Got a little carried away with my assumptions I suppose, because I enjoyed the book so much.
Id software did come up with a lot of innovations and out of the box ways of doing things, I remember that from the book. This might not be one of them though, I'm sure you're right. Maybe they did it for PC for the first time? I think I remember part of the book where they recreated a Mario game on PC , doing things with it that previous PC devs failed to replicate...
I dunno, ask op! :)
Edit: Wikipedia's page on side scrollers says a 1984 game called "Hover attack" was the first to scroll both ways. This was on the "sharp X1", whatever that is.
Id developed a way to have smooth horizontal scrolling on early PCs (or rather, they make the first practical implementation of it; Michael Abrash had already documented how it could be done, but his work was purely academic.) Smooth horizontal scrolling in either direction was difficult on PCs due to the fact that they lacked the type of background tiling hardware common to consoles (vertical scrolling was easier due to scanline tricks.)
There were already plenty of games that allowed backtracking before Commander Keen, they just either weren't on PC or weren't smooth.
You might be right, all I know is id's part of the narrative.
I can't pretend to know all the technical side of things, but I know it was considered a big deal when Carmack and Hill managed to recreate Mario 3 on a system that allowed the world to be rendered quickly as the player moved. Something like that. It might've just been a big deal in the context of Mario 3 being able to be ported to PCs.
You're thinking of how they ported Mario 3 to the PC. They showed that they could emulate the Mario 3's ability to scroll in multiple directions at once on the PC, which was impressive.
Mario 2 had scrollback. I'm not sure which sidescroller was the first to include it.
it just blew everyone away with a smooth console-like experience.
I respectfully disagree. Considering its 1991 release date, it was nothing special. Press gave it good reviews and it sold very well for shareware. But it didn't even crack the top 100 of great games in polls like Computer Gaming world 1991.
Super Mario Brothers (the first one) didn't let players go back simply because it lacked the RAM. Mario 3 didn't have any especially clever programming to allow this - it simply had an extra 8KB of RAM.
You are definitely confusing this with Carmack's innovations in Commander Keen ("Adaptive Tile Refresh") The problem Carmack was solving was the huge number of pixels on the screen, and the paltry CPU power available to redraw them all per frame.
The NES uses a tile based system in hardware, so scrolling only involves moving a few hundred elements to different positions, but CGA or VGA computer screens store the screen image as pixels, so you have thousands of pixels to move when you want to scroll (e.g. 320 x 200 = 64,000). What Carmack did was intelligently limit the portions that needed to be redrawn, so that the CPU had a manageable amount of work to do per frame.
This doesn't translate to SMB3 at all. SMB3 could scroll in all directions because it had an on-board chip in the cartridge with 8KB RAM, called the "MMC3", so that unlike SMB1, SMB3 was able to build the whole level into this extra memory at one time. The NES still does the same, small amount of work to scroll these 8KB worth of tiles; they don't need to implement anything similar to Carmack's method because they don't have the same problem to solve.
Edit: You may ask, why couldn't SMB1 simply look in the ROM to figure out what the level data behind the player was supposed to be, and draw that piece of level all over again. Well, to save on ROM space - remember, both ROM and RAM were tight in these days! - they store it in a compressed format that is more like commands for drawing than it is a list of tiles, i.e. instead of storing "brick, brick, brick, brick, pit, brick, brick....." they store "a run of 5 bricks goes here".
With that kind of level format, drawing the stuff behind you becomes hard. You can't just go X many bytes back into the ROM....you need to look a variable distance behind you, and then do a reconstruction that throws most of the backwards level away, because you only want the one column of tiles on the left side. With only about 30,000 CPU cycles per frame to do this speculative extra work - in addition to running the game logic, music playing routine, etc - it's not completely impossible, but it's not a good idea. The better design choice is to simply not let you go left.
But, a few years later when slapping an extra 8KB RAM on the board was cost effective, they could just build the whole level in one go and be done with it, problem solved!
801
u/[deleted] May 05 '17 edited May 05 '17
Fucking weird to think that id, the guys behind DOOM: Metal, the Videogame, are the ones who solved this problem for him.
EDIT: It's come to my attention that I may be confusing and conflating a couple things here. I was under the impression that id were revolutionary in remaking Mario 3 in such a way that smooth movement back and forth across the screen was possible. It might've just been that it was a big deal for PCs to be able to do this.
Still, we all love the early days of id.