By the way, cpyv2v uses the slow LMMM VDP command, when you do not care about transparency and odd x coordinates, HMMM is much faster.
In MSX-C there not exist HMMM, I suposse that I must use BIOS calls, right?
In the screenshot above, the pattern in the top of the screen is copied several times to the middle of the screen:
- The copies on the left are copied using logical operation 0 (IMP).
- The copies on the right are copied using logical operation 8 (TIMP).
Thanks Javi, I've tried even with logical op 8, but it doesn't works. Here goes the pictures:
This is the custom palette in MiFui. As you can see, I've selected RGB=442 as transparent since it's only used in background tiles.
This is the upstatirs tile. Since it appears on background, I can use transparent color and copy it using without transparency.
This is the background generated in BASIC with PSET option (no transparency)
Same screen in MSX-C, the upstairs are transparent, whenever logop=0 or logop=8.
What could be wrong? Thanks.
Same screen in MSX-C, the upstairs are transparent, whenever logop=0 or logop=8.
What could be wrong? Thanks.
Can you show the relevant part of the code?
Same screen in MSX-C, the upstairs are transparent, whenever logop=0 or logop=8.
What could be wrong? Thanks.
Can you show the relevant part of the code?
Sure, here goes:
/* Iterate over all tiles of screen 16x16 tiles */ for(y=0;y<=12;y++) { for(x=0;x<=15;x++) { adr=(x+y*16)+(int)(256*(int)sc); pantalla[x][y]=stage[adr]; /* stage contains tiles of all stage */ tl=pantalla[x][y]; if(tl==0) { /* If tile=0, copys a black tile located in 240,144 */ cpyv2v(240,144,255,159,(TINY)1,(NAT)x*16,(NAT)y*16,(TINY)0,(TINY)8); } else { /* In other case, copy the tile located in x-y */ sx1=(NAT)((tl-1)%16)*16; sy1=(NAT)((tl-1)/16)*16; cpyv2v(sx1,sy1,sx1+15,sy1+15,(TINY)1,(NAT)x*16,(NAT)y*16,(TINY)0,(TINY)8); } } }
Anything strange?
I don't see any obvious errors in the code (though you don't need all these casts).
Let me see if I understand this: the steps in the ladder tile are drawn in color 0?
By the way, this is what I did in the test program above:
@darkschneider,
Look at "HLT is a privileged instruction" in the 386 docs, that means it no more is a halt but does CALL the kernel.
Your feel about the issue is right in case there is
a sucessor of z80 with priviledged instructions
a new MSX using that
someone writing a DOSbox style virtualization for said MSX
rather hell freezes over
more likely there is a multitasking OS for the MSX with original z80. And there using HALT doesnt work.
once the OS is out, you need to add some function call to your app.
but yeah, the HALT instruction within the jiffy check loop can't hurt. but it is for dreaming purposes only
@Axelstone, the suspicious part about that color is not the RGB values, but that it is color number 0
rather hell freezes over
Only if you don't interrupt Satan. :-)
(sorry, had to)
Or maybe HALT him
@JaviLM Thanks for your help, I don't understand what could be wrong. Yes the problem is that color 0=black allways. In basic, as you can see, color 0=RGB values that it has. About casting, I must use incorrect compilation options, if I try what you are making (for example cpyv2v(.........,8)) I get compilation error: 9th argument conflict,I must made explicit casting to everything similar to your screen((TINY)5). My .bat compilation file is taken from your blog's tutorial
@hit9918 It thinks so, it's like color 0=black, whenever it RGB values are. It's strange because in BASIC there is a different behaivour as I said, and using this trick I could use full 16 colours instead of losing color 0 in transparent black.