| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Urgently needed: proper Bordergfx-editor!
The c64 scene definately needs an editor for proper border gfx! I'm fucking fed up with making my stuff on Potatoshop, counting colors manually while i pixel it and having to rely on the coder to convert it first to see what it it actually looks like on the real machine! And I probably hate doing it in Amica Paint (with totally different color restrictions!) just as much as the coder who later has to convert it to sprites!
From the feedback I got I know that people fucking love my border-GFX, and I myself enjoy it every time I see it done by others (like Duce's Catrabbit from X2008! Respect, pal! 8), and I think pretty much *every* gfxian would welcome the possiblity to extend his compopicture into the border, it's just that hardly anyone has a coder to work with that is willing/able to do this for him, and lacking the proper tool to do this with is pretty much the main problem here!
There's only two editors for border gfx I found (and no, I ain't talking about expanded-sprites-only stuff like ESCOS, I'm talking bitmap gfx, possibly Drazlace!): One allows you to extend some 4-color-gfx into the border (in 4 colors only any only sth like 10 chars high - meh!) and the other one is OSCAR from some OZ dude, done in 1988 (god, that code is SO inefficient with all the jumptables!), which I've added to CSDb.. I've spent some time working in this last December, and I can tell you that if you think our gfx-editors are unusable, you fucking ain't seen OSCAR yet! <:-) The unusability knows no bounds in this one, it's basically a new definition of the term!...
Here's what I'm thinking: Two separate editors, one for sideborder and one for upper/lower border, since the demands are rather different.
1) Sideboder editor feature list:
-should allow for loading standard bitmap gfx (also laced) in hires or multicolor (Koala, (Adv.) Art Studio, plain bitmap, Zoomatic, Drazlace, P1's Drazlace advanced for 2 screenRAMs)
-4 sprites
-Should allow setting the x-position and expansion of the sprites arbitrarily, but fixed for the whole screen. Pre-set layouts for the technically less inclined:
-2left/2right: 2 Mcol sprites side by side, 6 chars full width per border
-2left/2right: 2 Hires sprites side by side, 6 chars full width per border
-2left/2right: 1 Mcol sprite+1 expanded Hires sprite overlaid for 3 outer chars 1 color and 3 inner chars 4 colors (+$d021), 6 chars full width per border
-2left/2right: 1 Mcol sprite+1 Hires sprite overlaid, 3 chars per border
-2left/2right: 2 Hires sprites overlaid, 3 chars per border
This should cover most needs. The people requiring more sprites on one side than on the other should adjust it manually.
-Color-switching: I know that quite often coders don't want the maximum amount of color switching because they need the cycles for other stuff, but making the editor as flexible to set the number of swtichable registers per line would be way more work than it already is, so just go for something sensible, switching all colors every line (except for the badline) is doable, but probably a bit much, since the picture itself is just standard bitmap, so something like new colors every 4 lines should suffice for almost everything. And yes, I know that it has to be 1 line off from the badlines in order to have new colors every charline, that's okay! ;-)
-Would be totally awesome if the editor could read out the left/rightmost bitmap column colors upon importing the bitmap and already set those for the sprites!
-Zoom mode must also at least display one char-column of the bitmap, otherwise making it seamless would be quite taxing.
-$d021 is fixed (since there's no editor that allows for changing $d021 rasterwise anyway!)
-must support saving executables, packed would be best!
2) Upper/lower border editor feature list:
-Should allow for loading (I)FLI as well as files written by the sideborder editor. Dare I ask for (M)U(I)FLI support? ;-)
-Needs extra flexibility in X-Positioning and sprite Expansion as compared to the sideborder editor. The user should be able to change expansion/x-position thoughout the whole border area instead of the colors.
-For the technically less inclined it would be best to set x-position for every sprite and expansion globally (but different for the upper and the lower border). Those that need more can just twiddle with the respective registers! ;-)
-Would be totally awesome if the editor could read out the top/bottom bitmap charline colors upon importing the bitmap, interpolate them and already set them for the sprites!
-$d021 needs to be switchable along with X-expansion, spritecolors and positioning! This is very important!
-must support saving executables, packed would be best!
And NO, we DON'T NEED yet another fucking Windows-only PC pixeltool to achieve this, this can and should very much be done on c64 itself! >:-)
I know this is a lot of work, but rest assured I and pretty much every other gfxian out there would REALLY appreciate this! ;-) I've talked to various coders about this and it seemed to me they didn't really see the need for this, but there really is NOTHING apart from the 2 lame/unusable tools mentioned above. So if you're a gfxian, let them know how much you'd like something like this by hitting that "reply" button below! ;-D
If you tweak the X-Position and expansion a lot, I guess people wouldn't mind too much if zoom view wasn't fully accurate. I'd just appreciate being able to do it at all, and it'd still be less wrapping-my-head-around-it than doing it in Photoshop or Amicapaint, believe me! ;-D
I'd be more than happy to assist in development and beta testing if you decide to do this! |
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11164 |
get coding! |
| |
Stainless Steel
Registered: Mar 2003
Posts: 966 |
Get Crossbow out of retirement :-D |
| |
WVL
Registered: Mar 2002
Posts: 888 |
?Too many possibilities/options error |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Quote: get coding!
Thx for your valuable contribution, I'll try to remember that next time you ask me for PSX/GBA/Gamecube-gfx! <:-)
|
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Quote: ?Too many possibilities/options error
Well, nobody said it was gonna be easy! ;-) But see it that way: This needs to be done ONCE and then coders worldwide won't be bothered by stupid gfxians to add bordergfx ever again! ;-D Plus compopics will be alot BIGGER and more beautiful! 8)))
Also: if The Great Golden Dragon was able to do this (very unusably though) in 1988 (!) already, shouldn't we be able to improve that 20 years later? ;-D
Let me just mention that the featurelist above is an ideal one and doesn't have to be implemented right away. For a start I would be *very* happy already with a sideboder editor that only supported those "presets" mentioned above and an upper/lower border editor that only allowed one fixed x-positioning and expansion for the upper and lower border. Colorswitching is a must though, although for the start every 8 lines should also suffice...
As for gfx-importing: one format for every mode should be enough, you can just use other gfx converters to convert into this format! |
| |
chatGPZ
Registered: Dec 2001
Posts: 11164 |
i really fail to see how something like timanthes wouldnt be suited (and comfortable) for this task. (yeah yeah, evil windows only, too bad. thats what you get for using a niche OS). and i very much doubt aswell that suddenly everyone would be doing border gfx too - it's not like that ever happened with any of the other fancy gfx modes either :) |
| |
SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
.make the pic in timanthes in 320x256, save as bmp
.code a converter that strips the border and converts it into sprites
.code a setup
mwahahahah |
| |
yago
Registered: May 2002
Posts: 332 |
DeeKay, your Requirements are FAR too big to be attractive for any coder.
Cant you just use a (big) sprite-editor for the border gfx?
|
| |
Oswald
Registered: Apr 2002
Posts: 5034 |
i would do it like this: a very basic VICII emulator is needed which only concentrates on the graphical output, then you can assign a value to each sprite register for each rasterline + a sprite setup with the only restriction being 8 max on same line.
then the rest is up to the gfxer :) tho the user interface is a bitch alone, how to decide which sprite to plot into when they are overlayed etc.
finally the pic inside the borders could be imported as bmp from other editors.. |
| |
Stryyker
Registered: Dec 2001
Posts: 465 |
What platforms are acceptable for the editor to run from? |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Quote: i really fail to see how something like timanthes wouldnt be suited (and comfortable) for this task. (yeah yeah, evil windows only, too bad. thats what you get for using a niche OS). and i very much doubt aswell that suddenly everyone would be doing border gfx too - it's not like that ever happened with any of the other fancy gfx modes either :)
There's a few problems with Timanthes, and windows-only is only one of them
a) It doesn't support Interlace
b) Saving sth like that as executable would be major work, just as much prolly as doing a new editor
c) AFAIK it doesn't export sprites right now, so that needs to be implemented
d) right now it doesn't support bordergfx, so the special restrictions etc would have to be implemented
e) it's not a c64! ;-)
I think doing it in Timanthes would not differ very much from doing it in Photoshop, so I don't really see an improment here. Also, the work that would be required to implement this would not be that much different from doing it on c64 itself! And most importantly: If it's not easy to use and requires a coder, hardly any gfxian will use it! ;-)
Ease of use is the main reason other fancy gfx editors aren't so popular. And since there is only OSCAR, well, that pretty much explains why there are so few border-pics! 8) |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Quote: DeeKay, your Requirements are FAR too big to be attractive for any coder.
Cant you just use a (big) sprite-editor for the border gfx?
Well, If I thought that way, a lof of nice Crest parts wouldn't look as good! 8) I'm talking about stuff like "make me a sprite logo with 1 new color every line" (Coma Job FS-Plasma) or "make me a texture that only uses 3 colors every line" (Deus Ex X-Rotator) or "make me a logo that only uses 3 colors in the first 6 chars and 1 color in the next 6" (One-Der Wolfenstein) etc/pp...
Come on! This is far from impossible to do, and like said, it doesn't have to feature EVERYTHING! An usable OSCAR with some flexibility in the sprite expansion and x-positioning would be enough already!...
And no, I can't use a "big sprite editor", since that neither does color-changes nor does it show me the bitmap, so it's impossible to make it seamless... |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Quote: What platforms are acceptable for the editor to run from?
Well, I'd prefer c64 first and foremost! ;-)
If that's not an option for you, try to do it in SDL, that will be portable for almost any platform out there...
If you can't do that and opt for a wxwidgets/java/realbasic/QT-solution: Supported should be Windows, Linux and MacOS... |
| |
Dane
Account closed
Registered: May 2002
Posts: 421 |
Definitely less effort to work with a large canvas in Paint Shop Pro and pixel according to your sprite limitations. So no thanks, I'll pass. |
| |
algorithm
Registered: May 2002
Posts: 702 |
If pixelling by hand, non interlaced, like dane mentioned, use a program such as photoshop/paintshop pro keeping into consideration any limitations. use layers for any sprite overlays etc and feed the data through a converter which will convert to the required c64 sprite/bitmap format
Saves a lot of time and effort to create a drawing tool when everything you have is there
For wired conversions this is rather different as you would need specific reduction routines (eg dither, blending, mixing)
|
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Dudes, learn to read! I've been doing my bordergfx exactly like this for ages now, and IT SUCKS! First of all, keeping track of color usage manually is a pain in the ass. Second, this way ALWAYS requires a (rather skilled, at least if you wanna go sideboder plus upperlower boder) coder, so no GFXian can do it on his/her own!
Oh, and thanks for your support, Dane! >:-( Have you even thought about those GFxians that can't code? Trying to keep the border for "the elite", eh? |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Just to give you an idea what kind of improvement this would bring, compare this:
Cybernoid II +4 versus Freakout
..and keep in mind that what I'm proposing will even add another 6 chars left+right, since OSCAR only covers 3 chars on each side! ;-) Oh, and just try to ignore the lame expanded MCol sprites, this would be the first thing that needs to be improved from OSCAR! |
| |
null
Account closed
Registered: Jun 2006
Posts: 645 |
I think DeeKay's idea is pretty cool, but I somehow have the feeling such an editor is going to take a long time to actually surface...
------------------------------------
http://zomgwtfbbq.info |
| |
Sander
Registered: Jan 2002
Posts: 493 |
suport the call to make the border area accessible for everyone: Urgently needed: proper Bordergfx-editor!
Well Daniel.. you asked for it ;)
First of all, I'm very glad to see you passionate about scene matters!
But,.. I personally do not experience the lack of it, personally i'd go for a chat with the coder for the specs, work my way around it in Photoshop+Timanthes, have Mirage fix my mistakes (thx!), then it's off to the coder.
I understand what you mean, if it were a decade ago and i'd still be enthusiastic about pixeling in general, i might have felt the same. But today, i don't.
(Having said that, i've lost interest in hardcore pixelling, guess that's quite fundamental for this one :)
Anyway, i'd say; if Deekay needs one - he should get one! |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Sander: thx for your support, but *I* can hassle coders I know to do it, just like you. After all, I've made quite a few border gfx so far (best would probably be the frog in Risen from Oblivion, though hardly anyone has seen this! <:-). I'm actually thinking more of the people that *don't* have coders they can hassle. Plus it helps to keep in mind that coders are *MUCH LESS LIKELY* to put your compopic into the border than, say. gfx for s a demopart they made! ;-D
Let me stress once more that once a tool like this exists, *all* coders have way less work to do, converting, coding, arranging and fixing the sprites for bordergfx! ;-D
Come on! ESCOS was 22 years ago, and OSCAR 20! There's pretty much dozens of different tools for each graphical job on the c64, all basically doing the same thing (FLI/IFLI/Bitmap/Char/Sprite editors, converters), why not for border gfx? |
| |
Clarence
Registered: Mar 2004
Posts: 119 |
Side-Border Logo Editor V1.0 :)
|
| |
Twoflower
Registered: Jan 2002
Posts: 434 |
I support this noble cause. I stand up and say: yes! |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Thanks Clarence, that's the severeley limited 4-color-editor I was talking about in the original posting! 8)
But using that could be a starting point! ;-D You could even throw out all the char-logo-editing stuff cause that's not needed! |
| |
Dane
Account closed
Registered: May 2002
Posts: 421 |
Quote: Dudes, learn to read! I've been doing my bordergfx exactly like this for ages now, and IT SUCKS! First of all, keeping track of color usage manually is a pain in the ass. Second, this way ALWAYS requires a (rather skilled, at least if you wanna go sideboder plus upperlower boder) coder, so no GFXian can do it on his/her own!
Oh, and thanks for your support, Dane! >:-( Have you even thought about those GFxians that can't code? Trying to keep the border for "the elite", eh?
All your borders are belong to us! :D |
| |
Hein
Registered: Apr 2004
Posts: 933 |
I doubt there are many graphic artists who will want it. If they want to do specific border graphics (the 2 cool people out there), maybe they can try to enjoy the fun coders have to go through whenever something special has to be done. Timanthes supports sprite export, though. Besides that, every border graphic is so specific, because we want to get the best possible solution anyway. X/Y-stretched underneath hires sprites and other odd combinations. Spend a night preparing your sprites and find a coder (or DIY).
Obviously, you are the one urgently in need of that special coder person.
[edit]You know enough about c64 graphics and bicycles, it won't take you long to learn assembly so you can write your own display code[/edit] |
| |
algorithm
Registered: May 2002
Posts: 702 |
Cant you get Crossbow to do such a thing? Or is he too busy on 'meet crest'? |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Hein: I seriously doubt there are many gfx artist who will NOT enjoy this option! If you can extend your picture into the border and it looks cooler, why the FUCK not? 416*305 is a whole lot bigger than 320x200, in fact it is almost twice as many pixels..
Maybe people won't use it for everything, but I sure as hell can tell you at least 30 pics from the top of my head that would have looked way better if they weren't cut off by the border!
Did I mention that very many people have commended me on my bordergfx, telling me how much they enjoy seamless gfx that goes into to the border? Seriously: BORDERGFX! In 2008! Again: That's 20 years after OSCAR and 22 years after ESCOS, and IT IS STILL CONSIDERED BLACK MAGIC by people!
Seriously, I am quite baffled by the resistance some people show here. Why is that? What's the point in refusing to acknowledge this could be a great tool for the common gfxer? I for my part have been dreaming about an editor like this basically since around '89. Then RUN magazine supposedly had sth like that as a listing, so I sat down to first type in their whole toolchain (checksum editor and their "MSE", as data lines!) which was different from the 64er stuff I had ofcourse!) and then the editor itself. I was rather "happy" when I was finally done to find out that it was nothing more than an ESCOS-converter that would display a piece of a 4-color bitmap in expanded Mcol-sprites over the whole screen. Then I read in Propaganda about OSCAR and dug through every PD-archive in Germany to finally find it, but I was very disappointed when I got it that it was totally unusable. Well, some 18 years later I still don't have a tool for this (even though the codingskill required for fullscreen open border has been considered standard stuff for at least 15 years now!), I have made many bordergfx, but it was always a *very* tedious job and always required a coder!
Shame on you for not reading the specs I laid out above, otherwise you'd have noticed that I did think of maximum flexibility for almost any kind of picture...
And thank you, I do speak assembly already, in fact I hacked around in OSCARs displayer code, trying to achieve what I want (expanded hires sprites (to cover 6 chars instead of 3) plus Mcol-sprite in siderborder, unexpanded offset sprites in upper border). But since the code is rather inefficient and full of jumptables wasting cycles I got stuck somewhere, starved of cycles to switch some registers in time when going from upper border to sideborder. Re-coding the displayer (which I personally couldn't do!) is out of the question, since that'd almost certainly fuck up the already made spritegfx, as OSCAR is very specfic and weird about its sprite layout and bitmap data. Oh, did I mention it is a FUCKING PAIN to do actual gfx in OSCAR, which is what a gfxian should be doing?
Algo: Xbow is very busy these days and if he finds some time to do c64 stuff, it prolly won't be for sth he doesn't consider a breakthrough! ;-) |
| |
SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
Better to code a simple paint prog like Project 1,
and have the border there seperated with a white line,
and then when you paint in the border, it auto limits your color choices.
Click a button to on/off the border line, to see the whole pic.
|
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
rambones: what part about "not another windows-only solution" did you not understand?
In how far is this easier than coding the editor on the c64? Does the sprite-logic and sideborder code magically manifest itself through the mere use of Visual Studio (tm)?
PC-based pixelstuff has its merits and some stuff should or even must definately be done on the PC (believe me - I know! <:-) Simply pixelling in the border area is most certainly not one of these tasks... Crossdev is fine, but I have a feeling some people meanwhile advocate crossdev for crossdev's sake, and not because it actually makes sense... |
| |
Oswald
Registered: Apr 2002
Posts: 5034 |
"Well, some 18 years later I still don't have a tool for this"
"Urgently needed: proper Bordergfx-editor!"
:-) |
| |
JackAsser
Registered: Jun 2002
Posts: |
Quote: rambones: what part about "not another windows-only solution" did you not understand?
In how far is this easier than coding the editor on the c64? Does the sprite-logic and sideborder code magically manifest itself through the mere use of Visual Studio (tm)?
PC-based pixelstuff has its merits and some stuff should or even must definately be done on the PC (believe me - I know! <:-) Simply pixelling in the border area is most certainly not one of these tasks... Crossdev is fine, but I have a feeling some people meanwhile advocate crossdev for crossdev's sake, and not because it actually makes sense...
Ofcourse is it easier to code an editor on a modern HW with a modern OS than doing it on the C64. Come on... don't be so naive. |
| |
TPM
Registered: Jan 2004
Posts: 109 |
Well, i think Rambones' idea is the best so far. I can imagine there are several solutions to use sprites in the border, depends on the screenlayout together with some other gimicks and effects on the screen. E.g. then you can choose how the border sprite is generated (multicolored, interlaced, sprite overlays, etc), otherwise you sticked to the solution of the editor, i'm afraid, and for a designer that would be a limitation, while the designer usually doesn't prefer any limitation.
It's not for crossdev's sake, but for the best result sake ;) Crossdev just makes you (designer and coder) more flexible. |
| |
Mace
Registered: May 2002
Posts: 1799 |
Since we're thinking out loud, I'll dump some of my brainfarts:
During editing, I don't think it's necessary to have the sprites in the border already. In edit mode, the sprites can be within the screen area, with part of the picture attached.
No need to build an editor for the entire picture, but it might be wise to be able to pixel at least some pixels on the edge of the picture to make it fit better to the colour restrictions of the sprites.
Let's presume we're only talking about sideborder editing.
The layout of the editor could be so that one half of the screen holds the sprites and part of the picture, over the entire height.
On the other half you have a zoom area and perhaps a part with tools/icons/info.
Depending on which side of the picture you work on (left or right) these halves swap, so that it has some sort of an intuitive visual interface.
I thought of a name for the editor, but it seems there's already a Triad demo by the name of 'Over The Edge' :-)
Any suggestions?
|
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Quote: Ofcourse is it easier to code an editor on a modern HW with a modern OS than doing it on the C64. Come on... don't be so naive.
Dude, maybe you should check our tooldisks before you call me naive. I've used OSCAR and I've worked with and on many c64-tools and also made many SB-gfx to be able to say this is very well doable on c64 itself.. Using crossdev to *make* the editor is another thing, that for sure is easier and more comfortabe..
Maybe it helps to stress -yet again- that OSCAR is from 1988! <:-)
And for the record: With what I'm doing right now I can see what a huge difference there is between gfx displayed on a c64 and on a PC, PAL-emulation notwithstanding! |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
Reminds me of an idea I had a few years back - a gfx editor on a modern platform (preferrably Java or otherwise platform independent) which could handle any c64 mode. This could be done relatively easy if it was the user's responsibility to make something that was possible to display. The tool should just provide 8 sprites and a background layer to draw on, as well as all the VIC properties like multicolor on/off, border on/off, sprite x-expansion, sprite color, etc. customizable for each line.
The output format should include the bitmap/char/sprite gfx as well as some tables for all of these properties, and then the user needed to make a converter that could turn this into a displayer routine.
Not as easy to use as an editor for a predefined format, but easier than using layers in Photoshop, and a lot more flexible than a usual editor.
I think the ultimate C64 mode would be (I)UFLI with some more flexibility for the sprites. A single layer of sprites is not ideal since you need more detail on some areas, and on other areas the sprites are not needed at all. So it would be better if it was possible to concentrate the sprites where they are most needed, as well as change properties like x-expansion, multicolor mode and colors. MUFLI was a step in the right direction, but still not as good as it could be.
|
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
You may not notice it with Interlace-pictures, because it's all a blur basically, but PAL-emulation (which AFAIK none of the PC-pixeltools even supports!) is still *way* inadequate... |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Quote: Reminds me of an idea I had a few years back - a gfx editor on a modern platform (preferrably Java or otherwise platform independent) which could handle any c64 mode. This could be done relatively easy if it was the user's responsibility to make something that was possible to display. The tool should just provide 8 sprites and a background layer to draw on, as well as all the VIC properties like multicolor on/off, border on/off, sprite x-expansion, sprite color, etc. customizable for each line.
The output format should include the bitmap/char/sprite gfx as well as some tables for all of these properties, and then the user needed to make a converter that could turn this into a displayer routine.
Not as easy to use as an editor for a predefined format, but easier than using layers in Photoshop, and a lot more flexible than a usual editor.
I think the ultimate C64 mode would be (I)UFLI with some more flexibility for the sprites. A single layer of sprites is not ideal since you need more detail on some areas, and on other areas the sprites are not needed at all. So it would be better if it was possible to concentrate the sprites where they are most needed, as well as change properties like x-expansion, multicolor mode and colors. MUFLI was a step in the right direction, but still not as good as it could be.
Oh, MUFLI is fucking amazing, believe me! ;-) I thought about arranging sprites where they are most needed, kinda like the overlays in those Rainbow Arts intropics (Grand Monster Slam or Circus Attractions), too, but it'd make pixelling even MORE complicated than it already is.. Nobody is using our editors already anyway as it is, so the option to arrange sprites manually would be pointless and would prolly even scare away the people that dare to try it...
It helps to remember that "As good as it could be" depends *solely* on what picture you're trying to make!
I'm trying a quite different approach now to popularize these modes, stay tuned for that.. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11164 |
Quote:You may not notice it with Interlace-pictures, because it's all a blur basically, but PAL-emulation (which AFAIK none of the PC-pixeltools even supports!) is still *way* inadequate...
bullshit. infact its one of the most "real" things in vice, and 2.1 will fix the last remaining glitches too. it's scary how authentic it looks now to be honest :)
and you gotta be kidding that writing the editor for the c64 would be in any way compareable with making it for the pc. |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
Quote:You may not notice it with Interlace-pictures, because it's all a blur basically, but PAL-emulation (which AFAIK none of the PC-pixeltools even supports!) is still *way* inadequate... Still it's probably easier to do proper PAL emulation than to do the ultimate gfx tool on C64.
|
| |
Oswald
Registered: Apr 2002
Posts: 5034 |
Cruzer, right I said this too, an all round editor would need to feature a simple line based VICII "emulator" (concentrating on the output only), and possibility to change any register on any line. Ofcourse skipping the hairy stuff like d011 tricks, spritecrunch, d018 change should be possible on each line, sprite plexing should come for free just like turning off borders, etc. when this is done the hard thing is to find out & realize a clever user interface to draw into this :) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11164 |
Quote:
Cruzer, right I said this too, an all round editor would need to feature a simple line based VICII "emulator" (concentrating on the output only), and possibility to change any register on any line. Ofcourse skipping the hairy stuff like d011 tricks, spritecrunch, d018 change should be possible on each line, sprite plexing should come for free just like turning off borders, etc.
hehe, thats almost exactly how my converter works.... except i missed the opportunity to support gfx in borders when i started, and now its too late =P
Quote:
when this is done the hard thing is to find out & realize a clever user interface to draw into this :)
...and that was the point when i didnt bother to finish the whole thing :) the user interface is super annoying to code =P
|
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Quote: Quote:You may not notice it with Interlace-pictures, because it's all a blur basically, but PAL-emulation (which AFAIK none of the PC-pixeltools even supports!) is still *way* inadequate...
bullshit. infact its one of the most "real" things in vice, and 2.1 will fix the last remaining glitches too. it's scary how authentic it looks now to be honest :)
and you gotta be kidding that writing the editor for the c64 would be in any way compareable with making it for the pc.
..And this from the guy that uses the most sickening Color palettes? <:-)
It's definately not "bullshit", and you of all people should realize I know very well what I'm talking about. PAL-Emulation does neither dot-creep nor the "eating away" of pixels when rastered with black, which renders it EXTREMELY inaccurate for anything hires that's not interlaced, and AFAIK nobody even has plans to implement this...
And about the editor: Like others you keep forgetting that the main issue with such an editor is not the userinterface, but the c64-displayercode, quite unlike all the existing PC-pixeltools. The editor itself doesn't need anything else than setting pixels and choosing colors, so meh!
Ofcourse, if you want to do the "draw in all colors without restrictions and then convert to c64"-approach like with Timanthes, a PC would be way better suited, but that's not the approach I'm aiming for... |
| |
Mace
Registered: May 2002
Posts: 1799 |
Quoting Groepaz:the user interface is super annoying to code Typical for computernerds to find it difficult to communicatie with the outside world ;-) |
| |
Oswald
Registered: Apr 2002
Posts: 5034 |
"Like others you keep forgetting that the main issue with such an editor is not the userinterface,"
when the cursor is over arbitrarily positioned overlayed hires/mc/expanded sprites how should the editor decide which is the active plot surface/tint ? How would you like to setup line by line setupable registers ?
frankly its much easyer to write a pc based editor which I described, than to write what you ask for. its like doing 15 editors in one:) |
| |
linde
Registered: Jul 2006
Posts: 47 |
How about drawing it in a PC editor and have the program send the data to the C64 quickly as you draw with some transfer cable? I think that approach was discussed before. |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Quote: How about drawing it in a PC editor and have the program send the data to the C64 quickly as you draw with some transfer cable? I think that approach was discussed before.
Funny, I totally missed that thread. Akshully, we're working on such a soluition right now, but not for this project! ;-) Stay tuned!.. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11164 |
Quote:It's definately not "bullshit", and you of all people should realize I know very well what I'm talking about. PAL-Emulation does neither dot-creep nor the "eating away" of pixels when rastered with black, which renders it EXTREMELY inaccurate for anything hires that's not interlaced, and AFAIK nobody even has plans to implement this...
the effect you describe (both are the sympthom of the same thing infact) have little to do with PAL :) it's also something which varies a lot (much more than other PAL stuff) depending on the combination of vic/monitor/cable |
| |
algorithm
Registered: May 2002
Posts: 702 |
As long as the pc/linux tool displays the output as accurately as the c64 would (eg with pal emulation) then this is all that is required. There would be zilch advantage on using a c64 in this case.
Whats important in a converter or cross development gfx tool is to ensure that the output looks as accurate as possible as it would on a real c64. No point in displaying an ifli pic as 320x200x16 as it will certainly not look like this on a real machine (due to the 2x1 pixels and overlap as well as the pal blending)
Click a button and import to c64 and will be just as good.there is absolutely no advantage in pixeling on a real c64 as long as the display output on the preview screen looks as authentic as possible
|
| |
Radiant
Registered: Sep 2004
Posts: 639 |
GangEd 1.01 much? |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Quote: As long as the pc/linux tool displays the output as accurately as the c64 would (eg with pal emulation) then this is all that is required. There would be zilch advantage on using a c64 in this case.
Whats important in a converter or cross development gfx tool is to ensure that the output looks as accurate as possible as it would on a real c64. No point in displaying an ifli pic as 320x200x16 as it will certainly not look like this on a real machine (due to the 2x1 pixels and overlap as well as the pal blending)
Click a button and import to c64 and will be just as good.there is absolutely no advantage in pixeling on a real c64 as long as the display output on the preview screen looks as authentic as possible
Oh my, listen to the coders talking... <:-) Do you also tell composers that reSID sounds exactly like the real thing? (just in case you actually believe that, go check the examples on kevtris page!) |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Quote: Quote:It's definately not "bullshit", and you of all people should realize I know very well what I'm talking about. PAL-Emulation does neither dot-creep nor the "eating away" of pixels when rastered with black, which renders it EXTREMELY inaccurate for anything hires that's not interlaced, and AFAIK nobody even has plans to implement this...
the effect you describe (both are the sympthom of the same thing infact) have little to do with PAL :) it's also something which varies a lot (much more than other PAL stuff) depending on the combination of vic/monitor/cable
That may be - just like filtercurves on SIDs vary. But is that a reason not to emulate the filter? 8)
And quite frankly I don't give a fuck what the cause is for that effect, just like composers don't care if it's the SID or some capacitors causing some effect.. IT'S FUCKING WRONG and far from 100% accurate, that's all that matters to me! |
| |
algorithm
Registered: May 2002
Posts: 702 |
Quote: Oh my, listen to the coders talking... <:-) Do you also tell composers that reSID sounds exactly like the real thing? (just in case you actually believe that, go check the examples on kevtris page!)
Well Video and audio emulation are not related in this case as we are talking about how an image would look like on a real c64 in comparison to en emulator.
ReSID is certainly not accurate in comparison to the real thing (although the emulation in Hoxs64 is more accurate)
But pal emulation is near or enough extremely accurate. Yes, it does not have the interference/noise but as someone previously mentioned before, different tv's output give slightly varied results. As long as the internal pal emulation is there, this is how a stock c64 should display the image |
| |
Hein
Registered: Apr 2004
Posts: 933 |
Didn't know OSCAR till yesterday. 20 Years too late, goddamn!
Anyhow, border graphics should remain special, not become a triviality. As long as there's no proper editor, border graphics are teh shit. ;) |
| |
Copyfault
Registered: Dec 2001
Posts: 467 |
It is rather interesting to see that up to now really no one seems to second DK's wish; even the GFXers do not raise their voices 'pro such a border-editor'. Odd...
If I had more time _and_ if I would only be able to finish at least one editor (how old is this ILM thing now? >10 yrs!) I'd gratefully offer my help. There's still some 2 or 3 ideas for new gfx-modes in my head but I doubt I will ever get the appropriate editors done. This prolly renders me out of business. Sad.
Personally I think that there's no real alternative to working on _da real thang_ when it comes to designing aspects (gfx'n'sound, that is...) - there's simply no possibility to get closer to the original.
For a pixel tool, the only exception could be a PC-based editor with permanent data-xfer to the C64 that makes it possible to watch the pic on the wanted platform. But DK seems to go into this direction already. Sounds promising!
Is DK really the last scener that prefers tools on C64? He should get an award for this attitude! |
| |
Mace
Registered: May 2002
Posts: 1799 |
Awards?
We could introduce the Grahammies for coding and the AcaDeeKaymy for graphicians... |
| |
Alias Medron
Registered: Dec 2001
Posts: 39 |
Gimme a sideborder GFX editor and i'll use it! (that's what most gfxers think).. and NO we aren't going to learn coding as long coders don't start painting :D |
| |
Ninja
Registered: Jan 2002
Posts: 408 |
You don't want that, really. Otherwise you'll get releases like FLI-Comic ;) |
| |
A Life in Hell
Account closed
Registered: May 2002
Posts: 204 |
Quote: That may be - just like filtercurves on SIDs vary. But is that a reason not to emulate the filter? 8)
And quite frankly I don't give a fuck what the cause is for that effect, just like composers don't care if it's the SID or some capacitors causing some effect.. IT'S FUCKING WRONG and far from 100% accurate, that's all that matters to me!
I agree with deekay, but this doens't stop from cross developing - you just have to look at it in a different way. For example, on the painter tool that I'm working on right now, the PC is used for input and editing, but the output image is always displayed (during editing) on a real hardware c64 connected via rrnet.
i don't know if rrnet's are common enough that this is useful for people other than me, tho.
(I'm tempted to have a crack at coding this on native c64, tho, because i think it would becool, but i guess i can't until christmast time) |
| |
Radiant
Registered: Sep 2004
Posts: 639 |
If just anyone could do border graphics it'd kinda reduce the awesomeness factor of it, wouldn't it? Personally I see nothing wrong with pestering one of your group's coders until he codes a customizable viewer... Or even an internal painting tool. :-)
Just keep in mind that even though sharing is nice we still are supposed to compete with each other somehow, not just collaborate randomly across groups. |
| |
Oswald
Registered: Apr 2002
Posts: 5034 |
whats so awesome in border gfx? we have editors for it since 20 years. we've are looking at them since 20 years. :P |
| |
Frantic
Registered: Mar 2003
Posts: 1635 |
I'm all with Deekay.. ;) |
| |
Stainless Steel
Registered: Mar 2003
Posts: 966 |
Quoting Radiantxnot just collaborate randomly across groups
That sir, is a narrow minded thought. Why shouldn't we collaborate with each other and make awesome things together? |
| |
Oswald
Registered: Apr 2002
Posts: 5034 |
Quote: Quoting Radiantxnot just collaborate randomly across groups
That sir, is a narrow minded thought. Why shouldn't we collaborate with each other and make awesome things together?
coz competition drives he scene |
| |
Radiant
Registered: Sep 2004
Posts: 639 |
Quote: Quoting Radiantxnot just collaborate randomly across groups
That sir, is a narrow minded thought. Why shouldn't we collaborate with each other and make awesome things together?
I didn't say we shouldn't. I just said we shouldn't focus on it, which is a growing trend. Groups exist for a reason! |
| |
Mace
Registered: May 2002
Posts: 1799 |
Quote:competition drives he scene We can still compete, but the competition will be between changing collaborations of people. ;-) |
| |
Frantic
Registered: Mar 2003
Posts: 1635 |
Now... This thread was about a border graphics editor. :)
...and besides, the "because it is easier" argument just falls flat in my ears. I mean.. According to that logic it would be easier to get rid of the C64 altogether. No need to transfer anything from PC at all. Make it PC only! Horray! ;) |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Quote: I agree with deekay, but this doens't stop from cross developing - you just have to look at it in a different way. For example, on the painter tool that I'm working on right now, the PC is used for input and editing, but the output image is always displayed (during editing) on a real hardware c64 connected via rrnet.
i don't know if rrnet's are common enough that this is useful for people other than me, tho.
(I'm tempted to have a crack at coding this on native c64, tho, because i think it would becool, but i guess i can't until christmast time)
\o
RRnet and 1541u+EN here! ;-D I'd love to try and betatest it. Unless it's yet again Windows only, then forget about it...
Native c64 is cool, too, but if the PC version has all kinds of features c64 just can't offer (see: Timanthes), there'd be no point making it on c64, because pixelprograms of all kinds *do* exist on c64 already (unlike for Siderborder! >:-)
|
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Quote: If just anyone could do border graphics it'd kinda reduce the awesomeness factor of it, wouldn't it? Personally I see nothing wrong with pestering one of your group's coders until he codes a customizable viewer... Or even an internal painting tool. :-)
Just keep in mind that even though sharing is nice we still are supposed to compete with each other somehow, not just collaborate randomly across groups.
That's about the dumbest thing I've heard on a long time... Actually that applies to both points, i thought we passed the "internal only group tool" bullshit stage like 15 years ago!..
Yet again:
a) "pestering your coder" mostly only works if it's gfx for a part *he* made, not your compopic!
b) not everyone HAS a coder capable of border-hacking he can pester.
c) how many times do coders have to be pestered until someone does a tool *once* and that's the end of all pestering?
d) Even if you do it that way: IT'S TEDIOUS AND TIMECONSUMING to do it in Photoshop etc, keeping track of colors manually and converting the sprites! |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Quote: Now... This thread was about a border graphics editor. :)
...and besides, the "because it is easier" argument just falls flat in my ears. I mean.. According to that logic it would be easier to get rid of the C64 altogether. No need to transfer anything from PC at all. Make it PC only! Horray! ;)
Word, word and word by the power of ten, sir! 8)
A very good point you're making, I'm happy to see that there's not only "do yet another crossdev windows tool" people out there... |
| |
Mace
Registered: May 2002
Posts: 1799 |
Hey, I'm all in favour of an all C64 tool too.
I'm not a graphician and I never did anything with sideborders, though. So I won't use or code that program.
Yet, I'd love to see that program, as utilities are my favourite genre after demos :-) |
| |
Burglar
Registered: Dec 2004
Posts: 1054 |
I'm Not A Graphician (INAG), but wouldn't it be tons easier to add sideborder functionality to existing tools (project one, timanthes)? and then add a cool export feature that will automatically generate an executable .prg?
Writing another editor from scratch can be quite tedious I'd say...
<deekay> but I want to pixel on c64!
use oscar then ;)
edit: ok ok, I read the thread now, sorry for the dupe ;) |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Jesus Christ, will it ever stop? No, it's NOT EASIER! Did you guys ever even *think* of the insane AI that is necessary to draw *whatever* you want and actually hit a "convert to sideborder-c64" button and be done with it, like P1 and Timanthes do it? Making border gfx doesn't work that way! Especially not in the upper/lower border, where you *only* have sprites!
I'm not saying it's impossible, but the LOGIC that would have to be coded to try out different approaches and choose the best one (when talking to Krill about this he mentioned the word "compiler", which describes it fairly accurately!) is rather insane! If it was that easy, people would've done it by now, don't you think?
Look in my original posting for the different layouts in the sideborder for a start. THAT would be rather easy, just convert it in six different ways and then check which result has the least errors. But maybe not: what if the gfxian uses shitloads of colors on one side and none or very few on the other? 3/1 or 4/0 sprite layouts have different setups, but it's still calculateable.
Upper/lower border, however, isn't. The sheer amount of possibilities you'd have to try to get the best match is insane, with the extra arbitrary x-positioning of sprites and $d021!
And even if you do that, some gfx will look like shit while others look fantastic. But that's not what people expect from using a no-fuzz-paint-however-you-want-it'll-look-good-after-conversion PC pixeltool! You'd have to make your gfx in Timanthes/P1 so that it converts well, which requires you to have quite some technical knowledge and is bound to cause major brain tumors for the gfxian!
On the other hand: If you do it on c64, it's rather easy. GFXers can just pixel what's possible and nothing else, and nobody needs to implement any kind of AI! If you allow for fixed x-positioning and expansion of the upper/lower border sprites (individually please, not just one 24-char block! and different layouts for upper/lower border please, too! Hardly any picture is symmetrical in the x-axis in its needs!), you can already do some awesome GFX and offer quite some flexibility to the gfxian... |
| |
Hein
Registered: Apr 2004
Posts: 933 |
Doing border graphics is a piece of cake these days. |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Quote: Doing border graphics is a piece of cake these days.
Oh really? Also for people who don't have a coder at their disposal? <:-)
Why is there no editor for that then, neither on PC nor on c64? |
| |
Hein
Registered: Apr 2004
Posts: 933 |
Gfx-artists without coder, join a group, find a coder. :) |
| |
Mace
Registered: May 2002
Posts: 1799 |
DeeKay, there are editors and there could be something like you describe as graphics compilers.
It's a bit much to ask for some program that calculates the best possible combination of sprites in whatever mode and in whatever intelligently arrange pattern to have your pixels arranged.
I think to make this a little bit feasable, you'd have to settle with something that lets you arrange sprites by hand.
The rest would have to be real time graphician's brain power.
Don't scare off whatever coder would have the guts to even start this project ;-)
And I'd have to agree that the C64 platform would be more comfortable, as it will instantly show the possibilities. |
| |
A Life in Hell
Account closed
Registered: May 2002
Posts: 204 |
Quote: \o
RRnet and 1541u+EN here! ;-D I'd love to try and betatest it. Unless it's yet again Windows only, then forget about it...
Native c64 is cool, too, but if the PC version has all kinds of features c64 just can't offer (see: Timanthes), there'd be no point making it on c64, because pixelprograms of all kinds *do* exist on c64 already (unlike for Siderborder! >:-)
(actually, i don't have a windows machine, only linux+mac. i am a sad outlier. so no hoxs or timanthets for me, sad.) |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Quoting mace
DeeKay, there are editors and there could be something like you describe as graphics compilers.
Well, what would you call Timanthes and P1? They're not editors that let you work within c64 restrictions, like e.g. Elitepaint (atleast Timanthes last time I tried, never got to check out P1), but they convert (or compile) the pic after you drew it...
Quote:
It's a bit much to ask for some program that calculates the best possible combination of sprites in whatever mode and in whatever intelligently arrange pattern to have your pixels arranged.
How the hell did you get the idea I was *asking* for this? Did you even read my posting? I was trying to explain why implementing this in Timanthes or P1 is A LOT MORE work than doing it on c64!
Quote:
I think to make this a little bit feasable, you'd have to settle with something that lets you arrange sprites by hand.
The rest would have to be real time graphician's brain power.
Well, no shit, sherlock? <:-) That's *exactly* what I've been asking for from the start!
Quote:
Don't scare off whatever coder would have the guts to even start this project ;-)
I'm just trying to scare off people from making yet another crossdev-solution when this is clearly not necessary! ;-) |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Quote: (actually, i don't have a windows machine, only linux+mac. i am a sad outlier. so no hoxs or timanthets for me, sad.)
Welcome to the c64 scene, where anything non-c64 == windows! ;-D
I'm with you, dude, Linux+Mac all the way! 8) Still: I would much rather prefer a c64 solution, at least for the bordergfx-editor!... |
| |
Tao
Registered: Aug 2002
Posts: 115 |
Quote: Welcome to the c64 scene, where anything non-c64 == windows! ;-D
I'm with you, dude, Linux+Mac all the way! 8) Still: I would much rather prefer a c64 solution, at least for the bordergfx-editor!...
For me, the non-c64 world is all GNU/Linux :)
I know you've displayed an excellent non-ability to understand that coding a graphics program on a non-64 platform is more trivial than on the 64 itself, but believe me, it is. While I'd probably have felt tempted to attempt to do so anyway some 10 years ago, now I simply cannot push myself to it.
I might be able to get myself to cook something in GTK (or possibly SDL) though, if you can accept such a solution. Granted, PAL-emulation, etc, will not be on the agenda...
Oh, unlike most people here, I *do* see a use for a side-border graphics editor. I just find myself hard-pressed to see a point in implementing it on the 64 (beyond getting 100% correct previews; but that can be implemented at a later stage with RR-net). |
| |
Radiant
Registered: Sep 2004
Posts: 639 |
Quoting DeeKayThat's about the dumbest thing I've heard on a long time...
A powerful argument, and presented with such a courteous demeanor. I wouldn't personally hold a person who claims parallel programming is easy because he managed to add a few ampersands to a shell script as qualified to ratify on other people's level of insight, but I know you think highly of your abilities in that area. Be my guest if that's what floats your boat.
Enjoy the rest of your bottle of sour whine! |
| |
JackAsser
Registered: Jun 2002
Posts: |
Quote: Welcome to the c64 scene, where anything non-c64 == windows! ;-D
I'm with you, dude, Linux+Mac all the way! 8) Still: I would much rather prefer a c64 solution, at least for the bordergfx-editor!...
To fuel the flame: Write your shit in Java like I do (Yes Graham, I know it won't work on Amiga OS... but it WILL work without any hazzle on Windows, Mac and Linux :) I'm even sure that writing a proper PAL-emu filter is quite possible in Java with good performance. And if you insist on hating Java then do your shit in C/C++ and use some cross platform gfx layer and widget layer AND PLEASE do NOT use autoconf, simply write your own tidy small nice little Makefile, it's not THAT hard.
That being said, don't be lame.
|
| |
Oswald
Registered: Apr 2002
Posts: 5034 |
so why coders wont make it ? because coding such an editor regardless of platform/language/etc it would take more work than all the border gfx so far deekay had done during his scene careeer. :) |
| |
A Life in Hell
Account closed
Registered: May 2002
Posts: 204 |
Quote: To fuel the flame: Write your shit in Java like I do (Yes Graham, I know it won't work on Amiga OS... but it WILL work without any hazzle on Windows, Mac and Linux :) I'm even sure that writing a proper PAL-emu filter is quite possible in Java with good performance. And if you insist on hating Java then do your shit in C/C++ and use some cross platform gfx layer and widget layer AND PLEASE do NOT use autoconf, simply write your own tidy small nice little Makefile, it's not THAT hard.
That being said, don't be lame.
(use autoconf and automake, once set up automake particularly will make your life easier. fuck maintaining makefiles of doom(tm)) |
| |
JackAsser
Registered: Jun 2002
Posts: |
Quote: (use autoconf and automake, once set up automake particularly will make your life easier. fuck maintaining makefiles of doom(tm))
Only automake generate makefiles of doom(tm). :D But sure, for larger systems generating the makefiles and keep track of the dependencies is a sound idea. But not for a small proj like this imo. |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Quoting radiantx
A powerful argument, and presented with such a courteous demeanor. I wouldn't personally hold a person who claims parallel programming is easy because he managed to add a few ampersands to a shell script as qualified to ratify on other people's level of insight, but I know you think highly of your abilities in that area. Be my guest if that's what floats your boat.
Wow. You get an award in both quoting out of context and introducing some totally pointless new "points" into a discussion, just to "score".
I won't say anything to that "qualified" part of yours except for "check out our tooldisks", keeping in mind that I worked with the coders on every single of these gfx editors... Which is the reason they might appear so unusable, but well, shoot me! ;-)
As for the quoting out of context: You weren't talking about the technical realization of such a project, but you said "don't work together, we're supposed to compete in the scene". And sorry, that is just dumb beyond belief, i refuse to actually even reason with this, hence the "dumbest thing" remark... |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Quote: For me, the non-c64 world is all GNU/Linux :)
I know you've displayed an excellent non-ability to understand that coding a graphics program on a non-64 platform is more trivial than on the 64 itself, but believe me, it is. While I'd probably have felt tempted to attempt to do so anyway some 10 years ago, now I simply cannot push myself to it.
I might be able to get myself to cook something in GTK (or possibly SDL) though, if you can accept such a solution. Granted, PAL-emulation, etc, will not be on the agenda...
Oh, unlike most people here, I *do* see a use for a side-border graphics editor. I just find myself hard-pressed to see a point in implementing it on the 64 (beyond getting 100% correct previews; but that can be implemented at a later stage with RR-net).
That's still great, i'd still rather have a crossplatform crossdev solution than none at all! ;-)
As for the "excellent non-ability to understand": I've worked with various coders on more gfx-editors, both c64-based and crossdev, than probably anyone else here (I'm counting at least 13 for c64 (or c128! 8) and 2 crossdev ones from the top of my head). AND i was the only one that actually REASONED *why* impllementing it in Timanthes or P1 will be a lot more work! So will you cut me some slack, pretty please? <:-)
I will however agree that doing a completely new editor within c64 boundaries on PC (not the converter kind like P1/Timanthes) might probably be easier, since you don't have to worry about memory limitations etc... But not *that* much as many people here pretend it to be, since siderborder stuff isn't as memory-constrained as e.g. IFLI or UIFLI (it still all has be be within one bank, at least if you skip on the Lace-stuff for a start, so you still have 48KB for the editor! ;-) |
| |
Mace
Registered: May 2002
Posts: 1799 |
Quoting DeeKay:-Color-switching: I know that quite often coders don't want the maximum amount of color switching because they need the cycles for other stuff (...) I'm no übercoder (no Sherlock either ;-)), but isn't it a bit hard to change 6 colour registers (4 sprites + 2 multicol) exactly on the right rasterline (even if it's not a badline)? Especially when you also have to multiplex / change Y-coords of 4 sprites too.
Quoting DeeKay:-Zoom mode must also at least display one char-column of the bitmap, otherwise making it seamless would be quite taxing. Exactly my thought (in a previous post).
Quoting DeeKay:-$d021 is fixed (since there's no editor that allows for changing $d021 rasterwise anyway!) Perhaps a nice opportunity to add that feature anyway? :-)
|
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Who says you have to multiplex the sprites in the same line as you change the colors? ;-)
It can't be quite so taxing, if the OSCAR guy managed to do it in 1988, can it? <:-)
As for $d021: No, bad idea, there's no standard bitmap editor around that supports this, so you couldn't even pixel a pic to feed into the border-editor (and even if there was such a tool: people should be able to use their favourite tool for bitmap pixelling, be it Amica Paint, Art Studio or Zoomatic! ;-). But both Funpaint 2 and the BML FLI-editor always did, and from what I know in all these years nobody ever used that feature! <:-) |
| |
Mace
Registered: May 2002
Posts: 1799 |
Quoting DeeKay:As for $d021: No, bad idea, there's no standard bitmap editor around that supports this
Err, that's an odd reason, since you're asking for an editor that does things that hardly any editor does.
Ok, you say that the graphician should be able to use his/her fav tool to make the 'bitmap'.
But what prevends you from just making two copies of the same picture, with the right bg-colour for the part you're working on?
It's not too hard to think of a picture with split $d021 AND sideborder graphics...
You are suggesting to add loads of features into this new editor, but you seem reluctant to implement the easiest of them all :D |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
LOL! Akshully, that picture may *look* like it's switching $d021, but it's not! ;-)
$d021 is light blue throughout the whole pic, it only changes in the upper/lower border!... Check out my BP06 GFX semimar, there's a detailed gfx of all the colors used in SB in that pic near the end! (yes, that's EXACTLY what I meant with "tedious work in photoshop"! <:-)
I'm asking for an editor that allows gfxians to extend their picture into the border. But there's no editor that does standard bitmap with linewise $d021 switching, so adding that feature would be pointless and the work would be better put into other stuff, that's all I'm saying! ;-)
And drawing two half-pictures with different $d021: You're not serious, are you? <:-) Nobody can work that way, plus you'd need an extra program to merge the pics!... |
| |
Radiant
Registered: Sep 2004
Posts: 639 |
DeeKay: For the record, I reacted on your totally unmotivated flame by responding with another. You reap as you sow. However...
Quoting DeeKayAnd sorry, that is just dumb beyond belief
...is just plain repetition of your previous flame. You could at least have tried it with a new angle. I've understood that you think competition between groups in the scene is a bad thing, and I can certainly see arguments to support such a claim, but it's not like there is a lack of arguments for competition between groups either. Failing to recognize that other viewpoints than your own may be supported by valid arguments just makes you come across as either arrogant, ignorant or a combination thereof. |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Quoting radiantx
I've understood that you think competition between groups in the scene is a bad thing,
Oh please, spare me with the lunatic fringe already, that's just lame arguing..
You know I never said that. After all, I'm still in a group, aren't I? What I'm saying is that competition for competition's sake is an utterly dumb idea, trying to PREVENT people from working together!
And it's rather obvious that in the past, um, 10 years or so, people have been competing, but the teams change as needed, and sometimes even people that otherwise directly compete work on a production together. The Wild Bunch or Larsson Bros anyone? <:-) It's FRIENDLY competition, with the common goal to release kickass productions! You're proposing the unfriendly kind, that was so common in the cracking scene back then...
Quote:
and I can certainly see arguments to support such a claim, but it's not like there is a lack of arguments for competition between groups either. Failing to recognize that other viewpoints than your own may be supported by valid arguments just makes you come across as either arrogant, ignorant or a combination thereof.
Well, I'd say that "we're supposed to compete, so stop working on this project together" is rather arrogant, while failing to see what has happened in the past 10 years in the demoscene is quite ignorant... |
| |
Wile Coyote
Account closed
Registered: Mar 2004
Posts: 646 |
(Im no coder)
Id have thought it would be reasonably straight forward for a good coder to code something that allows for multi colour bitmaps (drawn using existing bitmap editors) to be loaded into memory, with an editor that allows for the sprites in the left and right borders to be edited (drawn). The option to save a RUNable image (for compo use) would be helpful too.
Creating a similar editor that allows for upper and lower borders to be used I guess throws up more issues, as some artists might want to position the sprites in different locations along the upper and lower border area. Although an option to side the spites left or right within the upper and lower border might be one solution.
For most artists, using Photoshop, some imagination, and knowing a good coder is the best option. |
| |
Mace
Registered: May 2002
Posts: 1799 |
What's so hard about positioning sprites?
It's even be possible to reposition sprites that already have content, without moving that content, provided that there's no roll-off.
Nah... if we can do FLI sideborder plasma and 50fps phongshade vectors, this can't be harder :-) |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Quoting wec
Id have thought it would be reasonably straight forward for a good coder to code something that allows for multi colour bitmaps (drawn using existing bitmap editors) to be loaded into memory, with an editor that allows for the sprites in the left and right borders to be edited (drawn). The option to save a RUNable image (for compo use) would be helpful too.
Well, so did I, but apparently doing what amounts to a slightly beefed up big-sprite editor with colors is black magic these days that requires dualcore PCs with C-compilers! ;-D
You don't even have to make it deal with color clashes, just make it plot hires or 00/01/10/11-multicolor pixels (depending on the layout the user chose) and leave the color changing to the gfxian, like OSCAR does (but please, please: don't put coloring into a separate module like OSCAR!). And let us edit each sideborder as a whole, that's one of the most timeconsuming and dreary tasks in OSCAR, editing each sprite individually (and it isn't even the full height of the sprite, oh no, just part of it, sometimes even wrapping around! a CHANGING part throughout the picture!)!..
If supporting interlaced modes is such a problem (i could imagine it to be, the editor would have to be quite different!), just leave it out and go for non-laced stuff for a start... Or make a completely separate version of the editor for Interlaced stuff! ;-)
Quote:
Creating a similar editor that allows for upper and lower borders to be used I guess throws up more issues, as some artists might want to position the sprites in different locations along the upper and lower border area. Although an option to side the spites left or right within the upper and lower border might be one solution.
Actually, positioning isn't that much of a problem. Just offer a seamless 24-char zoom-area of 8 sprites side by side, each either multicolor or hires, and let the gfxian arrange x-positioning and expansion of each sprite in the displayer manually (press u/l for upper/lower border, 1-8 for sprite, +/- for x-shifting and x for x-expansion). It won't look correct in the editor if you mess around with it, but who cares, we're not dumb, we can deal with *that*! ;-)
Quote:
For most artists, using Photoshop, some imagination, and knowing a good coder is the best option.
Right now, it is the only option. For all artists. That's just the problem! <:-) |
| |
Oswald
Registered: Apr 2002
Posts: 5034 |
if its such a little problem then code it... :) |
| |
Angel of Death
Registered: Apr 2008
Posts: 210 |
Jeeezes people!
Did you all have demotivational and assertiveness courses.
Deekay is not asking you to make the best editor known to man, ever.
Just make a damn effort!
I myself would have to recall numerous years of coding experience again to code something like it. Or find a time crystal to get the space in my schedule.
But if it was up to me there would be at least a modified timanthes or project-one or a modified koala painter on here.
(I know I'm not really helping with this post, either but I had to say this. I'ts just no way of speaking to one of the more respected sceners around)
I hope for Deekay that there is someone silently doing the work for him while we are bickering about $d021 splits and unnecessary sprite-plexing. |
| |
Oswald
Registered: Apr 2002
Posts: 5034 |
save DK and code it then. as I already said coding this tool would take more effort than DK's all bordergfx all together so far. happy coding! |
| |
Hein
Registered: Apr 2004
Posts: 933 |
yeh, save us from this assertive flaming. |
| |
Steppe
Registered: Jan 2002
Posts: 1510 |
For christ's sake, someone code him that editor already! I don't want to wait another 5 years for Meet Crest! ;-) |
| |
hollowman
Registered: Dec 2001
Posts: 474 |
Quoting Angel of Death
Deekay is not asking you to make the best editor known to man, ever.
Just make a damn effort!
As said in an earlier discussion, theres not a lot of coders searching forums for random coding projects to spend their limited spare time on.
Quoting JackAsser
To fuel the flame: Write your shit in Java like I do
Indeed. The time spent discussing here would be better spent reading "teach yourself *random language/rad tool* in x days" |
| |
hollowman
Registered: Dec 2001
Posts: 474 |
Quoting sad panda is sad
For example, on the painter tool that I'm working on right now, the PC is used for input and editing, but the output image is always displayed (during editing) on a real hardware c64 connected via rrnet.
When I have needed an editor for a custom format I have stuck to just quickly throwing together a pc tool that can load and save the image, and just barely set the pixels. But if I cared enough I would do something like that aswell.
Just code (or rip) a displayer of the image format and combine with one of the existing network protocols implemented on c64, and let the program on pc feed the changes of the image data live to the c64. |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Aided by copious amounts of alcohol I was actually able to persuade Doc Bacardi to code such an editor on Breakpoint 09! ;-) The alcohol and me showing him what I had done in OSCAR so far and how horribly awful it is to use did the trick I guess, hehe!... The agreement is that he makes a crossplattform editor in Java. Not as good as a native one, but still great! 8)
So there's no escape now, go for it, Baccy! 8)
P.S: It was quite hilarious, Ninja the next morning to Baccy: "...You promised him WHAT???" ;-D
|
| |
Ninja
Registered: Jan 2002
Posts: 408 |
Did he give you a deadline? It took me ~1.5 years of nagging to get him fix the bugs I found in DreamAss (for less than 100 lines changed) ;) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11164 |
my bet is that i will have my editor for International Karaoke finished long before baccy even started with this =D |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Well, i did find his phonenumber somewhere, so I will call him up frequently until he either gets a restraining order or makes the editor! ;-D |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Wrong guy - anyone got his phone# or where he lives? 8) |
| |
bugjam
Registered: Apr 2003
Posts: 2514 |
I do, but I won´t tell you - first he has to finish half a dozen other projects... ;-)
Btw: I have never tried the prog; do you think it would be an option to improve OSCAR instead of starting an all new editor? Like an OSCAR Gold? |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Bastard! ;-)
No, I don't think improving OSCAR would be an option. For starters, the SB-code is highly infefficient and outdated, he uses jumptables inside jumptables, wasting too many cycles. Also, the whole approach is unsuited for making an actually usable program out of it... |
| |
FATFrost
Account closed
Registered: Sep 2003
Posts: 211 |
errr, don't you got Xbow?? he is supremo coderrr!! but seriously, i would fukkin like this editor too, maybe if i donate some cash it will get done.... hmmmm... now only to find some cash...... |
| |
LOGAN
Account closed
Registered: Aug 2003
Posts: 71 |
Would be cool to have an full screen graphics editor. I came more about design than awesomeness/exclusive coding though. I even have no problem in ported graphics if the original graphic was produced as an original work by the graphician. In the end it's the result that matters, an awesome graphic on the c64.
So a cool editor would be great and also an asm routine to be able to use it in projects :) |
| |
Mirage
Registered: Jan 2003
Posts: 113 |
Still a long way to go, but something like this perhaps?
(Multi-platform this time around :))
|
| |
Mace
Registered: May 2002
Posts: 1799 |
P1wned!
+1 for the app's name! |
| |
Oswald
Registered: Apr 2002
Posts: 5034 |
cool, they'll bug you & not me from now on ;) |
| |
Sander
Registered: Jan 2002
Posts: 493 |
P1WNED \o/ |
| |
Sampaguita
Account closed
Registered: Apr 2008
Posts: 29 |
Quote: cool, they'll bug you & not me from now on ;)
Wouldn't that be a nice addition for ProjectOne? *ducks* ;) |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Yay Lars, go for it! ;-D
You got a very avid betatester in me if you need one! 8) I assume it's mono-compatible this time, or what did you use as a crossplattform basis? 8)
P.S: Why'd you drop your handle in May? |
| |
Joe
Registered: Apr 2002
Posts: |
Some time later... What happened to that promising editor of yours (Mirage)? |
| |
Stainless Steel
Registered: Mar 2003
Posts: 966 |
Quoting oswaldcool, they'll bug you & not me from now on ;) Oswald scared him off :-D |
| |
FATFrost
Account closed
Registered: Sep 2003
Posts: 211 |
so after all that... is there any chance of an editor? or was it all for nought.?? |
