Mappy

[Bonknuts]

Curious how many of you pce homebrew peeps use Mappy?

[cabbage]

I do--HuC's .FMP support is awfully convenient.

[Bonknuts]

You use LUA scripts in the mappy editor, to extend to PCE related functions?

[nodtveidt]

I use it now more than I used to because Windows 7 doesn't like my VB6-based custom map editor.

[Arkhan]

We use it.   It's the best way to quickly smash out your maps and then convert them to something useful.

[HyperFighting]

To Mappy or not to Mappy that is the question?

I think Mappy is a great little monster. You can load an image of tiles and draw with the tiles that you loaded in giving you some great optimization.

Now there is a little bad ass in town called ImagetoPCE this guy will take your image and optimize the similar tiles for you.

My thought is I would prefer to build my map in an image editor and then convert it to the 3 Bin files DATA, BAT, and PAL ImagetoPCE generates.

EX: Have a complex image and break into tiles load it into mappy and reassemble it.
EX: Have a complex image load it into ImagetoPCE and have it optimize the image for you

Currently I have downloaded lots of sources from the HUC site to see if any show case loading backgrounds from BIN files (No luck). I have also have tried quite a bit modifying Obey examples to see if I can get the image I have exported to display (No Luck). Finally I have read the original Image toPCE thread on this forum although an example is offered it is already compiled.

Does anybody know what it takes to load and display the data in the BIN files generated from ImagetoPCE with Huc?

 

[nodtveidt]

Just #incbin the three files it spits out, and do something like this:

Code: [Select]

load_vram(0x2000,datafile,0x2800);
load_bat(0x0,batfile,32,20);
load_palette(0,palfile,15);
Adjust according to your labels, the amount of data you're using, etc.

[TheOldMan]

Does anybody know what it takes to load and display the data in the BIN files generated from ImagetoPCE with Huc?

Haven't played with ImagetoPCE, But displaying images on the pce is basically a 3 step process:

1) Load the tile data (the tile graphics). I believe load_chr() and/or load_tile() do that. Which you use depends on how the data is actually compiled in.
2) Load the palette data.
3) Load the BAT data. The are several ways to do this; Not sure what the functions are called, but there is one to load only the BAT area. Generally, I prefer the VRAM function, though.  BAT is located at 0x0000.

Some words of advice on getting things to work:
  Load the tile data first. Then you can look in the mednafen debugger and see a) IF it loaded correctly, and b)Where it loaded. If you don't see any tile stuff in mednafen, try hitting the [TAB] key to change palettes. You might be using an all-black palette
  When you load the palette data, make sure you load the correct palette for the tiles. It's easy to load the sprite palette area instead of the tile palettes
  Once you load the BAT area, you should see -something- on the screen. If you don't, check the palette. Your BAT information may be expecting a specific range of palettes, and/or a specific location for the tile data.

  As for finding problems: A hex editor is invaluable for that. You can open the data files with it, and see where things are and usually figure out what went wrong. HuC has all the information you need to decode how the various data blocks should be set up. It will take some looking through the docs, but it is there.

The good news is, once you do it and get it to work, you can wrap it in a function call, and not have to worry about it too much

[HyperFighting]

  I can't thank you guys enough! I really appreciate the help. I have posted some modified Obey Brew source that incorporates the ideas you guys have helped me with! It should compile provided the gfx files are in place...Obey Brew's "Part 4 - Playing With Yourself" will give you the Bonk GFX and you'll need to process a 256x256 image through ImagetoPCE.

I had an indexed colour 256x256 image that was less than 16 colours. (Only required one palette)

In imagetoPCE I specified 1 palette and the optimize flag as there where several repeated tiles. I used the three 3 files that it spat out and the rest is history. My goal is to eventually do a larger image but man was it satisfying when the image displayed on the screen! I have been using Hugo but I am defiantly excited to switch it up to mednafen (Hoping to run it using a .bat file from the Huc command prompt to make for an easier testing environment)

Things to pay attention too

#incbin(scene_data,"Star_DATA.bin");
#incbin(scene_bat,"Star_BAT.bin");
#incbin(scene_pal,"Star_PAL.bin"); 

   load_vram(0x2000,scene_data,0x2800);
   load_bat(0x0, scene_bat,32,32);
   load_palette(0,scene_pal,1);

scroll(0, bonkx, 0, 0, 223, 0xc0);

Code: [Select]

#include "huc.h"

#incspr(bonk,"bonk.pcx",0,0,2,2);
#incpal(bonkpal,"bonk.pcx");

#incbin(scene_data,"Star_DATA.bin");
#incbin(scene_bat,"Star_BAT.bin");
#incbin(scene_pal,"Star_PAL.bin");

main()
{
int j1, bonkx;
bonkx = 104;
init_satb();
spr_make(0,104,153,0x5000,FLIP_MAS|SIZE_MAS,NO_FLIP|SZ_32x32,0,1);
load_palette(16,bonkpal,1);
load_vram(0x5000,bonk,0x100);

load_vram(0x2000,scene_data,0x2800);
load_bat(0x0, scene_bat,32,32);
load_palette(0,scene_pal,1);

satb_update();

for(;;)
{
vsync();
j1 = joy(0);
if (j1 & JOY_LEFT)
{
spr_ctrl(FLIP_X_MASK,FLIP_X);
bonkx--;
}
if (j1 & JOY_RGHT)
{
spr_ctrl(FLIP_X_MASK,NO_FLIP_X);
bonkx++;
}
scroll(0, bonkx, 0, 0, 223, 0xc0);
spr_x(bonkx);
satb_update();
}
}

spr_make(spriteno,spritex,spritey,spritepattern,ctrl1,ctrl2,sprpal,sprpri)
int spriteno,spritex,spritey,spritepattern,ctrl1,ctrl2,sprpal,sprpri;
{
spr_set(spriteno);
spr_x(spritex);
spr_y(spritey);
spr_pattern(spritepattern);
spr_ctrl(ctrl1,ctrl2);
spr_pal(sprpal);
spr_pri(sprpri);
}


TheOldRover and TheOldMan are you guys responsible for Obey Brew? That site is so awesome! I ain't the best coder but enjoy it immensely the way the site is written really speaks to me and I have found it extremely helpful!

[nodtveidt]

I developed ObeyBrew.com but it wouldn't be even half what it is without people like TheOldMan and Arkhan. It still has a ways to go before it's finished though.

[TheOldMan]

TheOldRover and TheOldMan are you guys responsible for Obey Brew?

Not me. Rover, maybe.
............................................
Just for future reference: You should have spr_make either use globals or constant values in the function; you're losing a lot of cycles by having a load of parameters (which aren't really needed) that
get pushed and popped. I do admit, though, it is a one-time call, so that may not matter to you
Also, you should do the satb_update() right after the vsync(); that will cause the sprite table transfer to occur during the video blank period, and avoid any tearing and such caused by writing to VRAM during the active display period.

So why are you using the scroll() function, anyway? Just curious...

[nodtveidt]

He is using some code from one of the earlier obeybrew tutorials. It's not optimal code but it's functional.

[ParanoiaDragon]

Heh, I totally went in here thinking Bonknuts was thinking of porting Mappy to the PCE, & was going to voice how much I'd love to see Mappy Land, as I loved that game as a kid.  My bad!

[TheOldMan]

It's not optimal code but it's functional.

Understood. I was just wondering why use scroll() at all. Is he trying to implement a scrolling background? If so, why move the sprite (via srp_x() )? Doing both means both the background and sprite move, giving an effective 2 pixel movement, which can complicate other things....

While I admit that there is no single way to write 'correct' code, most programs are improved by looking at what was written (and worked) and trying to better it. Nobody gets it right the first time on their own

[nodtveidt]

I think he may just be experimenting for now... this code barely does anything at all outside of the basics. He may just be learning the ropes.