Suggestions

I hope you are still taking suggestions. I have been using Maptapper for quite some time and it's also a fantastic tool to grab images from games, not just maps

I'm currently trying to visualize images that use multiple color palettes via copper lists.

Is there a possibility to automate the "Stop at line::" option, so that it saves the current image for each line? or even better for each line that the color palette changes?

I can do it manually by changing the "Stop at line::" value and using the "Save Gfx" button, but this becomes quite a tedious task with images that change their palette more than 32 times.

[Codetapper]

It could be done but would be quite complex, buffering the image as it goes and copying into a 24 bit buffer, then copying the next bit in etc.

Can you not just grab a picture of the screen in WinUAE for that?

Ah, I see what you are thinking, but you are one step too far.

I'm not looking for the complete image - I'm looking for a sequence of images where each image has a different color palette.

The result would be something like the images from the Z-Out ending screen, that I attached:

The palette changes three times across the image and the result is three different images with the line number as suffix.

I can then use the individual images to create the palette view that I am using on my site by scripting something in php: http://amiga.lychesis.net/special/Co...ut_Ending.html

I know it's a very specific suggestion, but I thought it may be easy to implement on your side. I only recently discovered the "Stop at line" option in Maptapper and thought it would be perfect for such images.

[earok]

Any chance of a "Load Gfx" function? eg it takes an indexed PNG and pastes it back into the source file? It'd be massively useful for a stupid little graphics hack I'm doing.

Thanks in advance.

[Codetapper]

What do you mean "paste it back into the source file" exactly?

I am guessing you are wanting to put graphics into a WinUAE savestate, but it's just a big stream. Let's say you have ripped the graphics as 16x16 tiles, arranged as a 4x4 grid, and there are 3 on the screen in Atari ST format. You load a 320x256 indexed PNG. What on earth is the program supposed to do? Decode everything back from PNG into the format the game needs and guess how many tiles etc?

[BippyM]

He probably means convert an image to the correct format, and then insert that and replace all palette entries etc.. And it just work!

[earok]

Originally Posted by Codetapper

What do you mean "paste it back into the source file" exactly?

I am guessing you are wanting to put graphics into a WinUAE savestate, but it's just a big stream. Let's say you have ripped the graphics as 16x16 tiles, arranged as a 4x4 grid, and there are 3 on the screen in Atari ST format. You load a 320x256 indexed PNG. What on earth is the program supposed to do? Decode everything back from PNG into the format the game needs and guess how many tiles etc?

Not really into a WinUAE save state, but into a file or disk image where the graphics aren't compressed. My idea was, assuming you've got MapTapper configured with the correct offset, number of bitplanes etc for ripping a specific image from a file, you could load in a replacement image instead. I hadn't really thought about multiple tiles/images, just a one-by-one image replacement. Sorry, hope that makes sense!


Edit: This might help explain things, with the "Giana II" hack of Hard N Heavy what I did was

- Load a WinUAE save state in MapTapper to get the palette
- Load the WHDLoad disk image rip in MapTapper
- Ripped the graphics and noted the offsets etc
- Edited the PNGs
- Converted the PNGs back to bitplanes and stored them in the WHDLoad disk image with an ugly program I hacked together


What I was really after was the ability to do that last step in MapTapper itself.

[Codetapper]

That last step has a number of assumptions. For Giana 2 it might be simpler, but you're now wanting an indexed PNG converted back to the relevant destination format (and hoping that it's an exact size match, for example what if the game has 256 tiles and your screen has a different number?), but then you're wanting to inject that picture back into the middle of a WHDLoad disk image?

It sounds like a lot of coding required for your one case. Unless you can come up with some system of how it can all work, I don't think I can spare the time. I have a lot more pressing features to fix first aswell.

[earok]

Originally Posted by Codetapper

It sounds like a lot of coding required for your one case. Unless you can come up with some system of how it can all work, I don't think I can spare the time. I have a lot more pressing features to fix first aswell.

Fair enough mate

Hi, I'm not sure if I'm the first to ask, but I've come across the following problem again:

The current MapTapper takes the bitplanes from a single start address and assumes that they are stored sequencially after each other (even with the possibility to switch the order via the "Bitplane Order" option).

I was wondering if it could be possible to add the option to freely set the address for each bitplane, as I've got games (Defender of the Crown 2 at the moment) which stores the first three bitplanes in sequence without offset and then the last three more with an offset of several hundred bytes.

This could also be handy in conjunction with the "Info" tab, because this already shows the current bitplane addresses, width and height. This could simply be copied over to the "Tile Ripper" tab, just to be able to get a good start from a save state.

I hope this isn't a big thing and that you may consider to add it.

Thanks

[Codetapper]

That should be do-able. Space is always the problem, where to put up to 8 bitplane addresses...

That sounds great and I know what you mean (looks at his current version of MapTapper)

The Action Replay Cartridge had an interesting method to set the bitplane addresses by allowing you to lock individual bitplanes via hotkeys. The unlocked bitplanes could be moved by the usual cursor keys. That way you could lock the bitplanes that you felt were ok and move the bitplanes that needed to be somewhere else.