[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-25 16:14

Twoflower

Registered: Jan 2002
Posts: 434

I support this noble cause. I stand up and say: yes!

2008-11-25 16:15

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!

2008-11-25 16:30

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

2008-11-25 20:05

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]

2008-11-25 20:58

algorithm

Registered: May 2002
Posts: 702

Cant you get Crossbow to do such a thing? Or is he too busy on 'meet crest'?

2008-11-25 22:12

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

2008-11-26 01:47

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.

2008-11-26 03:46

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

2008-11-26 06:21

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

:-)

2008-11-26 08:31

JackAsser

Registered: Jun 2002
Posts: 1997

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.

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

Krill/Plush
Thunder.Bird/HF/MYD!..
Sentinel/Excess/TREX
MCM/ONSLAUGHT
Guests online: 53

Top Demos

1 Next Level  (9.7)
2 13:37  (9.7)
3 Mojo  (9.7)
4 Coma Light 13  (9.7)
5 Edge of Disgrace  (9.6)
6 Comaland 100%  (9.6)
7 Uncensored  (9.6)
8 No Bounds  (9.6)
9 Aliens in Wonderland  (9.6)
10 Wonderland XIV  (9.6)

Top onefile Demos

1 Layers  (9.6)
2 Cubic Dream  (9.6)
3 Party Elk 2  (9.6)
4 Copper Booze  (9.6)
5 Rainbow Connection  (9.5)
6 It's More Fun to Com..  (9.5)
7 Dawnfall V1.1  (9.5)
8 Birth of a Flower  (9.5)
9 Daah, Those Acid Pil..  (9.5)
10 Quadrants  (9.5)

Top Groups

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

Top Graphicians

1 Mirage  (9.8)
2 Archmage  (9.7)
3 Talent  (9.6)
4 Facet  (9.6)
5 Mermaid  (9.6)

Page generated in: 0.063 sec.