Jump to content
IGNORED

Graph2fnt


emkay

Recommended Posts

Wow - if something like this was available back in the C64vs800 wars it wouldve really helped the ole 800 ;)

Now I could say something... but I don't :)

 

Those (G2F) pics are simple conversions. No Interlace is used, no res-switching, no overlay (GPRIOR) colours...

We know, C64 has a higher "colour-resolution" , but don't even think about "Interlaced modes". With interlace, the C64 loses anyway.

Example: two interlaced pictures on the A8 means up to 9x9(81) colours per scanline. Even with the PAL artefacting on the C64, you will not gain that much colours.

Well... and you can interlace hires with colour modes.... not done before, but possible.

Link to comment
Share on other sites

Those (G2F) pics are simple conversions. No Interlace is used, no res-switching, no overlay (GPRIOR) colours...

We know, C64 has a higher "colour-resolution" , but don't even think about "Interlaced modes". With interlace, the C64 loses anyway.

Example: two interlaced pictures on the A8 means up to 9x9(81) colours per scanline. Even with the PAL artefacting on the C64, you will not gain that much colours.

Well... and you can interlace hires with colour modes.... not done before, but possible.

Interlace is one of the most crappy "tricks" ever used to "enhance" resolution. Look at some true 320x200 pictures instead :)

Edited by Fröhn
Link to comment
Share on other sites

 

It rulez because with a lot of trickery it can nearly do what a C64 can do without any tricks? :D

 

Trickery is, when Intelace is used, or cpu time is wasted for software raster programming.

DLI and the PM Overlay was ever available. So no trickery here. Only available featurs are used together ;-)

Link to comment
Share on other sites

It rulez because with a lot of trickery it can nearly do what a C64 can do without any tricks? :D

Trickery is, when Intelace is used, or cpu time is wasted for software raster programming.

Gnaaah interlace. Interlace is still no trick, and it sucks anyway because it flickers like hell.

DLI and the PM Overlay was ever available. So no trickery here. Only available featurs are used together ;-)

DLI = trickery to me, DL = no trickery. Anyway, if you see DLI's as "no trickery" then you should also see C64 raster IRQs as "no trickery" aswell, since they are almost the same: Issue IRQs on certain rasterlines. And with one IRQ every 8 rasterlines you can already do HEAVY gfx-mode trickery on C64 :)

Link to comment
Share on other sites

It doesn't matter what DLI is, more important is, what incredible and great things it does. DLI by itself does nothing, it is powerful when other Atari's features are used. It is not usual programming habit to use DLIs unless you are intermidiate or advanced programmer, so it my be called a trickery. But we all know it is one of Atari's strengths, sorry, features.

Link to comment
Share on other sites

Shouldn't that be 9+9=18 ?

No. ;-)

 

For example: simple overlapping 16 colour mode with 16 brightness mode = 256 (16x16)colour mode

You can multiply every available colour with the interlaced colour.

You both are wrong. If you mix red and green via interlace, it is the same as mixing green and red. If you mix two colors of the same palette, you get this formula: n*(n+1)/2. So mixing colors via interlace with the C64 palette results in 136 colors, if you do the same with a 9 color palette it's 45 different colors. Ofcourse, not all of these color combinations look good...

Link to comment
Share on other sites

Shouldn't that be 9+9=18 ?

No. ;-)

 

For example: simple overlapping 16 colour mode with 16 brightness mode = 256 (16x16)colour mode

You can multiply every available colour with the interlaced colour.

You both are wrong. If you mix red and green via interlace, it is the same as mixing green and red. If you mix two colors of the same palette, you get this formula: n*(n+1)/2. So mixing colors via interlace with the C64 palette results in 136 colors, if you do the same with a 9 color palette it's 45 different colors. Ofcourse, not all of these color combinations look good...

 

wrong too, emkay is right: when mixing graphics 9 (GTIA mode $40) and graphics 11 (GTIA mode $C0) you get 256 colors, simple as that. The modes both do not rely on the 9 palette colors, and the colorsets used for both modes are disjoint and distinguishable....

 

your argument only holds if you keep the palette (and gfx mode) constant every scanline....however it is hardly possible to change all 9 palettes every rasterline ;)

 

..but indeed, this color mixing of the PAL system sucks (even without interlace/flicker) ...on the NTSC it won't work and to generate such a display you need a timekilling DLI kernel.

 

...but about the point made on raster IRQ's: a C64 MUST do raster interrupts do reuse sprites for a vertical shape setup (if other sprites are already in use)...the Atari doesn't need that trick. In the contrary...the atari can even multiplex PMg in the horizontal range: 6 players are easily done, and then you still have the 'great' missiles :)...horizontal multiplexing is not possible (though also not needed) on C64....etc.etc.

 

So anyway, both computers have their qualities/advantages as pointed out many times before....and a MCS style picture does not make use of difficult DLIs...just positioning PMg in a clever way. Later eventually enhance the possibilities by DLI trickery or even GED type gfx (raster kernels).

Link to comment
Share on other sites

Shouldn't that be 9+9=18 ?

No. ;-)

 

For example: simple overlapping 16 colour mode with 16 brightness mode = 256 (16x16)colour mode

You can multiply every available colour with the interlaced colour.

You both are wrong. If you mix red and green via interlace, it is the same as mixing green and red. If you mix two colors of the same palette, you get this formula: n*(n+1)/2. So mixing colors via interlace with the C64 palette results in 136 colors, if you do the same with a 9 color palette it's 45 different colors. Ofcourse, not all of these color combinations look good...

 

 

Ive seen many Gfx in Atari and C64, and always think there are a lot of pictures that looks better in Atari, and others that looks betters in C64. The pictures in C64 seems to be a fantasy acrylic color style. Could you give us a link about the best C64 pictures source? Maybe I lost the better stuff.

Link to comment
Share on other sites

your argument only holds if you keep the palette (and gfx mode) constant every scanline....however it is hardly possible to change all 9 palettes every rasterline ;)

 

That's why I wrote "up to" .

At least 5 registers are changable in a DLI. So perhaps, someone builds a graphicsmode with interleaved colour set, changing only them permanently.

With Raster code in Graphics mode, all colours are changeable, but some of them will be changed in the visuable range.

So, nothing is impossible ;-)

And yes, we can switch a wider pallette range than 16 colours. :ponder:

Edited by emkay
Link to comment
Share on other sites

wrong too, emkay is right: when mixing graphics 9 (GTIA mode $40) and graphics 11 (GTIA mode $C0) you get 256 colors, simple as that. The modes both do not rely on the 9 palette colors, and the colorsets used for both modes are disjoint and distinguishable....

As I said: If you use the SAME palette for mixing, it's 136 laced colors on 16 unlaced. Ofcourse mixing luma mode with chroma mode is two DIFFERENT palettes which results in 256 colors.

 

But he was talking about using 9 color palette + lace mixing = 45 colors.

 

...but about the point made on raster IRQ's: a C64 MUST do raster interrupts do reuse sprites for a vertical shape setup (if other sprites are already in use)...the Atari doesn't need that trick.

As emkay said: Is it a trick to use DLIs/Raster IRQs? The C64 sprite logic was designed for software multiplexing, so you can hardly call it a trick then :)

 

In the contrary...the atari can even multiplex PMg in the horizontal range: 6 players are easily done, and then you still have the 'great' missiles :)...horizontal multiplexing is not possible (though also not needed) on C64....etc.etc.

Yes, but even if you multiplex all players and all missiles horizontally, you get only 10 bytes per line. The C64 sprites have 24 bytes per line without any horizontal multiplexing :)

Link to comment
Share on other sites

As emkay said: Is it a trick to use DLIs/Raster IRQs? The C64 sprite logic was designed for software multiplexing, so you can hardly call it a trick then :)

 

Exactly the same argument should indeed hold for the DLI color changes e.a.....at least in my eyes it's all normal coding based on the standard features of the computer...not making use of weird bugs in a videochip (like the weird GTIA bug for graphics mode 10). In my eyes f.e. the PAL color mixing is not more than a bug... Graph2font type screens on atari is as normal coding tricks as raster IRQ sprite multiplexing on C64.

 

...but my point is more like: the whole Atari vs. C64 discussion is old and boring.

we can list hundreds of advantages and disadvantages etc. and i.m.h.o. it doesn't add up to the general feeling of joy for our platforms.

 

After all they are very similar and comparable platforms too. And just because of that it's hard to tell which one is the best.

Try to compare the C64 or A8bit to other 8bits from the same era (early '80ies)....we see that they both are far better than others...the fact that this discussion is still not over yet can be interpreted as this: The platforms are equally good.

 

(by the way: one extra note....did you know the C64 spoils cycles of its 2MHz clock?)

Link to comment
Share on other sites

In my eyes f.e. the PAL color mixing is not more than a bug...

Which kind of "PAL color mixing"? The one with mode 9 and 10 = 256 colors? That's not a bug, it's a feature :)

 

Btw, that mixing is done in the PAL-decoder in the monitor. The Atari has nothing to do with it, you can use that kind of mixing on ANY system using a PAL video (RGB @ 50 Hz ain't PAL though, so no ST or Amiga).

 

(by the way: one extra note....did you know the C64 spoils cycles of its 2MHz clock?)

Depends on how many sprites you have turned on :)

Link to comment
Share on other sites

Now I could say something... but I don't :)

Speak out loud: Atari rulez :P

It rulez because with a lot of trickery it can nearly do what a C64 can do without any tricks? :D

 

I wouldn't call that trickery.

 

Player/Missile overlays will work in plain BASIC without a single

byte of MC-code. In charmode, using GPRIOR, 17 colors are possible.

 

Players and missiles can be as high as the whole screen and you

can redefine the shape in every line.

 

You can't change player positions and colors from line to line, but cleverly

made pictures or games graphics won't need any DLIs.

 

I posted a small demo program a few years ago showing these 17

colors. It's a BASIC program without any ML code.

 

LC

Link to comment
Share on other sites

In my eyes f.e. the PAL color mixing is not more than a bug...

Which kind of "PAL color mixing"? The one with mode 9 and 10 = 256 colors? That's not a bug, it's a feature :)

 

Btw, that mixing is done in the PAL-decoder in the monitor. The Atari has nothing to do with it, you can use that kind of mixing on ANY system using a PAL video (RGB @ 50 Hz ain't PAL though, so no ST or Amiga).

 

(by the way: one extra note....did you know the C64 spoils cycles of its 2MHz clock?)

Depends on how many sprites you have turned on :)

 

This actually works on both the ATARI STE and the AMIGA, at least on PAL systems.

 

I once wrote a Mandelbrot fractal program using 8 x 8 = 64 colors on the STE (8 colors

and 8 greys) and 16*16 on the A500 (32 color mode, 16 colors, 16 x greys). Technically,

more colors where possible, but I just wanted "good combinations".

 

It works by placing 2 pixels besides each other horizontally, reducing the resolution to

160*200. There are some artifacting glitches, so it doesn't look perfect.

 

I have to look for the program.It was written in Omikron BASIC on the STE and AMOS on

the AMIGA, for both systems my PAL TV was used. No machine code was necessary.

 

LC

Link to comment
Share on other sites

This actually works on both the ATARI STE and the AMIGA, at least on PAL systems.

 

I once wrote a Mandelbrot fractal program using 8 x 8 = 64 colors on the STE (8 colors

and 8 greys) and 16*16 on the A500 (32 color mode, 16 colors, 16 x greys). Technically,

more colors where possible, but I just wanted "good combinations".

 

It works by placing 2 pixels besides each other horizontally, reducing the resolution to

160*200. There are some artifacting glitches, so it doesn't look perfect.

 

I have to look for the program.It was written in Omikron BASIC on the STE and AMOS on

the AMIGA, for both systems my PAL TV was used. No machine code was necessary.

This is a different kind of "mixing" and heavily depends on the monitors resolution. But the mode 9 + mode 10 mixing does NOT depend on the monitor, since that happens during PAL decoding and also does not give you any artefacts or glitches but a perfect 50:50 mix.

Link to comment
Share on other sites

Btw, that mixing is done in the PAL-decoder in the monitor. The Atari has nothing to do with it, you can use that kind of mixing on ANY system using a PAL video

 

Sure - but, out of the common 8-bitters, only Atari has something substantial to mix this way (i.e. 16 hues x 16 shades = 256 colors). So you can't say that "Atari has nothing to do with it"; surely it has, it generates enough hues and shades so that the mixing makes sense and produces excellent effect: non-interlaced graphic mode in 256 colors, where each visible pixel has independent color from any other.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...