| |
Oswald
Registered: Apr 2002
Posts: 5017 |
P1
Project One V0.5
post bugreports, questions, feature requests here, should be a better place than the comment area of the release.
|
|
... 276 posts hidden. Click here to view all posts....
|
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
okay, Valsary's finding is not a bug, it's a feature :D. In that situation in the character there's simply no place for any more colors, AND the option "4th color replaces" is turned on. This option makes P1 to replace the old color if the new color cannot be put down. and this is exactly what happens.
Valsary: "@Oswald: Hmm...You're right, but notice that while you can add that color in FLIGraph as a normal pixel, you cannot add it in P1 until replacing another one, just look again at those links i sent and try paint the same char i did in FLIGraph into ProjectOne. I noticed that when i start fill the char with yellow color as first it works ok, but always when try like i reported, i cannot put that yellow pixel at all or duble it by replacing blue."
I think this is due to the different distribution of colors amongst the attributes.
P1 has the purple as d800 and brown and red eats up the possible screen ram colors. So the yellow line just does not fit in.
fli graph has probably blue or purple as d800, so the yellow line still fits in.but it can work in other situations too.
maybe this should lead to a consideration of in what order the different attribute spaces should be filled up ? |
| |
Valsary
Registered: Mar 2004
Posts: 11 |
>maybe this should lead to a consideration of in what order
>the different attribute spaces should be filled up ?
yes...in what order, i think $d800 should be filled first, but i'm not sure, just trying to image how it would work then. |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
I have a neat idea. P1 could actively monitor the attributes, and actively swap them in the background. The first rule that comes to my mind is to set the most used color to be d800. |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
@oswald: when you put a new pixel, the check all combinations of color attributing and choose a set that works. If none work, then you have a color clash. And only WHEN you have a true color clash you apply the scheme you have today. |
| |
Valsary
Registered: Mar 2004
Posts: 11 |
That's for sure great idea!!! P1 could use 100% of FLI mode posibilities then...same thing you can do with IFLI mode. |
| |
WVL
Registered: Mar 2002
Posts: 886 |
Quote: @oswald: when you put a new pixel, the check all combinations of color attributing and choose a set that works. If none work, then you have a color clash. And only WHEN you have a true color clash you apply the scheme you have today.
A scheme would be pretty simple, I even implemented something like this on the C64!!
- first check if there are 4-pixel-rows with 3 or 4 different colors (excluding $d021)
- check which color of that occurs in the most rows
- chose that color for $d800.
f.e.
$d021== black
row 1 - red, green, yellow
row 2 - blue, yellow, purple
row 3 - purple,blue
row 4 - red, purple, yellow
row 3 can always be handled with fli, so we dont look at it
rows 1,2 and 4 have >2 colors (not counting $d021), so one of them has to become $d800
then we start counting :
red is used in 2 rows
green is used in 1 row
yellow is used in 3 rows
purple is used in 2 rows
blue is used in 1 row
-> we pick yellow for $d800, and magically every row can be done. Ofcourse there's lots of situations where you still dont have enough colors, but hey, what can you do :)
|
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
Jack, the first part of your idea would work, the 2nd would have problems.
the problem is that you couldnt add new colors, coz every new color would be converted into one of the 3(+background) existing ones.
This would need a backbuffer of the colors that were really put down, and a visible layer of the resulted conversions. Pretty much like Timanthes. So far P1 works directly into an emulated c64 memory, and the picture is based on that.
edit: jack, Im not sure if completely understand u, if there's a clash, then reconvert the char ? |
| |
Jetboy
Registered: Jul 2006
Posts: 212 |
How about adding sprite layer?
That would probably only work on non-fli modes, but there would be some more posibilities. |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
sprites will come for sure. but before that the screen handling needs a major rewrite. (OOP instead of arrays and support for different sizes)
The biggest headache with sprites is that what should be supported and what not.
ATMO I think 2 modes should be done.
- mode1: each sprite works as a sprite column, so the height is unlimited. This would make ufli modes easyer to handle.
- mode2: sprites works exactly as on c64. you can define up to 256 sprites, freely positionable, max 8 on the same rasterline etc.
both modes would support change of all sprite attributes, mode1 would let all (or most) attributes to be set on a rasterline basis.
|
| |
Jetboy
Registered: Jul 2006
Posts: 212 |
That would be awesome!
Both modes would have good use.
The second mode would be especialy nice, but there are a lot of problems to solve.
1. It would require custom display routine to be generated for picture. That brings some complication as in some setup changing neccesary sprite properties wouldnt be possible (change all 8 sprites position, mode, color, multicolors, expansion in one line - which may happen to be bad line). It all can be taken into consideration, but it would be titanic work to force editor not to allow such combinations.
2. Two (or more) modes to paint. One - you treat each sprite as separate layer, and must select any given layer to be able to paint on it. You just paint pixels - hard as some sprites/background would be multicolor/hires.
3. it would benice if you could setup sprites position, and sprite number - so you can have multiple sprite data used in different part of the picture - you paint one - and all change. Somewhat like characters and character generators work.
It's alot to think of, and a lot to code, so maybe it is best to wait with those changes after the rest is done. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | ... | 29 - Next |
