Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
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-25 11:16
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...
2008-11-25 11:20
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...
2008-11-25 12:47
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.
2008-11-25 13:46
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)

2008-11-25 14:03
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?
2008-11-25 14:28
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!
2008-11-25 14:29
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
2008-11-25 14:30
Sander

Registered: Jan 2002
Posts: 487
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!
2008-11-25 14:44
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?
2008-11-25 15:01
Clarence

Registered: Mar 2004
Posts: 119
Side-Border Logo Editor V1.0 :)
Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 - Next
RefreshSubscribe 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
St0rmfr0nt/Quantum
DJ Gruby/TRiAD
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 Crackers
1 Mr. Z  (9.9)
2 S!R  (9.9)
3 Antitrack  (9.8)
4 Mr Zero Page  (9.8)
5 OTD  (9.8)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.054 sec.