Jump to content
IGNORED

Wizzy on the 7800?


karri

Recommended Posts

I just accidentally drew two Wizzy sprites in the same position. At least it looks so. The right end of the 2nd sprite line combines sprites. How is this even possible in the indirect mode? Perhaps I got the holey stuff wrong? And it draws areas twice?

 

strange.thumb.png.82f11a70dea2716eb43c8110f89623d5.png

 

Is such a trick possible with the DL records? Could I draw an animated character in 8 colours by drawing it twice with 4 colours? The indices for these lines were

5*2, 6*2, 7*2, 8*2, 9*2, 10*2, 11*2, 12*2, 13*2, 14*2, 15*2,
36*2, 37*2, 38*2, 39*2, 40*2, 41*2, 42*2, 43*2, 44*2, 45*2, 46*2, 47*2,

 

So I have no clue of what has happened here.
 

 

I also realized that I just run out of indices - not memory with this 2 byte per mapped tile trick. I had to fill half of the 4k block with zeros to make the data cover 4k.

1346467867_Screenshotfrom2022-03-0611-39-40.png.5f2518ad354d7ada35f0285abcac5131.png

Link to comment
Share on other sites

4 hours ago, karri said:

I just accidentally drew two Wizzy sprites in the same position. At least it looks so. The right end of the 2nd sprite line combines sprites. How is this even possible in the indirect mode? Perhaps I got the holey stuff wrong? And it draws areas twice?

 

Indirect mode just means use the char map to select graphics data, nothing more. If you draw overlapping objects, and the last one has transparency, the other one(s) will show through, regardless of DMA mode.

 

You may have gotten the holey stuff wrong. Maybe you did not offset the high byte? For example, if some graphics data start at $E0xx, and you want it to show up 3 lines below the top of the zone, set the high address byte to $E3: MARIA will read the top 3 lines for this object from $F2xx, $F1xx, and $F0xx, which holey DMA will treat as zeros. After that MARIA will read $EFxx (the top line of the actual graphics data) and so forth, all the way to $E3xx at the bottom of the zone. Then, typically, you draw the remaining 3 lines in the zone below, by setting the header's high address byte to $D3.

 

For purposes of drawing backgrounds, the graphics are typically aligned to the zones. (To be clear, "background" is a use case, not a formal distinction to MARIA.)

 

4 hours ago, karri said:

Is such a trick possible with the DL records? Could I draw an animated character in 8 colours by drawing it twice with 4 colours?

 

Yes (but only 7 colors, since background/transparency is shared across all palettes). 160B will probably be more efficient, and give you 13 colors instead of 7. But — assuming kangaroo mode is off — overlaying 160A objects will work, if that's your preference.

 

4 hours ago, karri said:

I also realized that I just run out of indices - not memory with this 2 byte per mapped tile trick. I had to fill half of the 4k block with zeros to make the data cover 4k.

 

I think people think of 2-byte chars as meaning only getting 128 chars. That's not quite right, since they can overlap, as you have discovered. The real limitation is 256 bytes.

 

The data in your image uses only 128 bytes per page. No reason you can't use the other half for more chars (or other assets, if you'd prefer).

 

Link to comment
Share on other sites

19 hours ago, Defender_2600 said:

 

 

As a side note, I would just suggest to consider the real pixel aspect ratio so that, as far as possible, this beautiful graphics do not look wide on real hardware.

 

 

 

1098606171_realpixelaspectratio.thumb.PNG.0d0d6483b2d3a01a0d6c86eba095b7cc.PNG

 

 

 

 

1731768252_realpixelaspectratio..thumb.PNG.cd09bf4688a3ddb50666f86876813e93.PNG

 

 

 

 

1081674560_realpixelaspectratio...thumb.PNG.31539be11c7a12e1cc52b8761cbef771.PNG

 

Is the correct way to deal with aspect ratio to first define the number of lines on the screen and then decide of the number of pixels to use for the width of the character?

 

The hardware does not seem to have any means to duplicate lines. So I seem to be forced to use direct draws only and use 16 scanline chunks.

Link to comment
Share on other sites

19 hours ago, karri said:

I am also trying to map the colours from Lynx to the 7800. Here is a map I did.

7800_Lynx.png.7edf5d001ac7aa4e784318a0c4a901ef.png

 

The small square samples are the closest colour I found on the 7800 palettes. The values are hue-luminance pairs.

These values are trying to mimick the Dawnbringer 16 colour palette. I hope I git the values right.

The only selection that appears incorrect is "FF".  White would better be served as "0F", and may have been what was intended, the above just being a typo.

 

Two things to consider when selecting a palette value: 

1.  Display types: modern (LCD, OLED, Plasma, etc.), or traditional (CRT), significant impacts the appearance of the NTSC $1x range. 

2.  Palette ranges $Ex and $Fx are highly fluid in their appearance, based on how long the system has been consistently running ("warmup"), and the aforementioned display type factor. 

 

There are some other subtle to relatively minor deltas as well.  The above covers the most concerning ones.

 

Below, in the spoiler, are four points to compare as typical examples:  1. CRT Cold  2. CRT Hot  3. LCD Cold  4. LCD Hot

 

 

 


1245409707_AtariCRTVsLCD2022.thumb.png.88851641f7b210e2fdc01a099d32c2c6.png
 

 

 

Review of Atari 7800 Color Documentation from http://7800.8bitdev.org/ will be very helpful, as is the excellent example warmup gif provided there. 

 

If looking for game examples, breakdowns, further comparisons, as well as alternative options for palette selections, see this thread.

  • Like 2
Link to comment
Share on other sites

Thank you for the corrections. If I go with the 13 colour mode then I will probably run with a fixed palette looking like this:

7800_Lynx.png.9da1ebaa74639adf1e85607e7c22bf53.png

 

For the aspect ratio I am probably picking the PAL screen with 242 visible lines and tailor the tile widths to match the height of 32 scanlines. My guess is that 16 by 32 pixels produce a square in PAL mode. I will just double the lines in my 16 by 16 graphics.

 

Obviously the indirect drawing mode works only for 8x8 single colours character maps.

  • Like 2
Link to comment
Share on other sites

2 hours ago, Pat Brady said:

Yes (but only 7 colors, since background/transparency is shared across all palettes). 160B will probably be more efficient, and give you 13 colors instead of 7. But — assuming kangaroo mode is off — overlaying 160A objects will work, if that's your preference.

Depending upon the game's requirements it may be safer to work with two overlaid draws in exchange for the overhead of parsing the second Display List entry. Switching render modes within a line requires you also switch back - and if Maria runs out of render time and your next line doesn't start with a 5-Byte Display List to "default" the render mode, you'll get some funky visuals.

 

1 hour ago, karri said:

The hardware does not seem to have any means to duplicate lines. So I seem to be forced to use direct draws only and use 16 scanline chunks.

This was added in the Rescue on Fractalus prototype by shifting the address lines of expansion memory in the cartridge, but yes - it's not a standard feature. Most of the Aspect Ratio stuff can be handwaved by doubling the lines in any 160 mode (as you already described) or ignoring it for the 320 modes.

 

Usually software doesn't accommodate for the nuances here and most players won't notice unless they're looking closely.

Edited by TailChao
  • Like 3
Link to comment
Share on other sites

On 2/24/2022 at 10:09 PM, Defender_2600 said:

...that lynx graphic could be almost identical on the 7800, you just need to double the vertical resolution in order to get square pixels, therefore from 160 * 102 to 160 * 204.

 

4 hours ago, karri said:

For the aspect ratio I am probably picking the PAL screen with 242 visible lines and tailor the tile widths to match the height of 32 scanlines. My guess is that 16 by 32 pixels produce a square in PAL mode. I will just double the lines in my 16 by 16 graphics.

This. It is exactly what I meant by a perfect aspect ratio conversion, and preserving every detail of the original graphics (and if you want, you could also add more detail, since you are using a higher vertical resolution). It also has the advantage of displaying larger graphics on the screen and this is again eye candy.

 

In any case, I would suggest not to exceed 224 visible lines, so that the playing field is fully visible in the NTSC version.

 

 

 

1367637456_lynxvs7800.thumb.PNG.f07d1cc7e8ca55cd552e35aafd2fd174.PNG

 

Edited by Defender_2600
  • Like 1
  • Thanks 1
Link to comment
Share on other sites

4 hours ago, karri said:

If I go with the 13 colour mode then I will probably run with a fixed palette looking like this:

 

Using the 160 modes, you don't have the limit of 13 colors or even 16 colors, in fact you can use (and without tricks) up to 24 colors + the background color / transparent :

 

- 160A (WM=0,RM1=0,RM0=0) 2 bits per pixel, 3 colors + background/transparent from 8 palettes

- 160B (WM=1,RM1=0,RM0=0) 4 bits per pixel, 12 colors + background/transparent from 2 palettes

 

The 160B mode is 4 bits per pixel therefore it consumes more resources than 160A 2 bits per pixel, consequently not all types of games can be made using *exclusively* the 160B mode, however it can be a tremendous ally when used in conjunction with the 160A.

 

An excellent example of games made in 160A + 160B are Ninja Golf (1989), Bentley Bear's Crystal Quest (its engine can display up to 52 colors on screen!), Arkanoid (the head graphics of DOH and Arkanoid Spaceship are made entirely in 160B mode), E.X.O., Bomber Hero (WIP), and the recent Attack of the PETSCII robots (WIP) made almost exclusively in 160B (!!).

 

 

 

531516034_7800Bomberman.thumb.PNG.f9d4dc07b6b27ff6ec9a9f1062014562.PNG

 

 

 

2024523764_7800BombermanvsTurboGrafx16.thumb.PNG.97ed2329e42fe2c734f5d10fc200fcd3.PNG

 

 

 

283325783_7800headgraphicsofDOH.thumb.PNG.c6d7ec02efc627162a0f3f873023c002.PNG

 

 

 

190255083_7800DOHgraphicVSNES.thumb.PNG.cbc67b6a1d12e8cf607fbf63e548c42a.PNG

 

 

 

 

Edited by Defender_2600
  • Like 3
  • Thanks 1
Link to comment
Share on other sites

Thank guys, this advice is really helpful. So I will go with a light green background as that colour is never used on the characters. Setting the first palette to also have light blue for the sea, pink for the roads and yellow or peach for adding debris/flowers should allow me to use 160A for the background. I may need palette 2 for the walls.

 

Edit:

I may need different palettes for sea, wall and grass areas. Combining them all to the same 4 colours looks awful.

  • Like 4
Link to comment
Share on other sites

Unfortunately I do not own a real 7800. So I wonder if someone could have a look if this works on a real 7800 at all. The build is for a 48k cart.

 

The screen looks like this in an emulator:

displaytest.thumb.png.c4c24497133380da8c30bd5f154f575d.png

displaytest.a78

 

I just realized that the playfield may be too large. Here is a 2nd version with 224 lines playfield.

smallerplayfield.a78

 

So once I figure out if the machine is PAL or NTSC ( = Never Twice Same Colour ) I could then change my dll list to math the lines.

  • Like 6
Link to comment
Share on other sites

2 hours ago, karri said:

Unfortunately I do not own a real 7800. So I wonder if someone could have a look if this works on a real 7800 at all. The build is for a 48k cart.

Here's how it looks on my Concerto. Looks like the top is cut off a bit.

 

259995061_1592816904415610_2245657504760172809_n.thumb.jpeg.d7206f45c70b9e6210dffd93dd057cc3.jpeg

  • Thanks 1
Link to comment
Share on other sites

8 minutes ago, Karl G said:

Here's how it looks on my Concerto. Looks like the top is cut off a bit.

 

259995061_1592816904415610_2245657504760172809_n.thumb.jpeg.d7206f45c70b9e6210dffd93dd057cc3.jpeg

Thanks! Good enough for now. I plan to keep the playing area as shown. Perhaps I move lines around to center the image in the playfield.

It would be nice to be able to cut out the area without content. My background colour is light green as it is about the only colour that is not used much on the characters of the game.

Link to comment
Share on other sites

3 hours ago, karri said:

It would be nice to be able to cut out the area without content. My background colour is light green as it is about the only colour that is not used much on the characters of the game.

 

To get it, you can use black color as a background, (or use black tiles) on the top and bottom of the screen. Just remember that, since you are using vertical scrolling, with your graphics it is necessary that all palettes share the same background color.

 

Edited by Defender_2600
Link to comment
Share on other sites

43 minutes ago, Defender_2600 said:

 

To get it, you can use black color as a background, (or use black tiles) on the top and bottom of the screen. Just remember that, since you are using vertical scrolling, with your graphics it is necessary that all palettes share the same background color.

 

Thanks! Really good advice about the background colour. I was just in the process to mess it up!
 

My guess is that I have soon screwed up the build in every way possible. I really, truly HATE the way 7800 uses zones and DL lists. What have these guys been smoking?

  • Like 3
Link to comment
Share on other sites

Just now, gambler172 said:

Hi Karri

 

i get the same result on my Dragonfly cart....

Thanks Walter. I hope to get something scrollable later this week. Right now I am mainly hurting my brain by trying to remember everything I read this week. My impression is that the Lynx is much easier than the 7800.

 

Link to comment
Share on other sites

9 minutes ago, karri said:

Thanks Walter. I hope to get something scrollable later this week. Right now I am mainly hurting my brain by trying to remember everything I read this week. My impression is that the Lynx is much easier than the 7800.

People describe the 2600 as being a challenging system to code for. Certainly it has the most nerd cred for that. But I find the 7800 to be the more challenging system of the two.

 

  • Like 2
Link to comment
Share on other sites

1 hour ago, karri said:

Thanks Walter. I hope to get something scrollable later this week. Right now I am mainly hurting my brain by trying to remember everything I read this week. My impression is that the Lynx is much easier than the 7800.

 

Well for me the Lynx is near impossible to code, even with Fadest editor

  • Confused 1
Link to comment
Share on other sites

Ok. How do you deal with speed problems? The update is kind of slow on my tiled screens.

wizzy.a78

 

Currently you can navigate with cursor keys. I am a bit nervous about any kind of animation if the background needs to move.

 

I assume that once I have set up the scenery I can just move the enemies and Wizzy on the screen without refreshing the background. Correct?

 

And don't think about soft scrolls yet. Currently I am redrawing the screen in tile increments only.

 

Is it possible to adjust horisontal offset without the graphics re-drawing on the screen?

 

Can you also update stuff in advance outside the screen and then just roll it in smoothly without this re-draw effect?

 

Double buffering?

Link to comment
Share on other sites

Great progress! Redoing all of the DLs each frame is almost always going to be a non-starter in terms of cpu, as you've found.

 

2 hours ago, karri said:

I assume that once I have set up the scenery I can just move the enemies and Wizzy on the screen without refreshing the background. Correct?

Correct. You just leave the the screen background objects as-is in the DL, and update the DL after those objects.

 

2 hours ago, karri said:

Is it possible to adjust horisontal offset without the graphics re-drawing on the screen?

Yes, absolutely. Since these horizontal offset DL memory locations don't change, you can just have one routine with all of the required INCs and another routine with all of the required DECs for right and left fine-scroll.

 

You didn't ask, but you can coarse scroll vertically by changing the DLL pointers, and then only update one row of "background" objects.

 

Quote

Can you also update stuff in advance outside the screen and then just roll it in smoothly without this re-draw effect?

 

Double buffering?

Whenever possible, you should restrict screen updates to non-visible periods, to avoid screen tearing and/or glitching from half-updated DL objects. (If you setup an interrupt that triggers at the top and bottom of your active screen, you can update a memory location to flag when the visible screen is active. Don't restrict yourself to just vblank)

 

Double-buffering is entirely possible, and we have published homebrew games that use it. That said, it has it's own challenges; you need twice the DLL memory, and any changes to "background" DL objects need to be propagated to both DLs.

 

I wrote up some general points on maximising sprites a while back, which may be of interest. Among other things, It talks about splitting your game code into two sections, where you first run code that can run during the visible screen, and then do routines that update the screen during non-visible. Avoid any complicated logic during the non-visible time (where cycles are tight) should be avoided, even if it means trading off a bit more time during the visible screen. (where cycles are more plentiful) IMO this focus on visible vs non-visible code is foundational to efficient use of the 7800. (Of course, that visible/non-visible focus goes away if you decide to do double-buffering.)

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

21 hours ago, karri said:

My guess is that I have soon screwed up the build in every way possible. I really, truly HATE the way 7800 uses zones and DL lists. What have these guys been smoking?

 

1901479611_UpinSmoke.jpg.d216309034f2de5c7bb03046d29b5735.jpg

 

What if it's like... a blitter, but there's no framebuffer?

 

You mean it uses tiles and sprites?

 

Nah, man - it's got draw commands but they show up on the tv instead of in memory.

 

How we gonna parse all that junk?

 

*puff puff* uh... make the lists like... smaller, lots of smaller lists!

 

Far out.

 

Whatever it was, the Jaguar's designers picked up the roach.

If you want a Lynx attached to a television, try 3DO.

 

 

20 hours ago, RevEng said:

People describe the 2600 as being a challenging system to code for. Certainly it has the most nerd cred for that. But I find the 7800 to be the more challenging system of the two.

I've been beating this drum for a long time - but I think the challenge with the 7800, if you're coming from the 2600, is to not follow the same design paradigms. There's a lot of parallels between Atari's wedge and Nintendo's thing that looks like a VCR and the cartridge slot goes bad.

  • Like 2
  • Haha 5
Link to comment
Share on other sites

21 hours ago, RevEng said:

People describe the 2600 as being a challenging system to code for. Certainly it has the most nerd cred for that. But I find the 7800 to be the more challenging system of the two.

 

For me it's hard to compare. It's just a very different challenge. Except for audio, where it's a very similar challenge.

  • Like 1
Link to comment
Share on other sites

One step further, I hope.

 

Now I implemented some kind of block scroll combined with monitoring interrupts. In an emulator the speed is better. But still far from flicker free double buffering.

 

Any comments for what it looks on a real 7800 is appreciated.

(The colours and details of background graphics is still far from completed.)

 

wizzy.a78

 

I may have to separate the filling in of dirty tiles to keep playability the same for horisontal and vertical movements. In this case speed is more important than visuals.

  • Like 1
Link to comment
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...