| |
Mirage
Registered: Jan 2003
Posts: 113 |
New PC paintprogram for c64
Some of you might already know this, but i've been working on a paintprogram of my own for some time now.
It's based on Paint.Net (http://www.eecs.wsu.edu/paint.net/ (check it out, it's great (and free!))), so it has layer functionality, effects, all default tools, antialiasing, unlimited history and more fancy stuff you'll only find in that program and photoshop but my adaptation also has filters to convert to c64 formats (FLI, koala and single color bitmap but also the option to convert to sprites and more).
On top of that you can paint and draw in single and multicolour mode with all 16 c64 colours and a transparent colour.
Here's a screenshot of what it currently looks like and shows some of the features:
http://www.tehwinnar.com/timanthes001.jpg
It currently doesn't export anything, because i'm not quite sure how to implement that yet, so any suggestions are welcome :)
For the moment i'd like to get some feedback and in about a month (I have to put together a document first on how to use it) I'll be putting out a first alpha version which people can test (this requires windows 2000/server 2003/XP and the .Net framework 1.1)
Cheers,
Mirage/Focus |
|
... 91 posts hidden. Click here to view all posts....
|
| |
Hein
Registered: Apr 2004
Posts: 945 |
Quote: hmm.. transparant background is REALLY nice idea.. that way it's easy to add rasterbars behind :) more colors!! yay!
i think it will also not be that hard to make super-UFLI modes this way, with all sprites differently colored ,and vertical sprite-color splits :) maybe even moving sprites in x also!
Your pinball tables would have been graphically finished a lot faster too... |
| |
Hein
Registered: Apr 2004
Posts: 945 |
Quote: madcrow: I disagree with the 2nd part of your post. Restricting the inner data structures of an existing Paintproggy to 16 colors, and run a c64 mode restriction filter when something changed is a good idea imho. If the proggy thats being modified is cleverly designed this can work out real good.
mirage: if .net is fast enough try to make the filters to try all possible color combinations out of the colors used in the char then pick the combination with least error, rather than dropping least used colors. what if you have the same amount of pixels of different colors "least used", how can you pick which is best to keep ?
It was something Mirage asked to Sander and myself, and I think the concluding method has proven to be a good solution. Especially the fact that the 16 colours per char remain in a layer and clashes only appear when the layer restrictions are set to appropriate format, is incredibly handy.
In other words, usability of a tool is more important than detailed codepron. RTMFP is often the answer, even if the interface stinks and priorities are set to wrong issues. |
| |
Oswald
Registered: Apr 2002
Posts: 5086 |
Hein: I was suggesting a slightly better method. |
| |
Mirage
Registered: Jan 2003
Posts: 113 |
Quote: madcrow: I disagree with the 2nd part of your post. Restricting the inner data structures of an existing Paintproggy to 16 colors, and run a c64 mode restriction filter when something changed is a good idea imho. If the proggy thats being modified is cleverly designed this can work out real good.
mirage: if .net is fast enough try to make the filters to try all possible color combinations out of the colors used in the char then pick the combination with least error, rather than dropping least used colors. what if you have the same amount of pixels of different colors "least used", how can you pick which is best to keep ?
Oswald:
I don't see a difference between your method and mine?
Let's say I've got 1 char with 5 white pixels, 3 yellow ones, 2 green ones and 2 blue ones...
If I keep the green pixels I will have 2 blue pixels clashing, if I keep the blue pixels I will have 2 green pixels clashing...
I have no way of knowing which colours i should mark as clashing either way... For now I just pick the first color i find and mark the other ones as clashing, so if the upperleft pixels happens to be blue then the green colours will be marked as clashing. |
| |
Oswald
Registered: Apr 2002
Posts: 5086 |
mirage: I've implemented both methods, but checking now I think most of the time there's only minor difference. A picture needs to have a big amount of colors / chars to have differences big enough to be spotted instantly by eye.
There's a difference in what our routines do. You search for clash bugs, and I use them for converting pics. Deciding which pixel is better to mark as clash bug is rather a matter of taste or philosophy.
I convert a char with all possible 3 color combinations (out of the colors used in the char). If there's a color in the original char, that's not in the current 3, then I check RGB color distances, and I will replace that color with the closest from the current 3 . Then I add the distance to an error value, thats stored for each color variation/char. At the end the char will be converted with the 3 colors that generated the smallest error.
Taking your scenario my routine would drop the 2 green pixel, as replacing green with yellow results in least distance (error) as replacing blue (I assume dark blue) with yellow white or green.
However I think that the best algorythm is in a good gfxer's eye :) |
| |
Mirage
Registered: Jan 2003
Posts: 113 |
"However I think that the best algorythm is in a good gfxer's eye :)"
So true, that's why i'd rather not start replacing any colours for others and just leave them marked as 'clashing colours' after which the gfxer can just replace them with whatever colours he or she sees fit (or replace some non-clashing colours, so that the clashing colours become non-clashing again) :) |
| |
Optimus
Registered: Jan 2002
Posts: 122 |
Oswald: Maybe that's a bad surprise (and funny coincidence for some :), but I don't think it makes your programm useless. I had it in my HD and started already using it now I started working on my second C64 demo. It helped me on converting some small gfx and repixeling them so that they don't look awfull. Perhaps I will pixel something with that too in the future. Perhaps the other programm is more complicated and I may prefer to use yours for the simple stuff. Anyways,. I think I'll keep both of them in my HD. I actually got inspired for starting something similar for the sleepy CPC scene (I don't know when :)
But where is now the link of Project One? I was looking for it some days ago and now I can't even find the CSDb entry here! ;P I need to download the newest version if it's newer than the one I have (can't check right now) |
| |
Mirage
Registered: Jan 2003
Posts: 113 |
Me trying to export stuff over the last couple of days:
First bitmap:
www.tehwinnar.com/regvice.jpg
Colors:
Oops, wrong bitorder... fixing:
Better... now trying to paint over the image to see what it'll do to colorclashes:
Still ok... we're exporting... took this oportunity to fix the palette colours... this is what it looks like now:
Trying to export an FLI image now...
Can't be bothered using the right opcodes to get the right colours in those 3 chars on the left at the moment... I'll leave that for a later time :)
Checking palette again:
Still looks fine...
Spent some time converting/retouching some pictures in FLI:
Still all fine... I will spend some time now integrating exporting and quick viewing in vice... over time i will have finished my realtime pal-emulation-preview window from within the paintprogram |
| |
Hein
Registered: Apr 2004
Posts: 945 |
amateur :) |
| |
Mirage
Registered: Jan 2003
Posts: 113 |
het is hier allemaal wat moeilijker dan op het focus forum... ik kan het niet helpen dat onze spullen superieur zijn, hoor |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 - Next |
