|  Post Your Message | |
| |
| | Previous Messages | Posted By
MMS
on 2017-02-03
18:05:13
 |  Re: Colors area for Multicolor screen
Hi Mad!
No issue! I never though it was by intention, sometimes the 64bit OSs behave badly with 32bit code.
I will check it out, and many thanks for your kind help! I really appreciate it.
|
|
Posted By
Mad
on 2017-02-03
08:45:51
| Re: Colors area for Multicolor screen
Hey MMS i compiled it with a normal visual studio (i do also have win10 64bit). I'll check the settings. I can give you the source, if that could help, but it's really hacky.. PM me if there are further problems..
edit: I compiled it again with all the standard settings (inclusive manifest generation), the one before was compiled with mostly my pc 4k settings. However it ran on my computer without problems and kaspersky didn't say that it's a virus.. the newly compiled is here: https://www.dropbox.com/s/7k639bhtpgcxmnv/3farb.zip?dl=0 perhaps this runs. but remember you have to specify a commandline argument (the png you want to convert)
edit2: if nothing works, download the source which should be easily compileable in VS2008 or higher, here: https://www.dropbox.com/s/e3fq9mg8iob7m2e/3farbkonverter.zip?dl=0
and sorry for the inconvenience, this was not intended!
|
|
Posted By
MMS
on 2017-02-02
17:11:18
| Re: Colors area for Multicolor screen
Hi Mad,
Thank you for the proggy, I downloaded it! I will test it this week.
Today I finetuned my BASIC "soft-sprite" routine and the movement of the crosshair, on a (still) drawn multicolor backgound (you know, circle, box and the others  )
Yeah, it works, and not interfere with the backgroung and with attributes (before and after movements I use the SSHAPE and GSHAPE, but not hassle with the copy of the crosshair with GSHAPE+XOR)
I may need some speed increase in the drawing, as it takes ~0.8sec. I will test if this direct drawing or the GSHAPE routine is faster.
Unfortunately none of them will become faster after compiling it.
Maybe it will be fastest, if I would go back the "bloody roots", and draw the crosshair with BASIC2.0 style direct POKE commands (if I use only fix positions, then it may work)
PS: thank you for your comment on VDC challenge! BTW I am amazed by Bauknecht stuffs, keep on the good work!
For a long time I also used only FLI, IFLI and IHFLI pictures. The HFLI quality was also a surprise for me some time ago But in 30-40% of the cases the HFLI look much crappier than FLI, and need much more photoshop like prework, but that is the part of fun 
Update: sorry it hngs and completely kills my Win10 64bit, also Avast goes crazy with it. Never mind, my diplome work Mandelbrot kills it completely too :-)
I will check it with my second PC I am just repairing, it has Win7 32bit.
|
|
Posted By
Mad
on 2017-01-24
10:25:18
| Re: Colors area for Multicolor screen
So here is a little windows executable, which should do a very primitive approach to convert the picture.
It needs a 320x200 image as input (perhaps already converted with the plus4emu tools so that you already have a multicolor picture with dithering).
I think I don't have enough time to code a propper picture conversion tool with everything needed for it, that would consume too much time.
The "tool" here converts a 320x200 png picture given by the commandline parameter, to an only 3 colored multicolor block one with the background color set to black. You must specify the png as the only commandline parameter else it will be crashing ..
Sorry that I just can't do more at the moment.. Perhaps you can use the tool to get some propper test graphics for your basic programm. (However it uses a fixed plus4 palette at the moment, what could also be a drawback) A good tool would take a lot more time and effort..
Ah and it outputs the bitmapMemory (8000 bytes) and ColorMemory(1000 bytes) and LumaMemory(1000 bytes) and the converted .png. (didn't test it, yet. The base are the routines I use here to convert all the images to plus4.)
So here it is: https://www.dropbox.com/s/7k639bhtpgcxmnv/3farb.zip?dl=0
Sorry for that primitive approach, a propper converter would take much longer.. Perhaps I will look somewhen into the plus4emu sources of that tool, it should be easy to get it working with only 3 colors, the main problem would be to get it to compile here.
Perhaps some others, could help, too.. :)
ps: The VDC Challenge rocks, didn't know that such clean HFLI pictures are possible.
|
|
Posted By
MMS
on 2017-01-23
19:07:43
| Re: Colors area for Multicolor screen
Hi!
Thnx for the response! Probably I could use that...
Well, imagine a crosshair.
If that Color 3 object (or drawing) is just 8x16 pixel size (in multicolor, in hires size: 16x16) then it could be fast enough even with XOR-ing it again to backgroung remove the previous stage and to save the next background (if necessary at all). Approximately 0.5 - 0.7 sec the total period,, you you can notice the crosshair drawing with your bare eyes, but not annoying.
I am just writing the cursor control to move aroud (into fixed positions).
|
|
Posted By
Mad
on 2017-01-23
18:21:06
| Re: Colors area for Multicolor screen
Looks like a serious bug. Don't know, why it is implemented that way, perhaps just size reasons, so that the color an luma ram get updated everytime, too. Dunno why noone noticed it in the past, perhaps it's just the usecase with the background picture, but that is very unlikely, too.
One question, do you think you could move a color3 object purely in basic? If you want a simple 3 color multicolor converter (instead of the 4 colors) for a picture I could supply one.. I just don't know if basic is fast enough for blitting a whole object over the bitmap in a considerably good speed.
So, what I wanted to say: "nice find!".. Let's see if someone has a clue about this!
|
|
Posted By
MMS
on 2017-01-23
17:44:53
| Re: Colors area for Multicolor screen
Actually, I found a rather strange behaviour of the DRAW routine.
I loaded converted multi picture, and wanted to draw on it.
I tried to draw lines with Color 0, 1, 2, 3, and although color 0 and color 3 are global, the all the lines drawn messed up the attribute memory, instead of just setting the pixels to background0 or color3, as it should be (as they should not infuence the attribute clor/luminance map at all).
Even if the converted graphic has such a chaotic attribute settings, how the color3 line can influence it at ALL?
The DRAW routine should NOT write anything to the color / luminance memory, just to the bitmap when I draw with 0 or 3 color setting.
I tested YAPE and Plus4Emu, and they behave the same.
Please let me know if I missed a logical step or explanation there.
As you can see, it is a normal multiciolor bitmap, quickly converter to show the problem.
I drew 4 lines, the first is with color 0 (background) is almost non visible, but messed up the attributes near to first wheen/tyre.
Then came the lines with Color1, then Color 2 and finally Color 3.
As you see, all had influence on the color attributes at some area, though color 0 and color 3 should not have any, just changing the bitmap's double pixel to the two color register's representative pixel pair value. Strange, yeah?
Maybe it could be a great improvement of the Plus4emu converter, if NO Color3 would be used AT ALL during conversion. sure, it would greatly reduce the color and fine details., but you could freely move a Color 3 object over the screen, like a soft-sprite.
|
|
Posted By
SVS
on 2016-09-09
09:01:55
 | Re: Colors area for Multicolor screen
Thank you all.
I supposed (well: I hoped) that by modifying (writing) a cell, some routine would update the colors/luminance areas with the current colors at $FF17, $FF18.
It should be useful to decompile the DRAW command since, as Csabo said, it takes care of it automatically.
[Update]
While DRAW and BOX do update the col/lum areas, it seems that a simple CHAR w,x,y," ",1 does not! :-( Even if w specifies colors 1 or 2.
Any other tip?
|
|
Posted By
Csabo
on 2016-09-08
19:06:23
| Re: Colors area for Multicolor screen
"Is there a way to automatically store these colors (for that 4x8 cell) in the Colors' area?" No, there isn't. If you POKE into the bitmap, the colors will not be changed.
"Or maybe one have to calculate and set it manually :-/ ?" Yes. It's not that hard though The BASIC DRAW command would take care of it.
|
|
Posted By
gerliczer
on 2016-09-08
15:13:03
| Re: Colors area for Multicolor screen
Hi SVS,
You should really check the Ultimate Map. I think you know the guy who made it.  As Luca already said, the colours 1 and 2 are defined by the luminance and colour matrices. There is a handy little routine in the ROM at $C5A7 that helps filling memory areas in multiples of 256 bytes.
|
|
Posted By
Luca
on 2016-09-08
15:03:43
 | Re: Colors area for Multicolor screen
Wait a minute: you're talking about bitmap, where $FF17 and $FF18 have no role: in a MC bitmap you set $FF15, $FF16 and the two assigned colors by assigning their luminances in $X000-$X3E7 and their colors in $X400-$X7E7.
|
|
Posted By
SVS
on 2016-09-08
12:55:39
| Colors area for Multicolor screen
I have a question for you graficians! (Sorry if it is a lame question...)
I want to directly draw to Multicolor screen, by poking byte by byte the image over the bitmap. I've set the colors (1, 2, 3) to the TED registers #16, #17, #18.
Is there a way to automatically store these colors (for that 4x8 cell) in the Colors' area? Or maybe one have to calculate and set it manually :-/ ?
|
|
| |
Copyright © Plus/4 World Team, 2001-2024. Support Plus/4 World on Patreon |
