Picross game
Is it really a problem if the number have different colors on the various lines ?
If you don't change the paper and the ink on each vertical line, and just use normal/inverse/normal/inverse, you will get your two paper colors, and the corresponding inverted paper color.
Let say you want BLUE and CYAN bands. That's colors 4 and 6. The inverted colors for 4 is 3 (YELLOW), and 1 (RED).
This means you can have BLUE/YELLOW and CYAN/RED without ever changing an attribute (ie: just playing with the inverted bit).
Now you will tell me "Yes, but I also need to highlight the line currently selected by the player, and I can't insert an attribute color change for the vertical lines".
And this is correct.
But then you can use the second level trick, which is to reverse the reverse
If you display normaly, you can have: YELLOW on BLUE
If you invert the video, you get RED on CYAN
But if you do a XOR %00111111, you get also BLUE on YELLOW and CYAN on RED.
This may or may not help you, but looks good so far, keep up the good work
If you don't change the paper and the ink on each vertical line, and just use normal/inverse/normal/inverse, you will get your two paper colors, and the corresponding inverted paper color.
Let say you want BLUE and CYAN bands. That's colors 4 and 6. The inverted colors for 4 is 3 (YELLOW), and 1 (RED).
This means you can have BLUE/YELLOW and CYAN/RED without ever changing an attribute (ie: just playing with the inverted bit).
Now you will tell me "Yes, but I also need to highlight the line currently selected by the player, and I can't insert an attribute color change for the vertical lines".
And this is correct.
But then you can use the second level trick, which is to reverse the reverse
If you display normaly, you can have: YELLOW on BLUE
If you invert the video, you get RED on CYAN
But if you do a XOR %00111111, you get also BLUE on YELLOW and CYAN on RED.
This may or may not help you, but looks good so far, keep up the good work
I am working on this and studying the possibilities... I am wondering if changing so many bytes will be practical, I mean in a line there will be (16+8)*6=144 bytes where I need to invert and I have to do the same to the vertical line that will double the amount of the bytes, 288. Each time the player moves over the board I will have to restore the previous position 288 bytes and inverse the new 288 bytes Perhaps this will be ok I haven't tried it yet.Dbug wrote:Is it really a problem if the number have different colors on the various lines ?
If you don't change the paper and the ink on each vertical line, and just use normal/inverse/normal/inverse, you will get your two paper colors, and the corresponding inverted paper color.
Let say you want BLUE and CYAN bands. That's colors 4 and 6. The inverted colors for 4 is 3 (YELLOW), and 1 (RED).
This means you can have BLUE/YELLOW and CYAN/RED without ever changing an attribute (ie: just playing with the inverted bit).
Now you will tell me "Yes, but I also need to highlight the line currently selected by the player, and I can't insert an attribute color change for the vertical lines".
And this is correct.
But then you can use the second level trick, which is to reverse the reverse
If you display normaly, you can have: YELLOW on BLUE
If you invert the video, you get RED on CYAN
But if you do a XOR %00111111, you get also BLUE on YELLOW and CYAN on RED.
This may or may not help you, but looks good so far, keep up the good work
From a purely CPU point of view, you can transfer without any problem at least one kilobyte of data while still staying at 50fps, even with a very crappy routine.
If it ever become a performance issue, you can count on a number of people here helping to get this "invert 288 bytes" routine fast enough
If it ever become a performance issue, you can count on a number of people here helping to get this "invert 288 bytes" routine fast enough
GreatDbug wrote:From a purely CPU point of view, you can transfer without any problem at least one kilobyte of data while still staying at 50fps, even with a very crappy routine.
If it ever become a performance issue, you can count on a number of people here helping to get this "invert 288 bytes" routine fast enough
Finaly I am back to this...
Log
- Instead of building the screen with a routine, I have used HIDE(Thank you Twi) and compacted the screen, takes 1.7Kb.
I have a problem with the movement of the target, althought it moves quite well it flickers a lot, any ideas on how to fix this?
Next:
-IRQ
(Will add a pic later on, the website I use for hosting is in maintenance now)
Log
- Instead of building the screen with a routine, I have used HIDE(Thank you Twi) and compacted the screen, takes 1.7Kb.
I have a problem with the movement of the target, althought it moves quite well it flickers a lot, any ideas on how to fix this?
Next:
-IRQ
(Will add a pic later on, the website I use for hosting is in maintenance now)
Thank you Dbug, I want to add some gfx to the lower right area... will have to see what I will do about it, I am not that great with gfx
Thank you also for the help with. As you told me to do, I am using now a backbuffer where I draw all before copying its contents to the screen. This reduced the flicker dramatically, barely noticeable now. I think sooner or later I will have to move to disk as memory will be tight if I want to add a fair number of levels.
I need to work on a presentation/menu screen.....
I changed the colours a bit and added that little screen where the picture of the level will be displayed once the player finishes it:
Thank you also for the help with. As you told me to do, I am using now a backbuffer where I draw all before copying its contents to the screen. This reduced the flicker dramatically, barely noticeable now. I think sooner or later I will have to move to disk as memory will be tight if I want to add a fair number of levels.
I need to work on a presentation/menu screen.....
I changed the colours a bit and added that little screen where the picture of the level will be displayed once the player finishes it:
It has been on hold, looking for some incentive, I got some nowibisum wrote:This is looking really nice - any recent updates by chance?
Also what has hindered the development is that I can't get oricutron to work in mu linux box. I don't rather not use euphoric. oricutron works under Wine but I am picky what can I do....