I am a turncoat. A simple sprite demo for Sega Master System

Discussion of development of software for any "obsolete" computer or video game system. See the WSdev wiki and ObscureDev wiki for more information on certain platforms.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: I am a turncoat. A simple sprite demo for Sega Master System

Post by lidnariq »

tepples wrote: Tue Dec 17, 2019 9:51 pm Status bars are painful unless a game scrolls only horizontally.
Or only vertically. Although I don't know which games use the 24-and-8 split. (at the very least, Gauntlet.)
User avatar
TmEE
Posts: 960
Joined: Wed Feb 13, 2008 9:10 am
Location: Norway (50 and 60Hz compatible :P)
Contact:

Re: I am a turncoat. A simple sprite demo for Sega Master System

Post by TmEE »

tepples wrote: Tue Dec 17, 2019 9:51 pmperiodic noise
It shouldn't be called as such, it is 6.25% duty cycle square wave on VDP PSG (SMS and MD) and 6.666...% on real TI chips.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: I am a turncoat. A simple sprite demo for Sega Master System

Post by lidnariq »

There's something to reinitialize the state of the LFSR when that mode is selected? I naïvely thought it would have kept the same register contents when the feedback taps were modified.
User avatar
TmEE
Posts: 960
Joined: Wed Feb 13, 2008 9:10 am
Location: Norway (50 and 60Hz compatible :P)
Contact:

Re: I am a turncoat. A simple sprite demo for Sega Master System

Post by TmEE »

Any freq write resets the LFSR to 1000 0000 0000 000(0) and the noise/square setting turns off the feedback, so single bit loops through it continuosly, producing (100/16 or 15)% duty cycle depending on VDP or TI PSG.
calima
Posts: 1745
Joined: Tue Oct 06, 2015 10:16 am

Re: I am a turncoat. A simple sprite demo for Sega Master System

Post by calima »

lidnariq wrote: Tue Dec 17, 2019 3:19 pm Would you be willing to talk your experiences with SDCC? I'm curious.
I didn't end up doing anything with it, I looked at the bug list and went "yeah hell no". Bugs of the type "using this-sized loop counter to access that-sized array generates invalid code" are simply unacceptable.

It's true that was a couple years ago. There's a chance current sdcc is less bad. However the Alex Kidd point makes me think there hasn't been any noticable progress wrt that.
turboxray wrote: Tue Dec 17, 2019 2:35 pm I meant Assembly. And I also mean hardware - nes video hardware and mapper stuff is convoluted and unnecessarily complex. Yeah, CPU's are a matter of opinion; I find 65x more comfortable than the z80. It feels less restrictive, but it's not like night and day difference. But yeah I wasn't referring to the CPUs.
Yes, Nintendo hardware design sucks. I believe you the SMS is nice in that regard, Genesis is well designed in my experience.

@tokumaru
You enjoy writing asm, but that's not very common nowadays. For someone who wants to make a game that does X for platform Y, "yeah you have to write Z80 asm" is a major obstacle.
User avatar
TailChao
Posts: 11
Joined: Sat Oct 20, 2012 9:44 am
Contact:

Re: I am a turncoat. A simple sprite demo for Sega Master System

Post by TailChao »

tepples wrote: Tue Dec 17, 2019 9:51 pm There are 70 lines of vblank, and VRAM updates are allowed to extend past vblank so long as you avoid (or tolerate) tearing and don't write twice in (I think) 26 cycles. I satisfied the latter constraint just by moving some inc hl instructions around. Overall, the architecture appears to encourage the sprite cel streaming that Battletoads and Haunted: Halloween '85 for NES are known for.
I'd argue streaming new data to VRAM is necessary since you lose a good amount of patterns to allocating the background map (even more if that's plural). Your loader (and technique) looks fine, my only concern would be the impact of stacking bidirectional scrolling, palettes, more characters, bla bla - on top of this. Those 70 lines disappear fast. But again, as a demo on how to use the hardware it's more than fine.

Once you start adding raster effects, loading data during active scan isn't too convenient and then the usual unrolled OUTI vblank transfer becomes necessary. What I found works well is to estimate how far you are into vblank as to switch between a set of fast and trickle transfers, the latter of which anticipate the start of active scan and expect to be kicked out. Then you defer any unfinished transfers to the next vblank.


Obligatory Whining : My only severe gripe with this hardware was the lack of sprite palette control. Flipping I can live without, but this heavily impacts what you can convey to the player within a limited number of drawings. Otherwise it was friendly.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: I am a turncoat. A simple sprite demo for Sega Master System

Post by tepples »

TailChao wrote: Wed Dec 18, 2019 8:14 am
tepples wrote: Tue Dec 17, 2019 9:51 pm Overall, the architecture appears to encourage the sprite cel streaming that Battletoads and Haunted: Halloween '85 for NES are known for.
Your loader (and technique) looks fine, my only concern would be the impact of stacking bidirectional scrolling, palettes, more characters, bla bla - on top of this. Those 70 lines disappear fast.
I dealt with all that in in HH85. This game's VRAM update engine can do up to one VRAM transaction per vblank. This can be scrolling the screen, loading new background tiles, or loading a sprite cel. The game allows up to six characters on screen at once: one player character and five enemies. Actors typically animate on eights (7.5 fps) at their fastest, and most enemies animate slower or don't change cels at all most of the time. This means up to six out of every eight vblanks, but usually only about half, are needed for sprite cel updates. That leaves the other half for the background.

As for two sprites wanting to change cels in the same frame: I've used a few mitigations for VRAM channel congestion. First, many enemies are timed to change cels on a vblank whose lower 3 bits matches the enemy's index into the sprite table. Second, HH85 double-buffers its sprite cels. When the VRAM channel is otherwise idle, it tries to predict each actor's most likely next cel based on the current cel and load that. If an actor wants to switch to a cel that is already prefetched, or the cel loading can fit into the next VRAM update window, it's switched. Otherwise, the sprite just keeps displaying the same cel. I haven't done any statistics on how often a sprite cel load was delayed, but it didn't cause too much of a visible problem in-game.
TailChao wrote: Wed Dec 18, 2019 8:14 am My only severe gripe with this hardware was the lack of sprite palette control. Flipping I can live without, but this heavily impacts what you can convey to the player within a limited number of drawings. Otherwise it was friendly.
You mean for things like flashing an enemy's palette when it receives damage?
User avatar
TailChao
Posts: 11
Joined: Sat Oct 20, 2012 9:44 am
Contact:

Re: I am a turncoat. A simple sprite demo for Sega Master System

Post by TailChao »

tepples wrote: Wed Dec 18, 2019 9:21 am I dealt with all that in in HH85...
Sure, and that's a fine approach to apply here if the visuals are designed for this update style. The only drawback I can think of is if your animation timing isn't even (i.e. heavy use of smears which last two or three frames). Otherwise no problem.

tepples wrote: Wed Dec 18, 2019 9:21 am You mean for things like flashing an enemy's palette when it receives damage?
That would be one example, yes. Some of the library uses nice substitutes, but having the ability to use either palette for sprites would have been preferred.
turboxray
Posts: 348
Joined: Thu Oct 31, 2019 12:56 am

Re: I am a turncoat. A simple sprite demo for Sega Master System

Post by turboxray »

Regarding the sprite palettes; that's one thing I never understood with Sega and the SMS or MD. I mean, sure the NES is 2bit pixels but it has 8 palettes! Arcades at the time, even Sega's own 8bit and 16bit, had up to hundreds of palettes. It seems such a small thing to skimp, especially considering palette 'animation' (like flashing, water/fire, etc) was a popular cheap animation trick. I mean, the SMS wasn't Sega's first home gaming console either.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: I am a turncoat. A simple sprite demo for Sega Master System

Post by tokumaru »

Palette cycling effects (waterfalls, fire, blinking lights, etc.) have little to do with the number of palettes, because the colors are changed in place. What the lack of palettes prevents you from doing is palette swaps (enemies with the same graphics but different colors, Mario's invincibility, some characters charging their attacks, flashing projectiles, etc.).
turboxray
Posts: 348
Joined: Thu Oct 31, 2019 12:56 am

Re: I am a turncoat. A simple sprite demo for Sega Master System

Post by turboxray »

tokumaru wrote: Wed Dec 18, 2019 1:12 pm Palette cycling effects (waterfalls, fire, blinking lights, etc.) have little to do with the number of palettes, because the colors are changed in place.
If you're limited to one palette, then colors have to be reserved in said palette for cycling. If you're using 4 colors reserved for animation(water for instance), then you've just reduced your total colors from 16(15) down to 12(11). That's significant. That single palette is greatly impacted. If you have 2,3 or 4 palettes, then it isn't that significant (and you could easily use more than 4 colors).
What the lack of palettes prevents you from doing is palette swaps (enemies with the same graphics but different colors, Mario's invincibility, some characters charging their attacks, flashing projectiles, etc.).
It doesn't prevent you, it just lowers your color count per object to enable the same effect; you simple region out the palettes into groups of 3 or 4 sets or whatever (quite a number of Genesis games do this too). 3 sets gives you 5 individual colors per object. Better than 3 on the NES, but nowhere near as nice as the 15 capable.

It affects both situations. I'm just saying, these were common practices before the SMS and at the time of the SMS development.


Tangent: Maybe Sega's design wasn't so much a standard 4bit color tiles/sprite system, but that rather giving the opposite approach of; you're responsible to dividing it until unique colors regions if you want that effect, but you're not limited to a lower color depth with more sub-palettes. But that would mean their design wasn't an absolute "this is a 4bit color tile/sprite system, compared to 2bit systems", but rather "let's not restrict to a setup that focus solely on lower bit-depth paired with lots of palettes". That is, until you realize all the pixel data is 4bit regardless of how many colors your cells use (dividing palette into regions). Then that idea seems a little absurd considering the amount of vram you have on the SMS (wasting 4bits per pixel to show only 4-6 colors per sprite?).
Last edited by turboxray on Thu Dec 19, 2019 3:16 pm, edited 1 time in total.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: I am a turncoat. A simple sprite demo for Sega Master System

Post by lidnariq »

I think they just hewed a little too close to the original TMS9918 design. If they'd figured out how to add an attribute byte, perhaps by having the SAT in mode 4 behave differently from modes 0-3, it would have helped greatly.

As far as adding more palettes... In the 2C02, the largest single area is (overwhelmingly) the OAM DRAM and its controller, while in the TMS9918 and SMS all that is just stored in the same RAM that holds tiles and nametables. The palette RAM isn't exactly big, but it did get boxed in by all the other functionality around it.
2c02-regions.png
Edit: See also nesdevwiki:File:Ppuareas.png.
Last edited by lidnariq on Mon May 18, 2020 7:51 pm, edited 1 time in total.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: I am a turncoat. A simple sprite demo for Sega Master System

Post by tokumaru »

turboxray wrote: Thu Dec 19, 2019 10:40 amIf you're limited to one palette, then colors have to be reserved in said palette for cycling. If you're using 4 colors reserved for animation(water for instance), then you've just reduced your total colors from 16(15) down to 12(11). That's significant. That single palette is greatly impacted. If you have 2,3 or 4 palettes, then it isn't that significant (and you could easily use more than 4 colors).
Of course it makes a difference when comparing the SMS to systems with multiple large palettes (MD, SNES), but I'm comparing the SMS to the NES, which has multiple small palettes, which add up to an equivalent number of total colors on screen. Color cycling isn't any more expensive on the SMS than it is on the NES, and I'm sure it was done abundantly in both systems.
It doesn't prevent you, it just lowers your color count per object to enable the same effect; you simple region out the palettes into groups of 3 or 4 sets or whatever (quite a number of Genesis games do this too).
But then you can't use the same character data, you have to spend extra tiles for each recolor, and that's why I said it prevents palette swaps: you're not swapping palettes at all, you're completely redrawing the graphics to use other colors. This is specially troublesome on the SMS, where a significant part of VRAM is used for things other than tiles, and sprite tiles can't be flipped.
Drag
Posts: 1615
Joined: Mon Sep 27, 2004 2:57 pm
Contact:

Re: I am a turncoat. A simple sprite demo for Sega Master System

Post by Drag »

I never knew the SMS had these kinds of limitations (I only knew about the lack of sprite flipping), and it really makes me appreciate what the NES afforded its developers. Now I want to go back and see how certain games (like the SMS Sonic and Mickey Mouse games) handle their vram.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: I am a turncoat. A simple sprite demo for Sega Master System

Post by lidnariq »

The MEKA debugging emulator is really nice.
Post Reply