[CSDb] - User Forums - Urgently needed: proper Bordergfx-editor!

You are not logged in - nap

CSDb User Forums

Forums > C64 Pixeling > Urgently needed: proper Bordergfx-editor!

2008-11-25 08:33

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!

... 111 posts hidden. Click here to view all posts....

2008-11-27 16:40

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...

2008-11-27 16:42

Hein

Registered: Apr 2004
Posts: 933

Doing border graphics is a piece of cake these days.

2008-11-27 16:45

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?

2008-11-27 16:58

Hein

Registered: Apr 2004
Posts: 933

Gfx-artists without coder, join a group, find a coder. :)

2008-11-27 20:00

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.

2008-11-27 22:21

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.)

2008-11-28 01:04

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! ;-)

2008-11-28 01:10

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!...

2008-11-28 04:45

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).

2008-11-28 06:44

Radiant

Registered: Sep 2004
Posts: 639

Quoting DeeKay

That'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!

Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 - Next

Refresh

Subscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search for in
All times are CET.

Search CSDb

Advanced

Users Online

Guests online: 140

Top Demos

1 Next Level  (9.8)
2 Mojo  (9.7)
3 Coma Light 13  (9.7)
4 Edge of Disgrace  (9.6)
5 Comaland 100%  (9.6)
6 No Bounds  (9.6)
7 Uncensored  (9.6)
8 Wonderland XIV  (9.6)
9 Memento Mori  (9.6)
10 Bromance  (9.5)

Top onefile Demos

1 It's More Fun to Com..  (9.7)
2 Party Elk 2  (9.7)
3 Cubic Dream  (9.6)
4 Copper Booze  (9.5)
5 TRSAC, Gabber & Pebe..  (9.5)
6 Rainbow Connection  (9.5)
7 Wafer Demo  (9.5)
8 Dawnfall V1.1  (9.5)
9 Quadrants  (9.5)
10 Daah, Those Acid Pil..  (9.5)

Top Groups

1 Nostalgia  (9.3)
2 Oxyron  (9.3)
3 Booze Design  (9.3)
4 Censor Design  (9.3)
5 Crest  (9.3)

Top NTSC-Fixers

1 Pudwerx  (10)
2 Booze  (9.7)
3 Stormbringer  (9.7)
4 Fungus  (9.6)
5 Grim Reaper  (9.3)

Page generated in: 0.169 sec.