Atari v Commodore

[andym00]

When I have the time i will update the MUCSU converter which will result in Higher image quality using the same processing time as before

 

Each sprite column will have its own optimised color (48x200 pixels) as well as two different sprite multicolors per 21 raster lines

 

Furthermore the user can select 8x8 charblocks that the converter will concentrate on discarding the rest allowing the user to ensure that specific area's of the screen have less errors in comparison with other parts (eg background) in comparison with the default brute force that looks at the whole image only

That's great news! I'm dead curious how it fairs against NUFLI stuff with these additions

 

I've been working on some stuff to do this kind of conversion with it in mind to process blocks of bitmap and sprites in double width sprite chunks (for a game level), with variable colour split sizes down to 8 lines for the multicolours and sprite colours, but it looks properly shit in comparison to what MUCSU turns out

[thealgorithm]

When I have the time i will update the MUCSU converter which will result in Higher image quality using the same processing time as before

 

Each sprite column will have its own optimised color (48x200 pixels) as well as two different sprite multicolors per 21 raster lines

 

Furthermore the user can select 8x8 charblocks that the converter will concentrate on discarding the rest allowing the user to ensure that specific area's of the screen have less errors in comparison with other parts (eg background) in comparison with the default brute force that looks at the whole image only

That's great news! I'm dead curious how it fairs against NUFLI stuff with these additions

 

I've been working on some stuff to do this kind of conversion with it in mind to process blocks of bitmap and sprites in double width sprite chunks (for a game level), with variable colour split sizes down to 8 lines for the multicolours and sprite colours, but it looks properly shit in comparison to what MUCSU turns out

 

It will be a vast improvement over the previous MUFLI conversion results with the same processing time used as before (only multiplexing per 21 lines with two multicolor sprite location memory writes.

 

Ofcourse NUFLI has far less restrictions in the mode itself (2 colors per 8x2) instead of 8x8 as well as sprite color changes per 2 lines but at the expense of virtually every CPU cycle exhausted for the screen. If I can get image quality high enough using MUCSU particularly with the user selected 8x8 blocks in the image for the converter to concentrate on then it should give comparable results.

[irwin]

When I have the time i will update the MUCSU converter which will result in Higher image quality using the same processing time as before

 

Each sprite column will have its own optimised color (48x200 pixels) as well as two different sprite multicolors per 21 raster lines

 

Furthermore the user can select 8x8 charblocks that the converter will concentrate on discarding the rest allowing the user to ensure that specific area's of the screen have less errors in comparison with other parts (eg background) in comparison with the default brute force that looks at the whole image only

That's great news! I'm dead curious how it fairs against NUFLI stuff with these additions

 

I've been working on some stuff to do this kind of conversion with it in mind to process blocks of bitmap and sprites in double width sprite chunks (for a game level), with variable colour split sizes down to 8 lines for the multicolours and sprite colours, but it looks properly shit in comparison to what MUCSU turns out

 

It will be a vast improvement over the previous MUFLI conversion results with the same processing time used as before (only multiplexing per 21 lines with two multicolor sprite location memory writes.

 

Ofcourse NUFLI has far less restrictions in the mode itself (2 colors per 8x2) instead of 8x8 as well as sprite color changes per 2 lines but at the expense of virtually every CPU cycle exhausted for the screen. If I can get image quality high enough using MUCSU particularly with the user selected 8x8 blocks in the image for the converter to concentrate on then it should give comparable results.

 

 

Hey, i'm very glad to see you here in Atari forums. I try to take your side on csdb because many C64 users don't hear about your MUCSU and comment NUFLI as "A new standard is born."

Anyway, back to Atari: maybe when you here - Can you do similar conventer for the Atari sprites rules? Of course in lowres because we on Atari don't have hires sprites and very restricted hires mode. But in 2x1 mode, conventer like MUCSU which compute and place sprites in specific area, would be very usefull for us. For now we have G2F and all this things we must do manually - and this takes ages (Emkay you know )

[thealgorithm]

When I have the time i will update the MUCSU converter which will result in Higher image quality using the same processing time as before

 

Each sprite column will have its own optimised color (48x200 pixels) as well as two different sprite multicolors per 21 raster lines

 

Furthermore the user can select 8x8 charblocks that the converter will concentrate on discarding the rest allowing the user to ensure that specific area's of the screen have less errors in comparison with other parts (eg background) in comparison with the default brute force that looks at the whole image only

That's great news! I'm dead curious how it fairs against NUFLI stuff with these additions

 

I've been working on some stuff to do this kind of conversion with it in mind to process blocks of bitmap and sprites in double width sprite chunks (for a game level), with variable colour split sizes down to 8 lines for the multicolours and sprite colours, but it looks properly shit in comparison to what MUCSU turns out

 

It will be a vast improvement over the previous MUFLI conversion results with the same processing time used as before (only multiplexing per 21 lines with two multicolor sprite location memory writes.

 

Ofcourse NUFLI has far less restrictions in the mode itself (2 colors per 8x2) instead of 8x8 as well as sprite color changes per 2 lines but at the expense of virtually every CPU cycle exhausted for the screen. If I can get image quality high enough using MUCSU particularly with the user selected 8x8 blocks in the image for the converter to concentrate on then it should give comparable results.

 

 

Hey, i'm very glad to see you here in Atari forums. I try to take your side on csdb because many C64 users don't hear about your MUCSU and comment NUFLI as "A new standard is born."

Anyway, back to Atari: maybe when you here - Can you do similar conventer for the Atari sprites rules? Of course in lowres because we on Atari don't have hires sprites and very restricted hires mode. But in 2x1 mode, conventer like MUCSU which compute and place sprites in specific area, would be very usefull for us. For now we have G2F and all this things we must do manually - and this takes ages (Emkay you know )

 

The NUFLI format is far more advanced than MUCSU but uses all the processing time for one image. One thing I know for certain is that the converter results in NUFLI used in the crest demo are not optimum bearing in mind that MUCSU can create images that are near the same quality for most images without the requirement for tweaking. I think many users would prefer a mode which gives full processing time at similar quality to NUFLI particularly when the above enhancements are made.

 

I am hoping to create a NUFLI converter as well. Perhaps Deekay wishes that I created it before. This would have prevented him from spending hundreds of hours tweaking the conversion results. :-)

 

I dont know much of the Atari, but if you can give me file format/limitation info, I can put something together

[Rybags]

It sounds essentially the same to what G2F does already with underlays, except of course that G2F uses character mode.

 

The only optimisations up and above that would be:

- using the VScrol trick to create shorter characters. I've already suggested this. It allows you to then have the attribute select bit only affect e.g. 4 pixels instead of 8. By using CHACT to turn characters upside down, you use all 8 bytes of each character definition.

Shorter characters than that are possible but then you start wasting memory. The CIN+ mode I did only uses the top/bottom byte of each character, so 6 of 8 bytes go unused.

The other downside is that the more new character lines you have, the more CPU time is lost (badlines).

 

- Repositioning players, changing graphics, colours etc within a scanline. I don't really use G2F so can't say if it can already do that.

[Tezz]

- Repositioning players, changing graphics, colours etc within a scanline. I don't really use G2F so can't say if it can already do that.

Yes this is possible with G2F using the GED- mode in bitmap or GED+ in char. Of course in char mode you get a "bad line" every eighth scan line where ANTIC gets the address of the charset in the DLI.

You can cover this limitation with some creative use of player positioning. This is how I created the new Bomb Jake title screen a few months back.

Edited July 31, 2009 by Tezz

[Tezz]

The only optimisations up and above that would be:

- using the VScrol trick to create shorter characters. I've already suggested this. It allows you to then have the attribute select bit only affect e.g. 4 pixels instead of 8. By using CHACT to turn characters upside down, you use all 8 bytes of each character definition.

Shorter characters than that are possible but then you start wasting memory. The CIN+ mode I did only uses the top/bottom byte of each character, so 6 of 8 bytes go unused.

The other downside is that the more new character lines you have, the more CPU time is lost (badlines).

Hopefully Tebe will implement the Vscroll trick in G2F soon, reducing the char block limitation to 4 pixels will be handy. As we've read in that new char mode thread, Tebe is attempting to include that in the next G2F version.

[emkay]

The only optimisations up and above that would be:

- using the VScrol trick to create shorter characters. I've already suggested this. It allows you to then have the attribute select bit only affect e.g. 4 pixels instead of 8. By using CHACT to turn characters upside down, you use all 8 bytes of each character definition.

Shorter characters than that are possible but then you start wasting memory. The CIN+ mode I did only uses the top/bottom byte of each character, so 6 of 8 bytes go unused.

The other downside is that the more new character lines you have, the more CPU time is lost (badlines).

Hopefully Tebe will implement the Vscroll trick in G2F soon, reducing the char block limitation to 4 pixels will be handy. As we've read in that new char mode thread, Tebe is attempting to include that in the next G2F version.

 

I'm not convinced about any (more) useful graphics coming out of that mode. Possibly, it is another step into the direction of a working screenmode for fast 3D (viewed) games.

[Tezz]

I've not had chance to take a look at NUFLI on the c64 yet but from what I can gather from the info above and the link, the pc program that thealgorithm created for his NUFLI mode is nice in that it automatically sets the player underlays in the conversion which is something that has to be done manually in G2F. I've noticed that a lot of people checking out G2F for the first time assumes that they will be able to load a multicoloured bitmap in for an automatic process such as this. PeteD recently expressed an interest in creating his own tool to this effect. I don't personally mind working that part of the conversions out manually myself. If someone is able to write a very clever piece of code to automate this to the same ability of working it out with the manual process that will be great however.

Edited July 31, 2009 by Tezz

[frenchman]

I had a NUFLI once, it was great fun!

[atariksi]

...

I dont know much of the Atari, but if you can give me file format/limitation info, I can put something together

 

It's hard for him to give limitation info as not all Atari graphics features/possibilities are known by many people including him (at least in this thread). It's more by experiment-- people have been finding out gradually.

[atariksi]

The only optimisations up and above that would be:

- using the VScrol trick to create shorter characters. I've already suggested this. It allows you to then have the attribute select bit only affect e.g. 4 pixels instead of 8. By using CHACT to turn characters upside down, you use all 8 bytes of each character definition.

Shorter characters than that are possible but then you start wasting memory. The CIN+ mode I did only uses the top/bottom byte of each character, so 6 of 8 bytes go unused.

The other downside is that the more new character lines you have, the more CPU time is lost (badlines).

Hopefully Tebe will implement the Vscroll trick in G2F soon, reducing the char block limitation to 4 pixels will be handy. As we've read in that new char mode thread, Tebe is attempting to include that in the next G2F version.

 

I'm not convinced about any (more) useful graphics coming out of that mode. Possibly, it is another step into the direction of a working screenmode for fast 3D (viewed) games.

 

I prefer linear graphics modes over working with 4*8 or 8*8 grids. I think PC CGA would win with char-based graphics as they had 640*200*16 mode using VQ and reducing char height.

[atariksi]

I've not had chance to take a look at NUFLI on the c64 yet but from what I can gather from the info above and the link, the pc program that thealgorithm created for his NUFLI mode is nice in that it automatically sets the player underlays in the conversion which is something that has to be done manually in G2F. I've noticed that a lot of people checking out G2F for the first time assumes that they will be able to load a multicoloured bitmap in for an automatic process such as this. PeteD recently expressed an interest in creating his own tool to this effect. I don't personally mind working that part of the conversions out manually myself. If someone is able to write a very clever piece of code to automate this to the same ability of working it out with the manual process that will be great however.

 

I have an algorithm to place sprites optimally in GTIA mode 9 but it gets more complicated in 160*200 and Graphics 10 with GPRIOR mode 0.

[Tezz]

I have an algorithm to place sprites optimally in GTIA mode 9 but it gets more complicated in 160*200 and Graphics 10 with GPRIOR mode 0.

that's cool, are you still working on that? I'd be interested to hear more about it. Back in the late eighties / early nineties we wrote a simple graphics 10 drawing program with the ability to make some dli colour changes. We did a few title screens for the games we were working on and I seem to remember mocking up a screen of the game Virus from the ST with it. It's a bit limited what you can produce in a 4:1 sized pixel ratio but we loved to have so many colours freely available. Edited July 31, 2009 by Tezz

[Tezz]

I prefer linear graphics modes over working with 4*8 or 8*8 grids. I think PC CGA would win with char-based graphics as they had 640*200*16 mode using VQ and reducing char height.

Yea I prefer it too in terms of drawing freely although with the 2:1 pixel ratio modes graphics 12 (Antic 4) char mode and graphics 15 (Antic E) bitmap mode, it's really the two benefits that the char mode brings to the table over the bitmap mode that g2f was originally created for. The extra colour register and the memory saving if optiimising the amount of chars/fonts used. Reducing the char size to 4 pixels high will bring some more possibilities for the detail in the picture, especially where the 710/711 register colours are needed to be used close together. The raster splits are more useful in the bitmap mode however with no bad lines to worry about but losing a colour register is still a kicker Edited July 31, 2009 by Tezz

[atariksi]

I have an algorithm to place sprites optimally in GTIA mode 9 but it gets more complicated in 160*200 and Graphics 10 with GPRIOR mode 0.

that's cool, are you still working on that? I'd be interested to hear more about it. Back in the late eighties / early nineties we wrote a simple graphics 10 drawing program with the ability to make some dli colour changes. We did a few title screens for the games we were working on and I seem to remember mocking up a screen of the game Virus from the ST with it. It's a bit limited what you can produce in a 4:1 sized pixel ratio but we loved to have so many colours freely available.

 

Originally the pictures I posted in this thread were Graphics 9 gray-scale only with 8-pixels resolution enhanced with sprites-- a quick job. Now, I am trying to optimize the code to use colors and more pixels than 8. Graphics 9 doesn't have GPRIOR mode 0 so for more colorful objects, Graphics 10 would be better for resolution enhancement.

[atariksi]

I prefer linear graphics modes over working with 4*8 or 8*8 grids. I think PC CGA would win with char-based graphics as they had 640*200*16 mode using VQ and reducing char height.

Yea I prefer it too in terms of drawing freely although with the 2:1 pixel ratio modes graphics 12 (Antic 4) char mode and graphics 15 (Antic E) bitmap mode, it's really the two benefits that the char mode brings to the table over the bitmap mode that g2f was originally created for. The extra colour register and the memory saving if optiimising the amount of chars/fonts used. Reducing the char size to 4 pixels high will bring some more possibilities for the detail in the picture, especially where the 710/711 register colours are needed to be used close together. The raster splits are more useful in the bitmap mode however with no bad lines to worry about but losing a colour register is still a kicker

 

I was speaking of static imagery and for that you get more colors if you re-use colors than get that extra color from char mode at cost of 40 DMA cycles. That mode where you go from ANTIC F -> Antic E' on same scanline is pretty interesting since you can essentially do the entire screen in ANTIC E' and GTIA fill-ins where needed. I was recently experimenting with GPRIOR mode 0 in ANTIC E' -- get more color combinations than normal ANTIC E.

[Tezz]

I was speaking of static imagery and for that you get more colors if you re-use colors than get that extra color from char mode at cost of 40 DMA cycles. That mode where you go from ANTIC F -> Antic E' on same scanline is pretty interesting since you can essentially do the entire screen in ANTIC E' and GTIA fill-ins where needed. I was recently experimenting with GPRIOR mode 0 in ANTIC E' -- get more color combinations than normal ANTIC E.

Sorry, yes I misunderstood your original post there. I find the mode switching interesting too, it's here that I've found difficulties with the emulation timing however, I was working on an idea a few months back for a intro screen using mode switching and was banging my head against the wall for a while when it wasn't producing what I was expecting, I automatically assumed it was my mistake but fortunately I had the two emulators and my real xe to compare results. I must get back to that soon.

Have you produced anything to demo your results with GPRIOR 0 so far?

Edited August 1, 2009 by Tezz

[atariksi]

I was speaking of static imagery and for that you get more colors if you re-use colors than get that extra color from char mode at cost of 40 DMA cycles. That mode where you go from ANTIC F -> Antic E' on same scanline is pretty interesting since you can essentially do the entire screen in ANTIC E' and GTIA fill-ins where needed. I was recently experimenting with GPRIOR mode 0 in ANTIC E' -- get more color combinations than normal ANTIC E.

Sorry, yes I misunderstood your original post there. I find the mode switching interesting too, it's here that I've found difficulties with the emulation timing however, I was working on an idea a few months back for a intro screen using mode switching and was banging my head against the wall for a while when it wasn't producing what I was expecting, I automatically assumed it was my mistake but fortunately I had the two emulators and my real xe to compare results. I must get back to that soon.

Have you produced anything to demo your results with GPRIOR 0 so far?

 

I thought emulators were just buffering up the image so they don't have to do any timing.

 

You mean gprior 0 in mode E'?

[atarian63]

Hey, the tread is long and deep but is dying again!

[PeteD]

 

http://www.grapheine.com/bombaytv/movie-uk...0234602928.html

[+Stephen]

 

http://www.grapheine.com/bombaytv/movie-uk...0234602928.html

Commodore FTW

 

Stephen Anderson

[dwhyte]

 

http://www.grapheine.com/bombaytv/movie-uk...0234602928.html

 

lol... that's hilarious!!!

[Godzilla]

yea, i have to say, in that fight, c= won...

[oky2000]

Does anyone have a link to the old Atari computer adverts, you know the one where the guy strips the stripes from the Commodore (as in military commodore personal not the machine/company) and does equally funny quips at apple and IBM I believe?

 

I can only see the non-UK adverts on youtube which are alien to me!