Jump to content
IGNORED

Better Graphics!?!?!?!


Recommended Posts

Ok -- so now I get MCS, what about doing some of the stuff like this:

 

http://www.studiostyle.sk/dmagic/gallery/gfxmodes.htm

 

Surely there are some ideas here that the Ataari could steal...

 

I've seen soem of the GTIA trick modes, most look chunky or flickery -- these C64 IFLI etc modes look really rather nice!!!

 

Any ideas??

 

sTeVE

Link to comment
Share on other sites

TIP isn't the same as IFLI, the colour depth is better but it's only half the resolution; IFLI is 296x200. We've been reading up on the Atari's abilities and i don't think many of the "custom" modes are actually translatable, they rely too heavily on the way the C64 handles it's display.

 

The C64 technically functions at 320x200 regardless of which mode the graphics are in, so it's possible to overlay monocolour sprites on a multicolour picture or scroll 160x200 images at half a pixel; MCI and IFLI both rely on the scrolling for smoothness of the interlace (they overlap half pixels) and UFLI, SHIF or X-FLI have sprite overlays to increase their resolution or colour depth. One mode that does have promise is possibly AHires (320x200 3 colours) although it'd probably be limited to half screen width on the Atari when the C64 is full screen.

Link to comment
Share on other sites

What about enhancing MCS (160*192(240)):

 

MCM -> Multiplex mode

 

Using the full screen DLI for changing colors and Player positions by a logic filter to create pictures with up to 128 Colors. This would look like multicolor pictures on the C64. There will be time left for playing music...

 

MCI -> MCS interlace

 

Using the MCS technique with interlaced colors. This would enhance the possible colors to theoretical 128X128 = 16384.

Usable would be ~81 colors

 

 

MCX -> MCM interlaced

 

Using MCM with Interlace. This means simply 16256 colors with more than 6000 colors viewable. But that is a non serious Number, belonging to the resolution itself.

 

 

 

Some Hires modes to explain ? ;)

240x240 for example?

Link to comment
Share on other sites

TMR, thanks... i thought that IFLI are 160x200 still...

 

but we can expand the resolution by removing borders, etc...

 

and we can use these modes for fullscreen effects like in Numen, have you seen numen on emu? you need atari800win 3.x at least so the gfx is emulated correctly....

 

hve

Link to comment
Share on other sites

TMR, thanks... i thought that IFLI are 160x200 still...

 

but we can expand the resolution by removing borders, etc...

 

and we can use these modes for fullscreen effects like in Numen, have you seen numen on emu? you need atari800win 3.x at least so the gfx is emulated correctly....

 

hve

 

MSC can build a similar color-palette with a higher resolution anyway.

By using of DLI ;) No...not Displaylist Interrupt but Display-List Interlace ;)

You can build multi color modes in Hires....

And if Heaven can remember how he got the extra Screen line, he would be able to build a routine to let ANTIC srcoll half-Scanlines to build colored modes like 384*476 ;)

Link to comment
Share on other sites

All that happens with only Displaylist changes is nothing to real mention of CPU Usage.

The biggest Problem of the XL/XE is not the CPU it is the Memory of only 64k. So I am still dreaming of an active Memory Controller :ponder:

Please remember: A picture of 320*200 with real 256 colors uses 64k for itself.

Another problems are the "Hi tech" MCS editing tools.... there is none ;(

As I released the MCS Slideshow I still hoped, that it would be recognized by any Demo-Coder-Crew......but nothing happened...

Link to comment
Share on other sites

Here is on of the Pictures...from Jetboot Jacks link.

I made it a KIND BIGGER and outlined some C64graphics trick-lacks , which shows the way C64 pictures have to be made.

A "schooled EYE" can see the 4x8 (8x8) raster ....

In this way and without a big CPU usage or Interlace 30 colors are for real no problem on the XL/XE.

Link to comment
Share on other sites

Here is on of the Pictures...from Jetboot Jacks link.

I made it a KIND BIGGER and outlined some C64graphics trick-lacks , which shows the way C64 pictures have to be made.

 

Only in multicolour, FLI has attribute cells that are 4x1 pixels so that's one shared colour, one colour per 4x8 cell and the other two colours can be changed every rasterline giving 16 colours per 4x8 cell on those alone.

Link to comment
Share on other sites

TMR, thanks... i thought that IFLI are 160x200 still...

 

but we can expand the resolution by removing borders, etc...

 

That doesn't increase the resolution as such, just makes the picture bigger; HIP's pixels are simply twice as wide as either MCI or IFLI either before or after you take the interlace into account. If it were possible to scroll a 160x192 picture by half a pixel, MCI would be possible.

 

Technically an IFLI screen is 320x200 (FLI is 160x200) but the lefthand 24 pixels (12 for FLI) aren't useable because that's where the vertical smooth scroll is being messed with to force more badlines. It's possible to place sprites over that area and fake it, though.

 

have you seen numen on emu? you need atari800win 3.x at least so the gfx is emulated correctly....

 

Yup, seen it. =-)

Link to comment
Share on other sites

 

Only in multicolour, FLI has attribute cells that are 4x1 pixels so that's one shared colour, one colour per 4x8 cell and the other two colours can be changed every rasterline giving 16 colours on those alone.

 

Similar in MCS with fullscreen DLI (without interlace).

 

Per scanline 9 colors are available. With fullscreen DLI it is possible to update all Colors and Player positions each scanline multiple.

With the Charmode, the PMG Overlay and fullscreen DLI you may display up to 32 colors in a Block of 4*8. To make very good pictures only 8 colors are needed to view every 4*8 Picture-cells/color-clocks.

 

But... in fact... your argues are heavier than mine... because on the C64 are pictures made to proof them.... On the XL/XE it is still theory.

Link to comment
Share on other sites

So, if I undestand correctly...

 

C64 FLI is done by a simulation of a DLI or kernal allowing colors to be changed on each scanline -- so with MCS type displays we can get 9 colors per line, and on each line a different 9 - which is great :)

 

C64 IFLI uses the finer scrolling of the C64 (one Antic mode F pixel resolution as opposed the the Atari 8bit's Antic E pixel resolution for scrolling) to flicker the picture back and forth whilst swapping the contents of the screen between 2 FLI images.

 

So on the 8bit we could use a 160X192 5 color Antic 4 display and we could vertically flicker the display (scroll down one scanline display image one, scroll up one lscanine display image 2) and get pretty much the same effect without having to go into TIP/HIP style GTIA big pixel modes -- which always looked too chunky for my eyes :)

 

But -- interlacing is always flickery :(

 

Now what about multiplexing the PMG sprites horizontally for MCS into 2 sections (Left and Right of the screen) and changing their color on either side of the screen -- to get 8 unique PMG colors in 8 sections to enhance MCS -- ok so the CPU would have little time for anything else, but that's not the point, the image quality would be good and no interlacing, just DLI

 

Of course combined with interlacing and we could get mad images....

 

Anyone think any of this sounds feasible??

 

sTeVE

Link to comment
Share on other sites

Jetboot Jack

 

You have understood correctly. But you didn't understand all of it ;)

 

At first: To get a resolution of 160x192(240) with up to 128 colors Interlace is not needed.

 

The good thing of a "full screen DLI" is, that there is only one WSYNC needed to put the rest of the colors allways on the same position of the screen.

The manual screen of my game ADMIRANDUS changes by LDA $ STA$ 12 colors visible( one register 12 times) in every Charmode-line (I don't know how much color changes are not visible in the black borders))

In addition: Using Charmodes means, you have only 1 big line which is using much DMA. The next 7 lines you can do additional things like a precise timing for POKEYs soundregister updating.

The question is not if it would be feasible. The question is: When will it ever be done?

 

 

 

Supplemental:

 

One not unimportant fact is:

 

On the C64 Interlace gains 128 colors, which are flickering

On the XL/XE there are 128 colors possible without flickering.

Link to comment
Share on other sites

ok guys.... the question is really...why the hell non of the polish coders ever used this mode?????????

 

i'll ask our experts fox,eru & dracon... there must be a reason... ;)

 

so... emkay... i love your energy in promoting this mode... so where is your "converter" for this??? or editor??? you must have a kind of tool otherwise how did you make your slideshow? ;)

 

one reason why this MCS was never used... you could not make a "sprite" cursor to draw in a painting software... ;)

 

steve... HIP/TIP must be better looking on TV sets than on 21'' pc monitors... :) on that even IFLI flickers... ;)

 

TMR... i'll have to double check regarding $D404 (HSCROL) as all doc tells me antic scrolls by "color-clocks"... but f.e. in highres modes... a pixel is 1/2 color clock... so you might be right... remembers me that for my monochrome scrollers i always used 0-3 for hscroll to move a char...so this seem to be true...

 

hve

Link to comment
Share on other sites

Heaven

 

1. You don't need to tricky use a scrollregister just for Hires you can use a DL-Interlace. This means:

 

DL

 

e

f

e

f

e

f

 

The next frame uses:

 

DL

 

f

e

f

e

f

e

 

and back....

 

And you have your "hires" Colormode...

 

 

 

2. Your "cursor" to draw pictures could be made by a "EOR" Softwaresprite ;)

 

 

 

3. If I were a Coder Crew I would develop all around MCS and Hires color ;)

Link to comment
Share on other sites

ok guys.... the question is really...why the hell non of the polish coders ever used this mode?????????

 

 

Take a look on the "best" Emulator for the XL/XE. Go one step beside the standard book coding, and the emu produces garbage or nothing. This belongs to the graphics and to the sound. And I am not writing about any HW-bugs, that the emulator does not keep.

IMHO the XL/XEs Emulation ist not even at 50% of the real machine. And to view the achievement of the demos and games is by the fact, that they are running quite well on the 50% emulator.

Or should I write else: Ofcourse is a 50% used machine (XL/XE) worse than a 150% used machine (C64)....

Link to comment
Share on other sites

hmmm. you might be right to a certain point... but why is it then not possible to do a 1:1 port of f.e. giana sisters? on c64 not high tech on atari it would need a lot of afford... if you want to have it looking like the c64 original...

 

ok... f.e. the ik+ project shows that its possible with ik+ from c64... but is it just possible because archer mclean developed the engine on atari? and therefore the c64 version is using just 80% of the machine? where <re f.e. the sprites if all are just "software sprites"???

 

i know nothing is for free in life except death but f.e. would be a summergames II possible? summergames I looks poor compared to the c64...

 

hve

Link to comment
Share on other sites

hmmm. you might be right to a certain point... but why is it then not possible to do a 1:1 port of f.e. giana sisters? on c64 not high tech on atari it would need a lot of afford... if you want to have it looking like the c64 original...

 

 

Heaven... we are talking about pictures and to get the highest Quality ... do you remember ? ;)

 

This time I will answer your question with a new question ;)

 

What would we talk about, if I never had built the MCS standard?

Maybe we were talking about: if it ever it was possible to use multiple Fonts and PM overlay to create pictures with more colors :ponder:

Today we are talking about how much colors are possible.

If only one coder team had built a tool to edit my released MCS pictures in the time from 1991 to 2003, I would look somehow to develop games with this... But it seems to be the hardest way to get sh*t out of the XL/XE users brains and to use different techniques without any questions...

Standard programming is like:

 

-make a picture

-make a dli

-make a sound

-make a VBI

 

What about optimizing programming by

 

-make a screenroutine inside a DLI (colorchanging and incl. scrolling and soundtiming etc.)that is used during the screen is build and DMA uses the most Time....?

-The processor has the most speed (near 1,79MHz) available, when no DMA is used. This is the time from the last displayed line until ANTIC reads the DL-Data. Viewed by thumbnail the gameroutine has about still 600MHz available....

What will be possible?

Link to comment
Share on other sites

So, if I undestand correctly...

 

C64 FLI is done by a simulation of a DLI or kernal allowing colors to be changed on each scanline

 

Sort of, sticking to multicolour bitmap for the moment, the C64 uses bit pairs to represent colours so a 4x8 pixel area is eight bytes. The VIC-II uses two 1,000 byte attribute maps that control the colour for each 4x8 pixel; two nybbles from one map for %01 and %10 bit pairs, a nybble from the $d800 colour RAM for %11 and the background colour is %00 so each character cell has three colours.

 

Since the C64's RAM is divided into four 16K banks and the 8,000 bytes of bitmap data take half of a bank, there are eight spaces for 1,000 bytes of colour so if the screen pointer is changed every rasterline the top pixel line of the bitmap is fed colour from screen 1, the second from screen 2 and so on, going back to screen 1 after screen 8.

 

C64 IFLI uses the finer scrolling of the C64 (one Antic mode F pixel resolution as opposed the the Atari 8bit's Antic E pixel resolution for scrolling) to flicker the picture back and forth whilst swapping the contents of the screen between 2 FLI images.

 

[Nods] Yup.

 

So on the 8bit we could use a 160X192 5 color Antic 4 display and we could vertically flicker the display (scroll down one scanline display image one, scroll up one lscanine display image 2) and get pretty much the same effect without having to go into TIP/HIP style GTIA big pixel modes -- which always looked too chunky for my eyes :)

 

But -- interlacing is always flickery :(

 

Ah, no. IFLI relies on that half pixel overlap. For the first frame the pixels could be;

 

AABBCCDD

 

...and on the second they might be...

 

DAABBCCD

 

...and that overlap blends them together far better than just swapping images. That's why HIP and it's variants work so well, they're basically doing the same thing but with wider pixels.

Link to comment
Share on other sites

one reason why this MCS was never used... you could not make a "sprite" cursor to draw in a painting software... ;)

 

What, you think with 200 of the 300 rasterlines of CPU used to display a FLI or IFLI image on the C64 there's an editor that lets you paint directly into those modes? Every native FLI/IFLI/whatever editor i've seen edits to a zoomed image... =-)

 

steve... HIP/TIP must be better looking on TV sets than on 21'' pc monitors... :) on that even IFLI flickers... ;)

 

IFLI flickers a lot less on a composite video monitor than it does under emulation, part of the problem is that the emulators aren't always 50FPS, another part is the colour palette isn't perfect. With a good choice of colours, IFLI is very clean, as HIP is if the colours for the image are chosen well.

 

TMR... i'll have to double check regarding $D404 (HSCROL) as all doc tells me antic scrolls by "color-clocks"... but f.e. in highres modes... a pixel is 1/2 color clock... so you might be right... remembers me that for my monochrome scrollers i always used 0-3 for hscroll to move a char...so this seem to be true...

 

i'm only going by the sketchy research i did, feel free to check me but i've never seen anything in 160x192 scroll half a pixel on the Atari...?

Link to comment
Share on other sites

i'm only going by the sketchy research i did, feel free to check me but i've never seen anything in 160x192 scroll half a pixel on the Atari...?

 

You are correct. You may only scroll by 1 160th at a time.

 

-Bry

Link to comment
Share on other sites

we all should not forget...

 

here is the TIP editor for PC to paint/color pics...

 

http://www.atariage.com/forums/viewtopic.p...9&highlight=tip

 

so emkay... would it not be possible to code a converter/enhancer on PC in c? you could simply (?) have a transfer table PC color - XL table which holds all information and transfers that to display list, sprite overlays, positions for color change etc... should be not impossible...

 

re: "interleaving between rasterlines"

 

i want to point out that in numen we have most of the time (esp. the HIP/TIP effects (plasma tunnel with the flower, TQA bumpmapping) things going on between rasterlines so it's more "kernel" routines like on 2600... ;) fox squeezed out every CPU cycle he can, so minimum of CPU wasting... the stuff is draw "on the fly" with the rasterbeam... not like i do code my stuff... waiting for VBL and then prepare the display buffer... ;)

 

re: 1/2 color clock interlace like HIP/TIP with higher resolution...

 

emkay, the mode e + f interlacing (vertically) does not gain anything to have more colors??? or would it be possible to have a 320x200x4????

(without DLIs + PM stuff)

 

re: "cursor in HIP/TIP"

 

TMR it was more an inside joke... as some HIP mode uses all color registers available on atari, so even the ones for sprites... but i guess this is not true for TIP anymore... as TIP does not use any except background:

 

again here are the docs:

 

hip:

 

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

 

tip:

 

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

 

and more infos on the "kernel technique":

 

http://www.s-direktnet,de/homepages/k_nadj...dj/mode9++.html

 

hve

Link to comment
Share on other sites

Heaven

 

>so emkay... would it not be possible to code a converter/enhancer on PC in c? you could simply (?) have a transfer table PC color - XL table which holds all information and transfers that to display list, sprite overlays, positions for color change etc... should be not impossible...

 

It is truely not impossible. But you have to manage the timing of the original machine. Therefore it was necessary to create such a Fullscreen DLI that a coder may adapt...

 

>fox squeezed out every CPU cycle he can, so minimum of CPU wasting... the stuff is draw "on the fly" with the rasterbeam...

 

There is a big difference between TIP and a non flickering mode in which colors be changed multiple in one scanline. By using the DLI, really nothing can interfere any color...

 

 

 

>emkay, the mode e + f interlacing (vertically) does not gain anything to have more colors??? or would it be possible to have a 320x200x4????

(without DLIs + PM stuff)

 

For the first time: yes . But what will stop you from using DLI colors ?

Link to comment
Share on other sites

i'm only going by the sketchy research i did, feel free to check me but i've never seen anything in 160x192 scroll half a pixel on the Atari...?

 

You are correct. You may only scroll by 1 160th at a time.

 

-Bry

 

 

Correct.

 

But why is the scrolling of the ANTIC smoother than on C64 VIC?

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

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