[MSX-C] Q&A official thread

Page 16/57
9 | 10 | 11 | 12 | 13 | 14 | 15 | | 17 | 18 | 19 | 20 | 21

By Sylvester

Hero (542)

Sylvester's picture

12-09-2015, 12:22

Ok, found some time again to program again Smile But got stuck with creating some missing functions. I need a string replace and word wrap function. I think i need to read some more about strings, pointers and memory usage (malloc, free, memcpy, memset), but if somebody can give some hints in the mean while Smile Here is the code i have so far and it only hangs at the moment Sad

hmm, the forum code tag doesn't like my code, so here a link to pastebin: http://pastebin.com/q9B4H0Xv :)

By anonymous

incognito ergo sum (116)

anonymous's picture

12-09-2015, 13:10

AxelStone wrote:

@JaviLM Done, there is no rstplt() in anywhere, and nothing happens Sad . I've tried even remove initplt() and I have the same result. It's strange, perhaps there is something wrong in MiFui pictures format, but in Basic it works.

Confirmed, the problem is the usage of the transparent color in the tile. The code is correct. Look at this:

1) Move from the first screen to the second and we get this:

2) Move from the third screen back to the second and the result is this:

As you can see, the steps take the color of whatever was drawn under them. A clearer example:

In other words, don't use color 0 for non-transparent pixels.

By AxelStone

Prophet (3064)

AxelStone's picture

12-09-2015, 13:18

Hi @Louthrax, the problem is why it's painting with transparency if i wanted it. Using a special color for transparency has a problem, you only have 15 colors since 16th is a unused color (only used for transparency). However it seems it's the way it must be.

@JaviLM Thanks for the info, I'll use then a specific color as Louthrax suggest.

By AxelStone

Prophet (3064)

AxelStone's picture

12-09-2015, 14:36

Fixed using a specific color for transparent:

It need a little image working since you lost 1 color and has to adapt rest of graphic. However I still has the doubt: If I'm using logical operation 8, it should not draw transparent right? At this point is not relevant since I've modified palette, is only curiosity B-)

By Grauw

Ascended (10321)

Grauw's picture

12-09-2015, 14:51

You shouldn’t have to resort to sacrificing that colour… Did you check hit9918’s post?

hit9918 wrote:

It gets confusing, what was solved and what not, transparent blit topic vs palette.
Go screen 1 in BASIC. Make color 0,4,1. Then color 0,4,15. whoops, it changes with border color. It is the MSX1 thing, involved a genlock story.
vdp(9) = vdp(9) OR 32. then it is palette.

So, color 0 equals the border colour unless you set bit 5 in VDP register 8 (9 in Basic), see the V9938 application manual, quote “TP Sets the color of code 0 to the color of the palette”.

What you saw was that all the pixels did get written correctly by the copy without transparency, however because the TP bit was not set, the palette colour was ignored and in stead it showed the colour set as the border colour (in your case, black). Revert back to your original palette and set TP, and it should all work as you wanted.

By AxelStone

Prophet (3064)

AxelStone's picture

12-09-2015, 17:51

@Grauw Something like that?

TINY value;

I've tried and doesn't works. It's strange, I remember I used VDP(9)=VDP(9)OR&H20 in Basic and it works.

Sorry @hit9918, I didn't see your answer.

By Grauw

Ascended (10321)

Grauw's picture

12-09-2015, 18:00

That seems alright… Do you do it after the screen mode switch?

By AxelStone

Prophet (3064)

AxelStone's picture

12-09-2015, 18:19

After screen mode switch.

By kanima

Master (194)

kanima's picture

12-09-2015, 20:27

Just a wild guess: maybe the rdvdp and wrtvdp routines use the same register numbers as BASIC? In other words, try it with 9 instead of 8.

By DarkSchneider

Paladin (942)

DarkSchneider's picture

13-09-2015, 10:18

But even setting the color 0 not to change the border, the problem is that the copy command is not using the IMP logop. If it were using it should not matter if is the border color or not. Then I think the function ASM code should be revised and see what is doing.

Also, let me tell why HMMM should not be used in real life. I put the doc to refresh:
Let see the parameter:
HMMM - bytes <- continuous bytes
LMMM - dots <- rectangle

The problem is that using HMMM we have to manually copy line by line, waiting with the CPU to the line to be copied and then copy the next one. In real life you don't want to copy only a line, but a rectangle. Then the problem is that having the CPU busy in waiting the VDP to control the lines copy, it is a total waste of CPU, you lose the parallel operation with the VDP, that is the idea of a co-processor.
Using LMMM you send the copy rectangle command and forget, use the CPU for another purposes meanwhile.

HMMM can only be used really for full lines copy, because it can do it without CPU intervention. This is equivalent to vertical copy so YMMM could be used. Maybe the "bytes" version of command are really to VDP internal usage but exposed to users (why not?). Maybe it uses them internally for other command and controlling by its own the line copy instead using the CPU for handling it.
Or, HMMM is really useful to copy from VRAM to VRAM blocks of data, like sprites or graphics tiles in SC4 that are sets of contiguous bytes of data.

Page 16/57
9 | 10 | 11 | 12 | 13 | 14 | 15 | | 17 | 18 | 19 | 20 | 21