Jump to content
Darkhog

APAC graphics mode in ACTION?

Recommended Posts

I've learned some time ago about Any Pixel, Any Color software graphics mode. Unfortunately I don't know how to use it with ACTION!. All I found was some shady assembly (which I don't know how to integrate).

 

Doesn't anyone have APAC action file, so I could do

 

INCUDE "D:APAC.ACT"

 

and then init it and use?

Share this post


Link to post
Share on other sites

Bumping, because I'd like to use this mode in actual game (to this point I've seen it used only in demos), for both sprites (software of course) and levels.

Share this post


Link to post
Share on other sites

i'm assuming the .ACT file would be ACTION! code rather than assembly language... is compiled ACTION! actually fast enough to generate an APAC display?

Share this post


Link to post
Share on other sites

No, no no... ACT file would be assembly code wrapped in Action routines, pretty much same way Action runtime library is. I don't believe ACTION! is fast enough to generate APAC display on itself.

Share this post


Link to post
Share on other sites

No, no no... ACT file would be assembly code wrapped in Action routines, pretty much same way Action runtime library is. I don't believe ACTION! is fast enough to generate APAC display on itself.

 

Fair enough, but you're still going to lose a lot of CPU grunt to a machine code APAC routine (a "cheap" APAC routine like the one i use is tying the CPU up for the entire height of the APAC display, the more efficient one used in Project M is still going to nick a significant percentage of that time as well) so i'd put a question mark next to driving an APAC-powered action game from ACTION! What sort of speed is it possible to get for software sprites?

Share this post


Link to post
Share on other sites

I don't know yet, I'll see. Can anyone track down

demo? It's running in APAC and only thing I found about it was this video. I'd say it's pretty efficient for me, so if sources of it are available, maybe we could rip APAC routine from it, if not decompile somehow (though I won't be able to do it myself because of my limited, read non-existent, knowledge about 6502 assembly).

 

//edit: Also, since Project M must also carry on top of itself 3d engine, being Wolf3d clone and all, I'd say its APAC routines are more than efficient for a game that is supposed to be like some early DOS platformers, like e.g. first two installments of Duke Nukem (they were 2d platformers).

 

//Another edit: From what I've read about Action, it seems that it generates very efficient and small code. So I assume, if APAC routine wouldn't be bottleneck, efficiency would be enough.

Edited by Darkhog

Share this post


Link to post
Share on other sites

An Assembly routine would be a must. Doing APAC is dead easy, just a simple case of alternating the PRIOR register between value of $C0 and $40 per scanline with a WSYNC store thrown in to keep the timing.

 

Can't Action have some inline assembly? If not then some sort of patch could be used to add what's needed to a compiled program.

Share this post


Link to post
Share on other sites

Yeah, but as I said, I don't understand assembly. Let alone integrate it with Action code - if I'd know, this topic wouldn't even be here, as I found above article long time ago when I googled for APAC for action.

Share this post


Link to post
Share on other sites

Yeah, but as I said, I don't understand assembly. Let alone integrate it with Action code - if I'd know, this topic wouldn't even be here, as I found above article long time ago when I googled for APAC for action.

 

That's the problem with compiled languages really, you're at the mercy of the compiler; if it doesn't support something you either have to hope someone else found the need and did the work of building an extension for you or learn what's required to do it yourself i'm afraid...

Share this post


Link to post
Share on other sites

The best I can tell you:

 

APAC runs out of a modified Graphics 8+16 (or Antic mode F) screen. A function called a Display List Interrupt changes the PRIOR register every scanline to alternate between mode 9 and mode 11 (or $80 and $C0, 128 and 192 decimal).

 

So what you would do is modify your display list for DLI's ... by taking each instruction that has a 15 or a 79 in it, and adding 128 to it. For this, it might be helpful to read up on display lists to see how they work.

 

Then you would need a DLI routine for changing the PRIOR every scanline, and then enable the interrupt.

 

Here are some articles which may help, these are for BASIC but it may be possible to modify these for Action!

 

 

http://www.atarimax.com/freenet/freenet_material/12.AtariLibrary/2.MiscellaneousTextFiles/showarticle.php?44

http://www.atariarchives.org/mapping/appendix8.php

http://www.atariarchives.org/c2ba/page078.php

http://www.atarimagazines.com/compute/issue47/153_1_Atari_Display_List_Interrupts.php

Share this post


Link to post
Share on other sites

I gave it a shot without using interrupts:

 

BYTE VCOUNT=$D40B
BYTE PRIOR=$D01B
BYTE WSYNC=$D40A
CARD DLIST=$230
CARD POINTER LMS
BYTE POINTER BM
CARD I,HUE,LUM
BYTE C

PROC MAIN()
GRAPHICS(
PRINT("APAC IN ACTION!")
LMS=DLIST+4
BM=LMS^
FOR I=0 TO 5120 DO
 HUE=I/80:LUM=I MOD 80
 IF LUM<40 THEN BM^=LUM&15
 ELSE BM^=HUE&15 FI
 BM=BM+1
OD

DO
 WHILE VCOUNT <> 15 DO OD
 WHILE VCOUNT < 95 DO
  WSYNC=0:PRIOR=$41
  WSYNC=0:PRIOR=$C1
 OD
 WSYNC=0:PRIOR=$01
 PUT(C&$7F):C=C+1
OD

 

Here is the .ACT file:

 

APAC.ZIP

 

Screenshot:

 

post-21021-0-20890300-1366272844_thumb.png

 

Enable PAL Blending for best results.

  • Like 1

Share this post


Link to post
Share on other sites

Excellent ... :) Now, for those people using NTSC, how would you go about introducing a scanline shift?

 

That is, taking the first instruction of your DLIST, and swapping 96 and 112 on the VBLANK to jitter the screen up and down a scanline? This helps make the mode look better for NTSC people.

 

Edit: Just had a thought ... Would this work?

 

DO
WHILE VCOUNT <> 15 DO OD
WHILE VCOUNT < 95 DO
WSYNC=0:PRIOR=$41:DLIST=96
WSYNC=0:PRIOR=$C1:DLIST=112
OD
WSYNC=0:PRIOR=$01:DLIST=96
PUT(C&$7F):C=C+1
OD

 

Also: to plot on this mode, you need to POKE (87,9) and use even scanlines for the chroma aspect, odd scanlines for the luma, when plotting pixels. DRAWTO would be unusable, it would require custom PROC routines for drawing lines.

Edited by Synthpopalooza

Share this post


Link to post
Share on other sites

Excellent ... :) Now, for those people using NTSC, how would you go about introducing a scanline shift?

 

Here you go:

 

BM=DLIST
DO
WHILE VCOUNT <> 14 DO OD
 IF C&1 THEN WSYNC=0 FI
 WHILE VCOUNT < 95 DO
  WSYNC=0:PRIOR=$41
  WSYNC=0:PRIOR=$C1
 OD
 WSYNC=0:PRIOR=$01
 PUT(C&$7F):C=C+1
 IF C&1 THEN BM^=$60 ELSE BM^=$70 FI
OD

 

APACJIGL.ZIP

 

Also: to plot on this mode, you need to POKE (87,9) and use even scanlines for the chroma aspect, odd scanlines for the luma, when plotting pixels. DRAWTO would be unusable, it would require custom PROC routines for drawing lines.

 

True. I resorted to using a pointer to draw the color bars. Here is a version with wide bars:

 

APAC2.ZIP

Share this post


Link to post
Share on other sites

Excellent. Thank you! By the way, how well does it work with software sprites in terms of performance? As this will be used in a game, I need to know.

 

//edit: Can anyone write ApacPlot routine, that would work just like Plot library routine, but taking third argument which would be color?

Edited by Darkhog

Share this post


Link to post
Share on other sites

Excellent. Thank you! By the way, how well does it work with software sprites in terms of performance? As this will be used in a game, I need to know.

 

The short answer is going to be "slowly"; that APAC routine is going to take the entire play area to run, so if it's 192 scanlines high you're losing a massive chunk of CPU grunt each frame. The cheap and nasty EORed software sprite routine i wrote in machine code at the start of the week manages the equivalent of three 4x8 "pixel" objects per frame in the time that'd be remaining, so that's three objects with hardly any definition in motion that become a mess if they cross anything else.

 

Don't be fooled by the video you linked to by the way, that's just plotting one ball per refresh and doesn't even need to clear it before the next plot.

Share this post


Link to post
Share on other sites
Don't be fooled by the video you linked to by the way, that's just plotting one ball per refresh and doesn't even need to clear it before the next plot.

 

Then how about Project M, which runs APAC -*AND*- 3D engine on top of that?

Share this post


Link to post
Share on other sites

Yea, I'm afraid my example code burns the whole raster period for twiddling the PRIOR register as TMR said. It is more proof of concept than practical. It's fine for static images, but it leaves very little CPU time for modifying the display. There's barely enough time to do a PUT every frame and you cannot exceed the allotted time for computation per frame without ruining the display.

 

Project-M uses a smaller screen area and uses interrupts to leave as much CPU time as possible. Using interrupts also makes it easier to spread computation over many frames. You could definitely use the same techniques in Action!, but I don't know of any ready made examples. Of course, now I'm intrigued by the challenge...

 

Using a general-purpose PLOT routine for soft sprites would be very slow. It would be faster to write your soft sprite routines to write directly to screen memory. What kind of frame rate are you trying to achieve?

 

BTW, the balls demo is named qlkee. Assembly source code is here. Executable and info are here, here and here.

  • Like 1

Share this post


Link to post
Share on other sites

Then how about Project M, which runs APAC -*AND*- 3D engine on top of that?

32 bytes wide screen to reduce DMA and memory footprint, IRQ based APAC (only every 2nd scanline) to reduce interrupt overhead, pure assembler.... and in addition you have to be NRV :-)

  • Like 3

Share this post


Link to post
Share on other sites

32 bytes wide screen to reduce DMA and memory footprint, IRQ based APAC (only every 2nd scanline) to reduce interrupt overhead, pure assembler.... and in addition you have to be NRV :-)

 

i was going to write a long, drawn out reply explaining everything that makes Project M what it is but... that sums it up beautifully. =-)

 

 

Just to add that, whilst Action's compiler is good, at best it'll only produce code similar to unoptimised assembly language; even that cheap and cheerful EORed software sprite routine i mentioned previously is optimised to a degree (there's a lot of unrolling in there and i've never seen a native 8-bit compiler do that) so three objects per frame is probably a generous estimate for what Action can actually achieve.

Share this post


Link to post
Share on other sites
Using a general-purpose PLOT routine for soft sprites would be very slow. It would be faster to write your soft sprite routines to write directly to screen memory.

Unfortunately I don't know where screen memory is located and Mapping the Atari isn't particularly helpful and is even more confusing in this regard.

Share this post


Link to post
Share on other sites

Screen memory is located wherever you put it, basically. You tell the system, there is no specially reserved memory for graphics. You can find out where the OS thinks it is for normal screen modes via locations 88 and 89. You can control it yourself by those locations as well as by LMS instructions in your display list.

Share this post


Link to post
Share on other sites

32 bytes wide screen to reduce DMA and memory footprint, IRQ based APAC (only every 2nd scanline) to reduce interrupt overhead, pure assembler.... and in addition you have to be NRV :-)

 

i was going to write a long, drawn out reply explaining everything that makes Project M what it is but... that sums it up beautifully. =-)

...

 

Well, I was going to do the same thing, but I would had forgotten to mention the 32 bytes wide screen :ponder:

So resuming:

- 32 bytes wide screen

- over an area of 128 scanlines

- assembler IRQ system to toggle the PRIOR register

- one IRQ interruption every two scanlines

 

So basically you lose most of the time in 64 scanlines (80% - 90% app), like 20% of the frame time in PAL land.

I suppose if you can run assembler code from Action you could set up the IRQ system.

A DLI system doesn't work for this (the "one interrupt every two lines"), because you need to start the interruption before the start of a line, to do the first change to PRIOR, then waste a little time before doing the second change after the end of the same line.

With a 40 bytes wide screen you would lose a similar time, but I never tested this.

 

(And no, you don't need to be NRV, there are many people here as crazy as me :P )

  • Like 1

Share this post


Link to post
Share on other sites

Screen memory is located wherever you put it, basically. You tell the system, there is no specially reserved memory for graphics. You can find out where the OS thinks it is for normal screen modes via locations 88 and 89. You can control it yourself by those locations as well as by LMS instructions in your display list.

 

I'm a bit of an Action! newbie myself ...

 

Where would be a good place to store the screen and character set? Let's assume, I am using Antic 4 in normal mode (960 bytes) and need 1K for a character font. I know I can rely on the OS modes, but I generally consider it more efficient to build my own display list,.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...