http://cinemassacre.com/2014/12/12/alf- ... game-nerd/"But why is it that everytime Alf turns around he disappears for a brief instant"
Is that because the SMS doesn't have sprite flipping, so the animation frames of Alf facing the other way are being written to vram? That's some sloppy programming if so.
Here's the Youtube version for those who prefer that source:
https://www.youtube.com/watch?v=TCcB0iUvU_YThere are plenty of SMS games (ex. Golvellius, Shinobi) where the SMS's lack of sprite X/Y flip capability doesn't hinder the experience in any way when changing the direction the player is facing, so my guess is that it's just sloppy/lazy coding compounded with running out of tile space. Someone would need to actually run the thing under a decent emulator (read: one with good debugging capability) to see if that's the case.
Either way, Alf ideally shouldn't "blink", and especially for how long he does: multiple frames, and I'd guess 2-4 from the look of it (does the SMS use 240p like the NES?). It's not even something like sprite rotation (like what's commonly used on the NES to "overcome" the 8-per-scanline limitation).
We've discussed the SMS's lack of sprite flip capability before:
viewtopic.php?f=2&t=5850 -- tokumaru has some good insights there.
That game is pretty horrible in general though -- you can't see it from the AVGN video, but the music slows down during areas where there's a lot of processing going on (probably someone having to skip frames because of doing too much outside of NMI) -- see around 1:27 or so --
https://www.youtube.com/watch?v=Ox8aKg4XElc . And be sure to watch around 2:10 or so: the divers attacking Alf, as well as Alf himself, flip vertically without any flicker. The same, but horizontally, when he's in space (see ~5:50). Both space and the underwater parts have significantly less graphics on-screen, so that would support my "they ran out of tile space and are having to copy lots of data around in RAM and back" theory. (Or maybe even from ROM, but then we get into pondering how much ROM space was available vs. how much the company wanted to spend, and if they used software compression).
And the ending is so disappointing and awful for such a painful game.
Ha! I kill me!Footnote, probably unrelated: I still think it's super weird how on the SMS there's 64 bytes of unused (or "undocumented") data in the middle of the sprite attribute table, especially since the table is only 256 bytes to begin with. One doc even says "use it for whatever you want!" and I'm just like "?!?!?!?!?!"
Yeah, the SMS is bonkers. No sprite flipping and no mid-field vertical scroll writing (meaning driving games can't have smooth hills.)
And ALF...... programmed in Borland Pascal by programmers weaned on the PC-XT, mayhaps?
Meka has great debug tools. Use the tile viewer to see what happens when you turn left and right. I would guess that the long pause is the result of loading tiles for several frames of animation, instead of only the frame that will be used next. With many animation frames loaded at the same time, there isn't enough space to double buffer sprites and prevent glitches (or, in this case, disappearance). Most Master System games prefer to double buffer the main character and constantly load new animation frames. Enemies, however, don't usually have as many animation frames, so they're still loaded in complete sets (which would explain enemies in ALF not displaying the same issues as the title character).
Do any notable Master System games use sprite scaling? The obvious solution for SMS flipping (a bit reverse lookup table) could do scaling (a bit deletion lookup table) with very little overhead, as seen
here where I scale a 32x48 sprite at 15 fps on an NES.
The most notorious part of Alf on Sega Master System is what happens if you buy the Alf Book item.
The item's description says "This will take you back".
When you use the item, it shows you some backstory, then the game restarts. Get it? "Takes you Back!"
tepples wrote:
Do any notable Master System games use sprite scaling?
Well, Earthworm Jim uses the VDP's capability of scaling all sprites by 2x to draw it status bar, but that's probably not the type of scaling you're talking about! =)
Racing games with a 3D perspective (such as Road Rash) are the most obvious candidates for real time sprite scaling.
Dwedit wrote:
The most notorious part of Alf on Sega Master System is what happens if you buy the Alf Book item.
The item's description says "This will take you back".
When you use the item, it shows you some backstory, then the game restarts. Get it? "Takes you Back!"
This made my morning. You're awesome, Dwedit.
It has the Takeshi's Challenge theme. Do you seriously need to know more? (・・ )
Also apparently yes, some enemies trigger the blinking too. Worse, it seems like it can happen fullscreen (i.e. every sprite gets wiped off the screen). And there's tearing on Alf's sprite sometimes (as if his tiles didn't align up). I think it'll be better to not try to understand what's going on, sounds like it would melt many brains in the process =P
ccovell wrote:
Yeah, the SMS is bonkers. No sprite flipping and no mid-field vertical scroll writing (meaning driving games can't have smooth hills.)
...and yet they decided to build the SMS port of Hang-On directly into the system.
...by getting rid of hills. OutRun had hills and it didn't fare well. (Road Rash also had them but they were software rendered, and if it wasn't for the lack of FM support it'd be hard to tell apart from its 16-bit counterpart o_O) The fact that horizontal scrolling was limited to 32 tiles didn't help either (the road would bleed from the sides without an easy way to replace the tiles since it's per-line, Road Rash hides this by wasting sprites, OutRun just shows glitches)
The inability to change vertical scrolling mid-screen is because it keeps track of the current line and advances it by 1 per line (the value in the scroll register is only used for the first line). Actually this would also be a problem with the NES if it wasn't because you can outright override the internal state (IIRC you need a different method to set the scroll value in that case).
I think not being able to change vertical position mid-frame is a huge bummer (together with the inability to flip sprites of course) for the SMS. Many games cannot have an informative status bar because of this(especially for games that have vertical scrolling obviously) and have to rely on sprites to display the scores on screen, whereas most of the other information such as remaining number of lives, etc. are missing, forcing players to press PAUSE for vital information. I think some games don't even display the scores in-game at all(Wonder Boy was an example, but at least the necessary health bar was shown). I'm not sure what will happen in a vertically scrolling game if the hardware function of freezing the first row of background tiles is enabled(I think the Window layer of the Mega Drive is a spiritual successor of this) though. As far as I know, while some early games used this function for an easy status bar, most newer games didn't use it, and that it doesn't even work(because that first row of tiles is off the visible display area) for Game Gear games running in the "proper" lower resolution doesn't help.
Still, a "proper" way to have split-screen scrolling without additional hardware(compared to the Famicom where you need to poll sprite 0 hit and/or waste time on cycle counting codes, unless the cartridge's mapper provides another means to doing so; also most of the Famicom games have visible garbages near the screen edges on lines where scrolling is split for... reasons) on the SMS does help. A lot of their games had impressive (at the time) parallax scrolling floor(what will also be used in the arcade game Street Fighter II), especially early games such as Hokuto no Ken and Transbot, which also extended to the Mega Drive versions of Hokuto no Ken (again) and Altered Beast.
Gilbert wrote:
I think not being able to change vertical position mid-frame is a huge bummer (together with the inability to flip sprites of course) for the SMS. Many games cannot have an informative status bar because of this(especially for games that have vertical scrolling obviously) and have to rely on sprites to display the scores on screen, whereas most of the other information such as remaining number of lives, etc. are missing, forcing players to press PAUSE for vital information.
Platformers can usually get away with delayed vertical scrolling in order to have more complete status bars. It worked beautifully for the Mickey Mouse games, which are some of the best in the platform, IMO.
Quote:
A lot of their games had impressive (at the time) parallax scrolling floor(what will also be used in the arcade game Street Fighter II), especially early games such as Hokuto no Ken and Transbot, which also extended to the Mega Drive versions of Hokuto no Ken (again) and Altered Beast.
Aladdin has some of the best effects I've ever seen in an 8-bit game, completing the parallax effect with 3D walls. This only goes on for the first 2 levels it seems, the rest of the game is much more "normal".
tokumaru wrote:
Gilbert wrote:
I think not being able to change vertical position mid-frame is a huge bummer (together with the inability to flip sprites of course) for the SMS. Many games cannot have an informative status bar because of this(especially for games that have vertical scrolling obviously) and have to rely on sprites to display the scores on screen, whereas most of the other information such as remaining number of lives, etc. are missing, forcing players to press PAUSE for vital information.
Platformers can usually get away with delayed vertical scrolling in order to have more complete status bars. It worked beautifully for the Mickey Mouse games, which are some of the best in the platform, IMO.
Quote:
A lot of their games had impressive (at the time) parallax scrolling floor(what will also be used in the arcade game Street Fighter II), especially early games such as Hokuto no Ken and Transbot, which also extended to the Mega Drive versions of Hokuto no Ken (again) and Altered Beast.
Aladdin has some of the best effects I've ever seen in an 8-bit game, completing the parallax effect with 3D walls. This only goes on for the first 2 levels it seems, the rest of the game is much more "normal".
That's true about not having the mid-screen vertical scrolling, but I thought a certain region of the screen could be defined to be immobile specifically for things like status bars. Am I thinking of a different Sega system? (I am not referring to the Mega Drive's Window layer)
Yeah, you can define a horizontal piece of the tilemap at the top of the display as none scrolling, to form a window. But IIRC, you can also do this for a vertical 'bar' on the right side as well. No idea how this affects the GG display.
The top two tile rows can be specified to ignore horizontal scroll, and the right eight tile columns can be specified to ignore vertical scroll. They only ignore one of the scroll axes though as far as I know, so this means they're only useful for games that scroll in a single direction (on the other hand, this probably would have helped with the NES a lot if it had that feature...)
As for the Game Gear, well, remember it's basically just the center of the Master System window, so basically those two features end up off-screen and become useless. At least it has the sprite scaling bug fixed (which is why Virtua Fighter Mini takes advantage of it).
Sik wrote:
The top two tile rows can be specified to ignore horizontal scroll, and the right eight tile columns can be specified to ignore vertical scroll. They only ignore one of the scroll axes though as far as I know
Well, this makes the first option pretty useless, since you could very easily mimic the effect with a mid-screen horizontal scroll change, without being restricted to a particular height or position for the status bar. As for the second case, yeah, it seems somewhat useful if you're only scrolling vertically.
Quote:
At least it has the sprite scaling bug fixed (which is why Virtua Fighter Mini takes advantage of it).
What sprite scaling bug? This games was ported to the Master System though (by TecToy, probably), wasn't it? What about Earthworm Jim on the SMS, which uses scaled sprites for its status bar? Do those games fail when played on certain SMS consoles?
BTW, though I should mention an SMS game which used a creative solution for the status bar vs. vertical scroll issue:
YsThe words are sprites, but the meters are background tiles. Since they don't have any vertical details, they can be drawn taller than they need to be and only a section of each is displayed with raster effects. They always start and end at the same screen positions, but the actual tiles are scrolling vertically, which can't be noticed because there are no vertical details.
The same concept could probably be used for more complex status bars, if you used symbols instead of words to indicate what's being measured, and bars, squares, sticks, or anything else without vertical details to measure/count stuff.
tokumaru wrote:
Sik wrote:
At least it has the sprite scaling bug fixed (which is why Virtua Fighter Mini takes advantage of it).
What sprite scaling bug?
Only the first four of the eight sprites on a scanline can be stretched horizontally. This bug is fixed in the SMS 2 and Game Gear. (
Source, beginning at "sprite pixels are zoomed to double")
tokumaru wrote:
Well, this makes the first option pretty useless, since you could very easily mimic the effect with a mid-screen horizontal scroll change, without being restricted to a particular height or position for the status bar.
Except for the part that you avoid having to set up a raster effect, which honestly is a hassle. I mean, what's easier, writing raster effect code that needs to ensure it fires in the correct line as well as undo its effect in vblank, or just setting a bit in a register and forget about it? =P
This is the same deal with the NES, where you need to do a busy loop with the sprite 0 collision flag in order to do a scroll split for a HUD like the one in Super Mario Bros. Want to bet it'd be much easier if it could have been done by just setting a bit?
tepples wrote:
Only the first four of the eight sprites on a scanline can be stretched horizontally. This bug is fixed in the SMS 2 and Game Gear.
So Virtua Fighter Animation has glitched characters and Earthworm Jim has a glitchy status bar on a huge number of Master System consoles? how were games even allowed to use that feature?
Sik wrote:
Except for the part that you avoid having to set up a raster effect, which honestly is a hassle. I mean, what's easier, writing raster effect code that needs to ensure it fires in the correct line as well as undo its effect in vblank, or just setting a bit in a register and forget about it? =P
I do get your point, but personally, I'd rather go though a little more trouble if that meant more versatility (i.e. no size and position restrictions). If I realize that a 2-tile tall status bar at the top of the screen would look worse than a 4-tile tall one at the bottom, I would never settle for the former just because it's easier to implement.
tokumaru wrote:
So Virtua Fighter Animation has glitched characters and Earthworm Jim has a glitchy status bar on a huge number of Master System consoles? how were games even allowed to use that feature?
The Virtua Fighter game is Game Gear only, so it never glitches. As for Earthworm Jim: the problem happens when there's over 4 sprites in the same line, so as long as you don't surpass this limit you're safe. (also if you wonder, this feature wasn't even added by Sega, it was inherited from the TMS9918 which originally had a 4 sprites per line limit, which is why the bug happens - Sega simply didn't take it into account)
tokumaru wrote:
I do get your point, but personally, I'd rather go though a little more trouble if that meant more versatility (i.e. no size and position restrictions). If I realize that a 2-tile tall status bar at the top of the screen would look worse than a 4-tile tall one at the bottom, I would never settle for the former just because it's easier to implement.
Yeah, but most developers who just needed a quick HUD and that were on a tight deadline sure would appreciate it =P
Sik wrote:
I mean, what's easier, writing raster effect code that needs to ensure it fires in the correct line as well as undo its effect in vblank, or just setting a bit in a register and forget about it? =P
What's easier: writing raster effect code once, or setting a bit in a register and then later having to write raster effect code when you port the game from the SMS to the Game Gear, which lacks this feature?
tokumaru wrote:
So Virtua Fighter Animation has glitched characters and Earthworm Jim has a glitchy status bar on a huge number of Master System consoles? how were games even allowed to use that feature?
By ensuring that the stretched sprites are frontmost.
Sik wrote:
most developers who just needed a quick HUD and that were on a tight deadline sure would appreciate it
That or just copy the HUD code from the same studio's previous project.
tepples wrote:
What's easier: writing raster effect code once, or setting a bit in a register and then later having to write raster effect code when you port the game from the SMS to the Game Gear, which lacks this feature?
When you're porting to Game Gear you're going to need
a lot more than that since the screen is much smaller in the first place (to the point that you probably can't afford having a scroll-based HUD and you'll have to go with sprites instead).
Sik wrote:
The Virtua Fighter game is Game Gear only, so it never glitches.
I'm pretty sure TecToy released a game called "Virtua Fighter Animation" for the SMS, and a quick search informed me that it's the same game. Was something relevant cut when Mini was converted into Animation?
Quote:
As for Earthworm Jim: the problem happens when there's over 4 sprites in the same line, so as long as you don't surpass this limit you're safe.
Have you even looked at the game before replying? It uses 8 scaled sprites in a row as an improvised status bar, on the GG as well as on the SMS.
Quote:
(also if you wonder, this feature wasn't even added by Sega, it was inherited from the TMS9918 which originally had a 4 sprites per line limit, which is why the bug happens - Sega simply didn't take it into account)
I see, but if they were aware of the bug they shouldn't have allowed developers to use it in Earthworm Jim.
Quote:
Yeah, but most developers who just needed a quick HUD and that were on a tight deadline sure would appreciate it =P
Could be, but that's why I said that I, personally, wouldn't settle for something less than ideal if the ideal is doable. Someone else under pressure might.
Perhaps EWJ detects the original Sega Master System VDP (315-5124) and reverts to a simpler bar than it uses on the bug-fixed VDP in the SMS 2 (315-5246).
Vertical scaling apparently doesn't suffer from the bug.
How does the game look through a Power Base Converter? The Genesis VDP's SMS mode apparently doesn't support scaling at all.
tepples wrote:
How does the game look through a Power Base Converter? The Genesis VDP's SMS mode apparently doesn't support scaling at all.
Nope, in fact that bit was replaced with the 128KB mode toggle (which switches the VRAM bus into 16-bit while in mode 5, albeit that's completely unusable on a stock Mega Drive which only has 8-bit VRAM). Why didn't they leave it as MAG in mode 4 is anyone's guess, they were probably making up space in the die (every other SMS2 improvement is retained as far as I know).
EDIT: oh also I just remembered, all PAL systems use the SMS2 VDP, so in theory PAL-only games don't have to worry about the scaling bug.
As long as we're thinking about Earthworm Jim for SMS, I have a hunch that it shares some code with the Game Boy version. The two look like they play similarly, and share a lot of low-res resources (with the GB ones at a lower depth).
Sik wrote:
EDIT: oh also I just remembered, all PAL systems use the SMS2 VDP, so in theory PAL-only games don't have to worry about the scaling bug.
TecToy releases were intended for PAL-M consoles, which are not really PAL. It's still possible that the consoles released by TecToy had the more recent VDP though, considering that since they only started making consoles a few years after it had already been released in other regions.
Well, later NTSC systems also had the fixed VDP, it's just that in those territories it was kind of useless since you couldn't rely on everybody having it. But on other places it was a safe bet, to the point that Codemasters would always use the 224 height resolution instead of the 192 one (I wonder if they were even aware that the 224 one wasn't present in all consoles).
But yeah, it's likely that TecToy's systems were using the fixed VDP. I'm not sure if they were using PAL-M though (Brazil is next to a PAL-N territory after all, many TVs were NTSC + PAL-N + PAL-M compatible, and they also sold consoles in Argentina which is a PAL-N territory).
Sik wrote:
I'm not sure if they were using PAL-M though (Brazil is next to a PAL-N territory after all, many TVs were NTSC + PAL-N + PAL-M compatible, and they also sold consoles in Argentina which is a PAL-N territory).
All video game consoles officially released here output PAL-M (even if that means stuffing a transcoding board inside an otherwise NTSC console, as was the case of the Atari 2600 and the NES), that's for sure. PAL-N wasn't common around here at all... AFAIK, TVs only started supporting all 3 standards in the late 90's.
I must admit I don't know what the deal is with SEGA consoles exactly, since they don't have a transcoding board like some other consoles do, but since the VDP outputs signals that are converted into composite by another chip, there's probably something going on with that chip.
Alright, or maybe it was actually being converted by the RF unit (which is separate). Although that leaves composite - but then again, if the TVs supported NTSC it was probably easier to just output NTSC then. I know that in Argentina TVs became able to support both NTSC and PAL-N because VHS players were imported from the US and thereby NTSC, but the local TV signal was PAL-N, and having TVs support both was the easiest solution to that (eventually later that expanded to supporting PAL-M as well, since that allowed exporting the TVs to Brazil).
Pretty much every Mega Drive I've seen here was NTSC or PAL-N though (or toggled between those when they had a region switch), but if there was a RF unit it'd be always PAL-N (in practice everybody used composite instead). We also got the model 3 which is NTSC-only so it's safe to assume that by that point going NTSC-only was safe in Argentina.
SMS2 VDP is not exclusively used in EU machines, whole variety is represented.
The whole PAL-M, N etc is irrelevant, the only difference is framerate and color subcarrier. Framerate is selectable between 50/60 on all VDP versions and color subcarrier is dependant on the crystal used with the RGB encoder circuit outside the VDP.