[bailli]

Hi everybody,

inspired by this thread I started to work on a level editor for Donkey Kong '94 for the good old trusty Gameboy: eDKit !
The editor is written in Qt and therefore should be cross-platform compatible.

Get the source code here:
https://github.com/bailli/eDKit
I do not plan to provide compiled binaries!
Okay I tested cross-compiling into a single static binary today. This was only shortly tested under WINE

The editor expects "base.gb" in the same directory as itself. For OS X this means really in the same directory as the executable (i.e. eDKit.app/Contents/MacOS/base.gb - thank you Raccoon Sam).
The base ROM is needed for: tile information, tileset creation (if no old PNGs in "tiles" exist) and SGB palettes; it is also used as a base if the save target does not exist. Afterwards the level data is also loaded from the base ROM if no ROM file is specified as commandline argument. Of course opening level data from a different ROM via File->Open is also possible, but the "base" stays the same.

This project is in a very early state - still here is what is currently working (or not):

• Reading and decompression of the complete level data
• Reading (most) tiles/tilesets directly from the ROM file
• Displaying levels with SGB palette
• Displaying sprites with SGB palettes -- OBP is wrong for some sprites
• Editing of sprite properties
• Editing of switch data
• Re-compression algorithm for the level tilemap
• Writing (most) changes back to ROM possible - but very experimental!
• Export/import to/from file of individual levels
• VRAM usage is calculated (but might be off a few tiles in special cases)
• Changing the SGB palette for the arcade levels may freeze the game! (The value is used for some other stuff - needs more debugging; low priority)
• Unlimited undo for current level
• Feel free to suggest better names for the music and tileset dropdown list

Here are some more screenshots:

[Da_GPer]

OMG! I was wondering when this will happen! I cant wait for it to be finished so I can try to make my own classic style DK game! 

[Zoinkity]

Cool you've got it displaying the levels.  Best of luck to you on this one!

[ChronoMoogle]

Shit just got real - Nice work! I hope this will get a good hacking project once the GB Everdrive is out... It's one of my favorite GB Classic games

[Jeville]

Thanks for this. I'll be sure to use it when it's ready.

[Mattrizzle]

Great job! I'm so glad to see that my old data is finally being used for something (or I assume, at least).

Here are other features to keep in mind:

• Whatever determines which cutscenes play at the beginning/end of a level (e.g. D.K. carrying Pauline away, Mario running through a door) isn't a part of the level data. For example, if you were to give World 0 levels the locked door and key instead of Donkey Kong and Pauline, after unlocking the door, D.K. would still appear with Pauline and attempt to climb the stage. These animations could be hard-coded.
• All of the Super Game Boy palettes are stored in one area of the ROM, LZSS-compressed, but it's been so long that I can't remember where they are.

Some offsets for non-level data:
3C000-3C093 Non-level tilemap pointer table (Map screens, post-boss sequences, menus, etc.)
78000-780DF Palette map pointer table (not the colors themselves, but these determine which areas of the screen get assigned which of the  four Super Game Boy palettes)

[bailli]

Thank you for your motivation and some pointers 

Since my first post I didn't get much work done, but editing the basic level tilemap is now working (with some quirks).
I just want to finish some minor things, before I will push this very preliminary version to GitHub.

Besides the level tilemap and the obvious things like size, music, tileset, time there are three additional parts to the level description. After the level tilemap is a list of RAM positions for sprites like DK, Pauline and the Mario starting position. The RAM position basically translates directly to offset in the level tilemap. This is very straight forward but not yet editable because I am still indecisive how to display these sprites, and because ripping the graphics straight from the ROM like I do for the level tiles will not work or would need much more work than it is worth...

The other two parts are before the level tilemap and are "optional" and both not fully understood by me. The first is somehow some more sprites and RAM address. The very first level uses this for example, but it just contains DKs sprite again, and testing the level without it seems to result in no visible difference... I have not really looked much further into this.

The last part is related to switches. I already had a quick attempt to follow its contents in the debugger, but lost track. More or less blind editing of the bytes mostly results in no response from flipping the switch or in messing up the whole level upon loading...
March 03, 2014, 02:35:56 pm - (Auto Merged - Double Posts are not allowed before 7 days.)Hi everybody,

the first post now contains a link to the GitHub repository.

As stated in the previous post, editing of the tilemap works, if you use more tiles/sprites than fit inside the gameboy's VRAM the level is not displayed correctly. The sprites can be displayed as black boxes and moved around.

[Da_GPer]

Thank you for your motivation and some pointers 

Since my first post I didn't get much work done, but editing the basic level tilemap is now working (with some quirks).
I just want to finish some minor things, before I will push this very preliminary version to GitHub.

Besides the level tilemap and the obvious things like size, music, tileset, time there are three additional parts to the level description. After the level tilemap is a list of RAM positions for sprites like DK, Pauline and the Mario starting position. The RAM position basically translates directly to offset in the level tilemap. This is very straight forward but not yet editable because I am still indecisive how to display these sprites, and because ripping the graphics straight from the ROM like I do for the level tiles will not work or would need much more work than it is worth...

The other two parts are before the level tilemap and are "optional" and both not fully understood by me. The first is somehow some more sprites and RAM address. The very first level uses this for example, but it just contains DKs sprite again, and testing the level without it seems to result in no visible difference... I have not really looked much further into this.

The last part is related to switches. I already had a quick attempt to follow its contents in the debugger, but lost track. More or less blind editing of the bytes mostly results in no response from flipping the switch or in messing up the whole level upon loading...
March 03, 2014, 02:35:56 pm - (Auto Merged - Double Posts are not allowed before 7 days.)Hi everybody,

the first post now contains a link to the GitHub repository.

As stated in the previous post, editing of the tilemap works, if you use more tiles/sprites than fit inside the gameboy's VRAM the level is not displayed correctly. The sprites can be displayed as black boxes and moved around.

I do not plan to provide compiled binaries!

I was wondering, since bailli wont make any compiled binaries, will someone post a compiled one for us?

[bailli]

I am just too lazy to set up another build environment, If somebody provides windows/osx binaries I will include them happily in the starting post.

The current version is more a play-around-preview-version. I do not recommend anyone do to do serious work, since the only way to "save" is to write a modified ROM, and I cannot guarantee that (old) modified ROMs will load correctly in future versions.

The modified ROM almost always contains completely shifted level data since my LZSS compression result is somehow worse than the original data (although recompression is only done for modified data). I write currently all levels sequentially since the rom bank switch depends on the level number.

Another word about the "tileset" selection in the editor: It currently does not filter the "tiles" which are actually sprites. So be careful - if a tile looks like crap it is probably from a sprite...

One last note about the "text box": It only displays information - editing does nothing. I created it trying to understand the switch and "additional sprite" data...

[Raccoon Sam]

Tried to build on OSX 10.9.2. I'm not even a beginner when it comes to building from source, but I opened the .pro file in Qt Creator, configured it with the suggested default settings and hit "build and run."
It halts with one error:
/Users/dude/Downloads/eDKit-master/main.cpp:1: error: 'QtGui/QApplication' file not found
#include <QtGui/QApplication>
         ^

[bailli]

Hm,

I have no experience with OSX. A quick google search came up with this for example: http://qt-project.org/forums/viewthread/23425
Do you try to build against Qt 5 ? I am still using Qt 4...

[Raccoon Sam]

Of course.. that might be it. I'm using Qt 5.2.1.
I'll try the link as soon as I get home.

[UltimateGamerCC]

VERY NICE, DK for GB blew me away... I thought it was like the original Arcade/NES Game but that's the real surprise about it... after the first 4 levels the gameplay shifts to that of today's "Mario VS Donkey Kong" for an astounding 96 levels...

I gotta say the this would be great if it's real easy to use, I would get in line to use it

seriously, I would put it on my to-do list right along with my other major hacks, especially if you make it easy to switch out Mario's sprites for another character (Wario VS Donkey Kong anyone??) XD

[Raccoon Sam]

Now that I added QT += widgets to the .pro file, it gives me this error:
:-1: error: [ui_MainWindow.h] Trace/BPT trap: 5

Coincidentally, I also get this error when trying to compile Devin Acker's Kirby's Dream Course editor.

[bailli]

The ui_MainWindow.h file is generated during compile time by Qt. Is this errer issued by qmake or by make/gcc ?
Did also replace QtGui by QtWidgets in the "#include <QtGui/QApplication>" lines?

It may also help to clean up all Qt generated files and rerun qmake.

[Revenant]

Now that I added QT += widgets to the .pro file, it gives me this error:
:-1: error: [ui_MainWindow.h] Trace/BPT trap: 5

Coincidentally, I also get this error when trying to compile Devin Acker's Kirby's Dream Course editor.

Hey, guess who? :V

You might have gotten to this already, but try the same stuff I did to KDCEditor's project file to get it built on OS X:

Code: [Select]

CONFIG += c++11
macx:QMAKE_CXXFLAGS += -stdlib=libc++

[Raccoon Sam]

Hey, guess who? :V

You might have gotten to this already, but try the same stuff I did to KDCEditor's project file to get it built on OS X:

Code: [Select]

CONFIG += c++11
macx:QMAKE_CXXFLAGS += -stdlib=libc++

Hi Devin! I tried adding both of those to the .pro file and the line:

Code: [Select]

QT += widgetsas instructed in the link earlier... but still, halts with one error:

/Users/vernerikontto/Downloads/eDKit-master_revenant fix/main.cpp:1: error: 'QtGui/QApplication' file not found
#include <QtGui/QApplication>
         ^

:c

[bailli]

As I asked earlier: Have you also replaced
#include <QtGui/QApplication>
with
#include <QtWidgets/QApplication>

?

As for the development of the actual editor: I had not much time in the last two weeks - so I got basically nothing done...

[Raccoon Sam]

Yeah.
Then it says:
'QtGui/QMessageBox' file not found: #include <QtGui/QMessageBox>

[Revenant]

You really should just be able to remove the QtGui/QtWidgets prefixes when building with either Qt 4 or 5 as long as the project file is configured correctly, i.e.:

#include <QApplication>
#include <QMessageBox>
etc.