Darkhog Posted April 13, 2013 Share Posted April 13, 2013 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? Quote Link to comment Share on other sites More sharing options...
Darkhog Posted April 14, 2013 Author Share Posted April 14, 2013 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. Quote Link to comment Share on other sites More sharing options...
TMR Posted April 16, 2013 Share Posted April 16, 2013 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? Quote Link to comment Share on other sites More sharing options...
Darkhog Posted April 16, 2013 Author Share Posted April 16, 2013 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. Quote Link to comment Share on other sites More sharing options...
TMR Posted April 17, 2013 Share Posted April 17, 2013 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? Quote Link to comment Share on other sites More sharing options...
Darkhog Posted April 17, 2013 Author Share Posted April 17, 2013 (edited) 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 April 17, 2013 by Darkhog Quote Link to comment Share on other sites More sharing options...
Rybags Posted April 17, 2013 Share Posted April 17, 2013 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. Quote Link to comment Share on other sites More sharing options...
Darkhog Posted April 17, 2013 Author Share Posted April 17, 2013 Yeah, action can have some sort of inline assembly, just look like Action Runtime is being written like: http://atariwiki.strotmann.de/wiki/Wiki.jsp?page=ACTION%20Runtime%20von%20Jeff%20Reister - those routines are written in assembly, however you'll need to assembly them by hand. As I said, I'm unable to do it myself, so I need help. Quote Link to comment Share on other sites More sharing options...
Synthpopalooza Posted April 17, 2013 Share Posted April 17, 2013 (edited) This may help: http://wiki.strotman...C Graphics Mode The good stuff is at lines 5860 to 6210. Edited April 17, 2013 by Synthpopalooza Quote Link to comment Share on other sites More sharing options...
Darkhog Posted April 17, 2013 Author Share Posted April 17, 2013 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. Quote Link to comment Share on other sites More sharing options...
TMR Posted April 17, 2013 Share Posted April 17, 2013 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... Quote Link to comment Share on other sites More sharing options...
Synthpopalooza Posted April 17, 2013 Share Posted April 17, 2013 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 Quote Link to comment Share on other sites More sharing options...
Xuel Posted April 18, 2013 Share Posted April 18, 2013 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: Enable PAL Blending for best results. 1 Quote Link to comment Share on other sites More sharing options...
Synthpopalooza Posted April 18, 2013 Share Posted April 18, 2013 (edited) 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 April 18, 2013 by Synthpopalooza Quote Link to comment Share on other sites More sharing options...
Xuel Posted April 18, 2013 Share Posted April 18, 2013 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 Quote Link to comment Share on other sites More sharing options...
Darkhog Posted April 18, 2013 Author Share Posted April 18, 2013 (edited) 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 April 18, 2013 by Darkhog Quote Link to comment Share on other sites More sharing options...
TMR Posted April 18, 2013 Share Posted April 18, 2013 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. Quote Link to comment Share on other sites More sharing options...
Darkhog Posted April 18, 2013 Author Share Posted April 18, 2013 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? Quote Link to comment Share on other sites More sharing options...
Xuel Posted April 18, 2013 Share Posted April 18, 2013 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. 1 Quote Link to comment Share on other sites More sharing options...
+JAC! Posted April 18, 2013 Share Posted April 18, 2013 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 :-) 3 Quote Link to comment Share on other sites More sharing options...
TMR Posted April 18, 2013 Share Posted April 18, 2013 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. Quote Link to comment Share on other sites More sharing options...
Darkhog Posted April 18, 2013 Author Share Posted April 18, 2013 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. Quote Link to comment Share on other sites More sharing options...
danwinslow Posted April 18, 2013 Share Posted April 18, 2013 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. Quote Link to comment Share on other sites More sharing options...
NRV Posted April 19, 2013 Share Posted April 19, 2013 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 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 ) 1 Quote Link to comment Share on other sites More sharing options...
Synthpopalooza Posted April 19, 2013 Share Posted April 19, 2013 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,. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.