Overview Features Coding ApolloOS Performance Forum Downloads Products Order Contact

Welcome to the Apollo Forum

This forum is for people interested in the APOLLO CPU.
Please read the forum usage manual.
Please visit our Apollo-Discord Server for support.



All TopicsNewsPerformanceGamesDemosApolloVampireAROSWorkbenchATARIReleases
Running Games and Apps.

PocketSnespage  1 2 3 

Nixus Minimax

Posts 416
07 Nov 2018 08:16


Interesting. But I believe with the RGBG-pattern you will halve your colour resolution and thus would have to use a hires mode to achieve the looks of a hicolored lowres mode.

BTW, I wonder whether the RGBG-pattern could be used with some shifting-dithering effect to mask the colour bleeding:

odd frames:
shift odd lines 1 pixel right
shift even lines 1 pixel left

even frames:
shift odd lines 1 pixel left
shift even lines 1 pixel right



Xan X-vision
(Needs Verification)
Posts 35/ 1
07 Nov 2018 10:31


Renee Cousins wrote:

 
Vojin Vidanovic wrote:
 
    If you would go in depth, NeoGeo has more then just 10Mhz m68k.Also, its chipset is defenetely superior to Amiga. Comparing similar titles or just plain look at NeoGeo titles shows it.
 

  NEOGEO has two CPU's, a 10MHz 68000 and a 4MHz Z80. The Z80 really adds no additional compute power since it's so slow, but it does allow sound to be precisely timed regardless of what the 68K is doing. These are both very modest processors, even against the 68EC020.
 

 
  Not that slow (here it is rendering a special cpu consuming screen mode besides effects
 

  EXTERNAL LINK   
Renee Cousins wrote:

  The NEOGEO was more specialized at handling sprites, making writing games a bit easier. Amiga's sprite engine was rather lacking and better suited as a fast-scrolling background layer than as player sprites, but I digress. The AGA hardware could absolutely produce higher resolutions with higher colours than the NEOGEO.
 
 
Vojin Vidanovic wrote:
 
    HAM6 and HAM8 were never used so much - because they cannot be used for fast anim and action, just for background pictures and pic displays.
 

  This is a huge misconception. Making a HAM6 scroller would not have been any harder than a 256-colour one and would have looked mind-blowing-ly superior. The problem was the palette-selector red herring. If you omit that and use a simple RGBG pattern, you make HAM every bit as easy to manage as any other screen mode.
 
  You don't even have to use C2P at this point. Your BOBs are pre-C2P'd in memory and you just blit like normal. And if the blitter is "too slow", then the 14MHz 68EC020 can easily make up the difference and still have more CPU power left over than the NEOGEO has.
 
  Just because no one did at the time doesn't mean that it couldn't have.
 

 
  My head just exploded: Are you telling me, 30 years before, that we could have used HAM and also saving c2p time, and almost nobody did it, just because they didn't know how to???
 


John William

Posts 563
07 Nov 2018 16:18


xan x-vision wrote:

Renee Cousins wrote:

 
Vojin Vidanovic wrote:
 
      If you would go in depth, NeoGeo has more then just 10Mhz m68k.Also, its chipset is defenetely superior to Amiga. Comparing similar titles or just plain look at NeoGeo titles shows it.
   

    NEOGEO has two CPU's, a 10MHz 68000 and a 4MHz Z80. The Z80 really adds no additional compute power since it's so slow, but it does allow sound to be precisely timed regardless of what the 68K is doing. These are both very modest processors, even against the 68EC020.
 

 
  Not that slow (here it is rendering a special cpu consuming screen mode besides effects
 
 
  EXTERNAL LINK   
 
Renee Cousins wrote:

    The NEOGEO was more specialized at handling sprites, making writing games a bit easier. Amiga's sprite engine was rather lacking and better suited as a fast-scrolling background layer than as player sprites, but I digress. The AGA hardware could absolutely produce higher resolutions with higher colours than the NEOGEO.
   
   
Vojin Vidanovic wrote:
 
      HAM6 and HAM8 were never used so much - because they cannot be used for fast anim and action, just for background pictures and pic displays.
   

    This is a huge misconception. Making a HAM6 scroller would not have been any harder than a 256-colour one and would have looked mind-blowing-ly superior. The problem was the palette-selector red herring. If you omit that and use a simple RGBG pattern, you make HAM every bit as easy to manage as any other screen mode.
   
    You don't even have to use C2P at this point. Your BOBs are pre-C2P'd in memory and you just blit like normal. And if the blitter is "too slow", then the 14MHz 68EC020 can easily make up the difference and still have more CPU power left over than the NEOGEO has.
   
    Just because no one did at the time doesn't mean that it couldn't have.
 

 
  My head just exploded: Are you telling me, 30 years before, that we could have used HAM and also saving c2p time, and almost nobody did it, just because they didn't know how to???
 

Only way to find out is now to write a game that uses HAM and see if what Vojin said is true or not.


Renee Cousins
(Apollo Team Member)
Posts 142
07 Nov 2018 17:53


Nixus Minimax wrote:

Interesting. But I believe with the RGBG-pattern you will halve your colour resolution and thus would have to use a hires mode to achieve the looks of a hicolored lowres mode.

Yes, to get NEOGEO 320, I need 640 HAM.
Nixus Minimax wrote:

  BTW, I wonder whether the RGBG-pattern could be used with some shifting-dithering effect to mask the colour bleeding:
 
  odd frames:
  shift odd lines 1 pixel right
  shift even lines 1 pixel left
 
  even frames:
  shift odd lines 1 pixel left
  shift even lines 1 pixel right

There's not a ton of fringe, but if you wanted to reduce it, doing a temporal blend that reverses the sample order would be better. Something like:

Odd frames:
0:RGBGRGBG...
1:BGRGBGRG...
2:RGBGRGBG...
...

Even frames:
0:GBGRGBGR...
1:GRGBGRGB...
2:GBGRGBGR...
...

This would not necessarily add any extra work either, since you can just swap the 5/6 plane pointers to the different mask pattern and use a different C2P routine when rasterizing.




Renee Cousins
(Apollo Team Member)
Posts 142
07 Nov 2018 17:58


xan x-vision wrote:

Not that slow (here it is rendering a special cpu consuming screen mode besides effects
EXTERNAL LINK 

Not really that fast either...

NEOGEO: 2.33 MIPS (Z80@0.580MIPS and 68000@1.750MIPS)
A1200: 4.34 MIPS (at 14.32 MHz)
V2: 100+ MIPS
 
xan x-vision wrote:
 
  My head just exploded: Are you telling me, 30 years before, that we could have used HAM and also saving c2p time, and almost nobody did it, just because they didn't know how to???

Yes, exactly.



Renee Cousins
(Apollo Team Member)
Posts 142
07 Nov 2018 18:22


John William wrote:

  Only way to find out is now to write a game that uses HAM and see if what Vojin said is true or not.

We can make a quick and dirty proof that would provide 12-bits per pixel at an effective resolution of 160H in lores on ECS hardware (AGA would need a bit more work).

In AMOS, open a 320x200 screen and create a custom copper list for it writing $7A00 into BPLCON0 (7-bitplane mode, HAM enabled) and then use the COPPER to write BPL5DAT and BPL6DAT with the RGBG patterns described above before each scan line.

Then we just need to pre-generate some 16-colour BOBs and start blitting away. Note that there's no reason this shouldn't work with scrolling and tilemaps, etc.

This is the C# code I used for testing the effect on bitmaps -- it could easily be changed to a bitmap converter.

EXTERNAL LINK 
Note that one big improvement to avoid the left-edge fringe is to have a palette of 16 grays and make the first pixel on each line (and the first pixel ONLY) use the palette instead of any of the three RGB components.

Also, while the screen loses half it's horizontal resolution, sprites are, of course, not affected. These could be used for a parallax foreground layer, player ships, bullets, etc. However, at lores, the blitter can keep up with redrawing the whole screen every frame, so you can still have animated tiles and full colour objects that way as well.

Hires 60fps is PROBABLY beyond the ability of the blitter to keep up with for redrawing the whole screen, but you never do that with a scrolling tile map. Slowing in-tile animations to say 20 fps would also solve this. If you still want full colour player BOBs, then you simply redraw the overlapped tiles every frame and leave the rest alone.


Samuel Crow

Posts 424
07 Nov 2018 19:42


Renee Cousins wrote:

  NEOGEO: 2.33 MIPS (Z80@0.580MIPS and 68000@1.750MIPS)
  A1200: 4.34 MIPS (at 14.32 MHz)
  V2: 100+ MIPS

Re: 68ec020 14 MHz
Having only chip RAM negates the speed advantage of an A1200 with a bandwidth bottleneck.


Vojin Vidanovic
(Needs Verification)
Posts 1916/ 1
07 Nov 2018 20:17


Renee Cousins wrote:

          Hires 60fps is PROBABLY beyond the ability of the blitter to keep up with for redrawing the whole screen, but you never do that with a scrolling tile map. Slowing in-tile animations to say 20 fps would also solve this. If you still want full colour player BOBs, then you simply redraw the overlapped tiles every frame and leave the rest alone.

         
          That is exactly where NeoGeo would shine, plus add 16-bit sound and way more hacky 12-bit pallete already.
         
          Things you laugh are "done right".Z80 even has sound RAM, ROM is 512KB etc,  Sprites would be handled but way powerful hardware making a huge jump from m68k, way better then EC020,chip RAM and AGA.
       
        Maybe you are right, we could use HAM6 and HAM8 way more - but that simply wasnt so, I believe mainly to basic model shortcomings. I suppose you are "called" to do a HAM8 game, super hi-res (non-interlaced please) on a Vamp.
       
          Pure look at NeoGame games, of similar era as Amiga 500 to Amiga 1200
        EXTERNAL LINK         
            But as explained, Vamp brings new era in all aspects and respects :-)
     
      CPU being faster in c2p was I believe "since 030 and fast RAM"  EXTERNAL LINK last updated 1999
          Even combination of CPU and Blitter was avail for c2p but for 020+FAST minimum EXTERNAL LINK     
    Amiga ECS/AGA Blitter was easily surpassed, so FBlit was a long software replacement :-)
    EXTERNAL LINK      and first ideas go back to 1991
    EXTERNAL LINK     
    So all in one, before Vamp or RTG/AHI we couldnt really say we have a great sound (Paula was all the same), Blitter was easily surpassed, ChipRAM was more a limit then real VRAM and c2p was additional killer for non expanded or non boxed Amiga models. Even the OS was not so customizable and modern before MUI. So in my eyes, community did all the "dirty work" - from adding menu adder function, to dockies and start, increasing speed in all aspects and creating new layers to support better gfx/sound and even GUI.
   
    That is why I am not so attached to basic AmigaOS installs. They all need a lot of love and work :)
     
    Harsh reality. There were better solutions, but we had a community by then :-) A1000 and A3000 were revolutions,rest is try to cash on. A3000+ in 1991 would be too, but it was scrapped to low cost ... Amiga 4000.

EXTERNAL LINK 
Case  Altered A3000 desktop unit (minor modification to Zorro slots and PSU)
CPU  On-board 25MHz 68030 (w/ MMU) and '882, the particular machine shown in the photographs is used with a commodore A3640
ROM  AmigaOS 3.0 (double ROM, as found in the A4000)
RAM  2MB Chip, 8Mb Fast (A3000-style ZIP RAM)
Chipset  AA/AGA
Sound  onboard DSP socket, intended for AT&T DSP3210
Buster  Rev. 11
Zorro Slots  4 Zorro III, 2 in-line ISA, 1 Video slot
SCSI  A3000 style SCSI Controller (same Western Digital rev. 8 chip as in the A3000)
Drives  1.76MB Floppy drive
Others  Hardware clock


Nixus Minimax

Posts 416
08 Nov 2018 08:10


Renee Cousins wrote:
  Yes, to get NEOGEO 320, I need 640 HAM.

OK, but this means that screen DMA will slow down chipmem even more than it is already.

There's not a ton of fringe, but if you wanted to reduce it, doing a temporal blend that reverses the sample order would be better. Something like:
 
  Odd frames:
  0:RGBGRGBG...
  1:BGRGBGRG...
  2:RGBGRGBG...
  ...
 
  Even frames:
  0:GBGRGBGR...
  1:GRGBGRGB...
  2:GBGRGBGR...
  ...
 
  This would not necessarily add any extra work either, since you can just swap the 5/6 plane pointers to the different mask pattern and use a different C2P routine when rasterizing.

Yes, I also thought about this later yesterday. You already have all the BOBs in "colour rotated" variants so you would just have to choose the right variant for each frame.

The modification to the c2p routine would be really simple, just changing the first pass (byte-shifting) would be sufficient.
 
BTW, I believe this isn't entirely new, I think the popular hicolor mode used in many Amiga demos uses a similar approach but instead of using hires to get more or less the look of a lores screen it masks out the bleeding pixels using sprites. I always hated the look of this mode due to the black masking pixels.



Michael Borrmann

Posts 140
08 Nov 2018 11:17


Renee Cousins wrote:

    Okay, to avoid the bleed you use a simple stipple pattern of RGBGRGBG across the screen.
   

   
I think I get it now after some scribbling stuff on paper..: :D

The trick is, instead of freely deciding from pixel to pixel whether you hold and modify R,G,or B to mutate from color $000 to $fff (for instance) you do this in a fixed sequence, so you have the possibility to blit BOBs into there without color bleeding since the way the colours are modified is "controlled".
 
I think I don't get yet why:
  * ...horizontal resolution is halved by this.
  * ...why do you need the additional (fourth pixel) green modify step, when any colour only needs three steps/pixels to fully go from one color to another anyway.

 
Thanks,
super interesting topic for me...


Renee Cousins
(Apollo Team Member)
Posts 142
10 Nov 2018 22:13


Michael Borrmann wrote:

  I think I don't get yet why:
    * ...horizontal resolution is halved by this.
    * ...why do you need the additional (fourth pixel) green modify step, when any colour only needs three steps/pixels to fully go from one color to another anyway.
 
  Thanks,
  super interesting topic for me...

Okay, let's take my pattern -- RGBGRGBG and unpack it into three layers:

R---R---R---R---....
-G-G-G-G-G-G....
--B---B---B---B....

Each layer is 4-bits. Our red and blue layers are only getting updated every fourth pixel, so they're 1/4 the horizontal resolution. If you're running a 640H screen, this means that red and blue are effectively only 160H. We help this by alternating the red and blue on each scan line. Ideally we'd want to average two red or two blue source pixels -- and with pre-C2P this is okay. But doing live C2P, we skip every other red and blue pixel for speed.

However, the green is updated every other pixel, so it's only halving the resolution, so if your screen mode is 640H then the green layer is effectively 320H. Because the eye is much more sensitive to green, this is the more important colour component to update more frequently. We don't shift this and keep it a simple 1-to-1 from our original low-res image.

Also, multiples of four makes everything a lot easier because &3 is faster than %3. A lot.



Renee Cousins
(Apollo Team Member)
Posts 142
10 Nov 2018 22:18


Nixus Minimax wrote:

  BTW, I believe this isn't entirely new, I think the popular hicolor mode used in many Amiga demos uses a similar approach but instead of using hires to get more or less the look of a lores screen it masks out the bleeding pixels using sprites. I always hated the look of this mode due to the black masking pixels.

Unique uses this for some of their demos. I'm not sure anyone else has and this has only been done for C2P effects not for pre-C2P-ed BOBs.



Renee Cousins
(Apollo Team Member)
Posts 142
10 Nov 2018 23:46


Samuel Crow wrote:

  Re: 68ec020 14 MHz
  Having only chip RAM negates the speed advantage of an A1200 with a bandwidth bottleneck.

Chip RAM is a bit of a bottleneck, yes -- but much less so on AGA than ECS, especially if you keep the total number of bit planes to a minimum Technically, HAM only ever needed four bit planes, and that's what Commodore didn't get. On ECS, we can enable four bit plane HAM and save 33% of our DMA. On AGA, HAM6 only uses a fraction of our DMA even though we have a couple of completely pointless bit planes.

CPU speed doesn't really matter here -- the only probably problem would be how MUCH chip memory you have since having four of every object on top of animation would eat a lot of memory. An unexpanded Amiga 1000 could do a game in HAM.


Renee Cousins
(Apollo Team Member)
Posts 142
11 Nov 2018 01:44


Wow, a lot to unpack here...
Vojin Vidanovic wrote:
That is exactly where NeoGeo would shine, plus add 16-bit sound and way more hacky 12-bit pallete already.

Well, 16-bit is a BIT of a lie. The source data is 4-bit ADPCM, so there's compression noise and generally I heard next to no difference playing a single channel of NEO GEO at 8-bit than at 14-bit on the Amiga. Where bit depth helps is mixing which would have been avoidable with more channels, but chest la vie. Anyway, software mixers are like 5-6 operations per sample these days? Even a stock 68000 can soft-mix several channels.
         
Vojin Vidanovic wrote:
Things you laugh are "done right".Z80 even has sound RAM, ROM is 512KB etc,  Sprites would be handled but way powerful hardware making a huge jump from m68k, way better then EC020,chip RAM and AGA.

I disagree completely. Sprites are powerful 2D elements useful for some scrollers and beat-em-ups but useless for anything else. The NEOGEO is crippled and the types of games it can do are limited. Can the Amiga 1200 blit 381 16x16 sprites? I would bet with clever programming, the Amiga 1200 could do nearly every NEOGEO game there is.
         
Vojin Vidanovic wrote:
Maybe you are right, we could use HAM6 and HAM8 way more - but that simply wasnt so, I believe mainly to basic model shortcomings. I suppose you are "called" to do a HAM8 game, super hi-res (non-interlaced please) on a Vamp.

No, I'd only do hires, there's no need for super hires or interlaced.

Vojin Vidanovic wrote:
Pure look at NeoGame games, of similar era as Amiga 500 to Amiga 1200 https://www.youtube.com/watch?v=IiowJ6qPSq0

I'm aware at the time that games did not measure up. There are a lot of factors at play here. The Amiga was often given quick ports from the Atari where all they'd do is use sprites and/or the COPPER to add a few extra colours. The Amiga hardware was complex and difficult to use fully and many of these tricks didn't come about until years later.
         
Vojin Vidanovic wrote:
But as explained, Vamp brings new era in all aspects and respects :-) CPU being faster in c2p was I believe "since 030 and fast RAM"  EXTERNAL LINK last updated 1999. Even combination of CPU and Blitter was avail for c2p but for 020+FAST minimum http://aminet.net/package/dev/src/c2p4

C2P isn't at play here. You **CAN** use C2P, but HAM C2P needs an 060 to play well.
     
Vojin Vidanovic wrote:
Amiga ECS/AGA Blitter was easily surpassed, so FBlit was a long software replacement :-)

Even on an 060, the blitter is still of use. FBlit sort of presumes you have nothing better to do with the CPU in the meantime.

Vojin Vidanovic wrote:
So all in one, before Vamp or RTG/AHI we couldnt really say we have a great sound (Paula was all the same), Blitter was easily surpassed, ChipRAM was more a limit then real VRAM and c2p was additional killer for non expanded or non boxed Amiga models.

Not interested in the PC-fication of the Amiga.

Vojin Vidanovic wrote:
Even the OS was not so customizable and modern before MUI. So in my eyes, community did all the "dirty work" - from adding menu adder function, to dockies and start, increasing speed in all aspects and creating new layers to support better gfx/sound and even GUI.

That's insane. A little skinning and a totally "meh" GUI don't compare to the work making the OS itself.

Vojin Vidanovic wrote:
That is why I am not so attached to basic AmigaOS installs. They all need a lot of love and work :)

Sometimes there is beauty in simplicity. Backing up a dump truck of bloat doesn't make it better. It makes it worse.
     
Vojin Vidanovic wrote:
Harsh reality. There were better solutions, but we had a community by then :-) A1000 and A3000 were revolutions,rest is try to cash on. A3000+ in 1991 would be too, but it was scrapped to low cost ... Amiga 4000.
 
  EXTERNAL LINK 
  Case  Altered A3000 desktop unit (minor modification to Zorro slots and PSU)
  CPU  On-board 25MHz 68030 (w/ MMU) and '882, the particular machine shown in the photographs is used with a commodore A3640
  ROM  AmigaOS 3.0 (double ROM, as found in the A4000)
  RAM  2MB Chip, 8Mb Fast (A3000-style ZIP RAM)
  Chipset  AA/AGA
  Sound  onboard DSP socket, intended for AT&T DSP3210
  Buster  Rev. 11
  Zorro Slots  4 Zorro III, 2 in-line ISA, 1 Video slot
  SCSI  A3000 style SCSI Controller (same Western Digital rev. 8 chip as in the A3000)
  Drives  1.76MB Floppy drive
  Others  Hardware clock

Could have been so beautiful, could have been so right ... I think of all that could have been, on those long, lonely nights.


Renee Cousins
(Apollo Team Member)
Posts 142
11 Nov 2018 02:28


What was right for Commodore at the time was Hombre, not AAA. What's right for Amiga now, is neither -- with the raw power of NVIDIA GPU's, it absolutely pointless to compete in either 2D or 3D. What's better is to make the best Amiga as it was. Not as it could have been. Not as some sycophant thinks it ought to be. And not even as it might have been had we seen  AAA or Hombre reach the light of day. It needs to just be, an Amiga.


Mr Niding

Posts 459
11 Nov 2018 12:50


Renee Cousins wrote:

What was right for Commodore at the time was Hombre, not AAA. What's right for Amiga now, is neither -- with the raw power of NVIDIA GPU's, it absolutely pointless to compete in either 2D or 3D. What's better is to make the best Amiga as it was. Not as it could have been. Not as some sycophant thinks it ought to be. And not even as it might have been had we seen  AAA or Hombre reach the light of day. It needs to just be, an Amiga.

As a non-coder, Im going to be careful getting into a discussion on these topics.

But Looking at for example Windows on my PC, WIN10 put the performance to a crawl, even tho I had a quite decent setup. I just upgraded to a monster, and now Win10 is working quite nicely.

The old hardware is now running Windows XP, since I have some legacy programs I want to run, which WIN10 refuses to run. And WIN XP has no lag.

Points is, I agree with Renee that we shouldnt look blindly at hardware specs, but rather think about what can be done with the design we got. Loading it up with bloat will cripple even the best hardware, so smarter utilization of a given hardware standard seems to be the best way to go instead of throwing cycles and Mhz at the problem.


Michael Borrmann

Posts 140
11 Nov 2018 17:12


Renee Cousins wrote:

  Okay, let's take my pattern -- RGBGRGBG and unpack it into three layers:
 


  R---R---R---R---....
  -G-G-G-G-G-G....
  --B---B---B---B....
 

 
  Each layer is 4-bits. Our red and blue layers are only getting updated every fourth pixel, so they're 1/4 the horizontal resolution. If you're running a 640H screen, this means that red and blue are effectively only 160H. We help this by alternating the red and blue on each scan line. Ideally we'd want to average two red or two blue source pixels -- and with pre-C2P this is okay. But doing live C2P, we skip every other red and blue pixel for speed.
 
  However, the green is updated every other pixel, so it's only halving the resolution, so if your screen mode is 640H then the green layer is effectively 320H. Because the eye is much more sensitive to green, this is the more important colour component to update more frequently. We don't shift this and keep it a simple 1-to-1 from our original low-res image.
 
  Also, multiples of four makes everything a lot easier because &3 is faster than %3. A lot.
 

I'd really love to see how a game would look like using this mode, especially a tile scrolling one.

I imagine a lot of color artefacts happening while the graphics scroll over the RGBG matrix.

I am really not convinced yet, that this is feasible. :/



Renee Cousins
(Apollo Team Member)
Posts 142
12 Nov 2018 04:41


Michael Borrmann wrote:

  I'd really love to see how a game would look like using this mode, especially a tile scrolling one.
 
  I imagine a lot of color artefacts happening while the graphics scroll over the RGBG matrix.
 
  I am really not convinced yet, that this is feasible. :/

Challenge accepted. Remember, these consoles existed in a time where PAL and NTSC televisions were still the norm. Horizontally, both suffered from a lot of colour distortion and blurring. The effect the HAM mode gives is not that dissimilar to a fake CRT effect and is producing colour, still, at a higher resolution than NTSC could.

What this really means is that often graphics are designed to not be displayed sharply. Often that softness was leveraged in dithering techniques that do not work well on modern LCD monitors (especially when upscaled several times). You're welcome to take a glance at the imgur link, but hopefully I can get this working in GNGEO soon enough and we can see it in motion.


Michael Borrmann

Posts 140
12 Nov 2018 07:55


Renee Cousins wrote:

    Challenge accepted. Remember, these consoles existed in a time where PAL and NTSC televisions were still the norm. Horizontally, both suffered from a lot of colour distortion and blurring. The effect the HAM mode gives is not that dissimilar to a fake CRT effect and is producing colour, still, at a higher resolution than NTSC could.
   
    What this really means is that often graphics are designed to not be displayed sharply. Often that softness was leveraged in dithering techniques that do not work well on modern LCD monitors (especially when upscaled several times). You're welcome to take a glance at the imgur link, but hopefully I can get this working in GNGEO soon enough and we can see it in motion.
 

  The problem I especially see here is, that while you avoid that effect for BOBs by using four different RGBG rotations on your BOBs, the scrolling tiles won't.
 
  If you don't want to scroll by 4 pixels, which would look very jerky, you would need four different versions of each tile as well, and blit these each and every frame into the screen buffer.
 
  Which is not an option on a system below a 68040 config, I guess.
 
  This mode could work and look interesting on non scrolling games, though.


Nixus Minimax

Posts 416
12 Nov 2018 09:02


Renee Cousins wrote:
Chip RAM is a bit of a bottleneck, yes -- but much less so on AGA than ECS, especially if you keep the total number of bit planes to a minimum Technically, HAM only ever needed four bit planes, and that's what Commodore didn't get. On ECS, we can enable four bit plane HAM and save 33% of our DMA. On AGA, HAM6 only uses a fraction of our DMA even though we have a couple of completely pointless bit planes.

I would have thought that you'd also have to DMA the two control bitplanes and thus use 6 and 8 bitplanes, respectively, for HAM6 and HAM8. Is there a dirty little trick like disabling DMA and writing a fixed value to the DMA registers for the control bitplanes?


posts 46page  1 2 3