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

Welcome to our latest new user dstar ! (Registered 2024-05-25)

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 06:44

JackAsser

Registered: Jun 2002
Posts: 1994

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

To fuel the flame: Write your shit in Java like I do (Yes Graham, I know it won't work on Amiga OS... but it WILL work without any hazzle on Windows, Mac and Linux :) I'm even sure that writing a proper PAL-emu filter is quite possible in Java with good performance. And if you insist on hating Java then do your shit in C/C++ and use some cross platform gfx layer and widget layer AND PLEASE do NOT use autoconf, simply write your own tidy small nice little Makefile, it's not THAT hard.

That being said, don't be lame.

2008-11-28 07:11

Oswald

Registered: Apr 2002
Posts: 5028

so why coders wont make it ? because coding such an editor regardless of platform/language/etc it would take more work than all the border gfx so far deekay had done during his scene careeer. :)

2008-11-28 09:19

A Life in Hell
Account closed

Registered: May 2002
Posts: 204

Quote: To fuel the flame: Write your shit in Java like I do (Yes Graham, I know it won't work on Amiga OS... but it WILL work without any hazzle on Windows, Mac and Linux :) I'm even sure that writing a proper PAL-emu filter is quite possible in Java with good performance. And if you insist on hating Java then do your shit in C/C++ and use some cross platform gfx layer and widget layer AND PLEASE do NOT use autoconf, simply write your own tidy small nice little Makefile, it's not THAT hard.

That being said, don't be lame.

(use autoconf and automake, once set up automake particularly will make your life easier. fuck maintaining makefiles of doom(tm))

2008-11-28 10:20

JackAsser

Registered: Jun 2002
Posts: 1994

Quote: (use autoconf and automake, once set up automake particularly will make your life easier. fuck maintaining makefiles of doom(tm))

Only automake generate makefiles of doom(tm). :D But sure, for larger systems generating the makefiles and keep track of the dependencies is a sound idea. But not for a small proj like this imo.

2008-11-28 12:54

DeeKay

Registered: Nov 2002
Posts: 362

Quoting radiantx

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.

Wow. You get an award in both quoting out of context and introducing some totally pointless new "points" into a discussion, just to "score".
I won't say anything to that "qualified" part of yours except for "check out our tooldisks", keeping in mind that I worked with the coders on every single of these gfx editors... Which is the reason they might appear so unusable, but well, shoot me! ;-)

As for the quoting out of context: You weren't talking about the technical realization of such a project, but you said "don't work together, we're supposed to compete in the scene". And sorry, that is just dumb beyond belief, i refuse to actually even reason with this, hence the "dumbest thing" remark...

2008-11-28 13:10

DeeKay

Registered: Nov 2002
Posts: 362

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

That's still great, i'd still rather have a crossplatform crossdev solution than none at all! ;-)

As for the "excellent non-ability to understand": I've worked with various coders on more gfx-editors, both c64-based and crossdev, than probably anyone else here (I'm counting at least 13 for c64 (or c128! 8) and 2 crossdev ones from the top of my head). AND i was the only one that actually REASONED *why* impllementing it in Timanthes or P1 will be a lot more work! So will you cut me some slack, pretty please? <:-)

I will however agree that doing a completely new editor within c64 boundaries on PC (not the converter kind like P1/Timanthes) might probably be easier, since you don't have to worry about memory limitations etc... But not *that* much as many people here pretend it to be, since siderborder stuff isn't as memory-constrained as e.g. IFLI or UIFLI (it still all has be be within one bank, at least if you skip on the Lace-stuff for a start, so you still have 48KB for the editor! ;-)

2008-11-28 13:11

Mace

Registered: May 2002
Posts: 1799

Quoting DeeKay:

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

I'm no übercoder (no Sherlock either ;-)), but isn't it a bit hard to change 6 colour registers (4 sprites + 2 multicol) exactly on the right rasterline (even if it's not a badline)? Especially when you also have to multiplex / change Y-coords of 4 sprites too.

Quoting DeeKay:

-Zoom mode must also at least display one char-column of the bitmap, otherwise making it seamless would be quite taxing.

Exactly my thought (in a previous post).

Quoting DeeKay:

-$d021 is fixed (since there's no editor that allows for changing $d021 rasterwise anyway!)

Perhaps a nice opportunity to add that feature anyway? :-)

2008-11-28 13:21

DeeKay

Registered: Nov 2002
Posts: 362

Who says you have to multiplex the sprites in the same line as you change the colors? ;-)
It can't be quite so taxing, if the OSCAR guy managed to do it in 1988, can it? <:-)

As for $d021: No, bad idea, there's no standard bitmap editor around that supports this, so you couldn't even pixel a pic to feed into the border-editor (and even if there was such a tool: people should be able to use their favourite tool for bitmap pixelling, be it Amica Paint, Art Studio or Zoomatic! ;-). But both Funpaint 2 and the BML FLI-editor always did, and from what I know in all these years nobody ever used that feature! <:-)

2008-11-28 13:50

Mace

Registered: May 2002
Posts: 1799

Quoting DeeKay:

As for $d021: No, bad idea, there's no standard bitmap editor around that supports this

Err, that's an odd reason, since you're asking for an editor that does things that hardly any editor does.
Ok, you say that the graphician should be able to use his/her fav tool to make the 'bitmap'.
But what prevends you from just making two copies of the same picture, with the right bg-colour for the part you're working on?

It's not too hard to think of a picture with split $d021 AND sideborder graphics...

You are suggesting to add loads of features into this new editor, but you seem reluctant to implement the easiest of them all :D

2008-11-28 14:04

DeeKay

Registered: Nov 2002
Posts: 362

LOL! Akshully, that picture may *look* like it's switching $d021, but it's not! ;-)
$d021 is light blue throughout the whole pic, it only changes in the upper/lower border!... Check out my BP06 GFX semimar, there's a detailed gfx of all the colors used in SB in that pic near the end! (yes, that's EXACTLY what I meant with "tedious work in photoshop"! <:-)

I'm asking for an editor that allows gfxians to extend their picture into the border. But there's no editor that does standard bitmap with linewise $d021 switching, so adding that feature would be pointless and the work would be better put into other stuff, that's all I'm saying! ;-)
And drawing two half-pictures with different $d021: You're not serious, are you? <:-) Nobody can work that way, plus you'd need an extra program to merge the pics!...

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

celticdesign/G★P/M..
Dymo/G★P
JEZ
Exploding Fi../Techn..
Zephyr/Elysium
Guests online: 94

Top Demos

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

Top onefile Demos

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

Top Groups

1 Covert Bitops  (9.4)
2 Nostalgia  (9.4)
3 Oxyron  (9.3)
4 Booze 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.046 sec.