Omnimaga
General Discussion => Technology and Development => ROM Hacking and Console Homebrew => Topic started by: Zera on April 14, 2010, 11:23:36 pm
-
Relevant link (http://www.romhacking.net/docs/459/)
Just thought someone might be interested in this, possibly for reference or educational value. I know there have been a few Metroid-based projects for TI.
-
Nice, did Nintendo did the release? I wonder how legal it is to provide any ROM hacks that contain parts of this code? That said, maybe it doesn't matter much though, else that site may not have hosted it :P. It could be useful if someone wanted to do a calc Metroid indeed
-
I'm pretty sure it was created through reverse-engineering. I recall a utility being released a while back that could basically reverse-engineer the source code of NES games through a mostly automated process.
-
Interesting. I bet hardcore programmers could find rather funky stuff in some games sources, such as how randomizing works for example
-
Honestly, though, the Metroid NES engine sucked. No offense, but even the GB version let you shoot low to the ground. The best one was probably the SNES version,
-
Yeah true. PLus some maps were so repetitive. Old games engines are typically crappy, since the old consoles were so limited in power, they had to keep collision detection to a minimum. This is why for example in SMB you could go through walls when jumping backwards and stuff like this. But hey, it was in 1986 after all :P, back in the days this was probably the best platforming shooter around :P. IN 1986 I just came to birth and the Atari 2600 was still around.
-
Nice! I like to collect stuff like this whenever I come across it. :) It's always fun to look at how classic games were designed and programmed. Looking at this file, it looks like this was disassembled and reverse-engineered by somebody. Pretty well commented, too, so you can get some insight into how it works even if you don't know that particular ASM language.
I can think of many games I'd love to see files like this for but haven't found any yet. But I can imagine it takes a lot of time and work to document them like that.
Yeah, many classic games tended to have repetitive maps in order to conserve space. Games like Zelda I and II tended to reuse rooms a lot too. Super Mario Bros. I used a fascinating approach where patterns of blocks were defined and then levels were built using those patterns to save space. (I remember reading a discussion about that lost deep within the ticalc.org comment boards around a decade ago. Fun memories :)) Actually, Metroid does something similar IIRC. Actually, I think quite a few games used these types of schemes in general.
The cool side-effect of methods like that, though (especially in Metroid's case) is that if you take advantage of bugs in the game (or hack/cheat) to go outside the map and make the game load arbitrary non-map data as maps, you tend to see stuff that sort of makes sense and is more fun to explore, rather than just pure completely-random-looking gibberish.
-
Super Mario Bros. I used a fascinating approach where patterns of blocks were defined and then levels were built using those patterns to save space.
A lot of NES games took this approach - including Metroid. Every object in a level could only consist of some predefined pattern of elements, as opposed to a single element (block) by itself. A single room was often mapped to several locations, which accounts for a lot of the redundancy. A palette-swap and the appearance of different enemies and / or items gave the room some discernible difference from other rooms like it.
This really must have saved some space, I imagine. If you think about rendering a level as hundreds of individual elements for each 16x16 block that makes up the ceiling, floor, platforms, etc. - it would reserve quite a lot of memory. Strictly defining entire patterns of elements as a single object would cut down on the number of objects significantly.
-
It would be cool to be released by Nintendo. :P
I don't remember any notable company releasing some source code of some old software or game but sometimes they release freely some old classic. One example is an Elders' Scrolls old game for DOS by Bethesda, IIRC. You can freely play now with DOSBox.
-
Didn't Doom became open-source? I recall seeing it in the free FPS games section of Wikipedia before, but since it's Wikipedia maybe it was just misleading info.
-
Doom's source was released in '97, I think; but it wasn't released for DOS. I think someone had to port it over and then release the modified source.
-
IIRC it also required DOSBox, right? I remember trying Doom demo under Windows XP and getting like 4 fps x.x
-
I know there is a Flash version of Doom somwhere on the internet... I'll see if i can find it...
*runs off*
-
On my side, if I get my hand on a full doom copy, I just use some mod normally with enhancements so it looks better and stuff. There's also the SNES version but I don't remember if it had aiming up/down
-
heh heh. Metriod source code.....many of these games consistently used repititive images and maps in order to save space. think how much more space would be needed to incorporate seperate images for EVERYTHING. i mean we are talking about an old low-memory 8-bit NES cartridge. Not a PS3 blueray disc. XD
-
Yeah. Heck, even with calc games we do this sometimes. In Metroid II: Evolution, certain map data is used several times in a row, for example if you fall in a huge pit. In Illusiat 13, if I didn't do that with the Desert and the 4th Dimension dungeon, the game wouldn't even fit on a regular 83+ if it ever got finished.
In some old Illusiat games, the same map data was used for multiple dungeons too. For example, in Illusiat 11, the fire, ice and bolt dungeons are identical except the ASCII sprite palettes (which contains 2 tiles for the dungeon, 1 for the battle floor and one for the event triggering tile) were not the same accross all 3 dungeons. In Illusiat 10, there are twin towers somewhere. One is the magic tower and the other is the strenght tower. Both are exactly the same, even the tile palettes. Fortunately the entire game is not like this so only certain parts can be repetitive. Also those dungeons are generally very small (1x8 rooms, usually). This is always done to save space and stuff, not really because of laziness. Sometimes the limitations at the time are just too much.
-
In Metroid II: Evolution, certain map data is used several times in a row, for example if you fall in a huge pit
Heh. I didn't know that. I wonder how that's accomplished.
I only recently worked out the whole logic in infinite corridors: Place a teleporter toward the ending boundary, and have the player (unknowingly) teleport back to an earlier point in the corridor over and over. :P
-
Oh for example, my maps are split by columns. Each subprogram containing map data contains one column. If there's a huge pit somewhere, instead of doing
If A=1
map data
If A=2
map data
If A=3
map data
If A=4
map data
If A=5
map data
...
If A=20
map data
If A=21
map data
If for example the repetitive maps ranges from row 2 through 5 (row being A), I'll do the following instead:
If A=1
map data
If A>1 and A<6
map data
...
If A=20
map data
If A=21
map data
Saving a lot of memory
And yeah what you say about infinite corridors is how they works. I think some of my games uses such method. Instead of moving one map forward it just loops back.
-
FOr example the infinie Stairs in SM64...
-
Woah read time stamps bro, it's almost been 2 years since the last post here.
-
LOL
indeed :P :P :P
-
Wow quite the necropost indeed. I guess it doesn't help that this forum section barely has any discussion, though. X.x