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

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-26 08:38

TPM

Registered: Jan 2004
Posts: 109

Well, i think Rambones' idea is the best so far. I can imagine there are several solutions to use sprites in the border, depends on the screenlayout together with some other gimicks and effects on the screen. E.g. then you can choose how the border sprite is generated (multicolored, interlaced, sprite overlays, etc), otherwise you sticked to the solution of the editor, i'm afraid, and for a designer that would be a limitation, while the designer usually doesn't prefer any limitation.
It's not for crossdev's sake, but for the best result sake ;) Crossdev just makes you (designer and coder) more flexible.

2008-11-26 09:21

Mace

Registered: May 2002
Posts: 1799

Since we're thinking out loud, I'll dump some of my brainfarts:

During editing, I don't think it's necessary to have the sprites in the border already. In edit mode, the sprites can be within the screen area, with part of the picture attached.

No need to build an editor for the entire picture, but it might be wise to be able to pixel at least some pixels on the edge of the picture to make it fit better to the colour restrictions of the sprites.

Let's presume we're only talking about sideborder editing.
The layout of the editor could be so that one half of the screen holds the sprites and part of the picture, over the entire height.
On the other half you have a zoom area and perhaps a part with tools/icons/info.

Depending on which side of the picture you work on (left or right) these halves swap, so that it has some sort of an intuitive visual interface.

I thought of a name for the editor, but it seems there's already a Triad demo by the name of 'Over The Edge' :-)

Any suggestions?

2008-11-26 13:23

DeeKay

Registered: Nov 2002
Posts: 362

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

Dude, maybe you should check our tooldisks before you call me naive. I've used OSCAR and I've worked with and on many c64-tools and also made many SB-gfx to be able to say this is very well doable on c64 itself.. Using crossdev to *make* the editor is another thing, that for sure is easier and more comfortabe..

Maybe it helps to stress -yet again- that OSCAR is from 1988! <:-)

And for the record: With what I'm doing right now I can see what a huge difference there is between gfx displayed on a c64 and on a PC, PAL-emulation notwithstanding!

2008-11-26 13:25

Cruzer

Registered: Dec 2001
Posts: 1048

Reminds me of an idea I had a few years back - a gfx editor on a modern platform (preferrably Java or otherwise platform independent) which could handle any c64 mode. This could be done relatively easy if it was the user's responsibility to make something that was possible to display. The tool should just provide 8 sprites and a background layer to draw on, as well as all the VIC properties like multicolor on/off, border on/off, sprite x-expansion, sprite color, etc. customizable for each line.

The output format should include the bitmap/char/sprite gfx as well as some tables for all of these properties, and then the user needed to make a converter that could turn this into a displayer routine.

Not as easy to use as an editor for a predefined format, but easier than using layers in Photoshop, and a lot more flexible than a usual editor.

I think the ultimate C64 mode would be (I)UFLI with some more flexibility for the sprites. A single layer of sprites is not ideal since you need more detail on some areas, and on other areas the sprites are not needed at all. So it would be better if it was possible to concentrate the sprites where they are most needed, as well as change properties like x-expansion, multicolor mode and colors. MUFLI was a step in the right direction, but still not as good as it could be.

2008-11-26 13:27

DeeKay

Registered: Nov 2002
Posts: 362

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

2008-11-26 13:33

DeeKay

Registered: Nov 2002
Posts: 362

Quote: Reminds me of an idea I had a few years back - a gfx editor on a modern platform (preferrably Java or otherwise platform independent) which could handle any c64 mode. This could be done relatively easy if it was the user's responsibility to make something that was possible to display. The tool should just provide 8 sprites and a background layer to draw on, as well as all the VIC properties like multicolor on/off, border on/off, sprite x-expansion, sprite color, etc. customizable for each line.

The output format should include the bitmap/char/sprite gfx as well as some tables for all of these properties, and then the user needed to make a converter that could turn this into a displayer routine.

Not as easy to use as an editor for a predefined format, but easier than using layers in Photoshop, and a lot more flexible than a usual editor.

I think the ultimate C64 mode would be (I)UFLI with some more flexibility for the sprites. A single layer of sprites is not ideal since you need more detail on some areas, and on other areas the sprites are not needed at all. So it would be better if it was possible to concentrate the sprites where they are most needed, as well as change properties like x-expansion, multicolor mode and colors. MUFLI was a step in the right direction, but still not as good as it could be.

Oh, MUFLI is fucking amazing, believe me! ;-) I thought about arranging sprites where they are most needed, kinda like the overlays in those Rainbow Arts intropics (Grand Monster Slam or Circus Attractions), too, but it'd make pixelling even MORE complicated than it already is.. Nobody is using our editors already anyway as it is, so the option to arrange sprites manually would be pointless and would prolly even scare away the people that dare to try it...

It helps to remember that "As good as it could be" depends *solely* on what picture you're trying to make!

I'm trying a quite different approach now to popularize these modes, stay tuned for that..

2008-11-26 13:39

chatGPZ

Registered: Dec 2001
Posts: 11154

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.

2008-11-26 13:41

Cruzer

Registered: Dec 2001
Posts: 1048

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

Still it's probably easier to do proper PAL emulation than to do the ultimate gfx tool on C64.

2008-11-26 14:05

Oswald

Registered: Apr 2002
Posts: 5031

Cruzer, right I said this too, an all round editor would need to feature a simple line based VICII "emulator" (concentrating on the output only), and possibility to change any register on any line. Ofcourse skipping the hairy stuff like d011 tricks, spritecrunch, d018 change should be possible on each line, sprite plexing should come for free just like turning off borders, etc. when this is done the hard thing is to find out & realize a clever user interface to draw into this :)

2008-11-26 14:22

chatGPZ

Registered: Dec 2001
Posts: 11154

Quote:

Cruzer, right I said this too, an all round editor would need to feature a simple line based VICII "emulator" (concentrating on the output only), and possibility to change any register on any line. Ofcourse skipping the hairy stuff like d011 tricks, spritecrunch, d018 change should be possible on each line, sprite plexing should come for free just like turning off borders, etc.

hehe, thats almost exactly how my converter works.... except i missed the opportunity to support gfx in borders when i started, and now its too late =P

Quote:

when this is done the hard thing is to find out & realize a clever user interface to draw into this :)

...and that was the point when i didnt bother to finish the whole thing :) the user interface is super annoying to code =P

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

Nordischsound/Hokuto..
t0m3000/HF^BOOM!^IBX
Didi/Laxity
Flavioweb/🇮🇹HF..
d0c
Barfly/Extend
MCM/ONSLAUGHT
Nith/TRIɅD
aeeben
Guests online: 122

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 Swappers

1 Derbyshire Ram  (10)
2 Jerry  (9.8)
3 Violator  (9.8)
4 Acidchild  (9.7)
5 Cash  (9.6)

Page generated in: 0.06 sec.