Good Graph2fnt-artists?

[Lord-Chaos]

Is there anyone who would be able to convert AMIGA pictures to the ATARI 800 XL with Graph2fnt if I supply them?

 

I once wrote an unfinished rpg using Bard´s Tale graphics from ATARI ST (or AMIGA, both almost identical) in 256 color mode.It suffered from the lousy resolution.

 

The idea is to repaint the pics in 160*200 instead of 80*96 , the pictures are 112*88 on the AMIGA/ST , means 56*88 on the ATARI , usually less than 16 colors , there are more than 50 , almost 100 pictures.

 

The 3D graphics is build from tiles , has only 14 colors.

 

The game is pretty much a "conctruction set" , an engine , the only thing that is missing is an actual "game" , a story and a playable adventure.

 

BTW. You may look for "Beyond Castle Blackthorne" , it was the working title of the demo and may be somewhere in the net, it´s 128K and I think it was a double density disk.

 

I think with Graph2fnt the ATARI should almost reach AMIGA graphics quality , without animation.

 

I can also supply tgraphics of the Bard´s Tale clone "Legend of Faerghail" , which was 32color AMIGA (16 on the ST) , but non animated.

 

Thimo

[emkay]

Well... I think you know this picture already... It IS an AMIGA Conversion

 

 

 

It needs aprox. 10 "DLI's" and shows a max. of 8 colors in one scanline....

Fortunatly ... as Dracon told us.... a Graph2fnt version will soon be there which is making Mid-Line-changes possible....

Let's see, what we can do then

[Dracon]

Well, it has turned out that 'raster dividing' technique in chars mode isn't possible. There is some serious problems concerning (probably) timing, etc.

 

It's hard to explain precisely for me here... Every eight lines will be a "pause" in doing color changes... So... more color improvements got harder, anyway...

In graphix (bitmap) modes it works and it's simplier - for example in GED: raster dividing goes well there and is present on the whole screen... We will see what's next, but maybe anyone here will give any help on this ???

[emkay]

Well, it has turned out that 'raster dividing' technique in chars mode isn't possible.  There is some serious problems concerning (probably) timing, etc.    

 

 

It is a known issue that the first line of a charmode line is outpowered by 40 more DMA Cycles... But you have 7 more lines to use the feature of the so called "raster dividing".

Hey... even the C64 has a similar problem with the "Dirty-Line" but was it a handycap for a coder or an artist?

[Dracon]

It is a known issue that the first line of a charmode line is outpowered by 40 more DMA Cycles... But you have 7 more lines to use the feature of the so called "raster dividing".

What do you mean exactly? What should I tell to TeBe (he's looking for an idea) ?

Do you want to get a gfx mode in which you can change color several times in raster but not in the whole screen (as I said before, in every 8th line it will be stopped...) ??? That would suck, I'm afraid...

 

 

Hey... even the C64 has a similar problem with the "Dirty-Line" but was it a handycap for a coder or an artist?

really? So what's was C64 coders' solution about it ???

[Heaven/TQA]

cze my friend...

 

on c64 it's called "bad line" which seem to be similar to tebe's problem now... emkay's suggestion could be that you can use the advanced features in the 7 scanlines but in the 8 where he hasn't any cpu cycles left because of the char fetching etc just leave it "standard"... clever artists can work around...

 

but a message box should appear when the user wants to make a "raster split effect" on these lines and telling that it's not possible due to technical reasons...

 

reminds me on c64 FLI pictures where the 1st 3 rows are empty because of lacking CPU cycles...

 

ps. when can i have the 4pac MCS version????

[TMR]

Hey... even the C64 has a similar problem with the "Dirty-Line" but was it a handycap for a coder or an artist?

really? So what's was C64 coders' solution about it ???

 

We lose cycles all throughout the badline, so there are places where splits can still take place. More importantly, it doesn't affect bitmap mode because the screen isn't palette-based. The only exception to that is FLI and it's variants which, as Heaven says, lose the first three columns of the screen because we're screwing with the vertical smooth scroll on every rasterline for those first three characters and the way around that is to overlay multiple sprites onto the area to fill the gap since they're a rather convenient 3 characters wide (although it's a bugger to time, no WSYNC =-).

[emkay]

Hey... even the C64 has a similar problem with the "Dirty-Line" but was it a handycap for a coder or an artist?

really? So what's was C64 coders' solution about it ???

 

We lose cycles all throughout the badline, so there are places where splits can still take place. More importantly, it doesn't affect bitmap mode because the screen isn't palette-based. The only exception to that is FLI and it's variants which, as Heaven says, lose the first three columns of the screen because we're screwing with the vertical smooth scroll on every rasterline for those first three characters and the way around that is to overlay multiple sprites onto the area to fill the gap since they're a rather convenient 3 characters wide (although it's a bugger to time, no WSYNC =-).

 

 

Assuming the PMg abilities to fill the whole screen, it is more powerfull than the C64s Sprites, for the usage of "Image-Enhancement"

So it is always possible to brigde the whole charmode-line 0 with PM-"Underlay"... No one will recognize anything about a "Bad-Line)

[TMR]

Assuming the PMg abilities to fill the whole screen, it is more powerfull than the C64s Sprites, for the usage of "Image-Enhancement"

 

Well, it's not impossible to use the C64's hardware sprites for picture enhancement either; if they're in monocolour mode, horizontally expanded and recycled down the screen they match in nicely with a 160x200 pixel bitmap to give a fifth colour per character cell. Or it's possible to use the same sprite grid with the priorities low underneath a 320x200 res picture for AHires (have a look at Higher Love by Graffity for an example).

[emkay]

Assuming the PMg abilities to fill the whole screen, it is more powerfull than the C64s Sprites, for the usage of "Image-Enhancement"

 

Well, it's not impossible to use the C64's hardware sprites for picture enhancement either; if they're in monocolour mode, horizontally expanded and recycled down the screen they match in nicely with a 160x200 pixel bitmap to give a fifth colour per character cell. Or it's possible to use the same sprite grid with the priorities low underneath a 320x200 res picture for AHires (have a look at Higher Love by Graffity for an example).

 

Shure it is possible.

But this time you have to set some registers once and it will not cost any programming code to overlay PMg and Playfield with up to 160x240 pixel.

By midline-changes and PM multiplexing you can gain 12 colors per scanline for the full line while in a "Charmode 0" line only 6 colors can be used for the full line. For color ranges...in addition... you can use the separate colors of every P&M .

 

I hope TeBe will not retire from putting this feature into G2F.

[Heaven/TQA]

@ tmr

 

as i played around little bit with c64... i havent found any info that you can use sprites in kind of transparent mode and to mask pixels/colors? like you can do with atari PMs?

[analmux]

Do you mean that the c64 can't show sprites BEHIND playfield graphics.??

[Heaven/TQA]

@ ana

nope... i mean that sprite gfx is kind of altered with background like on some atari gfx modes...

 

f.e. make sprites transparent in front of chars, etc...

 

http://www.s-direktnet.de/homepages/k_nadj...dj/pmtrans.html

[TMR]

Do you mean that the c64 can't show sprites BEHIND playfield graphics.??

 

They're either in front of or behind, not affecting the colours like the Atari can do; fixed palette an' all that gubbins. =-) To be strictly accurate, when the sprite prioritie bits are set (selectable for each sprite) they only disappear behind one of the multicolours and character colour so if a background is designed well they can appear to be in front of some things and behind others with no programming required (have a look at Implosion for an example).

 

There are a few fun tricks possible if, for example, sprite 0's priority is set and sprite 1's isn't - because sprite 0 is always on top of sprite 1 it causes the background detail to mask off sprite 1 wherever they cross.

[TMR]

as i played around little bit with c64... i havent found any info that you can use sprites in kind of transparent mode and to mask pixels/colors? like you can do with atari PMs?

 

No, it's not possible and anything you see doing it is processing for all it's worth to make it happen. =-)

[analmux]

Okay, I must have misunderstood

 

No, the C64 doesn't have a transparant sprite mode AFAIK.

 

Atari 8bit is unique in this.

 

Atari makes use of ORing the setcolor values of the graphical elements (mixing PM and PF). As the C64 has no setcolor registers, just COLORs, they can't be mixed.

 

Try to mix color 0 and 1 on the c64 (I think it's black and red), the resulting color doesn't exist on the c64.

 

------

mux

[analmux]

There are a few fun tricks possible if, for example, sprite 0's priority is set and sprite 1's isn't - because sprite 0 is always on top of sprite 1 it causes the background detail to mask off sprite 1 wherever they cross.

 

This reminds me of the way sprites are clipped on the NES.

 

Take a look at Super Mario Bros 3, when mario enters a sewer tube. You see some square (black/red) shaped sprite blocks, they are behind PF graphics, and mario disappears behind them.

 

-----

mux

[tebe]

raster changes, random colors

[emkay]

raster changes, random colors

 

 

Very nice feature. When will you release that version of Graph2fnt?

Is it possible to multiplex a PLAYER in a scanline too?