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-28 15:54
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 DeeKay
And 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.
2008-11-28 16:08
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...
2008-11-28 21:37
Wile Coyote
Account closed

Registered: Mar 2004
Posts: 646
(I’m no coder)
I’d 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.
2008-11-28 22:03
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 :-)
2008-11-29 01:20
DeeKay

Registered: Nov 2002
Posts: 362
Quoting wec

I’d 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! <:-)
2008-11-29 06:44
Oswald

Registered: Apr 2002
Posts: 5034
if its such a little problem then code it... :)
2008-11-29 07:52
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.
2008-11-29 08:04
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!
2008-11-29 08:11
Hein

Registered: Apr 2004
Posts: 933
yeh, save us from this assertive flaming.
2008-11-29 09:08
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! ;-)
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
A3/AFL
Nicron
Krill/Plush
Hawk
Sentinel/Excess/TREX
Guests online: 66
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 Original Suppliers
1 Black Beard  (9.7)
2 Derbyshire Ram  (9.5)
3 hedning  (9.2)
4 Baracuda  (9.1)
5 Jazzcat  (8.6)

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