Daimakaimura (Ghouls 'n Ghosts) for the Atari STE

All about games on the Falcon, TT & clones

Moderators: Mug UK, moondog/.tSCc., [ProToS], lp, Moderator Team

User avatar
Anima
Atari Super Hero
Atari Super Hero
Posts: 599
Joined: Fri Mar 06, 2009 9:43 am
Contact:

Re: Daimakaimura (Ghouls 'n Ghosts) for the Atari STE

Postby Anima » Sat May 20, 2017 8:26 am

dml wrote:That's an impressive universal palette (DawnBringer). I notice it doesn't match STE rgb bitdepth as the values use all 8 bits of R,G,B where the STE has only 4 bits. Did you have to edit the values further or did you just let it quantise down to 4? I guess quantising would be enough since its already very well distributed.

You're right. However, the colours are scaled to the 8 bit range by multiplying the Atari RGB colour values by 0x11:

Code: Select all

magick atari_ste_palette.png -define histogram:unique-colors=true -format %c histogram:info:-
     78473: ( 17, 17, 34) #111122 srgb(17,17,34)
      5468: ( 51, 51,102) #333366 srgb(51,51,102)
      3750: ( 51,102, 34) #336622 srgb(51,102,34)
      8593: ( 68, 34, 51) #442233 srgb(68,34,51)
      5316: ( 85, 68, 85) #554455 srgb(85,68,85)
      4780: ( 85,119,204) #5577CC srgb(85,119,204)
      2974: (102,170, 51) #66AA33 srgb(102,170,51)
      6408: (102,187,204) #66BBCC srgb(102,187,204)
     18318: (119,119,102) #777766 srgb(119,119,102)
      2830: (136, 68, 51) #884433 srgb(136,68,51)
      5501: (136,153,153) #889999 srgb(136,153,153)
      2136: (204, 68, 68) #CC4444 srgb(204,68,68)
      2350: (204,119, 51) #CC7733 srgb(204,119,51)
      7080: (204,170,153) #CCAA99 srgb(204,170,153)
      3486: (221,204,102) #DDCC66 srgb(221,204,102)
     11129: (221,238,221) #DDEEDD srgb(221,238,221)


dml wrote:And have you considered interlacing this palette to get it up to 5 effective bits? If you alternate every 2nd palette index (high/low on alternate fields) it should keep the flicker minimal, unless one colour dominates at any time - but that's about the best you can do without requiring more gfx of course.

A good idea. I'll have to check that.

dml wrote:I have recently coded a new palette generator algorithm/tool which improves on previous attempts but as usual it depends on availability of input graphics (like lots of screengrabs and sprite sheets). While it does produce very optimal superpalettes, I'm not sure how results would compare with a 'psychologically optimal' palette like this one. At least, if *this* palette hadn't worked out so well I would soon have been suggesting to try it :D But this does look good...

That sounds really interesting so I would like to give it a try. The search for the optimial palette is never over.

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3429
Joined: Sat Jun 30, 2012 9:33 am

Re: Daimakaimura (Ghouls 'n Ghosts) for the Atari STE

Postby dml » Sat May 20, 2017 9:04 am

Ok cool I can get it in shape to have a try (it needs some adjustment settings exposed). I'll need some representative gfx (originals, preferably un-gamma'd) as source material to get settings sensible - but will keep results off this thread since its a bit of a tangent to the main work going on here. I'll just PM you or something, and if its of any use here you can play with it yourself.

Still I think the current palette is more than good enough to just keep moving on with the game. Experimenting is just fun!

User avatar
dlfrsilver
Atari God
Atari God
Posts: 1282
Joined: Mon Jan 31, 2005 1:41 am
Contact:

Re: Daimakaimura (Ghouls 'n Ghosts) for the Atari STE

Postby dlfrsilver » Sat May 20, 2017 11:40 am

Anima wrote:
chlu600 wrote:It'll be hard anyway to create an optimal 16-color palete for only one level and it's sprites.

Yes indeed. I think I've found a good one. Actually it's the "DawnBringers 16 colours palette":
Image

Here are some remapped MAME screenshots using the palette:
ImageImage
ImageImage
ImageImage

dml wrote:Great progress - this looks amazing!

Thanks Doug! I hope that I can squeeze everything into the 4 MB of the STE.
:cheers:


Anima, i must say that this 16 colors palette is VERY good :) if you can keep it, it's going to be really good !! :D
Now SPS France representative since the 19th of June 2014. Proud to be an SPS member !

jury
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 138
Joined: Tue Sep 21, 2004 11:11 am
Location: Poland

Re: Daimakaimura (Ghouls 'n Ghosts) for the Atari STE

Postby jury » Sat May 20, 2017 4:13 pm

Anima wrote:Here are some remapped MAME screenshots using the palette:
ImageImage
ImageImage
ImageImage


Damn, it looks beautiful :) And if it will play 25 frames/s ( or more :) ) I'm definitely in! ( this palette rocks! )
Last edited by jury on Sat May 20, 2017 8:06 pm, edited 1 time in total.

User avatar
AtariCrypt
Captain Atari
Captain Atari
Posts: 340
Joined: Fri Mar 14, 2014 5:04 pm
Location: Lancashire, England
Contact:

Re: Daimakaimura (Ghouls 'n Ghosts) for the Atari STE

Postby AtariCrypt » Sat May 20, 2017 4:39 pm

I'd pay for this!!!

charliesgames
Retro freak
Retro freak
Posts: 13
Joined: Wed Mar 04, 2015 7:03 pm
Contact:

Re: Daimakaimura (Ghouls 'n Ghosts) for the Atari STE

Postby charliesgames » Sat May 20, 2017 4:43 pm

This is looking great. Been really enjoying this thread.

Cheers
Charlie
Take a look at my games: http://www.charliesgames.com

User avatar
Anima
Atari Super Hero
Atari Super Hero
Posts: 599
Joined: Fri Mar 06, 2009 9:43 am
Contact:

Re: Daimakaimura (Ghouls 'n Ghosts) for the Atari STE

Postby Anima » Sat Jun 03, 2017 10:39 am

Another short update: one of the two biggest issues has been solved. The sprite drawing code uses 16 bit addressing for a faster Blitter register setup each line. This, however, limits the screen area to 64 kB. Horizontal scrolling would be possible to a certain extent but vertical scrolling is not. I hope to get a short demo running to demonstrate this.

The other main issue is loading the graphics on demand. Not easy when the first MB is completely oberwritten by the arcade program ROM.

Stay tuned... :cheers:

User avatar
dlfrsilver
Atari God
Atari God
Posts: 1282
Joined: Mon Jan 31, 2005 1:41 am
Contact:

Re: Daimakaimura (Ghouls 'n Ghosts) for the Atari STE

Postby dlfrsilver » Sat Jun 03, 2017 1:10 pm

Great :) There is a problem with horizontal scrolling ? how can it be ? what is the technical bottleneck ?

Loading graphics on demand = splitting the assets per sprites, there's no other way, or you will go for a 4-6mb of ram unified game.....
Now SPS France representative since the 19th of June 2014. Proud to be an SPS member !

User avatar
Cyprian
Atari God
Atari God
Posts: 1331
Joined: Fri Oct 04, 2002 11:23 am
Location: Warsaw, Poland

Re: Daimakaimura (Ghouls 'n Ghosts) for the Atari STE

Postby Cyprian » Sat Jun 03, 2017 8:32 pm

instead "technical bottleneck" I would say it is "optimization side-effect"
instead of writing full 32bit destination address into the BLiTTER's destination (or source) register, he writes only lower 16bit, therefore he saves some CPU cycles per the BLiTTER initialization. A side-effect is that, a destination (or source) memory area is 'limited' to 16bit memory page.
Jaugar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
SDrive / PAK68/3 / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
Hatari / Aranym / Steem / Saint
http://260ste.appspot.com/

User avatar
dlfrsilver
Atari God
Atari God
Posts: 1282
Joined: Mon Jan 31, 2005 1:41 am
Contact:

Re: Daimakaimura (Ghouls 'n Ghosts) for the Atari STE

Postby dlfrsilver » Sat Jun 03, 2017 8:43 pm

Cyprian wrote:instead "technical bottleneck" I would say it is "optimization side-effect"
instead of writing full 32bit destination address into the BLiTTER's destination (or source) register, he writes only lower 16bit, therefore he saves some CPU cycles per the BLiTTER initialization. A side-effect is that, a destination (or source) memory area is 'limited' to 16bit memory page.


Ah ok..... this is indeed quite tricky to handle..... do you think there is or are possible ways to use not a lot more CPU cycle and at the same time get the full 32 bits thing ?
Now SPS France representative since the 19th of June 2014. Proud to be an SPS member !

User avatar
Anima
Atari Super Hero
Atari Super Hero
Posts: 599
Joined: Fri Mar 06, 2009 9:43 am
Contact:

Re: Daimakaimura (Ghouls 'n Ghosts) for the Atari STE

Postby Anima » Sun Jun 04, 2017 1:35 am

Cyprian wrote:instead "technical bottleneck" I would say it is "optimization side-effect"

Thanks for the perfect description.

dlfrsilver wrote:Ah ok..... this is indeed quite tricky to handle..... do you think there is or are possible ways to use not a lot more CPU cycle and at the same time get the full 32 bits thing ?

Actually you don't really need more than 64 kB. The problem here is that the Shifter always uses 24 bits for the display. This also gives a hint what we need to do to use only 16 bits: just keep the upper most video counter register constant.

User avatar
Anima
Atari Super Hero
Atari Super Hero
Posts: 599
Joined: Fri Mar 06, 2009 9:43 am
Contact:

Re: Daimakaimura (Ghouls 'n Ghosts) for the Atari STE

Postby Anima » Sun Jun 04, 2017 2:05 am

This image gives a good idea about the 64 kB "virtual" display memory and the displayed area.
Image

User avatar
Ragstaff
Atari Super Hero
Atari Super Hero
Posts: 586
Joined: Mon Oct 20, 2003 3:39 am
Location: Melbourne Australia
Contact:

Re: Daimakaimura (Ghouls 'n Ghosts) for the Atari STE

Postby Ragstaff » Sun Jun 04, 2017 7:05 am

So what % of speed do you gain in sending words to the blitter? I realise it's a very clever technique you have and not suggesting you abandon it, just curious

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2469
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: Daimakaimura (Ghouls 'n Ghosts) for the Atari STE

Postby AtariZoll » Sun Jun 04, 2017 7:12 am

Anima wrote:Another short update: one of the two biggest issues has been solved. The sprite drawing code uses 16 bit addressing for a faster Blitter register setup each line. This, however, limits the screen area to 64 kB. Horizontal scrolling would be possible to a certain extent but vertical scrolling is not. I hope to get a short demo running to demonstrate this.

The other main issue is loading the graphics on demand. Not easy when the first MB is completely oberwritten by the arcade program ROM.

Stay tuned... :cheers:


I don't get why sprite draw with 16-bit addressing should limit screen area to 64KB. You don't draw sprites of 2 screen size ? You set upper 8 bits of screen address properly before sprite draw, and that must be done only once, so really couldn't slow whole draw more than 1% , but rather less.
The real limit here is STE HW scroll.

You mean that TOS is killed by arcade program ROM content ? Well, not problem at all. I have all code needed for direct FDC loading from floppy, what can be placed anywhere in RAM, and it needs only couple hundreds bytes space. If graphic data is well packable it will speed up loading from floppy (depacker is fast), and more will fit on floppy. And of course, I have solutions for hard disk run when game uses low RAM, so TOS functions are not usable. But then it should work with 2 MB. Otherwise only direct hard disk access, no exit to TOS .
I'm not against GMO, I'm against that children play with fire.

User avatar
Cyprian
Atari God
Atari God
Posts: 1331
Joined: Fri Oct 04, 2002 11:23 am
Location: Warsaw, Poland

Re: Daimakaimura (Ghouls 'n Ghosts) for the Atari STE

Postby Cyprian » Sun Jun 04, 2017 9:09 am

Anima wrote:Another short update: one of the two biggest issues has been solved. The sprite drawing code uses 16 bit addressing for a faster Blitter register setup each line. This, however, limits the screen area to 64 kB. Horizontal scrolling would be possible to a certain extent but vertical scrolling is not. I hope to get a short demo running to demonstrate this.


what about using two 64kb the screen areas, one of them shifted vertically?
picked when needed in VBL, by changing the BLiTTER's upper 16bit destination address and SHIFTER's a high address register
Jaugar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
SDrive / PAK68/3 / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
Hatari / Aranym / Steem / Saint
http://260ste.appspot.com/

User avatar
Anima
Atari Super Hero
Atari Super Hero
Posts: 599
Joined: Fri Mar 06, 2009 9:43 am
Contact:

Re: Daimakaimura (Ghouls 'n Ghosts) for the Atari STE

Postby Anima » Mon Jun 05, 2017 8:13 am

Ragstaff wrote:So what % of speed do you gain in sending words to the blitter? I realise it's a very clever technique you have and not suggesting you abandon it, just curious

Some calculations: :coffe:

"Best case" Blitter setup with 16 bit addressing cycles:

Code: Select all

    add     #256-8,(a4) ; (4 + 4) + 4 + 4 (F + Rw + Ww).
    move    d5,(a3)     ; 4 + 4 (F + Ww).
    move    d6,(a2)     ; 4 + 4 (F + Ww).

    [Blitter cycles: 4 * (4 + 4 + 8)]

"Best case" Blitter setup with 32 bit addressing cycles:

Code: Select all

    add.l   #256-8,(a4) ; (4 + 8) + 8 + 8 (F + Rl + Wl).
    move    d5,(a3)     ; 4 + 4 (F + Ww).
    move    d6,(a2)     ; 4 + 4 (F + Ww).

    [Blitter cycles: 4 * (4 + 4 + 8)]

This gives 96 vs 108 cycles which results in a 12.5 % speed loss for the lowest number of cycles the Blitter will spend. The number will be lower in regular cases but I think that about 5-10% can be saved by using the 16 bit addressing.

User avatar
Anima
Atari Super Hero
Atari Super Hero
Posts: 599
Joined: Fri Mar 06, 2009 9:43 am
Contact:

Re: Daimakaimura (Ghouls 'n Ghosts) for the Atari STE

Postby Anima » Mon Jun 05, 2017 8:38 am

AtariZoll wrote:The real limit here is STE HW scroll.

Agreed. That was exactly the main problem. I still have to try the "solution" on a real machine but I think it'll work.

AtariZoll wrote:I have all code needed for direct FDC loading from floppy, what can be placed anywhere in RAM, and it needs only couple hundreds bytes space. If graphic data is well packable it will speed up loading from floppy (depacker is fast), and more will fit on floppy. And of course, I have solutions for hard disk run when game uses low RAM, so TOS functions are not usable. But then it should work with 2 MB. Otherwise only direct hard disk access, no exit to TOS .

Due to the size of game assets I think the only good way is using an HD for the game installation and I am targeting a 4 MB Atari STE system. As far as I understand you have a solution for this?

User avatar
Anima
Atari Super Hero
Atari Super Hero
Posts: 599
Joined: Fri Mar 06, 2009 9:43 am
Contact:

Re: Daimakaimura (Ghouls 'n Ghosts) for the Atari STE

Postby Anima » Mon Jun 05, 2017 8:45 am

Cyprian wrote:what about using two 64kb the screen areas, one of them shifted vertically?
picked when needed in VBL, by changing the BLiTTER's upper 16bit destination address and SHIFTER's a high address register

Interesting idea. However, as far as I understand I need to have another one for the work screen buffer as well and that adds a total of 128 kB, right?

I hope that the current solution so far will work because it has some nice advantages especially in respect to the performance of the scrolling display buffer updates.

User avatar
Ragstaff
Atari Super Hero
Atari Super Hero
Posts: 586
Joined: Mon Oct 20, 2003 3:39 am
Location: Melbourne Australia
Contact:

Re: Daimakaimura (Ghouls 'n Ghosts) for the Atari STE

Postby Ragstaff » Mon Jun 05, 2017 12:14 pm

Anima wrote:
Ragstaff wrote:So what % of speed do you gain in sending words to the blitter? I realise it's a very clever technique you have and not suggesting you abandon it, just curious

Some calculations: :coffe:

"Best case" Blitter setup with 16 bit addressing cycles:

Code: Select all

    add     #256-8,(a4) ; (4 + 4) + 4 + 4 (F + Rw + Ww).
    move    d5,(a3)     ; 4 + 4 (F + Ww).
    move    d6,(a2)     ; 4 + 4 (F + Ww).

    [Blitter cycles: 4 * (4 + 4 + 8)]

"Best case" Blitter setup with 32 bit addressing cycles:

Code: Select all

    add.l   #256-8,(a4) ; (4 + 8) + 8 + 8 (F + Rl + Wl).
    move    d5,(a3)     ; 4 + 4 (F + Ww).
    move    d6,(a2)     ; 4 + 4 (F + Ww).

    [Blitter cycles: 4 * (4 + 4 + 8)]

This gives 96 vs 108 cycles which results in a 12.5 % speed loss for the lowest number of cycles the Blitter will spend. The number will be lower in regular cases but I think that about 5-10% can be saved by using the 16 bit addressing.

Thanks for the explanation.
So if the blitter does the minimum amount of work you get a 12.5% gain, but if it does a big blit (sorry if that's wrong terminology) it is of less benefit. You estimate 5 - 10% faster is typical use case. So if you have to spend too many cycles making it all work in a 64kb buffer I guess it could reach a point where the gains aren't worth it (at least, for this game)

User avatar
Frank B
Atari Super Hero
Atari Super Hero
Posts: 857
Joined: Wed Jan 04, 2006 1:28 am
Location: Boston

Re: Daimakaimura (Ghouls 'n Ghosts) for the Atari STE

Postby Frank B » Mon Jun 05, 2017 4:41 pm

It only costs 8 bytes per 16 pixels scrolled. 2 pixels a byte. You could scroll a very long time before you exceed 32kb.
Scrolling vertically might get a bit fiddly though.

User avatar
calimero
Atari God
Atari God
Posts: 1941
Joined: Thu Sep 15, 2005 10:01 am
Location: STara Pazova, Serbia
Contact:

Re: Daimakaimura (Ghouls 'n Ghosts) for the Atari STE

Postby calimero » Wed Jun 07, 2017 6:56 pm

Anima wrote:
chlu600 wrote:It'll be hard anyway to create an optimal 16-color palete for only one level and it's sprites.

Yes indeed. I think I've found a good one. Actually it's the "DawnBringers 16 colours palette":
Image

Here are some remapped MAME screenshots using the palette:

What program did you use for remapping colors? I try with PhotoShop but results are far away from yours (with DawnBringers 16 colours palette).
Did you tune it manually ?
using Atari since 1986.http://wet.atari.orghttp://milan.kovac.cc/atari/software/ ・ Atari Falcon030/CT63/SV ・ Atari STe ・ Atari Mega4/MegaFile30/SM124 ・ Amiga 1200/PPC ・ Amiga 500 ・ C64 ・ ZX Spectrum ・ RPi ・ MagiC! ・ MiNT 1.18 ・ OS X

User avatar
Anima
Atari Super Hero
Atari Super Hero
Posts: 599
Joined: Fri Mar 06, 2009 9:43 am
Contact:

Re: Daimakaimura (Ghouls 'n Ghosts) for the Atari STE

Postby Anima » Wed Jun 07, 2017 8:19 pm

Frank B wrote:It only costs 8 bytes per 16 pixels scrolled. 2 pixels a byte. You could scroll a very long time before you exceed 32kb.
Scrolling vertically might get a bit fiddly though.

Exactly. Unfortunately Ghouls 'n Ghosts has definitely rounds where it goes in both directions:
Image

User avatar
Anima
Atari Super Hero
Atari Super Hero
Posts: 599
Joined: Fri Mar 06, 2009 9:43 am
Contact:

Re: Daimakaimura (Ghouls 'n Ghosts) for the Atari STE

Postby Anima » Wed Jun 07, 2017 9:18 pm

calimero wrote:What program did you use for remapping colors? I try with PhotoShop but results are far away from yours (with DawnBringers 16 colours palette).
Did you tune it manually ?

The sprite compiler does the remapping as well. It also creates mixed colours which will be drawn as a checker fill pattern.

User avatar
Frank B
Atari Super Hero
Atari Super Hero
Posts: 857
Joined: Wed Jan 04, 2006 1:28 am
Location: Boston

Re: Daimakaimura (Ghouls 'n Ghosts) for the Atari STE

Postby Frank B » Thu Jun 08, 2017 11:54 am

Anima wrote:
Frank B wrote:It only costs 8 bytes per 16 pixels scrolled. 2 pixels a byte. You could scroll a very long time before you exceed 32kb.
Scrolling vertically might get a bit fiddly though.

Exactly. Unfortunately Ghouls 'n Ghosts has definitely rounds where it goes in both directions:
Image


That should be ok. You can just scroll backwards and y wrap the screen. :) Have a look at this http://aminet.net/dev/asm/8wayscroller.lha
It's for the Amiga but it should be relevant here.

Frank

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3429
Joined: Sat Jun 30, 2012 9:33 am

Re: Daimakaimura (Ghouls 'n Ghosts) for the Atari STE

Postby dml » Fri Jun 09, 2017 4:14 pm

For what it's worth, I use 2 buffers (well, one 'tall' buffer) with the same data written to both simultaneously, at different positions. The display address can then 'hop' to the other buffer on a vertical wrap, and the image is already good. I termed this 'loopback scroll' in AGT. This is the cheapest method I know of (short of physically splitting the display on a raster, which involves physically splitting the sprite updates too).

There are other tricks to accelerate the updates, but maybe not applicable to the virtual tile drawing device being emulated here.


Social Media

     

Return to “Games”

Who is online

Users browsing this forum: No registered users and 1 guest