DKC Atlas Forum

[gamer_boy997]

Google is your friend.

That's the second time I heard that when I said I wanted to hack. Maybe Google is my best friend .

You might have said this already, but how much space does the cartridge-dumping tool take up in computers? I don't want this to waste too much space, otherwise, I'll probably never use it. Also, how can I find out if it's a 1.0 NTSC?

[Kiddy14]

Will the tool in the future be able to use all of the game versions? Even if the game is PAL or NTSC?

Spoiler!

I think the cartridge dumping tool is actually an external device you plug in your PC; of course, in addition of some software.
Something simmilar to this I believe:

[Simion32]

Kiddy14: I plan on including all versions later on, for ease of use.

As Kiddy14 stated, a cartridge-dumping tool isn't a computer program, it's a physical tool (like a gameshark is a hacking tool)!
That's why I said that I doubted you had one.

I'm sure that discussing ROMs any further than this would be against the rules...

Qyzbud: would it be a good idea to have this small ROM-related conversation spliced to a separate thread in the Emulation forum? Such as a ROM FAQ thread? I think it may be a good idea to have such a thread so that we don't have too many people asking what a ROM is... of course, said topic wouldn't link to any ROMs or anything against the rules.

[Qyzbud]

Discussion of the DKCRE will no doubt involve ROM discussion to a degree, but any unrelated ROM questions should be posted on the Emulation board. The Wikipedia ROM image article might be the best starting point for learning the basics, but our newly expanded ROM/Emulation Questions ("Should I get an emulator?") topic can be used for any further Q&A.

[gamer_boy997]

Thanks for letting me know all this guys! As I said before, I have rarely heard of emulators, this is pretty much the first time I have talked about them.

[Simion32]

I just thought I would provide a slight update on my progress, since I haven't gotten everything for the next version done yet.

DKCRE Progress Updates:
- Graphics decompression routine is faster, due to using a direct port of the routine rather than partial SNES emulation.
- The tool now accesses extraction parameters via INI files, making future modifications very easy and simple. This is taking quite a while to complete because of the string parsing, and also because I had to compile the extraction parameters into an INI file. This part is still not completely done, but it should streamline things when I get around to adding the other two games.
- Progress bars have been added to go along with the percentage meters. A re-design of the extraction detail messages is planned.
- I have added a few more Bonus Areas that seem to have been missing from the previous update. Specifically speaking, Jungles and Walkways were each missing at least one bonus area.

Also: apparently, the missing tiles from Mine Cart Carnage are stored in a separate tile map right after the level itself. So not only is Mine Cart Carnage the longest level in the game, it's also the only one to take up TWICE the amount of data (due to being double-layered). Mine Cart Carnage takes up a whopping 0.89% of the ROM.

[Gabriel]

Nice job. I guess to save space, Rare used two tile layers instead of more tiles for tracks on the ground. Quick question, how exactly are the graphics stored? At some point, I want to add graphics extraction to my editor.

[Simion32]

Actually, they probably would have saved more space if they had designed something to auto-place the tiles there. I mean, in an SNES game, $4900 bytes is a lot. I can't see why they had to store it using twice as much. Perhaps they were just doing whatever was the easiest?

how exactly are the graphics stored?

It's in some sort of RLE format. Unless you're using that LUA script add-on (I've never dealt with LUA at all), it might be slightly cumbersome to code a decompressor in MMF2.

Spoiler!

The uncompressed versions of the graphics are stored as such:

(each number represents a bit)
BYTE 1: 10001010 (worth 1 if bit is enabled, 0 if not)
BYTE 2: 00010101 (worth 2 if bit is enabled, 0 if not)
BYTE 3: 11010111 (worth 4 if bit is enabled, 0 if not)
BYTE 4: 10001010 (worth 8 if bit is enabled, 0 if not)

Add it up vertically to get this: D40696D6 ...each of those digits in the result represents a color in the palette the tile uses; which are the pixels.

Repeat that 8 times and you have a full 8x8 tile.

Sort of complicated way to store graphics if you ask me...

The sprite graphics on the other hand are uncompressed, but are stored somewhat messily (as evidenced by Mattrizzle's description of the format). This is something I still need to work on - I understand the format but haven't coded its extraction yet. Will start work on that as soon as I'm done with this INI stuff.

If you need more details, we can discuss this via PM.

[Simion32]

Here's a little more newsworthy information, that I find interesting yet worrying...

Nearly the entirety of the DKC2 ROM is compressed, including Levels, Tilesets, almost all Graphics, and maybe Physmaps. The only uncompressed parts I know of are sprites, text, and the object map data.

What this means, is that in order to have any flexibility in designing levels in DKC2, it would be necessary to expand the ROM to 48MBit or 64MBit. Wether this is possible, I don't know, but it seems the only solution. It would be very difficult to work within the stringent restraints of the compressed data size(s)... even if you re-compressed the levels, they would most likely not compress to the same size as before.

I have found this by looking at the ROM in a tile viewer. You can see the compressed data along with sprite data/graphics every so often. One strange thing is that there are sprites almost at the beginning of the ROM, which seems much different than the way DKC is organized.

I did a trace on the address and found a piece of code that accesses the data. However, modifying the two bytes in this code to $EAEA (in order to blank it out) not only results in corrupted graphics upon loading of any level; it also affects the map screens and the physical surfaces within levels.

This will result in catastrophic corruption of just about everything excluding sprites. This is how I've came to the conclusion that this compression affects most of the ROM, not just level graphics. Upon loading of Ghostly Grove, you will see something similar to this:

Spoiler!

DKC2_Data_Corruption.PNG (22.98 KiB) Viewed 268442 times

After finding this out, I saw that the makers of the Japanese DKedit tool have already done an ASM trace of this compression. So at least I won't have to re-invent that wheel, like I had to do for DKC. I can skip the step of tracing the routine and get straight to work with making a viable C++ port of the decompressor. However, I can not make sense of the notes which they have written in the trace (the translations don't make much sense apart from the phrase "RLE" which means run-length-encoding), so I'm sort of on my own in emulating this code via C++.

I don't need any help just yet, but I will ask if I need any help. Wish me luck!

[Gabriel]

Nearly the entirety of the DKC2 ROM is compressed, including Levels, Tilesets, almost all Graphics, and maybe Physmaps.

Uh-oh. I was hoping that once my editor worked 100% for DKC, I could just load a DKC2 rom with the extracted tilesets and it would work. If we lived in a perfect world.
I guess to save space, because many levels have lots of blank space (brambles, ship decks, etc), Rare must have compressed them, possibly with a similar RLE format to the graphics.
Rare does seem to like reusing stuff in their games. (The model format in DK 64 is very similar to that of Banjo Kazooie)

Slightly off topic, what is the maximum file size of a snes rom?

[Simion32]

I'm not sure what the maximum size is, but the largest I know of for sure is 64MBits. I think 128MBits might be possible.

Oh, and a conversion from 32 > 64 MBits isn't just like adding 0's to the end of the file. That won't work and will crash the game; you have to reformat the data pointers and everything so that it works in that format.

EDIT: Evidently, Rare must have been playing around with compression schemes. It seems that there's THIRTY-TWO sub-routines! DKC has only four.
EDIT 2: Drat! I'm going to have to do a trace anyway, because they didn't put down what code calls the routine!

[Mattrizzle]

Let me add my two cents. In DKC3, most of the text and some sprite tilemaps/graphics are also compressed.

Funky Kong and the Brothers Bear are two examples of compressed sprites. The only things I know these two have in common are:

• They only appear in a single area. (Wrinkly, Swanky and Queen Banana Bird also fall into this category, but their sprites aren't compressed.)
• Both of them use layering techniques.

[Simion32]

Thanks for the heads-up, Mattrizzle. Once my port of the DKC2 decompressor is done, I will probably go straight to porting DKC3's.

[Gabriel]

Any ideas on how the dkc 2 levels are compressed? Do they even use 32*32 tiles?

[Simion32]

Everything uses the same compressor. It's like RLE, where you can have lengths of either uncompressed or compressed data. Except it's not that simple in DKC2, because there are more than just the basic 4 "types" of data that DKC has. DKC2 has 16 different kinds. There are just as many additional functions, but I haven't a clue what they do yet.

It is very likely that levels use 32x32 tiles - the tilesets are stored packed in the ROM, and are de-compressed into RAM when in use.

Because of time restrictions (school), I haven't had time to attempt coding a port yet. I did however manage to figure out where it's storing the data. I still need to find out how it gets a pointer to the compressed data's location.

[Raccoon Sam]

They only appear in a single area.]

As far as I'm aware, Funky Kong makes an appearance in the credits, in a Mill stage.

[Simion32]

Finally, I have developed a function to extract sprites!

This image is 256x256 pixels. The "Magic Pink" edges of the sprite can be viewed by opening it in MS-Paint.
Also, this may or may not be the first animation frame of a Kritter, I didn't take the time to check.

test.png (1.92 KiB) Viewed 267975 times

This is how a Kritter looks when extracted- notice the large amount of white-space. All sprites will be copied to bitmaps of this size, and then later the white-space will be removed.

All I must do now is work on the animation side of things and make a list of what palettes the animations use, and it'll be ready for extraction of sprites!

[Raccoon Sam]

Good job.

[Simion32]

Thanks... you don't bother to type much, do you?

Anyway, a piece of info for Qyzbud: I checked, and that is indeed the very first frame in the animation.This seems to mean that your level maps might be a slight bit off. Maybe this is because the game processes a frame or two while the camera is "scrolling" to the Kritter (in your mentioned method of 'scrolling' immediately to where they are at). Looking at this in the debugger suggests that the first frame is loaded while the Kritter is off-screen, and once within range the Kritter has already passed through one frame.

Oh, and...

$0D11 Determines the sprite used for an object without a default animation
$0D45 Behavior/Defeated Animation
#$01: Donkey Kong
#$02: Diddy Kong
#$05: Kritter
(...)

That's very strange, that a Kritter would be represented by $05. I had to use the value $E9, which is what it SHOULD have been (multiply that by 2 and get $01D2, then add that to the offset $3E8572 to get the location of the pointer to the Kritter's walking animation). However, I cannot find where this value is coming from exactly - how does $05 eventually translate into $E9?! I found the location of the suspect $E9 value in ROM by using the debugger, but I can't figure out how it knows to get this value.

Perhaps there is a table for "animation sets" that links several animations together into single "object animations"...

[Qyzbud]

I checked, and that is indeed the very first frame in the animation. This seems to mean that your level maps might be a slight bit off. Maybe this is because the game processes a frame or two while the camera is "scrolling" to the Kritter (in your mentioned method of 'scrolling' immediately to where they are at). Looking at this in the debugger suggests that the first frame is loaded while the Kritter is off-screen, and once within range the Kritter has already passed through one frame.

Hmmm, that's quite surprising to me. The view shifting technique I use doesn't actually 'scroll' the camera; it 'teleports' it... by which I mean the shift occurs entirely between one frame and the next. This is the first frame I see when using the horizontal camera position adjustment:

Baddies caught at spawning point with PAR code 7E1A62FF

DKC1-(U)-(V1.0)-[!]_00006.png (18.59 KiB) Viewed 267926 times

As you can see, the view shows the sprites before they are even assigned their correct tiles and palettes. Even still, it's quite possible that the animations have already advanced to the 2nd frame by the time the sprites are drawn by the graphics processor... I dare say you know a bit more about this than I do.

Well, excellent work again, mate. When you get this extraction function into the Resource Editor, I'll be able to further improve the precision of the maps.

[Simion32]

This seems to be the case, further investigation reveals that each image in the Kritter's animation last 2 frames.

To explain why I think this happens:

Spoiler!

Animation timers are at ZERO when the enemies are off-screen.

When the view teleports, and the enemies are then onscreen, their timers are then at ONE. The sprites are only updated every other frame, so you end up seeing a bunch of "junk" tiles. (But, it's only the sprite graphics that are updated every other frame. Their positions are updated on all frames.)

Then, after advancing one more frame, the game updates sprites. Since the timers are now at TWO, and two frames have already passed, it displays the second image for each enemy.

Now, I'll have to work out how the animation digits are retrieved (the ones used in object code are different than the true animation pointers), otherwise it may be difficult to determine the palette for each sprite.

[Qyzbud]

Hmm, well that does make a fair bit of sense. I'll have to update all maps when we get this worked out precisely.

Oh well, keep up the outstanding work.

[Simion32]

Well, that was fast. I found where all this seemingly "missing" data is most likely being stored. Not only does each object have its own code, but I failed to notice that they also each have their own object property bytes (this is from Gian's docs):

35859F - 3585CE | DATA | ____
35BA79 - 35____ | DATA | Object properties (14 bytes for each object)

There is some undocumented space in-between these two listings, which reminds me: I've been meaning to make some sort of visual ROM-Map, which will state specifically what is where and what type of data the bytes are, etc... I'm sure this kind of thing is (almost) like what you intended to put in the ASM Adresses section of the site...?

EDIT: Oh no, I seem to have misrepresented the animation digit... I had a whole buch of digits written on a peice of paper, and assumed that the animation digit I used was for the start of the animation... the starting frame of the Kritter is indeed the one you have on the maps... Sorry for getting all this mixed up; this sprite stuff is a lot to wrap your head around, if you know what I mean.

However, there is absolutely no guarantee as to whether the ZS-Patch actually does show the first animation frames or not. It might not with other sprites. Basically we'll have to wait for sprite-mapping to be done in this tool to see whether the ZS-Patch worked in that respect.

[Qyzbud]

Well, that's a relief in a way. I was a bit worried that all of this precision I'd been striving for was somewhat in vain. I'm glad that my technique may yet be accurate, and that it may even have helped you worked out what was amiss on your end.

This 'visual ROM map' you speak of is pretty much exactly what I want to host on the Atlas, from the sounds of it. Perhaps we could work to assemble this together? I've no problem crediting you (or anyone else) for efforts which lead to valuable content for the Studies & Docs section.

[Simion32]

OK, let's keep this progress barrel spinning! I've now got the DKCRE able to extract whole animations at once. Of course the DKCLB isn't going to use GIF for its animations, but here's a few example GIFs I threw together anyway:
(Please note that these GIF's are not guaranteed to be at the correct speed, they are just for demonstration...)

Spoiler!

Do a barrel roll!

BarrelRoll.gif (6.83 KiB) Viewed 267795 times

Spoiler!

Klump.gif (8.56 KiB) Viewed 267791 times

What I must do next is manually make a list of every animation (around 440 of them) and their corresponding palettes. After that's done, most sprites except beta ones should be extractable!

[Cyclone]

Awsome. Good work Simion!

[Simion32]

Because of its relative usefulness, and because I already had most of the code for it, I've decided to include a sprite viewing mode in the next release of the DKCRE. Here's a preview of what it will look like:***IMAGE REMOVED***Anyone Have suggestions on this GUI?
Also, I have already added a "File" > "Open..." function, so that you don't have to have your ROM file specifically named.

[BlueTronic]

Anyone have suggestions on this GUI?

The sprites' names might be nice.

...And all it's animations in the preview. Also, the sprite preview part of the window could be smaller, since it's so much bigger than the sprites. The extra space could be used for more information.

[Simion32]

all it's animations in the preview.

An animation viewer, eh? Will do that.

Also, the sprite preview part of the window could be smaller, since it's so much bigger than the sprites. The extra space could be used for more information.

Yeah, but the window can have variable width. That extra space is actually necessary, as all sprites are built inside a 256x256 area.

There's something I didn't mention - the window can be resized to the dimensions that are needed, so there's no need to worry about running out of space. In fact, the window-resizing is animated so that it doesn't look as "abrupt" going from one size to another.

[Cyclone]

Once the extractor is able to extract sprites how will it do so? Will it save each sprite frame as an individual png frame or will is put them all into one sprite sheet. It would be cool if you had an option to output them as an animated gif but this is not that important.

[asmodeus]

OK, let's keep this progress barrel spinning! I've now got the DKCRE able to extract whole animations at once. [...]

Wow! I'm looking forward to the next version of it.

[Simion32]

Once the extractor is able to extract sprites how will it do so?

It already can! That's how the sprite viewer came about; the extraction function was structured so that I could use it for sprite viewing also.

They will all be outputted to individual frames, one PNG for each color of a sprite (Krushas will have twice as many PNG's dumped since they use two palettes).

Oh, and GIF isn't really an option since I'd have to pay royalties to use it (the GIF compression is trademarked or something).

However, do I plan on designing a sort of "Sprite" format to combine all the data for animations into single files (which will be used in the Delta Game Engine). This will make things more organized.

[Qyzbud]

These are some great new advancements, I'm looking forward to the next release.

I support the precision and simplicity of the current sprite output format (single frame 256px² PNG files, with palette variants)... but just for the record; GIFs are free to use now-a-days, as the LZW compression patents expired back in 2003/04. (Reference: 'Graphics Interchange Format' article, Wikipedia)

[Simion32]

So GIF is free to use now? I never gave it a second thought.

Of course, using GIF's would most likely ruin the precision of the images and/or make things overly complicated. Also, remember that I want support for images with any amount of colors, not just 256 colors per image. That is one reason I'm not using a low-color palette mode to render graphics.

I'll throw in another announcement that I neglected to post: I also plan on adding a Level Viewer too. With integrated object/banana viewing, of course!

I can't think of anything else at the moment, except that the tool is going to have an improved dialog interface (like the extraction options dialog).

[Kiddy14]

You can use APNG... is just like PNG except it allows to be animated; though it's not so supported by every browser and PC (Windows included)...

Spoiler!

See? It's a PNG except it's animated.

[Simion32]

What?! PNG just gets better and better the more I'm around it!

I still am not going to use an animated format such as this, because I need to store hit-boxes and SFX triggers along with the images in these animation datafiles.

The main idea is to keep it simple yet powerful.

[asmodeus]

You can use APNG... is just like PNG except it allows to be animated; though it's not so supported by every browser and PC (Windows included)...

Spoiler!

See? It's a PNG except it's animated.

What programm do you use to edit APNG?

[Kiddy14]

I just downloaded Simion32's Barrel Roll Gif and used this program to convert it to a APNG...

Well, I consider APNG to be the least option to be used; it's not supported by Windows, and just 4 browsers support it xD
How many colors does the sprites can have? I thought there were only up to 256 =S

[Simion32]

Each sprite in DKC only has 15 colors plus transparent. The SNES can only display 256 different colors at a time (one reason why color glitches happen with too many different objects onscreen).

I want to allow for custom sprites and get rid of color glitches in the DKCLB, so the sprites shouldn't be extremely limited in color. The "gnawzooka" is a good example of this - it uses a little less than 32 colors.

The point of high-color is to be able to put any sprite anywhere without it glitching up.

[Qyzbud]

Of course, a 'Gnawzooka' could easily be rendered even with the 16 colour limit... Rare often combined multiple sprites to get around palette limitations - Funky's surfboard in DKC is a separate sprite from Funky himself, and Klobber and his barrel in DKC2 are also separate sprites. Object pairs like this were used fairly extensively throughout the DKC trilogy, and in most cases (such as the ones I've mentioned), the sprites were only ever used/shown in combination, rather than individually. Most 'labelled' barrels (all DK barrels, DKC2's steerable barrels, DKC3's warp barrels, etc.) make use of this technique.

...but having true colour is always nice.

[asmodeus]

it's not supported by Windows and just 4 browsers support it xD

I use windows and firefox any my browser displays APNGs correct.

[Kiddy14]

15 colors? O_o
I see why Rare combined the sprites, 15 colors is just not enough; I believe they used the same technique with the DK Barrels.

The SNES can only display 256 different colors at a time (one reason why color glitches happen with too many different objects onscreen).

So there's where I got the 256 thing; so I assume when the game surpaces the 256 color limit, it changes sprites colors to ones already used. Now I get why some levels have enemies of similar colors of the backgrounds, like Slipslide Ride has blue kritters and zingers.

[BlueTronic]

I want to allow for custom sprites and get rid of color glitches in the DKCLB, so the sprites shouldn't be extremely limited in color.

Just don't take out all the awesome color glitches. It's just that glitch that makes the objects red and yellow when you make hacks, right? Color glitches like the one with Rambi in Oil Drum Alley will still work, won't they?

[Simion32]

Just don't take out all the awesome color glitches.

Most likely NOT possible because palettes won't be used. Of course the glitch could be "emulated" in a sense, but there is no way to tell what on earth would happen since it is a glitch... the results are unpredictable.

I could emulate the glitch, but it would be rather cumbersome to extract altered sprites just to make a glitch that has several hundred possibilities.

I wouldn't bother doing the colors half, but I might be able to do the actual mechanics of the glitch (like the DK-rides-DK one in Jungle Hijinxs). Sorry, but I don't think it's worth the effort to try to include the colors part.

Really, I'm 50/50 on including glitches. I'm stuck in the dilemma of "accuracy true to the game and cool-factor" VS. "glitches are bad/unpredictable"...

[Qyzbud]

I personally think emulating DKC's glitches is a bit of a silly idea. Maybe something like that could be added as an Easter egg once everything else is complete, but this kind of thing would certainly complicate the development of DELTA and the DKCLB. Besides, glitches are practically unavoidable when it comes to programming complicated software; we're sure to have a handful of new bugs to marvel over, whether Simion adds them intentionally or not.

[Cosmicman]

I'm sure there will be more than enough glitches naturally, which is not a bad thing, we all love glitches. Looks like you are almost done with the extraction part of DKC1 or maybe I'm mistaken , what else is there left to extract ?

[Simion32]

Announcement: The Bitwise File Access Routines are done!

These functions will allow the DKCLB and DKCRE to save/read values in level files using any number of bits. I guess you could say that I've broken the byte barrier, since I am no longer limited to using full bytes to store data. Here's the main two things this will accomplish:

Integers can be anywhere from 1-32 bits, and strings can be compressed when extra punctuation is not needed (for example you can store an author's name using only letters, numbers, and spaces. Add it up... 26 capitals + 26 lowercases + 10 numbers + space + (null character) = 64. This is perfect for using only 6 bits per character!). Strings can also be stored without being aligned to bytes, just like the numbers can.

I have already begun work on a level file generator, and the results are looking quite promising!
Here's what I got when I compacted Oil Drum Alley:

Normal Tilemap:
$2A00 (10,752 bytes) (14 bits for each tile number)
Compacted Tilemap:
$1C5E ( 7,262 bytes) ( 9 bits for each tile number)
[Compression Ratio: 11/16]

As you can see, this method saves a considerable amount of space compared to Rare's original format.
EDIT: Although I probably can't beat WinRAR's compression, the point is to save as much space as possible without using an actual compression format such as RAR or ZIP. Using one of those compression formats would heavily overcomplicate the whole process.

Looks like you are almost done with the extraction part of DKC1 or maybe I'm mistaken , what else is there left to extract ?

Mostly just physics data and some things that cover the finer "details" of the game. In other words, I've now extracted most of the major data, but there are still a few smaller things that need to be extracted/hacked.

[Cyclone]

Good stuff.

Sorry to sound dumb but are you compressing the actual rom data and reinserting it back into the rom or will this new code just be used for the level builder?

Oh and what is bitwise? sounds familier.

thanks

[Qyzbud]

Good show, old chap! This is all sounding like a technical triumph. I like how in some ways you are 'beating Rareware at their own game', so to speak. The efficiencies of your level layout data and text info storage are quite impressive. I wonder if some basic punctuation is necessary, though? Could a hyphen or a full stop be available in lieu of the null character, or is such a character necessary? I guess we could always remove a few of the less useful letters to make room - like Q, y, z... -er, wait a sec!

[Simion32]

I wonder if some basic punctuation is necessary, though? Could a hyphen or a full stop be available in lieu of the null character, or is such a character necessary? I guess we could always remove a few of the less useful letters to make room - like Q, y, z... -er, wait a sec!

The null character is used to detect the end of the string; in using it you won't have to define a string's length and it won't be limited by a maximum amount of characters.

Of course, 7-bit string compression will be a better choice for things that need punctuation. Let's see...

~0123456789 ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz
.!@#$%^&*()_[]{}/\|?,<>-=+;:'"~¿¿¿¿¿¿¿¿¿¿¿¿¿¿¿¿¿¿¿¿¿¿¿¿¿¿¿¿¿¿¿¿¿
(The first ~ represents the null character, and ¿ means that the character is undefined.)

There seems to be quite a lot of characters left to use (33 to be precise). It's anyone's guess what those could be used for (I don't think we need upside down question marks )... any suggestions? Perhaps they could be dual-tile characters (a letter plus a space) like rare used in DKC's text. I can't use any special symbols (I've only got the ANSI set to work with here), so that might be a good idea.

Sorry to sound dumb but are you compressing the actual rom data and reinserting it back into the rom or will this new code just be used for the level builder?

I'm "compressing" the ROM data and putting it in Level Builder files (I.E. the data is compressed, and stored in the files which will be used to store levels). This code is for the DKCLB levels only. Doing something like this in a ROM would be insanely difficult.

Oh and what is bitwise? sounds familier.

Something like reading it a bit at a time (0's and 1's). Try looking it up on Wikipedia, it should have a decent explanation.