Convert image to V9990 P1 mode

Champion (467)

10-11-2022, 20:14

Hi guys, is there a tool to convert an image to V9990 P1 mode, like BMP2MSX does for v99x8?

First I need to reduce color count to fit one or two palettes (16 colors each, 5 bits for each RGB component). Maybe is better to use GIMP or Paint.net? Is anyone experienced with it, to show a shortcut?

Secondly I will need to convert to the (strange) V9990 format for tiles and sprites. Maybe the only option for that is a custom script on some high leve language...

Thanks

ログイン/登録して投稿

By aoineko

Paladin (887)

10-11-2022, 23:03

If you target P1 mode, you can only use 1 palette of 16 colors for each layer (15 colors + transparency, to be accurate). Unless of course you plan to use split screen.

In MSXgl V9990 sample I use my MSXimg tool to convert image to 4-bits per pixel with V9900 palette 16-bits format.

Here is the command line I'm using:
MSXimg.exe img\data_bg.png -out %Dest%\v9990\data_v9_bg.h -pos 0 0 -size 256 48 -num 1 1 -name g_DataV9BG -trans 0xFF00FF -bpc 4 -pal custom --pal24

It generate C header file but you can generate assembler file or binary if you prefer. All option are available in the .txt file.

EDIT: And if you want to simplify your life when loading to VRAM, I strongly recommend you to work with 256 pixels wide data. Otherwise, you will have to rearrange your data in VRAM, which will make your code longer and slow down the transfer.

By assembler

Champion (414)

11-11-2022, 09:47

You can use bmp2g9b and g9klib by Teambomba here

About tiles and sprites: you have a big bitmap 256x2044 pixels (it should be 2048, but the last bytes are used for SPAT)

TILES: Each 8x8 fragment of this bitmap is a tile, referenced using 2 bytes.

SPRITES: Based on the value of R#25, one 256x256 portion of the complete bitmap is used as sprites.

Example

The example above shows the distribution of the tiles. Tiles starting with 0x05 are considered as floors, 0x06 as stairs. the 0x07 in this phase are not used, but they are the tiles that "kill".

The visible sprites are marked on the graph, and the rest are copied with commands in that area when they are needed

By Metalion

Paragon (1622)

11-11-2022, 09:44

albs_br wrote:

Secondly I will need to convert to the (strange) V9990 format for tiles and sprites.
Maybe the only option for that is a custom script on some high level language...

Strange ???
The V9990 handles tiles and sprites in the most simple way there is : it's just a bitmap !
It's definitely much simpler than TMS9918,V9938 or V9958.

By aoineko

Paladin (887)

11-11-2022, 10:08

I agree, but when you come from the MSX1/2 VDP world, I can understand that it's a bit confusing at first.

The fact that all the data in a tile/sprite is contiguous in VRAM on MSX1/2 VDP was not illogical. With the V9990, the data of each tile/sprite line is 256 bytes apart.

By albs_br

Champion (467)

11-11-2022, 13:35

The way you guys explained tiles/sprites organization in V9990 VRAM makes it looks much easier. And also makes much more sense.

The V9990 manual is not that clear.

About the tools, I will try them today.

By albs_br

Champion (467)

11-11-2022, 15:59

Is there a way to generate mixed Layer A and Layer B data (they will need to be scrolled together), so I could have 30 colors?

By aoineko

Paladin (887)

11-11-2022, 17:15

In theory it is quite feasible but MSXimg does not support this hybrid format yet.

If you want more color, why don't you use the B1 mode in 8 bit-per-pixel?
Managing software sprites in this mode requires a little more work, but at least you'll have a 256-color RGB or a 64-color palette mode.
The scrolling works very well in this mode and the handling of the software sprites through VDP commands is very fast for a z80.

EDIT: If limiting yourself to 1 palette per tile works for you, you could export your tiles in 2 times (with 2 palettes) and then build your level using tiles from both palettes on either plane.

By albs_br

Champion (467)

11-11-2022, 17:22

aoineko wrote:

Managing software sprites in this mode requires a little more work, but at least you'll have a 256-color RGB or a 64-color palette mode.

The speed achived by this method will bring to few/little sprites or low frame rate. I'm targeting now big (huge) sprites at ideally 60 fps.

By aoineko

Paladin (887)

11-11-2022, 17:43

The bigger the sprites, the more I would recommend software sprite for the V9990.
VDP commands are very fast and don't block le Z80.

However, for a large number of small sprites, the P1 mode is probably better.

It's up to you.

By albs_br

Champion (467)

11-11-2022, 19:35

aoineko wrote:

The bigger the sprites, the more I would recommend software sprite for the V9990.
VDP commands are very fast and don't block le Z80.

If the transfers are RAM --> VRAM, they do block the CPU. The fastest method is unrolled OUTI's, which will give at most 3kb / frame.

I need to update all 125 sprites per frame (or at least 3 frames).

125 sprites x 128 bytes per sprite = 16000 bytes
divided by 3 frames = 5333 bytes / frame

Is it achievable by any method on V9990? Maybe with turbo Z80 (Panasonic MSX2+) or Turbo R?