It looks like this nemesis 3 level got 1.4 charsets.
Setting xscroll = 0 and yscroll = 0 in the tool sourcecode to turn off the combination tiles, the converter says: bitmap: 5792 bytes. With xscroll = 1 it says 14176 bytes bitmap, that is factor a 2.5 penalty - too wild neighbour tiles combinations puzzeling.
A 3.5 charsets mass was created (all these figures actually without multiplying the 8x scrollsteps).
If you throw megaROM at it, maybe the max 128 chars onscreen limit is hit.
Reducing to 2 pixel scroll wont help the 128 chars limit.
That aside, I would rather snip halve the tiles than to give up full scroll.
But it is not really needed to give up tiles, the way they are glued together horizontaly got to be puzzeled less random. While big stuff is no problem. The fat magenta flower takes just a little more than normal.
The converters shell output, "names(8x8)", this shows the size of the nametable, 11k will write beyond the bload area of the demo. In the megaROM that one will be no issue.
but why not consider steps of 4 pixels? The result isn't bad for games (look at Genesis) and the color clash can be avoided in an optimal manner. You could think to have a full bitmap screen with pixels of size 4x1 and make it scroll on the x axis freely.
A small closed project could be nice to asses the technique.
4 pixels
But Genesis gfx scroll 1 pixel out of the box!
Except where genesis itself does clash.
Because 4 pixel scroll does not remove clash. Except the special case of 4 pixels aligned to 4 pixels, screen 3 resolution horizontal. So this wont make a difference to gradius gfx.
But have you already seen how 1 pixel scrollable gradius gfx look like?
click the scrollableSC2.jar converter... yeah!
What remains is that you need to change the puzzle.
If you press space key when mk_conv is finished, you can see the created tiles.
First candidate is that "a couple of green pixels" background tile, just blank it where it got neighbours, that one is minimum change on the original look.
Genesis scrolls at 4 pixel steps
The converter I have found in the photo demo shows only a small part of the image and does not return anything
This is why I was asking you
I have updated http://jf.peer.name/msx/demo20120119scrollphoto.zip to make the converter save the gif.
Also, you can drag the picture around with the mouse.
But clicking into the picture will show the original picture, converted to MSX palette.
There is a scanline colormixer in there.
Nemesis maps got so odd palette that the converter may make a mixcolor.
I've sent you a new picture with only 229 tiles (I used matlab to count them)
I'm not able to make the new tool work
No data are generated, can you give a try and see where I'm wrong?
Do you mean the scrollableSC2.jar?
Low comfort coders tool. Do not close window before shell printed "SAVING".
in msxscroll2.java source, after
saveimage(bi, new File("tst_converted.gif"));
you could add
System.exit(0);
run mk.bat to compile it. Then the resulting scrollableSC2.jar is usable as a batch version.
The tools should take insane amounts of tiles, unlikely blocks in there.
I reduced the map to 64 tiles but there is no way to make it work, I'm using jdk1.7.0_04, could this be the reason?
A similar looking level could be made if the troublemakers are replaced with a more repetitive pattern.
Well and when I get the nametable compressor done and separate color compression on the bitmap.
It is harsh conditions, but no dead end.
I gonna mail you some pics that work.
are the demos (e.g. http://jf.peer.name/msx/smoothscroller.zip) still somewhere to be found??