Introducing MDPPY++

Talk about development tools here

Moderator: BigEvilCorporation

Post Reply
djcouchycouch
Very interested
Posts: 710
Joined: Sat Feb 18, 2012 2:44 am

Introducing MDPPY++

Post by djcouchycouch » Wed Mar 07, 2012 3:20 am

Hi,

In my spare time I've been working on Kaneda's MDPPY plugin, refactoring and adding some features that were useful to me. I figured it would be a shame to not give back, so I'm releasing what I'm calling (for lack of a better name) MDPPY++.

You can find it here:

https://www.dropbox.com/s/6986n2gy0jcg9 ... 0.zip?dl=0
https://www.dropbox.com/s/nel6t4rmlu0sv ... 0.zip?dl=0

A quick rundown of features:
  • - Exports in ASM and C. I'm a C/C++ guy, so while I could use the ASM exports, I felt more comfortable with C.
    - Options to individually export the palette, tiles, the background or forground or a combination. I wanted a bit of flexibility on what to export.
    - Export settings are saved between invocations. Because having to input them again and again is a big pain in the ass.
    - ASM exports have examples of how to use in C. I kept having to remind myself how to use the ASM exports in C, so I print out reminders along with the exported code.
    - MapResource type in includes/MapResource.h, a type that can be used with exported ASM and C maps. Same as above.
    - Reasonably straightforward to add new types of exporters when the need arrives. Exporters.lua contains the glue functions to add new exporters. Exporter options are pretty limited, though.
The code is public domain. Do whatever you want with it. Detailed code license is in the ReadMe.txt.

Note to Kaneda: If the name or code is a problem, let me know. We'll figure something out.

It's the first release, so I'm sure there are totally obvious bugs or I've bungled some really easy thing. In any case, bugs, comments and feedback should go to djcouchycouch@me.com.

Version 1.1.0 (March 25th, 2012)
- added "export C Header and Source" export type. Header contains variables declared as extern, C source contains the data.
- fix for crash bug on start up when no settings.txt file is present.

Version 1.0.0 (March 6th, 2012)
- Initial Release


Thanks!
DJCC
Last edited by djcouchycouch on Fri Sep 22, 2017 10:58 am, edited 3 times in total.

KanedaFr
Administrateur
Posts: 1139
Joined: Tue Aug 29, 2006 10:56 am
Contact:

Post by KanedaFr » Wed Mar 07, 2012 9:55 pm

WOW! It seems there is a lot of works here ! :)

Congratulations

ps: and no problem for the name, it's not copyrighted :lol:

djcouchycouch
Very interested
Posts: 710
Joined: Sat Feb 18, 2012 2:44 am

Post by djcouchycouch » Mon Mar 26, 2012 1:16 am

Hi,

I've released MDPPY++ 1.1.0

http://dl.dropbox.com/u/17303735/MDPPY% ... 01.1.0.zip

Release Notes:

Version 1.1.0 (March 25th, 2012)
- added "export C Header and Source" export type. Header contains variables declared as extern, C source contains the data.
- fix for crash bug on start up when no settings.txt file is present.

As usual, send feedback, bug reports (with reproduction steps, please!) and comments to me at (djcouchycouch@me.com)

Thanks!
DJCC

Moon-Watcher
Very interested
Posts: 117
Joined: Sun Jan 02, 2011 9:14 pm
Contact:

Post by Moon-Watcher » Wed May 09, 2012 11:36 pm

Mappy and your plugins are really useful tools. I'd never use it before working with SGDK but reading Mappy's docs found:
Editing Properties of a Still Block. You will be shown the block you double clicked, along with it's properties. The numeric information is not used by Mappy and is entirely for your own use, as are the four collision detection, and 'other' bits
I think about the posibilities and Wow! IMHO Block Porperties seems like a great feature to implement. Do you think?

djcouchycouch
Very interested
Posts: 710
Joined: Sat Feb 18, 2012 2:44 am

Post by djcouchycouch » Thu May 10, 2012 12:01 am

You can get at the block properties if you export your map as text, from the File menu. You'll get something like:

Code: Select all

const BLKSTR foreground_blockstr[125] = {
{ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0x00 },
{ 1, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0x00 },
{ 2, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0x00 },

etc,etc
};

You'll find the declaration of BLKSTR in DOCS/mapdefs.h.

oofwill
Very interested
Posts: 173
Joined: Mon May 03, 2010 6:12 pm
Location: France - Niort

Post by oofwill » Thu Dec 20, 2012 3:16 pm

I'm trying to use MDPPY++. (thanks for it!)

Mappy side, ok. But when exporting tile in C, all my tiles look:

Code: Select all

/* tile 0*/
	0xFFFFFFFFFFFFFFFF,
	0xFFFFFFFFFFFFFFFF,
	0xFFFFFFFFFFFFFFFF,
	0xFFFFFFFFFFFFFFFF,
	0xFFFFFFFFFFFFFFFF,
	0xFFFFFFFFFFFFFFFF,
	0xFFFFFFFFFFFFFFFF,
	0xFFFFFFFFFFFFFFFF,

	/* tile 1*/
	0xFFFFFFFFFFFFFFFF,
	0xFFFFFFFFFFFFFFFF,
	0xFFFFFFFFFFFFFFFF,
	0xFFFFFFFFFFFFFFFF,
	0xFFFFFFFFFFFFFFFF,
	0xFFFFFFFFFFFFFFFF,
	0xFFFFFFFFFFFFFFFF,
	0xFFFFFFFFFFFFFFFF,

	/* tile 2*/
	0xFFFFFFFFFFFFFFFF,
	0xFFFFFFFFFFFFFFFF,
	0xFFFFFFFFFFFFFFFF,
	0xFFFFFFFFFFFFFFFF,
	0xFFFFFFFFFFFFFFFF,
	0xFFFFFFFFFFFFFFFF,
	0xFFFFFFFFFFFFFFFF,
	0xFFFFFFFFFFFFFFFF,

        ...
Strange?

Hum... probably a problem with color. Mappy's working at least with 256 colors?

djcouchycouch
Very interested
Posts: 710
Joined: Sat Feb 18, 2012 2:44 am

Post by djcouchycouch » Thu Dec 20, 2012 3:49 pm

From the code comments, I found

Code: Select all

    -- this code, based on the original asm palette export, assumes that the palette is
    -- the first 16 colors of the 256 color palette. Meaning that the image used as tiles
    -- have already been quantized before being used in Mappy.

So that means the exporter:
- assumes the image is in a 256 color format
- only uses the first 16 colors of the 256 color palette.

So your assets should be set up in a 256 color format but has been made to only use the first 16 colors. One way to do that is to convert your assets to a 16 color format, convert them again to 256 color format and then import into Mappy. Yes, it's pain. I had to do that too. I don't use Mappy any more (using Tiled instead) but I remember it was fussy about formats. It requires you to jump through a few hoops for things to work.

oofwill
Very interested
Posts: 173
Joined: Mon May 03, 2010 6:12 pm
Location: France - Niort

Post by oofwill » Thu Dec 20, 2012 5:30 pm

It's ok for the exportation now.
However, i've a problem using the code.

I'm trying to load a tile in ram using VDP_doVRamDMA, but i have always the same thing in vram whatever the tile i load.

Code: Select all

VDP_doVRamDMA((u32)level1_tiles[j], i, 32/2);
Is there something or more wrong in my code?

I've tried Tiled too and i admit i prefer Tiled handling.
But i do'nt even know how to export with it...

Chilly Willy
Very interested
Posts: 2984
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Thu Dec 20, 2012 5:52 pm

You probably meant (u32)&level1_tiles[j], not (u32)level1_tiles[j].

oofwill
Very interested
Posts: 173
Joined: Mon May 03, 2010 6:12 pm
Location: France - Niort

Post by oofwill » Thu Dec 20, 2012 5:58 pm

But where do i put my brain?! oh?! it's here :lol:

Thanks Chilly Willy, that was just that... :|

djcouchycouch
Very interested
Posts: 710
Joined: Sat Feb 18, 2012 2:44 am

Post by djcouchycouch » Thu Dec 20, 2012 6:18 pm

oofwill wrote:I've tried Tiled too and i admit i prefer Tiled handling.
But i do'nt even know how to export with it...
It's not as easy to write an exporter for it, but once you get Tiled and QT Creator setup, it's faster and better. I dropped Mappy because while Lua scripting is straightforward, it's a total bitch to debug. And I kept hitting limitations that were really annoying and I can't remember right now :)

If you don't want to go through all that, you could just export as one of the text-based formats it currently supports and write a converter in python or your favorite scripting language.

Post Reply