English Amiga Board - trying to display an AGA image...

English Amiga Board (https://eab.abime.net/index.php)

- Coders. Asm / Hardware (https://eab.abime.net/forumdisplay.php?f=112)

- - trying to display an AGA image... (https://eab.abime.net/showthread.php?t=106965)

jotd	14 May 2021 18:31

trying to display an AGA image...

3 Attachment(s)

I've converted a PNG image to raw data + copperlist and it doesn't work as well as it should

the image is shifted

EDIT: thanks to Stingray, found out that one bitplane was missing. One error less.

Attachment 71927

what I want to achieve

Attachment 71919

the start of the pic is shifted (modulo issue?).

this is exe + source code: Attachment 71928

There's an ECS (EHB) test that works perfect. The AGA test does not. That's my first AGA attempt so of course I screwed something up

For the ones who are curious:

I've got the supercars2 source code and got it running with a rebuild using OCS assets and files ripped off the original disks. I'd like to use DOS assets to pimp up the game to an AGA version: title screen, comm screens and more (colored enemy cars would be cool and/or more colors in backgrounds for instance). What's also planned: adding more tracks.

mcgeezer

14 May 2021 19:50

Quote:

Originally Posted by jotd (Post 1483630)

I've converted a PNG image to raw data + copperlist and it doesn't work as well as it should

- the image is shifted
- the colors are almost okay but not quite right

Attachment 71918

what I want to achieve

Attachment 71919

the start of the pic is shifted (modulo issue?). Plus the colors are perfect by moments, but completely off in some places

this is exe + source code: Attachment 71920

There's an ECS (EHB) test that works perfect. The AGA test does not. That's my first AGA attempt so of course I screwed something up

For the ones who are curious:

I've got the supercars2 source code and got it running with a rebuild using OCS assets and files ripped off the original disks. I'd like to use DOS assets to pimp up the game to an AGA version: title screen, comm screens and more (colored enemy cars would be cool and/or more colors in backgrounds for instance). What's also planned: adding more tracks.

What is you fetch mode and did you align your bitplanes accordingly?

jotd	14 May 2021 20:43

fmode is at 0. Setting 3 results in trashed display.But I'd like to be able to set FMODE to the fastest.

StingRay

14 May 2021 21:05

First observation: 40*240*8 = 76800. Your picture has a size of 67204 bytes (40*240*7 + 4 bytes (padding?)) so there's one bitplane missing!

jotd	14 May 2021 21:12

correct! thanks a lot. The colors are now perfect. But the pic is still shifted. Check my edit.

StingRay

14 May 2021 21:20

I have loaded your raw picture into a converter and it appears your source image is already shifted. How did you convert the image?

a/b	14 May 2021 21:29

Several things:
- Stringray beat me to it, raw image size doesn't match bitplane size times depth, it's too short
- fetch mode is not set in the source, but you later mentioned you use 0. OK, 0 works but if you want to use 3 you have to set modulos to -8 (they are 0 now) and align the image address to a quadword (8 bytes), it's aligned to a longword at the moment.
- image is not shifted for me (it looks fine other than the missing data), maybe it's something inherited from your workbench screen (one of $dffxxx registers) because you are setting up your copper in a quick&dirty way without LoadView(NULL) etc.

jotd	14 May 2021 21:36

great!

Code:

        move.w #$FFF8,bpl1mod(a5)                ; modulo de tous les plans = 40

        move.w #$FFF8,bpl2mod(a5)

        move.w  #3,fmode(a5)

and it also works. But the shift is stil there... It's not there with the ECS pic...

I have used LoadView(NULL) with same result. Edited first post with proper data (8 bitplanes)

a/b	14 May 2021 22:07

I've loaded the AGA picture into piccon as 320x240x256col, and the green/red jacket guy is the last person on the right side, there is no red/blue shirt girl next to him, she is the first person on the left side of the image.
It looks like the actual data you load from disk is shifted, nothing wrong with code/copperlist.

edit:
Looking at your python script bitplanelib.py, the problem is that you have also included picture dimensions (4 bytes) at the start of AGA picture. That's causing the shift by 32 pixels.

StingRay

14 May 2021 22:20

As I have already said, the source data is shifted! Either your conversion process is wrong or something else caused the shift but it's not related to the code. And adjusting the modulo for FMODE > 0 is ugly, better adapt your DDFSTOP settings.

ross	14 May 2021 22:25

What I would do:

- realign the image:

Code:

    cnop    0,8

image_data:

        dcb.b        36,0

    incbin        "title256.raw"

- skip the first line now invalid:

Code:

move.l #image_data+40,d1

- better setup the fetches and modulo:

Code:

        move.w #$00b0,ddfstop(a5)

...

        move.w #$0,bpl1mod(a5)                ; modulo de tous les plans = 40

        move.w #$0,bpl2mod(a5)

- adjust the view:

Code:

move.w #$20C1,diwstop(a5) ; la fenêtre écran

Try it :)

ah!, and also remove this damn:

Code:

clr.w copjmp1(a5)

StingRay

14 May 2021 22:32

I'd rather fix the conversion instead of dealing with an incorrectly converted image, but to each his own I guess. :)

ross	14 May 2021 23:05

Quote:

Originally Posted by StingRay (Post 1483729)

I'd rather fix the conversion instead of dealing with an incorrectly converted image, but to each his own I guess. :)

Absolutely right :agree
Was just to use the available data (and can be useful for understanding alignments on AGA.. maybe.. :))

jotd	14 May 2021 23:13

spot on! yeah my bitplanelib (that I had developped to hack AAOW to english) has a default option to include dimensions. I overlooked it! stupid

and the display stop worked perfect. Perfect pic now!

thanks all

a/b	14 May 2021 23:14

Hmm, now that's interesting. I haven't done any AGA coding, other than messing around with my old sources, in the last ~20 years and even back then it was pretty much setup a fmode 3 screen for c2p and call it a day. And pretty much any doc, aga coding guide, you name it back then said for fmode 1 or 2 you have to 32-bit align and subtract 4 from modulos, and for fmode 3 use 64-bit align and subtract 8 bytes. Which honestly didn't feel entirely intuitive to me but whatever, it worked. And that's how I always remembered it in some remote corner of my brain.
Now, if you think about it, this is not just a matter of ugliness... Does it actually mean overfetching and then correcting it via modulos? Because that's how it looks like compared to the suggested alternative.

jotd	14 May 2021 23:17

ECS mode is well documented, AGA was less documented because Commodore didn't want people to bang the metal directly... All AGA docs come from reverse engineering by hobbyists.

Personally I'm lost at DIWSTRT/STOP datafetch stuff.

ross	14 May 2021 23:21

Quote:

Originally Posted by a/b (Post 1483747)

Now, if you think about it, this is not just a matter of ugliness... Does it actually mean overfetching and then correcting it via modulos? Because that's how it looks like compared to the suggested alternative.

This.

A good way to slow down your AGA setup..

StingRay

15 May 2021 11:35

Quote:

Originally Posted by a/b (Post 1483747)

Does it actually mean overfetching and then correcting it via modulos?

Yes. That's what I meant with the modulo correction being ugly. :)

DanScott

15 May 2021 12:11

Quote:

Originally Posted by jotd (Post 1483751)

All AGA docs come from reverse engineering by hobbyists.

Apart from the ones floating around in 1993 that came from Commodore

kamelito

15 May 2021 14:06

Quote:

Originally Posted by jotd (Post 1483751)

Except the official AGA doc.

All times are GMT +2. The time now is 11:19.

Page generated in 0.05375 seconds with 11 queries