DKC Atlas Forum

[Myself086]

I've been working on a DKC1 editor since April 26. Current project name is DKCcreator but the name is subject to change.

I don't have a precise end goal for this project but here's what it can do so far:
- Edit tiles of any levels including water and ice cave.
- Draw single tiles, fill tiles of a selected region, copy/paste, paste repeated patterns, auto complete tiles by link logic.
- Undo button but no redo yet.
- Zoom in/out.

Feel free to comment or request a feature.

[Raccoon Sam]

Sounds great!
Some requests:
• Edit level length
• Map editor (edit paths, level names, level destinations and the map tiles themself. Maybe a single 256x224 image importer that auto-calculates palette/attribute bytes using Superfamiconv?)
• Numeric input access for sprites/bananas/scroll boxes.
• Dialogue editor

Some questions:
• What is the state of the project as of now?
• Is the project open source / on GitHub?
• What language is the program being programmed in?
• Got any screenshots?

[Myself086]

• What is the state of the project as of now?

I posted "what it can do so far" as in, they're all implemented now and nothing else.

• Is the project open source / on GitHub?

I've never been into open sourcing my code but maybe I'll change my mind.

• What language is the program being programmed in?

C# and rendered by OpenGL.

• Got any screenshots?

Here's one from today.

[Cody]

Looks good! I'm always stoked to see more DKC hacking news.

[Raccoon Sam]

Looks super!
Keep us updated!

I've never been into open sourcing my code but maybe I'll change my mind.

Well, it's your code so you have no obligation to share it with anyone, but for the benefit of the collective, Open Source projects are always better

Also, maybe a clipboard/scratchpad? It's less cluttered to assemble tile clusters somewhere where there's lots of room and bring them in the actual level when done.

[L_Sky]

Woahhh it looks amazing !!!
Can we try it so far? I'm really interested in editing tiles of water and ice levels.

Request : editing water/ice levels (enemies, bonus etc...).

Thanks a lot !!!

[Myself086]

I just started looking at entities. Some of you may call them sprites but this latter word is used for the visual object. An entity is an object that may or may not be visible and has its own sets of rules.

One very interesting thing about entities in DKC is that each one has custom scripts to set their properties. They aren't set at the assembly level and their overall structure looks very flexible and easy to understand.

Each script may or may not describe the entity entirely, you can have a blue print of a generic object such as a barrel. Then have a second script describing its appearence and calling the first script. Then have a third script changing where it's shooting at and how far then call the second script.

There is also some garbage data in these scripts so it opens the possibility of adding new ones without deleting old ones. Either way, it opens the possibility of changing enemy paths or behaviors. Visible entities such as a DK barrel could have the ability to change camera boundaries so if you lose this DK barrel you can no longer view some parts of the level. I don't know what else is possible yet but I have to go through and name all the hex values.

Entities are now visible on the map as purple squares for now, I won't manually put a sprite on each one because it would save time for me to work on these scripts. The editor can just read the script and figure out what sprite to show from there.

Unfortunately, entities aren't working for water/ice cave levels yet. I'll look into this after scripts.

Woahhh it looks amazing !!!
Can we try it so far? I'm really interested in editing tiles of water and ice levels.

Request : editing water/ice levels (enemies, bonus etc...).

Thanks a lot !!!

I want to release it around May 15. I want it to be at least in a better state or offer more than just editing level tiles. Your request will have to wait until after it becomes possible for horizontal levels because vertical levels have almost everything encoded differently.

[Raccoon Sam]

Full access to entity scripts seems like a holy grail in DKC hacking. With what we have now (dkedit, dkcre) it feels wasteful seeing a huge list of sprites that are only marginally different but being unable to actually edit those subtle differences. I can choose a barrel that shoots 5 tiles upright or 7 tiles upright, but if one that shoots 6 tiles is not on the list, I'm out of luck! Hopefully your entity editor opens a whole new world of possibilities.

Come to think of it, how far can the pointers reach? If there's a lot of free space somewhere (after expanding the ROM, in the very last case) I'd imagine "custom entities" wouldn't be too hard to implement, right? Just have the original sprites as they are, but if the user chooses to do so, they could make a 'copy' of a sprite but with a new set of scripts.

EDIT: Better yet, make a spec for a file format for custom sprites and allow for import and export – the program would only need to push the sprite data in and recalculate pointers. Implementing a "purge unused sprites" command would bring a lot of space to the ROM too.

[Myself086]

I just made a script reader as seen in the screenshot below.

This is the barrel on the top left corner of 1-5. I only tested a few different changes on this one. Barrels can shoot in 16 different directions determined by the highest 4 bits where you see direction. Distance seems very flexible for having a value of 0x2a20, I tested minimum and maximum distance. Setting the "Camera" to 0 will constantly show you the bottom part of the map following the terrain up and down.

I vaguely described these 3 scripts in my last post. The one on the left is for this specific barrel, it then calls the script shown in the middle to set sprite which then calls the script on the right. The last script seems to be for generic barrel cannon. If you really want to be efficient with these barrels, you could just place a few lines in the main script and call another script for whatever variables never change.

Come to think of it, how far can the pointers reach?

The pointers only have access to a LoRom bank (32 kilo bytes) and this bank is full, but seeing how far these calls are (0xb5cbaf to 0xb5aabb) and potential to optimize them somewhat, we may not have to worry about space. But in the case we do need more space, there's an entire unused byte in the low bits of the first word for Call. I have no idea if changing bank breaks the code. I don't want to worry about details too much at the moment but I'll keep these ideas in mind. I really like the import/export file idea.

The line I highlighted in the third script is useless.

Try these cheats as proof of concept: B5CBC6FF, B5CBBEC0
This will affect the barrel on the top left corner of 1-5 and every other barrel of the same type in other levels (if any).

[Quaraage]

Hi.
In fact, I analyzed sprite command for sdk/ dkc and I got many useful information, so I'd like to share these.

$8000
End of sprite definition. This command has no parameter.

$8100 XXXX
Load sprite animation XXXX. This command require one parameter and it is the index of sprite animation, not an address.

$8200 XXXX
Inherit sprite definition from $B5:XXXX. This command require one parameter and it is absolute address of inherited sprite.
Multi-step inheritance and multiple inheritance are also possible.

$8300
NOP. This command has no parameter and doesn't do anything.

$8400
Set sprite state rightwards. This command has no parameter.

$8500
Set sprite state leftwards (H-flip). This command has no parameter.

$8600
Set sprite state upside down (V-flip). This command has no parameter.

$8700
Set sprite state leftwards and upside down (H,V-flip). This command has no parameter.

$8800 XXXX
Set sprite color palette XXXX. This command require one parameter and it is sprite palette address.

$8900
Set sprite priority 0. This command has no parameter.

$8A00
Set sprite priority 1. This command has no parameter.

$8B00
Set sprite priority 2. This command has no parameter.

$8C00
Set sprite priority 3. This command has no parameter.

$8D00
[UNKNOWN] not used in original DKC. This command has no parameter.

$8E00 X000
Set OAM state. XOR X and hi 4 bits of variable $0C69. Low 12 bits are not effective. This command requires one parameter.

$8F00 XXXX YYYY
[UNKNOWN] Coordination control? Move this sprite relatively based on current active Kong's state(?)
If H-flipped and XXXX (YYYY) & 0x4000 != 0, add -XXXX (-YYYY) instead.
This command requires two parameters. First parameter is for X, and second is for Y. Each data is signed word.

$9000 XXXX YYYY
[UNKNOWN] Store YYYY to variable XXXX. If sprite is H-flipped and YYYY & 0x4000 != 0, store -YYYY instead. This command requires two parameters.

$9100 000X
Change sprite palette index for this sprite to X. This command requires one parameter and it is sprite palette index in VRAM. Valid value is 0 - 7.

$9200 XXXX YYYY
[UNKNOWN] Coordination control? Move this sprite relatively based on current active Kong's state(?)
If H-flipped and XXXX (YYYY) & 0x4000 != 0, add -XXXX (-YYYY) instead.
This command requires two parameters. First parameter is for X, and second is for Y. Each data is signed word.

$9300
[UNKNOWN] Coordination control? This command has no parameter.

$9400 XXXX YYYY ZZZZ
[UNKNOWN] If there are sprites which have control code XXXX, set hi 11 bits of sprite state from the first sprite which has control code XXXX and discard low 5 bits. YYYY and ZZZZ are ignored, and set control code XXXX to this sprite.(???)
Else, do many operation (unknown).
This command requires three parameters.

$9500 XXXX
Execute code on $B5:XXXX. This command requires one parameter and it is absolute address of assembly.

$9600 XXXX
[UNKNOWN] not used in original DKC. This command requires one parameter.

$9700 XXXX
Set OAM state . Hi 4 bits are only effective. This command requires one parameter and it is sprite OAM state.

OAM state (variable $0C69/ changeable by command $8400, $8500, $8600, $8700, $8900, $8A00, $8B00, $8C00, $8E00, $9100, $9700)
vhoopppn cccccccc
v: V-flip flag
h: H-flip flag
oo: sprite priority
ppp: sprite palette
n: name table
cccccccc: first tile number for this sprite

[VideoViking]

$8F00 XXXX YYYY
[UNKNOWN] Coordination control? Move this sprite relatively based on current active Kong's state(?)
If H-flipped and XXXX (YYYY) & 0x4000 != 0, add -XXXX (-YYYY) instead.
This command requires two parameters. First parameter is for X, and second is for Y. Each data is signed word.

$9000 XXXX YYYY
[UNKNOWN] Store YYYY to variable XXXX. If sprite is H-flipped and YYYY & 0x4000 != 0, store -YYYY instead. This command requires two parameters.

$9200 XXXX YYYY
[UNKNOWN] Coordination control? Move this sprite relatively based on current active Kong's state(?)
If H-flipped and XXXX (YYYY) & 0x4000 != 0, add -XXXX (-YYYY) instead.
This command requires two parameters. First parameter is for X, and second is for Y. Each data is signed word.

$9300
[UNKNOWN] Coordination control? This command has no parameter.

$9400 XXXX YYYY ZZZZ
[UNKNOWN] If there are sprites which have control code XXXX, set hi 11 bits of sprite state from the first sprite which has control code XXXX and discard low 5 bits. YYYY and ZZZZ are ignored, and set control code XXXX to this sprite.(???)
Else, do many operation (unknown).
This command requires three parameters.

Quaraage, do you think any of these codes could be tied to object scripts? For example, the Manky Kongs that can throw barrels. In the DKCRE application, placing a Manky Kong sprite alone can cause memory conflicts because there is no controller for the barrels. Manky Kong will continue to toss barrels so even if you run off the screen for the action to "sleep" or halt.

[Raccoon Sam]

Great job, Quaraage!
Do you think it would be better to leave a script editor as-is, giving the user full access to writing bytes, or make a pseudo-language/mnemonic interpreter?

[Myself086]

Thank you Quaraage, now I can focus on other things!

Great job, Quaraage!
Do you think it would be better to leave a script editor as-is, giving the user full access to writing bytes, or make a pseudo-language/mnemonic interpreter?

I want to make a pseudo language. Also the ability to edit some of these variables with graphical representation. I am currently in the process of extracting scripts and taking their calls (command 8200) out of them so they can be rebuilt to something that will at least match the size of the original or smaller.

Every commands aren't using the lower 8 bits. Any script starting with a command can be merged with the End command of a previous script. (00 80 00 82 -> 00 80 82)
Rewriting the assembly isn't out of the question.

One thing I noticed about the variables is that some of them have different meaning based on the one at 0d45. We'll have to figure them out one by one.

[Quaraage]

Video Viking,
I think these command don't have any relation for that issue, because sprite commands affect to all sprites with same effect. I guess sprite assembly of Manky Kong lacks dispose function, so they cannot be unload, but I hasn't check assembly of Manky yet.

Myself086,
Indeed, sprite commands don't use low byte, but all sprite are interpreted in word units in the sprite interpreter. Therefore, it needs to rewrite sprite interpreter assembly.
Variable $0D45 (in SDK(J), $0D57) is sprite status code. This is an index of array pointer of sprite assembly. Status code 0 means that this slot is free RAM.

By the way, also the cases Manky Kong isn't unloaded, memory conflict won't occur. Each barrel thrown by Manky occupies sprite slot, and then, if the number of barrels increases and there is no more free slot, the game just stops loading a new sprite. However, barrels thrown by Manky can unload normally, so this will not happen unless you put many Manky in one place. Even if Manky throw barrels from very far away, these barrels are unloaded and these slot are released immediately, unless using Manky and sprite "0x000C-0x0000" together in parameter 0x0005 sprite sets. ("0x000C-0x0000" is like to sprite 0x0B10 in DKC2) DKC has 11 slots for normal sprites, and 12 slots for EFX sprites.

For commands I marked as [UNKNOWN], I will continue to investigate.

[Quaraage]

According to my survey several years ago, sprite status codes are following

Spoiler!

0000:DISPOSED (FREE SLOT)
0001:DK
0002:DD
0003:
0004:
0005:Kritter
0006:Klump
0007:DD's hat
0008:Hit effect
0009:Rambi
000A:Expresso
000B:Winky
000C:Enguarde
000D:Squawks
000E:Necky
000F:Smoke
0010:Coconuts of Necky
0011:
0012:Goal (coaster)
0013:Exit
0014:Entrance
0015:Banana
0016:Lightning of KONG letter
0017:Hit effect
0018:Animal container
0019:Zinger
001A:Klaptrap
001B:Half tire
001C:Tire (low bounce)
001D:portable tire
001E:portable dark tire
001F:tire
0020:Spinner
0021:
0022:Iron barrel
0023:Barrel
0024:Old barrel
0025:OIL
0026:DK barrel
0027:TNT
0028:OIL
0029:Slippa
002A:barrel debris
002B:
002C:Soil filled with items
002D:
002E:
002F:Army
0030:Straight rope
0031:Rope
0032:Explosion
0033:
0034:Baloon
0035:Explosion
0036:Snow
0037:Gray smoke
0038:Cannon barrel
0039:unstable platform
003A:
003B:
003C:
003D:
003E:
003F:
0040:
0041:
0042:
0043:
0044:
0045:Token(?)
0046:Krusha
0047:unknown
0048:Elevator generator
0049:
004A:Continue barrel
004B:Mini Necky
004C:Dumb drum
004D:Gnawty
004E:
004F:Necky
0050:Manky
0051:Coaster
0052:
0053:Chomps
0054:Chomps Jr.
0055:Bitesize
0056:Squidge
0057:Croctopus
0058:Lift
0059:
005A:Light
005B:
005C:Fuel
005D:Hidden camera
005E:Coaster
005F:
0060:
0061:Clambo
0062:Perl
0063:Switch
0064:Switch barrel initialize/ Light flashing
0065:Lightning of continue barrel
0066:Star of DD's damage
0067:Lightning of continue barrel
0068:Rockroc
0069:Play SE
006A:Goal (Normal)
006B:Goal (Sea)
006C:Bosses/ Bonus/ Bonus win/ Bonus failure
006D:KONG slot
006E:Barrel
006F:Entrance wall
0070:Bosses/ Weapons of bosses/ Bonus
0071:Red gnawty
0072:Timer
0073:Arrow sign/ EXIT sign
0074:Golden Banana
0075:BG of King K.Rool
0076:Huge token
0077:Credit
0078:Gray Krusha

[Myself086]

Does the order matter for any commands from 8000 to 9700? Like setting some variables beforehand.
I want to reorder them by having the most common commands at the end so other scripts can inherit from somewhere in the middle of another script to save space.

[Quaraage]

Myself086
Usually, the order of commands is not very important, but if you have sprites that are written in an unusual command sequence, it probably should have been done with some intention.
For example, it is easier to understand such cases that using additional control by command $9500. Additional assembly may cause different result by sprites variable values.

[Myself086]

Come to think of it, how far can the pointers reach? If there's a lot of free space somewhere (after expanding the ROM, in the very last case) I'd imagine "custom entities" wouldn't be too hard to implement, right? Just have the original sprites as they are, but if the user chooses to do so, they could make a 'copy' of a sprite but with a new set of scripts.

Your comment about expanding the Rom inspired me to restructure the original data. It's taking a lot more time than expected but it'll be worth doing.

The Rom is now 8mb instead of 4mb, the editor no longer edits the Rom directly but instead you create a project with independent source files that get compiled into the Rom. The only down side of moving data around is not being able to use other editors anymore. On the plus side, you can break almost every original limitation for each level. Here are some of the new limits (some are subject to change so I post the lowest expected limits):
- Levels can be resized up to 1024x16 (horizontal) or 64x256 (vertical).
- Up to 8191 entities per level.
- Up to 21845 entity scripts.

Water and ice cave levels aren't fully supported. No camera yet, No world map yet.

I'll post again when something interesting comes up.

[Raccoon Sam]

The Rom is now 8mb instead of 4mb, the editor no longer edits the Rom directly but instead you create a project with independent source files that get compiled into the Rom.

This is very good news! I was just thinking about this the other day and wished that more editors did this. Especially Game Boy games where each bank is super tight already, it would make much more sense to restructure the original mess.
I think a hacker called Parasyte wrote some philosophy about similar things regarding non-destructive ROM hacking. Although it's intuitive to hack ROMs by finding the data and editing it where it stands (and build editors around this idea) it's much more beneficial to find out all data, get it out, edit that data and re-insert it back better. The go-to editor for Super Metroid has everything integrated and while it works, I'd much rather have a powerful exporter/importer and edit the levels in a separate editor that doesn't worry about pointers constantly, and only when my is work done, the re-importer/recompresser figures out where stuff goes and gives me a neatly structured ROM with lots of space to spare.

The only down side of moving data around is not being able to use other editors anymore.

The least you can do is generate verbose logs and/or include a readme that explains what your editor does to the ROM, namely where the new data is shuffled around to.


Thank you so much. I'm super excited!!


EDIT: one more feature request, low priority:
The original DKC has variety between cave levels by using the same tiles but with different palettes. Editing these palettes manually is easy but extremely tedious. However, if the same color math is applied to each color simultaneously it gives great results.
So maybe have a global HSL editor with instant preview, like this:
https://youtu.be/Y_qklrXWbrw

Or a Illustrator-esque color refiner where each color is linked to the last:
https://youtu.be/6BqWOkBnccw

(these are quick and very dirty demos straight out of professional image authoring software, but as far as I understand the color math behind it isn't rocket science)

[Myself086]

I believe the game supports the effect shown in the first video internally, look at the palette gradually changing at the end of 1-1.

Editing the 8mb Rom isn't recommended because the editor DOES NOT read 8mb Roms. It can only read the original 4mb and extract data from them. Once the Rom is recompiled, some of the data has different meaning than the original with additional assemblies to ease the process of compiling Roms.

I could create separate files for palettes. Either as a known palette file format or a 16x8 bitmap. Custom sprite palettes also come to mind. Every original palette has groups of colors close together and I'm sure you'll be able to pick what range of colors you want to change instead of everything at once.

Here's a screenshot I had for the main 3 sprite palettes: Banana, Donkey, Diddy.
Left most color is always invisible and games tend to set them differently on occasion.

[Raccoon Sam]

Speaking of files, what are all the files that get exported in the end?
I'm thinking
• levels*
• sprites*
• palettes
• tilemaps
• overworld maps*
• banana formations?
• individual SPC songs?
• credits/dialogue/level names?

*) There's probably no one-file solution because "levels" alone are nothing without their enemy maps, banana maps and camera coords. Likewise, "sprites" is a super vague term because their graphics alone do nothing – they need the entity scripts and whatever controls their behaviour, palettes, animation et cetera.

[Myself086]

Each file created by the editor may contain multiple data blocks to be compiled into the Rom.

DKCcPJ base project file containing file names, doesn't write anything to Rom even though it can.

DKCcMAP file will have 3 blocks: tile map, entities, cameras. I'm not sure how bananas work at the moment. Level names are stored in a different way compared to the original. A list of maps will be stored at the beginning of bank 7D with information such as: tile set index, music ID, spawn location, base level ID.

DKCcTS, tile set file containing compressed 8x8 tiles, uncompressed 32x32 tiles composed of 8x8 tiles, collisions, a link list (may become a separate file soon). A list of tile sets will be stored at the beginning of bank 7C.

DKCcES, entity script file. Scripts themselves can be named on the editor but their names aren't transferred to the Rom. This one breaks down into a lot of blocks. Let's say you have 2000 scripts, the script compressor will find repeated command lines and put them together into a new script. One command line can be used to inherit from this newly created script from and to any given point. So your 2000 scripts may be compiled into ~3000 blocks in total while still saving space over writing scripts in their raw format. Smallest possible block from this file is 10 bytes.

DKCcWM, single file for world map. I won't comment on this one because I haven't worked on it.


Here's how the compile process works:
- Step 1, ask every file objects what amount of space they need for each block. This is done by compiling the blocks with null pointers for better programming efficiency at the cost of nearly doubling the compile time (which is already very short).

- Step 2, sort all the block sizes requested in descending order and all the available banks in ascending order. You'll have a lot of 64 kb free banks and some weird sized banks. The compiler will take the largest requested size and place it in the smallest bank it can fit in then repeat the process for every blocks. This isn't optimal but it's good enough for now. Once this is done, the compiler will send addresses for each block.

- Step 3, tell every file objects to compile and return arrays containing the final data. The compiler then verifies block sizes in case of errors before writing to Rom.

[Raccoon Sam]

Sounds great

You should also note that the format used in the world maps' tilemaps is (likely) the same that is used in every other tilemap as well – the game over screen, the title screen image, the 'choose a file' dialog, the "copyright 199X Nintendo" screen and the "Nintendo presents" screen.
Editing these isn't top priority, of course, but giving the user an easy method to at least update the title screen would make a lot of sense, and once that's done, the same code can be reused to edit all the other tilemaps as well as long as you know the address of the map and the palettes used.

The introductory Rareware logo is a royal pain however. Unless my memory fails me right now, its graphics are stored in four different places (and in four different formats, including 8bpp linear) in the ROM and you must edit each to make it change.

You may be also interested in this information regarding the only* sprite in the world map: http://www.romhacking.net/forum/index.php?topic=23777

*) excluding the kong/kremling heads and the paths

EDIT: If you can get in touch with Mattrizzle, he likely knows some very valuable things regarding the game's innards you might want to know when developing the editor

[Myself086]

I found the addresses for world map backgrounds, they're all very straight forward but I don't want to make a tool to convert them. If there exists a tool to convert bitmap to 121 color, only use 8 palettes of 16 colors each with 1 shared color and only use 1 palette per 8x8 then I'd rather not try. I just started looking at them since last time I posted.

Thank you for pointing out the galleon being a sprite.

Interesting that you're using a Mac. I want to know if it runs on Wine or how close I am to compatibility with Mono project. I never use DirectX for anything just in case I need to port my code to other platforms.

I made my own emulator back in 2013-2014 (unreleased). I have my own built-in disassembler that only requires entry points and it figures out the entire structure of a function, labels every destinations of jumps and branches, automatically recognize status of MX flags even when the code isn't executed. I also made a built-in assembler. I can put break points on almost anything. If I'm ever missing a tool I can just make it. I'm having no problem finding whatever address I need. I haven't used any outside source information for these addresses yet.

I will need some help to identify all of the entity variables. Many of them have different meaning per entity. It isn't difficult but it's gonna take a lot of time.

I may contact Mattrizzle after I wake up.

[Raccoon Sam]

Your attitude sounds very professional, determined and inspiring. Keep up the good work!
I'm a Mac user, yes. Generally Mono apps works just fine, but the most common bugs are with Windows-related GUI things, I think. Usually ranging from "that doesn't look right" to downright abrupt crashes without warning. I will be happy to test the program if need be, to ensure cross-platform compatibility at least.

I'm not sure if such a bitmap conversion tool exists, but generally speaking, if it's not here it's unlikely it exists at all.

Also, when I was searching for the specifics regarding the Galleon sprite, I found a massive pointer array and while I was screwing around with overwriting the values, I was able to change the boombox in the intro to a frame of dancing Donkey Kong. Screwing around even more I was able to change the galleon sprite itself to the dancing DK too. It is likely that this huge array is a list of pointers to every single sprite's graphics/animation frame declaration. You might know this already, though (and if you don't, sorry, I never wrote the address of the array down... but then again you will probably find it in an eyeblink )

[Myself086]

I've been thinking about the image conversion process but because it's only low priority I'll just post the general idea of how it could be done:
1) Find which color is present within the most amount of tiles to determine the shared color.
2) Take all 64 colors of each tile and identify their HSL ranges for comparison.
3) Compare each tile's HSL range to see how close they are together.
4) Pick 8 tiles that have the lowest HSL range difference with any other tile. Also keep an array indicating which of the 8 selected tiles matched better for every tiles.
5) Create 8 new HSL ranges based on the palette array you made during step 4.
6) Pick 15 colors farther away from each other within each of these 8 ranges.
7) Apply these palettes to each tile by choosing closest matching color.

I finished writing the code to extract and show world maps, after zooming into various parts I just realized how badly encoded world 1 is.

A few things I want to point out about world map editing plans:
- The user will have no control over level ID.
- Some aspects of level links and type of level are hard coded, this will change.
- No map warps.
- More world maps can be added, the game supports up to 256 already.
- No up/down screen transition.

[Raccoon Sam]

Sounds like a solid plan!

- No up/down screen transition.

I'm not sure what you mean by this though.. are you talking about the brief fade out/in effect when you cross the map border, like from Reptile Rumble?

[Myself086]

Sounds like a solid plan!

- No up/down screen transition.

I'm not sure what you mean by this though.. are you talking about the brief fade out/in effect when you cross the map border, like from Reptile Rumble?

Yes, crossing the map border only happens horizontally. Writing code to do this vertically is too low priority in my opinion.

[Raccoon Sam]

I see. Not a big deal really – a clever map designer can circumvent this limitation anyway by designing the map parts just the right way.
One more thing; can you edit the level layer mode properties? The caves, for example, have the standard 4bpp level tiles and a 4bpp background plus an additional 2bpp foreground in front of everything, while Jungle Hijinxs has 4bpp level tiles, 4bpp background and an additional 2bpp far background and an HDMA gradient (no foreground at all). Pretty sure some snow levels have an animated 2bpp foreground snow layer too.
How much can we tinker with these level properties and is the user limited to just changing what foreground/background type combo to use in the particular level or are they able to actually use a custom new tilemap instead of overwriting the old ones?

[Myself086]

I see. Not a big deal really – a clever map designer can circumvent this limitation anyway by designing the map parts just the right way.
One more thing; can you edit the level layer mode properties? The caves, for example, have the standard 4bpp level tiles and a 4bpp background plus an additional 2bpp foreground in front of everything, while Jungle Hijinxs has 4bpp level tiles, 4bpp background and an additional 2bpp far background and an HDMA gradient (no foreground at all). Pretty sure some snow levels have an animated 2bpp foreground snow layer too.
How much can we tinker with these level properties and is the user limited to just changing what foreground/background type combo to use in the particular level or are they able to actually use a custom new tilemap instead of overwriting the old ones?

There are some addresses in the high range of bank 7E and low 7F for these things, I haven't looked at them too much and each level has its own hard coded method of setting them. What I'm gonna do for now is say I want a level to act the same as original 1-4, maybe 2 or 3 levels to act the same as stop and go station. There are 2 calls being made to set these things so I'm assuming you could have a cave with a jungle HDMA backdrop. Palettes are set in one of these 2 calls which I haven't looked into either. Tile sets will compile into the Rom at new addresses as well as their collisions and while there is a file for them (DKCcTS) I have no plan to make editing tools for tile sets. The 4bpp background is actually its own level but limited to 512x256 pixels as far as I know, you can see an example in the top left corner of the first screenshot I sent. I don't know where the 2bpp background comes from.

I'm starting to feel some exhaustion from this project. I may put it on the side soon for some time.

[Raccoon Sam]

Take your time, it would make no sense to rush it out and make something you're not satisfied with and end up burnt out.
We've got all the time in the world, and after all this is only a no-profit hobby to you – the lone developer.
Everyone here appreciates your efforts, so please only spend as much time on it as you feel comfortable.