[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-26 15:49

DeeKay

Registered: Nov 2002
Posts: 362

Quote: Quote:
You may not notice it with Interlace-pictures, because it's all a blur basically, but PAL-emulation (which AFAIK none of the PC-pixeltools even supports!) is still *way* inadequate...

bullshit. infact its one of the most "real" things in vice, and 2.1 will fix the last remaining glitches too. it's scary how authentic it looks now to be honest :)

and you gotta be kidding that writing the editor for the c64 would be in any way compareable with making it for the pc.

..And this from the guy that uses the most sickening Color palettes? <:-)
It's definately not "bullshit", and you of all people should realize I know very well what I'm talking about. PAL-Emulation does neither dot-creep nor the "eating away" of pixels when rastered with black, which renders it EXTREMELY inaccurate for anything hires that's not interlaced, and AFAIK nobody even has plans to implement this...

And about the editor: Like others you keep forgetting that the main issue with such an editor is not the userinterface, but the c64-displayercode, quite unlike all the existing PC-pixeltools. The editor itself doesn't need anything else than setting pixels and choosing colors, so meh!
Ofcourse, if you want to do the "draw in all colors without restrictions and then convert to c64"-approach like with Timanthes, a PC would be way better suited, but that's not the approach I'm aiming for...

2008-11-26 15:50

Mace

Registered: May 2002
Posts: 1799

Quoting Groepaz:

the user interface is super annoying to code

Typical for computernerds to find it difficult to communicatie with the outside world ;-)

2008-11-26 16:04

Oswald

Registered: Apr 2002
Posts: 5028

"Like others you keep forgetting that the main issue with such an editor is not the userinterface,"

when the cursor is over arbitrarily positioned overlayed hires/mc/expanded sprites how should the editor decide which is the active plot surface/tint ? How would you like to setup line by line setupable registers ?

frankly its much easyer to write a pc based editor which I described, than to write what you ask for. its like doing 15 editors in one:)

2008-11-26 16:28

linde

Registered: Jul 2006
Posts: 47

How about drawing it in a PC editor and have the program send the data to the C64 quickly as you draw with some transfer cable? I think that approach was discussed before.

2008-11-26 16:29

DeeKay

Registered: Nov 2002
Posts: 362

Quote: How about drawing it in a PC editor and have the program send the data to the C64 quickly as you draw with some transfer cable? I think that approach was discussed before.

Funny, I totally missed that thread. Akshully, we're working on such a soluition right now, but not for this project! ;-) Stay tuned!..

2008-11-26 17:13

chatGPZ

Registered: Dec 2001
Posts: 11148

Quote:

It's definately not "bullshit", and you of all people should realize I know very well what I'm talking about. PAL-Emulation does neither dot-creep nor the "eating away" of pixels when rastered with black, which renders it EXTREMELY inaccurate for anything hires that's not interlaced, and AFAIK nobody even has plans to implement this...

the effect you describe (both are the sympthom of the same thing infact) have little to do with PAL :) it's also something which varies a lot (much more than other PAL stuff) depending on the combination of vic/monitor/cable

2008-11-26 17:27

algorithm

Registered: May 2002
Posts: 702

As long as the pc/linux tool displays the output as accurately as the c64 would (eg with pal emulation) then this is all that is required. There would be zilch advantage on using a c64 in this case.

Whats important in a converter or cross development gfx tool is to ensure that the output looks as accurate as possible as it would on a real c64. No point in displaying an ifli pic as 320x200x16 as it will certainly not look like this on a real machine (due to the 2x1 pixels and overlap as well as the pal blending)

Click a button and import to c64 and will be just as good.there is absolutely no advantage in pixeling on a real c64 as long as the display output on the preview screen looks as authentic as possible

2008-11-26 18:02

Radiant

Registered: Sep 2004
Posts: 639

GangEd 1.01 much?

2008-11-26 18:19

DeeKay

Registered: Nov 2002
Posts: 362

Quote: As long as the pc/linux tool displays the output as accurately as the c64 would (eg with pal emulation) then this is all that is required. There would be zilch advantage on using a c64 in this case.

Whats important in a converter or cross development gfx tool is to ensure that the output looks as accurate as possible as it would on a real c64. No point in displaying an ifli pic as 320x200x16 as it will certainly not look like this on a real machine (due to the 2x1 pixels and overlap as well as the pal blending)

Click a button and import to c64 and will be just as good.there is absolutely no advantage in pixeling on a real c64 as long as the display output on the preview screen looks as authentic as possible

Oh my, listen to the coders talking... <:-) Do you also tell composers that reSID sounds exactly like the real thing? (just in case you actually believe that, go check the examples on kevtris page!)

2008-11-26 18:30

DeeKay

Registered: Nov 2002
Posts: 362

Quote: Quote:
It's definately not "bullshit", and you of all people should realize I know very well what I'm talking about. PAL-Emulation does neither dot-creep nor the "eating away" of pixels when rastered with black, which renders it EXTREMELY inaccurate for anything hires that's not interlaced, and AFAIK nobody even has plans to implement this...

the effect you describe (both are the sympthom of the same thing infact) have little to do with PAL :) it's also something which varies a lot (much more than other PAL stuff) depending on the combination of vic/monitor/cable

That may be - just like filtercurves on SIDs vary. But is that a reason not to emulate the filter? 8)

And quite frankly I don't give a fuck what the cause is for that effect, just like composers don't care if it's the SID or some capacitors causing some effect.. IT'S FUCKING WRONG and far from 100% accurate, that's all that matters to me!

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: 93

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