Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
 Welcome to our latest new user nurd ! (Registered 2024-06-16) 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 08:55
Stainless Steel

Registered: Mar 2003
Posts: 966
Quoting Radiantx
not 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?
2008-11-27 09:39
Oswald

Registered: Apr 2002
Posts: 5031
Quote: Quoting Radiantx
not 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
2008-11-27 10:45
Radiant

Registered: Sep 2004
Posts: 639
Quote: Quoting Radiantx
not 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!
2008-11-27 10:51
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. ;-)
2008-11-27 11:31
Frantic

Registered: Mar 2003
Posts: 1633
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! ;)
2008-11-27 11:33
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! >:-)
2008-11-27 11:39
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!
2008-11-27 11:42
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...
2008-11-27 11:48
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 :-)
2008-11-27 13:00
Burglar

Registered: Dec 2004
Posts: 1051
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 ;)
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
Bob/Censor Design
Epsilon/Fairlight
Fred/Channel 4
Bieno/Commodore Plus
Genius/Xenon
doZe
hedning/G★P
TheRealWanderer
Guests online: 100
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.7)
6 Aliens in Wonderland  (9.6)
7 Comaland 100%  (9.6)
8 No Bounds  (9.6)
9 Uncensored  (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 Daah, Those Acid Pil..  (9.5)
9 Birth of a Flower  (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 SHAPE  (9.3)
Top Diskmag Editors
1 Magic  (9.4)
2 Jazzcat  (9.4)
3 hedning  (9.2)
4 Elwix  (9.1)
5 Remix  (9.1)

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