Looking for 7800 programmer to assist porting a game

[tep392]

I'm trying to figure out the most efficient way to erase a character when using static display list entries. Does it save Maria cycles to move an object off screen vs. changing it to a blank object? I'm wondering how Maria treats a DL entry that is off screen, outside the 160 pixel line buffer. My guess is that Maria would still use 8 cycles to read the 4 byte header, but it should not need to read the graphics bytes (3 cycles each) if the x position is outside the 160 pixel wide buffer. If I erase an object by changing it to a blank character, Maria would still need to read the graphics data for the blank character. I could be wrong though. Maybe Maria still reads the graphics bytes but does nothing with them because the x position is off screen.

[Mord]

I'd assume if the blank character is the same width as the full sprite it's replacing it would still be read the same. Maria would need to read in the byte to even know it was blank.

 

One thing you could probably do, although I don't know how useful this would be in practice, is to have your sprites set up so that there's enough of a blank space at the start of each sprite. Then to "erase" them, you'd just have to change the width to be minimum - ie: just the blank portion of the sprite? Not a perfect solution but probably one of the fastest to change on the fly if you're directly editing the DLs.

[tep392]

I'm sure Maria would still read the blank sprite as well. I'm wondering if it still reads the sprite data when X>160. The Maria docs that I've seen don't talk about this, but they do talk about graphics DMA aborting when using holy DMA. It's conceivable that it could abort DMA when X is outside the range of the buffer. I suppose I could make a test to see what happens. Otherwise what I'll do is change the width to 1 to minimize graphics fetches (normal width is 3 bytes) and move off screen at the same time. I don't expect to have font space to spare.

[RevEng]

I believe that Maria reads and "renders" it anyway, throwing away off-screen pixels.

 

Maria will clip objects that are partially off-screen and partially on-screen, on either side of the screen, so it can't do just a simple X test. (ie. x=255 will position an object slightly off the left-hand edge.) So at the very least Maria would also need to do a width addition before such a test.

 

I think I tested the DMA results for this long ago, but not willing to swear to it.

[tep392]

I believe that Maria reads and "renders" it anyway, throwing away off-screen pixels.

I think this is correct and happens as the line buffer is being written to, so graphics data has already been read. Pixel data above 159 are thrown out. I found a paper on a 7800 FPGA development project that indicates this is the case.

[Trebor]

AtariAge user andym00 made a similar statement when discussing cycle accurate emulation. Not sure if it is the result of actual testing or referencing the same aforementioned paper; however, it was back in 2011:

 

"...dma is aborted in the case of exceeding the 159'th line ram pixel..."

 

Unsure if that helps reaffirm the information, but thought worthy of mentioning.

[tep392]

I have another idea. Since I'm using holey DMA, I could set the address of the unused DL header to point at a hole, which would abort DMA reading the graphics.

[RevEng]

Trebor just ran a test. An object being off-screen doesn't impact DMA in the slightest.

 

Test attached for the curious.

spritedmatest.bas.a78

spritedmatest.bas.bin

[Trebor]

Quick raw video...

 

https://www.youtube.com/watch?v=zKsa_J8hzRA

 

Kudos to RevEng for the test and CPUWIZ for his awesome MCPDev Cart.

 

Note: If trying the provided test under emulation, A7800 mirrors the real hardware, but the ProSystem emulator does not.

[tep392]

Could the program be modified to have the center rows of that large sprite point to a dma hole?

[RevEng]

Literally using a dma hole for sprite data (while using my regular sprite-DL routines) would be problematic, since any object with a Y that doesn't begin at the top of a zone would allow the non-hole data to peek through. Sort of the opposite of why we use holes in the first place.

 

Here's one that's in the spirit of what you want, I believe. It modifies the DLs that the middle of the meta-sprite is over, and re-points those sprite rows to the dma hole.

sprite_hole_dma.bas.a78

sprite_hole_dma.bas.bin

[peteym5]

Interesting stuff going on with Sprite Hole and DMA. I also discovered this sprite hole DMA limit and a process known as multiplexing is a way to work around this. Where as it will not draw all the sprites in one tv frame. Certain ones will not be drawn in one tv frame, but will be drawn in the next frame. I call it a "Sit out" because it is similar to having an American NFL Football Team with 53 players, but only 11 can be on the field on one time per play. If you want 16 sprites in a zone, but the 7800 can only show 12 of them, sprites number 0,4,8 will not be displayed frame 1, sprites number 1,5,9 not in frame 2, etc. They will "flicker" but that looks better than having a whole part of the screen go black. However, as I had stated before, having that many sprites in the same horizontal zone will be rare with many of my current productions.

[tep392]

My current plan for D2K is to build the screen with sprites. Girders can be made with sprites up to 31 bytes wide. There is a ton of blank space in the Donkey Kong screens and using character mapped graphics wastes a lot of Maria time fetching and drawing blank characters. By using sprites in a smart manner, I can put more animated objects in a zone without resorting to flicker. It will actually give me more font space as well because the Ramp screen in character mode requires girder/ladder characters drawn at 8 different vertical positions. Character map mode was going to require 112 characters in the font just for the girders and ladders. Another plus is reducing overall Maria cycles, leaving more CPU cycles for the game code. The downside is that my display list is going to use a lot of RAM, but I should still be ok with the base 4k.

[peteym5]

For D2K, can you make up the Girder and Latter characters and re-use them at several points on the screen or on different levels? A single font should be able to do it and still having look very close to the arcade.

 

I may be going for more of an arcade look and feel with Venture, but porting stuff over from the 8-bit code is a work-in-progress. Many say the 8-bit version is great, so I am considering having several game modes: Classic Arcade, Atari Mode, Challenger, and 7800 Mode. 7800 Mode will take advantage of the 7800 extra abilities like more monsters on screen at once.

Edited December 12, 2017 by peteym5

[tep392]

For D2K, can you make up the Girder and Latter characters and re-use them at several points on the screen or on different levels? A single font should be able to do it and still having look very close to the arcade.

 

I may be going for more of an arcade look and feel with Venture, but porting stuff over from the 8-bit code is a work-in-progress. Many say the 8-bit version is great, so I am considering having several game modes: Classic Arcade, Atari Mode, Challenger, and 7800 Mode. 7800 Mode will take advantage of the 7800 extra abilities like more monsters on screen at once.

Take a look at this map for the ramp screen. To do this in indirect mode (character mapped), I need to have a bunch of horizontally pre-shifted girders defined in the font to make each of these characters. Add even more characters to the font because of all the segments that have ladders on them. To make it worse, maria is spending a ton of time drawing blank characters. By using direct mode, I could theoretically have a single girder segment in my font and position copies of it at any x and y position as a sprite. I'll actually be making one long segment in the font, as highlighted at the bottom of the screen. I can put copies of that segment at any x and y position with whatever length is needed.

 

Using direct objects, instead of character mapped, might be a good option for Delta Space Arena.

 

[peteym5]

I will be using more direct objects for games like Putt 18 Mini Golf and Venture instead of having all the static graphics like walls being character set mode. Like the Treasures, Doors, etc in Venture, or the putting tee and water hazards in Putt 18 can be direct objects. I am using 160 pixel wide character mode because these games are being ported from the 8-bit that used Antic 4 screens and already have several games with screens with everything at the same locations.