sorry for scattering your dream, it is my fault... i'll stop using something i never used anyway and stop telling you what i know...

now the world can be how you thought it was again and everyone who reminds you it's different will be a M$ promotor again...

reality is that M$ doesn't want you to know this though, they want you and others to think GPL is a viral license and promote it as so. that way more people will choose not to use GPL... look up who started claiming GPL is viral and tell me what story was more M$ like, your or mine... then look up the statements made by GNU about the viral thing and the argument why it is not viral and tell me what those sound like, your or my story...

anyway, i said what i know. i didn't intend to stir up a shithole of emotions. do with what i said what you like and have a nice life.

Following Edwin's explanation and to clarify (or at least I hope so...) even more the graphics mode 2, look at the following comparisons:

Spectrum only screen mode:

256x192 pixels, 32*24 effective character matrix, 768 cells with 1 color attribute byte (FLSH|BR|FG|BG) each one, 21 redefinable characters (UDG) with inmediate effect on screen.

MSX1 graphics mode 2:

256x192 pixels, 32*24 effective character matrix, 768 cells with 8 color attribute bytes (FG|BG) each one. The main difference comes here, imagine the screen is built by 768 UDGs (really!), 3*256 UDG tables that can be redefined dinamically (like the spectrum's UDG). In the "spectrum compatible" mode you only need to keep the standard UDGs ordering, say three sequences of 0-255 bytes to cover all the screen, and only modify their definitions (pattern and color). This way you can mimic a 256x192 screen; but with an extra of colors per cell.

Thanks Edwin and jltursan - I think I'm finally getting a mental picture of how the MSX graphics work.
And it is by far the strangest display format I have come across and even beats the CPC interlaced bits display.

Ok, so in summary MSX graphics are using an indexed bitmap display buffer into a list of pattern (3x256 UDGs) memory.
The colour comes from a standard 768 attribute area.

Ok, so the display memory has a strange layout - so how does a typical MSX programmer transfer an image to display memory?
My approach would be to find the screen position I want an image (for example a tile) to appear then workout what section of tile memory I need to write to, and then transfer the image to the appropreiate tiles.
So my question is this -
Do MSX programmers use special code to transfer a linear Windows style bitmap into tile display memory?
Much like spectrum programmers who need to get around the 3x2K display problem as well?

If so when you store an image to be displayed do you store it in a normal way. ie. 1st row, 2nd row, ... last row. using the (FG|BG) colour format.
This seems logical and then use a special routine to transfer the linear bitmap into tile display memory.

I'm guessing you can't change the tile indexes in the 768 tile table?
If you could you could define a tile at one position and use it multiple times across the display and you only need to have 3 copies of it (1 for each section of the screen). True?

The reason for all these questions is that defining the image in the editor is no problem.
The problem comes when you want to use that image in the code editor.
The code editor in TommyGun uses image parsers/generators to convert the image into code.
Its this parser/generator that would need to know how you want to store your bitmaps and where I suppose.
So what kind of options you do require for the image parser?
Please look at the other computers (ZX Spectrum [attributes based images] and CPC [palette based images]) for examples on conversion options.

From what I have read so far - it looks like the MSX you get normal 4 color mode formats to create images with and special parsers to format the image into the correct code.
I have completed the monochrome sprite image and almost finished multicolor mode for the image editor.
I still have 16 color mode to do (FG|BG) and to write the code generators for the code editor.

I would be happy to offer a prototype for someone to use so they can check the correctness of the code output if required.
But it would be to just a few people - with preference given to Edwin and jltursan for their help if they are interested.

Quote:

And it is by far the strangest display format I have come across and even beats the CPC interlaced bits display.

Really? It's basically a character based display with definable characters. Apart from the three sets, it doesn't seem all that weird to me.

Quote:

Do MSX programmers use special code to transfer a linear Windows style bitmap into tile display memory?

I think the answer is more like: not at all. Basically, you define the patterns you need in a certain part of the game and mostly just update the name table and the sprite attribute table during play. I've never really considered linear bitmaps at all.

Quote:

I'm guessing you can't change the tile indexes in the 768 tile table?

I'm not quite sure what you mean here.

Quote:

If you could you could define a tile at one position and use it multiple times across the display and you only need to have 3 copies of it (1 for each section of the screen). True?

Yes.



I'm not entirely sure what you're doing with the images and how you use it in the end result. This will probably define how to best deal with the data. If you can be clearer on that, maybe I can make a good suggestion. If I have the time tomorrow, I'll download the program and an example project to see what it all does. Assuming that wine will do everything. (sorry, no Windows here )

Quote:

I would be happy to offer a prototype for someone to use so they can check the correctness of the code output if required. But it would be to just a few people - with preference given to Edwin and jltursan for their help if they are interested.

Sure. Seeing what you're actually trying to achieve makes things a lot easier.

Lets ignore the screen layout for a sec and change direction a little.

How would you MSX programmers like 4 colour images stored in normal ram ready for transfer to display memory?
I am assuming you store images off screen for transfer at later stages in a game of course.

The zx spectrum guys use a variety of formats and so the attribute parser in the code editor caters for this.
I would imagine you MSX programmers would have a similar set of various formats.
Each format used for different situations and tastes.

Just give some examples of how you would like to see your image data appear in the code editor.
This maybe easier to describe than the display formats

It would help if anyone giving format examples follows these simple guidelines:
1) you actually program graphics for the MSX
2) you have checked out TommyGun and its second tutorial and understand what image parsing is.
3) you have done both of the above

Quote:

How would you MSX programmers like 4 colour images stored in normal ram ready for transfer to display memory?

Basically the Mode 2 format is also used to store data. So you'd have a block of pattern data, color data and a name table to describe the image. Of course there are some variations on this to help mix image data for multiple images or something like that, but in the end it always comes down to pattern data+color data+name table data in the formats in which it's moved to VRAM.

Quote:

It would help if anyone giving format examples follows these simple guidelines: 1) you actually program graphics for the MSX 2) you have checked out TommyGun and its second tutorial and understand what image parsing is. 3) you have done both of the above

I'll try to do 2 when I'm back this evening.

Most of your conclusions are right, anyway let's make some corrections:

Quote:

The colour comes from a standard 768 attribute area.

Not exactly, that's the Spectrum one; the MSX has 8 times more color resolution, having every character/UDG cell, 8 color attribute bytes (8x1 sized rows with FG|BG layout). One more important detail to remember, if you think about this characters like being spectrum UDGs, imagine again that those UDG can be redefined with merged color attributes. The Spectrum has a fixed color table (like putting a colored glass in front the TV), the MSX has 768 FULLY tinted UDGs! that you can freely mix to build the whole picture.

Now, let's continue...

Quote:

I'm guessing you can't change the tile indexes in the 768 tile table?

Yes, you can (as Edwin has hint you answering your next question). The 768 tile table is the "NAME TABLE" and you can reorder the three 0-255 sequences at your will. You can get amazing gfx effects with that!. So, you have three main data storages or tables:

NAME TABLE: Where the 768 tile table order is stored (768 bytes length).
PATTERN TABLE: Where the tile definitions are stored (8*768 bytes length)
COLOR TABLE: Where the tile color attributes are stored (8*768 bytes length)

So, how you usually store your graphics?, mmmm, that's a good question. If you have understand all of the above, you'll guess by yourself that you have two main ways to work with MSX graphics:

1) Spectrum compatible: You left untouched the default TABLE NAME and ONLY change the PATTERN and COLOR tables. You'll get the same screen as with a Spectrum only with 8 time more color (and with the same color spills ). Like in the spectrum you'll have to move a lot of data to make things animated (even worse because there's more color attributes to set and the video RAM is not mapped on the main RAM ). Tons of EUROPEAN games are programmed using this approach, because they're direct spectrum conversions.

2) Character/UDG based: You redefine first the whole 768 tile set and their colors and after that you only change the NAME TABLE. You'll get easy management and fast lightning graphics (think on Speccy classical games like Savage, Popeye or A.M.C.); but with jerky movements cause you're moving them on a 8x8 basis.

Of course, between this two ways to make things, there're a lot of subtle mixings and combinations. You can use a lot of tricks to achieve anything you want...

To start with something basical, the easiest approach is having a tool to redefine n banks of 256 UDGs each (in a game is a common practice to have some tileset, one per level for example). Of course you can't assign a letter (A-U) to amp every UDG! , you need to show a matrix with the real shapes...
The big UDG editing panel must follow the same color rules as the "Screens" editor (if you've already finished it). One minor hint, don't use the the "UDGs" word, use "patterns" better...
The "Tiles" tab it's a bit more complicated as you can use two approaches: leave the user draw the tile like TommyGun permits now OR leave the user to build the tile using the, already draw, defined UDG set.
In the first mode you'll get a very intuitive board cause you're always looking the whole tile; but the problem that arises is, how to map the UDGs used to the real UDG table?, maybe you can use a little UDG selector box to point what UDGs will be used for the tile...
If you follow the second way, you only need to present the full tile set and let the user to compose the tile picking the right tiles. It's easy; but as you'll guess, you the hard part is having defined the UDGs keeping in mind the tile design. A possible solution could be a helper panel on the UDG editor where you can plot the UDGs to see how they look together, like a dashboard...

Well, I think it's enough for now.... I'm eager to test your first betas!

P.D.: You can get a lot of useful ideas from the following editors:

Character (UDG) editors:

Polka v1.2
I.C.V.G.M. v3.03

Screens editor:

CVPAINT v1.07a

There're a lot of ColecoVision tools cause it has the same VDP as the MSX!

@Kiwi: there are basically two ways to use mode 2 for games.
a) initialize the so called tile table with a number from 0 to 255 repeated for each of the three sequences of the tile table. In this way there is a unique tile for each area of 8x8 pixels in the screen, so you can forget the tile table completely and think as the screen as a matrix of 256x192 pixels. Now imagine to poke at increasing addresses the PATTERN TABLE with a value of 255. what you will see is the change of leftmost 8 pixels from top to bottom for 8 scan lines. when the 8 lines are filled (tile 0), you restart from top to bottom, for the next right 8 pixels (tile 1) and so on. when reach on the right of the screen you restart from the next second line of tiles (tiles 32 to 32+31=63), and so on.
the corrispondence between attribute color table and tiles is the same that is between pattern table and tiles. for each byte in the pattern table there is a unique byte in the attribute color table. In this mode you get a fully addressable matrix of pixels canvas. this is in this mode that the msx basic initialize the vram to achieve the addressability needed for graphics commands like circle, paint, pset or so on.

b) use this a a powerful tile mode. Let's immagine a game where you need to scroll an image of a 'house' made up of 4x5 tiles. in the spectrum way you have to move 8x4x5=160 bytes (i'm not considering the color attrs.). in the msx you can only move 4x5=20 bytes. Just fill the entire tile table with tile 0 (assuming this is the solid color blue) and fill for the house using tiles from 1 to 20, where each tile is a part of the entire image.


Almost most of the msx games uses this last solution, for two main reasons:

VRam access in not nearly comparable to those achievable in the spectrum.
If using way (a) the z80 has almost twice the amount of data to move comparing this with the zx.

Most msx converted games from the speccy run very slowly compared to the zx version ( knight lore for example )

Hope this is finally clear
if you need other explanations let me know.

A note. If you want to support msx2 pay attention at the sprite mode 2 multicolor function. I will describe this:

Assume you have a solid sprite made up of 32 bytes each one with value of 255, colored with color 4
Assume you have a second solid sprite made up of 32 bytes each one with value of 255, colored with color 1
There is a bit in the color table that allow you to tell the vdp this:
"When those sprites overlap, the frontmost does not hide the rearmost, instead, the overlapping part will be of the color made up of the OR logical operation between the color code of the two sprites overlapping" so in the latter example the overlapped part will be of the color 4 OR 1 = 5.

So assuming you have two 'grouped' sprites with areas overlapped, there will be these combinations:

You get a three color sprites because of this.
for each bit = 1 of the first sprite and bit = 0 of the second sprite you see color 4
for each bit = 0 of the first sprite and bit = 1 of the second sprite you see color 1
for each bit = 0 of the first sprite and bit = 0 of the second sprite you see trasparency (background)
for each bit = 1 of the first sprite and bit = 1 of the second sprite you see color 5 = color 1 OR color 4

crazy!

Thanks jltursan - the ICVGM program is a big help for data requirements.
It will be easy to produce a similar set of data from TommyGun.

Thanks also to pingpong.

I'm finally getting a good picture of what it is like to edit images for the MSX (or VDP 9918) computers.

I have a few ideas on how to manage the msx image/screen editing and so I will have a good think about it tonight when I get home and submit some ideas to you guys tomorrow.

The one problem I have with the editors jltursan showed me are that you can only edit a single character at a time.
Too limiting for me - I will allow you to edit any size image (as long as its a char by char size) and then probably allow you to choose how to place the tiles into the tile memory.
This should allow you to create tile with a bit more vision

So in short TommyGun should allow you to:
1) edit full size images (ie. n*m tiles) showing the colour attributes correctly
2) allow you to organize your tiles
3) allow overlapping sprite editing (MSX2 and above only? well images in general - but probably best applies to sprites)
4) output multiple formats of data in the code editor - table will be selectable and different formats available

Hopefully this will make the MSX 1 guys happy and I will then add any extra MSX 2 support

I see you had some problems understanding the NAME TABLE. I'll try to explain how it is usually used when programs use bitmap graphics:

MSX-BASIC uses always linear NAME table that is 0-255, 0-255, 0-255 so the blocks in screen goes like this:
00, 01, 02 ...
32, 33, 34 ...
64, 65, 66 ...
.
.
.

If we convert X and Y coordinates to bits in address it goes like this:

00 00 00 y7 y6 y5 y4 y3 x7 x6 x5 x4 x3 y2 y1 y0 (+PATTERN/+COLOR base addr.)
I----- High addr -----I I----- low addr ------I

This is the way NAME table is used also if you use programs like BMP2MSX...

Demos that use bitmap effects (like Lieves!Tuore or Bandwagon) often use NAME table like this:
00, 08, 16...
01, 09, 17...
02, 10, 18...
.
.
.

This is to awoid some shifting when converting X and Y to bits in address:

00 00 00 y7 y6 x7 x6 x5 x4 x3 y5 y4 y3 y2 y1 y0
I----- High addr -----I I----- low addr ------I

For games PATTERN / COLOR table is usually used as a fixed data storage and only NAME table is altered... but this is stuff that you already know... If you then change also PATTERN & COLOR table, you can get animated blocks / characters no matter where they are in screen. (Like in Griel's guest for sangraal)

My thoughts at the moment are to allow you to create any image as per what is normal in TommyGun.
From there you can then place the image into the map editor and then when you insert a map resource in the code editor - there will be a MSX specific map parser than will optimize the allocation of character tiles into Pattern/Color memory.
The other option is to create a specific MSX screen organiser to basically allow you to choose how you would like to layout your images into Pattern/Color memory.
It would show you a view of the 3 x 256 character pattern banks and you can then place and organise images from within the image editor into the 256 character pattern banks as you see fit.
There would also be a need to include a different code parser to parse this information into source code from which it would create the pattern memory (table), the color table etc. But probably not the name table. That would be left up to your program/game. Thus you layout the pattern/color memory accordingly.
The advantage to using a pattern/color bank organiser is that you could have more than 3.
That is you could manage many pages and keep them in ram for transfer to any of 3 256 character pages.
Ideal for different screens of a map.
Map screens would need to include NAME table generation and would also optimize the pattern/color tables to suit each screen.

As for sprites well I see they have their own table so it would be easy to manage sprites similar to normal images.

Does any of this make sense or would you like me to write a quick Word doc and host it on my web space?


There is alot of work to support the MSX.
So far I have these plugins:
Image editor:
1) Sprite palette (monochrome) - separate plugin
2) multicolor mode palette (64x48 mode) - separate plugin
3) 4 color mode (standard bitmap mode) - separate plugin

There allow you to draw MSX images - note they are not in any MSX specific format at this point.
They simple allow the image editor use the correct colors and to display the image correctly as per an MSX machine would.

Map Editor:
1) no changes required

Allows you to position images on a set of virtual screens. Your code still needs to transfer them to real screen memory.


Code Editor:
1) Map editor parser - automatically organises the 3x256 pages of pattern/color tables and generate the name table - separate plugin
2) Screen organiser parser - simply generate the pattern/color/name tables as per the screen layout information - separate plugin
3) Sprite parser - generate sprite pattern table for 8x8 or 16x16 sprites - separate plugin

These turn the images and map data into MSX specific assembly code (possibly C as well if people use it)


Screen Organiser: a New main plugin (like the map/code/image editors)
1) allow user to place images into pattern/color table and name table.
2) would also allow place of sprites into the sprite pattern table.

This would you to interactively place images into the pattern/color table or the sprite pattern table.
This would take awhile to complete.


This would be by far the biggest expansion to TommyGun for ANY machine/platform.
I just hope that at least one person would eventually use TommyGun to implement something useful.


How does all this sound? OK?

Oh there is also another option

A code parser that allows you to export any image/sprite to normal ram in pattern/color table format or sprite table format.
You can then generate your own table of image/sprite data and then transfer them into any pattern page you like.
You would also be able to output offset data for the Name table.
If the pattern/colour data is stored in row major in the table then you get 0,1,2,3,4,5,6 etc else if its stored by column major order you get 0, 32, 64 ... 8, 33, 65 ... etc.
Then depending on where you transfer the data into the pattern/color table you use that index + offset value in the Name table to see the correct character tile at that screen position.

Sound correct?

Also thank you NYYRIKKI that is a great explain of the tables and makes everything that so much more clearer and so I hopefully have my facts in the above 2 posts a little more accurate previous posts.

Quote:

You would also be able to output offset data for the Name table.

To mess up your head even a bit more: Address of name table, pattern table and color table can be altered in limited way by using VDP registers (see VDP documentation) but this is not very usefull in MSX1 as you have only 16KB video memory and so you can't store many pattern/color tables.

This is propably clear already but just in case... Pattern and color tables always goes together and by that I mean, that changeing of NAME table always affects both block color and layout.

Quote:

If the pattern/colour data is stored in row major in the table then you get 0,1,2,3,4,5,6 etc else if its stored by column major order you get 0, 32, 64 ... 8, 33, 65 ... etc.

Almost correct. The screen is anyway always split to 3 parts horisontally, so in column major order you'll get 0,8,16,24 ... 1,9,17,25 and you need to repeat this 3 times. Unfortunately it is not possible to mix blocks between these parts. If you want to do something like this, then you need to enter "32x24 coloured text mode" (SCREEN 1) (*), where there is only 256 blocks for whole screen. Unfortunately in this mode there is only one Backround/Foreground color combination for every 8 blocks.

If you think this MSX1 graphic mode as advanced text mode with possibility to use different font and font color for each of the 3 parts of the screen, this should not be hard to realize.

You may want to check this link out: http://www.work.de/nocash/portar.htm#videodisplayprocessor

(*) Someone may prove me wrong here, because there exists some undocumented screenmode in some TMS chips, but it will not work in all MSX computers. MSX computers may have TMS-9918, TMS-9928, TMS-9929, V9938 or V9958 VDP processor. How ever you don't have to care about that as long as you use only documented features.

The interesting fact is that this undocumented mode (very handy as it allows to have the same
tileset in all the 3 horisontal parts) seems unsupported by some versions of the TMS chips.

To be clearer, it seems that some TMS-9918 support it and some don't accordingly to ther
production batch.