Commodore 64 and Amiga 500 video hardware characteristics?

You can talk about almost anything that you want to on this board.

Moderator: Moderators

User avatar
TOUKO
Posts: 306
Joined: Mon Mar 30, 2015 10:14 am
Location: FRANCE

Re: Commodore 64 and Amiga 500 video hardware characteristic

Post by TOUKO »

I have no idea wtf is going on there gameplay wise, but you could accomplish the same thing in the Genesis and SNES (before mode 7) by having prerendered shrunken strips (or at least I think that's how it's done) like in Puggsy or the Lawnmower Man on Genesis.
No really, nothing on snes or MD are close to this one,you have a 8 way multidirectional scrolling with 2 layers,and a realtime boss zooming with lighning effect .

I'am curious to see an effect like this :
https://youtu.be/D3COba64xL4?t=2m54s

or this:
https://youtu.be/D3COba64xL4?t=4m

On Md or snes :mrgreen:
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: Commodore 64 and Amiga 500 video hardware characteristic

Post by psycopathicteen »

Revenant wrote:That's like saying every memorable C64 demo since 1987 "only" worked because of VIC-II glitches, which might be almost technically true, but it also discounts the massive amount of legwork and technical ingenuity it takes to turn a hardware glitch into something that's actually interesting to look at.
I guess that's true. It's just weird that for such an iconic system, there was still so many undocumented features that weren't discovered until 28 years later.

I hope somebody finds a secret register or something in the SNES.
Revenant
Posts: 462
Joined: Sat Apr 25, 2015 1:47 pm
Location: FL

Re: Commodore 64 and Amiga 500 video hardware characteristic

Post by Revenant »

psycopathicteen wrote:I hope somebody finds a secret register or something in the SNES.
There's the one that makes the SPC700 run slower and/or stop working, does that count? :D
93143
Posts: 1715
Joined: Fri Jul 04, 2014 9:31 pm

Re: Commodore 64 and Amiga 500 video hardware characteristic

Post by 93143 »

TOUKO wrote:
I have no idea wtf is going on there gameplay wise, but you could accomplish the same thing in the Genesis and SNES (before mode 7) by having prerendered shrunken strips (or at least I think that's how it's done) like in Puggsy or the Lawnmower Man on Genesis.
No really, nothing on snes or MD are close to this one,you have a 8 way multidirectional scrolling with 2 layers,and a realtime boss zooming with lighning effect .
Multidirectional scrolling is trivial on both SNES and MD. Two layers is trivial on both SNES and MD (indeed, scrolling both layers is trivial on both SNES and MD, and your example doesn't have that). The scaling boss is a bit large for 60 fps perhaps, but the required tileset for everything else is pretty tiny and doesn't change much, so double buffering the scaling boss should be feasible and result in a decent frame rate for the scaling/Z-axis motion (no reason why the X/Y motion shouldn't be 60 fps). The boss is horizontally symmetric and appears to be a bit chunky at the largest scales, which means you could probably use tile flipping and line scrolling to fit it comfortably into a two-frame update on NTSC. The use of line scroll (as well as the fact that the boss can take up basically the entire width of the screen, leaving nothing (on MD) or almost nothing (on SNES) for the HUD and squirrel) would require the boss to use a BG layer, which means the far background would have to be sprites (unless it's 2bpp, which is a great fit for Mode 1 BG3 on SNES), but that's okay because the required coverage is low, and at least on SNES the backdrop gradient is trivial with HDMA - MD would need to use a raster IRQ, but it's still feasible.

The "lighting effect" looks like simple palette animation. Trivial on both SNES and MD.

If my calculations are correct, a modified tepples method on SNES could manage a credible scaling frame rate on that boss without having to store the graphic at all scales. But I haven't gotten very far with this due to being busy with other stuff, so I don't have a solid grasp of the real-life speed attainable with this class of methods. And using such a method on a BG layer is more work than using it on sprites, since you have to render slivers in absolute position rather than just sliding sprites around. If either the HUD or the far background were 2bpp, and the boss were narrow enough to allow the player character to coexist without glitching, maybe using sprites for the boss would work - line scroll is fairly cheap with the tepples method, although it does have to be hard rendered and thus the DMA bandwidth requirement will increase for high zoom levels...

Alternately, you could do what Rendering Ranger did here, and just use sprites for the backgrounds and Mode 7 for the boss - this method (first used in Super Mario World) might not be quite feasible for the exact content shown in your example (there are nearly-full horizontal runs of tiles in the foreground layer), but the scene is at least almost sparse enough to work.
I'am curious to see an effect like this :
https://youtu.be/D3COba64xL4?t=2m54s
I'm not a 3D expert, but that doesn't look out of reach.
...yeah, that's trivial with Mode 7, and I bet Titan could figure out a way on the MD.
psycopathicteen wrote:I hope somebody finds a secret register or something in the SNES.
Ah, yes, the legendary $FEED...
Last edited by 93143 on Thu May 17, 2018 7:57 pm, edited 9 times in total.
User avatar
Drew Sebastino
Formerly Espozo
Posts: 3496
Joined: Mon Sep 15, 2014 4:35 pm
Location: Richmond, Virginia

Re: Commodore 64 and Amiga 500 video hardware characteristic

Post by Drew Sebastino »

Alternately, you could do what Rendering Ranger did here, and just use sprites for the backgrounds and Mode 7 for the boss
I love how the music broke for that level during the longplay. :lol: It even does it on BSNES in occasion, which is really bizzare; it might just be a problem with the game itself, but I don't recall it ever happening playing it in real hardware with my SD2SNES.
93143
Posts: 1715
Joined: Fri Jul 04, 2014 9:31 pm

Re: Commodore 64 and Amiga 500 video hardware characteristic

Post by 93143 »

I've tried Rendering Ranger on real hardware. I got a good playthrough, but when I had my brother play it the whole game glitched out when trying to start up Stage 5 - even the music froze. Kinda disappointing, because he thought it was a pretty neat game up until that point...
User avatar
Drew Sebastino
Formerly Espozo
Posts: 3496
Joined: Mon Sep 15, 2014 4:35 pm
Location: Richmond, Virginia

Re: Commodore 64 and Amiga 500 video hardware characteristic

Post by Drew Sebastino »

Aw man... He just missed one of the cleanest, non low-saturation BG3s in an SNES game.

I think it's a surprisingly solid game for something that's really only known because of its technical prowless and rarity. (Especially considering it was made by a European developer in the 90's. :lol:)

My main problem with the game is that huge ass, 7 hit lifebar... It's not even that it's too lenient either; on hard and the regular number of lives, I barely beat the game. The problem is that in many areas, it's impossible not to get hit; everything just kind of files accross the screen straight into you. It's a real shame that Stage 7, which is easily the most impressive looking in the game (especially with that phenomenal intro), is probably also the worst gameplay wise.
User avatar
TOUKO
Posts: 306
Joined: Mon Mar 30, 2015 10:14 am
Location: FRANCE

Re: Commodore 64 and Amiga 500 video hardware characteristic

Post by TOUKO »

The "lighting effect" looks like simple palette animation. Trivial on both SNES and MD.
Of course, it's a simple palette change, but it's here (axelay did it too ) :wink:

A 8 way scrolling on 2 layers with a near full screen zooming on snes ??,i think is barely doable,mode 7 is useless here and even with precalc,i think you do not have the DMA budget for that,or you must drastically reduce the fram rate .

the boss zoom in pugsy is way simplier than that.
https://youtu.be/jgQCVi6HE6Y?t=2m54s
The scaling boss is a bit large for 60 fps perhaps,
i think the boss is a bg layer, the second BG layer is done by sprites multiplexing .
The zoom is probably done by changing the X/Y harware scrolling, the copper can do it easily,but not at a 1 pixel precision.
I've tried Rendering Ranger on real hardware. I got a good playthrough, but when I had my brother play it the whole game glitched out when trying to start up Stage 5 - even the music froze. Kinda disappointing, because he thought it was a pretty neat game up until that point...
I think it's an awesome game from a technical point of view(manfred did wonder with the 65816), but an average game overall.
The musics except in the level 7 one are bad, and sfx are a bit boring .
Last edited by TOUKO on Fri May 18, 2018 2:45 am, edited 2 times in total.
User avatar
Drew Sebastino
Formerly Espozo
Posts: 3496
Joined: Mon Sep 15, 2014 4:35 pm
Location: Richmond, Virginia

Re: Commodore 64 and Amiga 500 video hardware characteristic

Post by Drew Sebastino »

TOUKO wrote:The musics except in the level 7 one are bad, and sfx are a bit boring.
Oh, really? I'm a bit partial to the metal tunes in this game. :P
User avatar
TOUKO
Posts: 306
Joined: Mon Mar 30, 2015 10:14 am
Location: FRANCE

Re: Commodore 64 and Amiga 500 video hardware characteristic

Post by TOUKO »

Oh, really? I'm a bit partial to the metal tunes in this game. :P
Yeah it's a matter of taste :wink:,this is why for me only the level 7 is good .
93143
Posts: 1715
Joined: Fri Jul 04, 2014 9:31 pm

Re: Commodore 64 and Amiga 500 video hardware characteristic

Post by 93143 »

TOUKO wrote:Of course, it's a simple palette change, but it's here
And? It's such a simple technique that it doesn't really alter the feasibility on SNES/MD. The giant scaling graphic is the only part that's remotely challenging.

You sounded like you were trying to portray this as something clearly beyond the capabilities of the SNES and MD. Is this not what you were trying to say?
mode 7 is useless here
Only for this exact scenario, and only because the foreground layer isn't quite sparse enough to avoid glitching when combined with the player, HUD, and far background if all of them have to be sprites.

...okay, I haven't actually verified that the boss will fit in 256 tiles with no horizontal flipping (this being Mode 7, you can vertically flip the whole picture in between scanlines, so it's possible you could save some tiles on vertically symmetric features). If not, there's a trick that allows a 128x256 4bpp Mode 7 graphic without any compression losses, or potentially even bigger and/or more colourful if the picture compresses well. I think you could get pretty close to what's seen in your example.

Did you watch the Rendering Ranger example? Multiple independently-scrolling backgrounds made of sprites, combined with a Mode 7 boss (complete with palette fade-in). Carefully designed to avoid sprite dropout. Granted the foreground layer is eliminated before the actual fight starts, but that's probably because the player in this case can put out some fairly massive firepower, and combined with the boss' firepower it would have guaranteed glitching. Your scenario seems to lack firepower entirely; it's just the squirrel and the machine.
and even with precalc,i think you do not have the DMA budget for that,or you must drastically reduce the fram rate
This isn't a generic full-screen graphic being scaled. It's a horizontally symmetric, vertically chunky full-screen graphic. That makes a big difference. Besides, even if you did have to drastically reduce the frame rate of the scaling (as you might if you attempted it in software), that wouldn't have to affect the frame rate of the rest of the action.
The zoom is probably done by changing the X/Y harware scrolling, the copper can do it easily,but not at a 1 pixel precision.
Interesting. But I was speculating about how to do it on SNES.

With precomputed graphics it's not hard at all. Considering how chunky the boss graphic seems to be at high zoom, along with the fact that the right side is a mirror flip of the left, I figure it probably doesn't need to be more than about 7-8 KB or so if you use a BG layer for it and repeat lines with HDMA scroll changes. Considering not much else is happening, you could probably update the whole thing in two frames on NTSC, or one frame on PAL (which may actually be the more appropriate comparison). The backdrop is dead simple to do with sprites; it doesn't even move, and coverage is low, but if it's only 2bpp it can be BG3. The foreground stuff can be a normal BG layer, and the HUD can be sprites, or BG3 or a mixture of both if the far background is sprites. The only question is storage, and you can get very fine-grained scaling in a few hundred KB with no optimization or compression, if you're willing to burn that much ROM.

Using precomputed sprites might work too, and it would take far less ROM because a lot of the fine scaling could be accomplished by shifting sprites relative to one another. You'd have to be super careful with sprite priority, though, to avoid massive glitching when scaling vertically - this is one scenario where the SNES has a disadvantage vs. the MD despite its slightly higher overdraw ratio, because it's the frontmost sprites that drop out, so you'd have to dynamically fiddle with sprite priority to keep the player's sprite in front of the sprites behind it, but behind the sprites beside it. Naïvely, DMA bandwidth requirements would seem to be higher than with a BG layer because you can't stretch sprites vertically with HDMA, so the graphics for a given frame take more space, but in practice you'd have several frames to upload the required shrunken sprites because with this scheme you don't need to update the whole mess every frame. You might actually be able to get 60 fps scaling this way. The boss seems to be slightly wider than the screen at its widest point and closest zoom, but if you used window masking instead of opaque sprites to fill, say, the dark part of the jet intakes, you might be able to avoid glitching since there's almost nothing else onscreen.

With a software scaling method, you have compute time to worry about (because all that crazy maneuvering in the previous paragraph is free, right?), and the tradeoffs get more complicated. An efficient quasi-tepples method of the sort I've been considering would involve 16-bit tables, which might actually take up more space than the precomputed BG approach... 8-bit tables are way smaller but constrain the method to be somewhat slower.

Technically it is possible to change H-scroll values during a line, and it would probably work if you used DMA. However, there are at least two reasons why this is a bad idea, possibly three: 1) DMA stalls the CPU, which is very bad in the case of a full-screen effect, 2) DMA is two dots per byte, and the timing alignment inevitably results in a one-dot horizontal offset between scanlines, so it's actually impossible to change a register at the exact same point on all lines, and 3) there's significant lag in the PPU's uptake of scroll values, which may or may not cause unresolvable issues. (I'd mention the 1/1/1 DMA/HDMA clash bug, but if you can pull off a timing-critical raster effect like this you can probably avoid triggering that bug in the process - in fact you can probably just forget about HDMA entirely and use DMA to do the same thing.) So duplicating the effect as you suspect it was accomplished on the Amiga is probably not reasonable on SNES - but as I've suggested above, there are other ways that could produce good results.
User avatar
Drew Sebastino
Formerly Espozo
Posts: 3496
Joined: Mon Sep 15, 2014 4:35 pm
Location: Richmond, Virginia

Re: Commodore 64 and Amiga 500 video hardware characteristic

Post by Drew Sebastino »

The only part where I noticed there would be sprite dropout for certain if you were to use Mode7 is the scoreboard when over that weird grate thing above the starting platform. I don't think any SNES game ever went that hardcore with sprites to fake backgrounds for Mode 7 (well, Cameltry/On the Ball) but I don't see why it couldn't be done here.

Actually, you know what? You could even use Mode 7 for the entire boss other than the top narrow part that reaches the scoreboard, and have only that be prerendered. The scoreboard could then still be BG3 like it would make most sense to be (it's only 2bpp).
Edit: Wait, no, this wouldn't work, because the boss really isn't tied to the screen much at all; if you fall fast enough, the scoreboard goes through the entire thing. I didn't watch it that closely...

Interestingly, Super Turican 2 typically uses BG3 for the status bar, but will switch over to sprites for Mode 7 or if all backgrounds are needed durring those lines. This isn't even an SNES game, but I observed in MAME that Ninja Baseball Batman does the same thing during the second stage when the clouds, large blimp, and bridge use all 3 background layers, so I guess it wasn't too uncommon.
User avatar
TOUKO
Posts: 306
Joined: Mon Mar 30, 2015 10:14 am
Location: FRANCE

Re: Commodore 64 and Amiga 500 video hardware characteristic

Post by TOUKO »

And? It's such a simple technique that it doesn't really alter the feasibility on SNES/MD. The giant scaling graphic is the only part that's remotely challenging.
I agree,but it's not like for exemple with pugsy where the boss stage is a simple zoom with nothing .
If you take this little effect alone, of course it's nothing as i said axelay did it,but it adds to the scene complexity .
Did you watch the Rendering Ranger example? Multiple independently-scrolling backgrounds made of sprites, combined with a Mode 7 boss (complete with palette fade-in). Carefully designed to avoid sprite dropout
Of course i know ,and you have the same in Mr nutz snes:
https://youtu.be/YX_HlhrSdhc?t=47s
With precomputed graphics it's not hard at all
Yes, it's the common and simpliest way, but it relies on how many bytes you can transfert each frame(because this kind of animation cannot sit in VRAM alone).

Thanks for your explanation, it was interesting to read :wink:

I am not saying amiga is the best machine, it's a better machine in some cases, worse in others .
The bitplanes manipulations is a part of his strenght,same as doing effects mid line with the copper which can drive all the chipset without any CPU intervention, but like HDMA on snes, it needs a list done before with the CPU(it's called copper list) .
The copper is in perfect sync with the TV's electron beam .

Look at agony:
https://youtu.be/a839o59Bt4s?t=4m57s
The Md cannot do that (the snes however can),the same with jim power .

The amiga is a 85's technologie, so he is not as powerfull as MD/snes/PCE for sprites intensive games and sub palettes are limited to 2,however it can multiplex his sprites for composing an entire BG layer without any sprites overflow .
The drawback is, it has only 8 hard sprites,of 16 pixels wide but up to 512 pixels high,the sprites colors are limited to 4 (if i remember correctly), and can be 16 if 2 sprites are attached,a bit limiting no ?? .
You can have 2 BG layers, but the colors drop to 3 bits per layer rather than 4 for 1 layer,quite limiting .
Also you have a limited number of DMA cycles each frame, and like the chipmem is slow (it's a 3.5 mhz RAM) you cannot use the chipset at his full set,because if you're using a chip intenselly, this is why if you use a chip intensely, you will reduce the use of other chips.
I don't think any SNES game ever went that hardcore with sprites to fake backgrounds for Mode 7
No, and even not on any consoles of that era because of sprites bandwidth, only the NG did this .
Interestingly, Super Turican 2 typically uses BG3 for the status bar,
Yes the snes has a 3rd BG layer, and even limited in bit per tile, it's quite usefull and for me way better than a BG done with sprites multiplexing.

The titan's guys have touched the amiga's coders's ego and have done a 8 layers checkerboard in OD2 (thanks to them) :mrgreen:
The answer was this :
https://youtu.be/nWJW0O3p1-E?t=41s

up to 13 layers in 332x256 .
93143
Posts: 1715
Joined: Fri Jul 04, 2014 9:31 pm

Re: Commodore 64 and Amiga 500 video hardware characteristic

Post by 93143 »

TOUKO wrote:
Did you watch the Rendering Ranger example? Multiple independently-scrolling backgrounds made of sprites, combined with a Mode 7 boss (complete with palette fade-in). Carefully designed to avoid sprite dropout
Of course i know ,and you have the same in Mr nutz snes:
https://youtu.be/YX_HlhrSdhc?t=47s
That doesn't have any of the features you were talking about. No scrolling, no palette animation/lighting... very convincing fake BG, but it doesn't go anywhere - it's basically just like Super Mario World. The boss isn't even that big. And didn't you say that nothing on SNES is like what you showed? I'm getting mixed messages here.
I am not saying amiga is the best machine, it's a better machine in some cases, worse in others
I agree, it's an impressive machine for its time. And since it works very differently from the SNES (as well as being far more expensive - $1295 for an Amiga 1000 in 1985, and $595 for an Amiga 500 in 1987), it's reasonable to expect that not everything it can do will end up translating perfectly.

But when someone shows me something like this and says it's impossible, something inside me refuses to accept the conclusion without trying to prove it wrong. One time somebody on a different forum posited a Moon-sized object on a 40-year collision course with Earth, the idea being that there would be nothing we could do about it - rather than accept his premise and go along with the line of discussion he wanted, I started speculating about thermonuclear pulse spacecraft and world economic output, whereupon he changed it to a black hole and three days, which I thought was rather rude...
User avatar
TOUKO
Posts: 306
Joined: Mon Mar 30, 2015 10:14 am
Location: FRANCE

Re: Commodore 64 and Amiga 500 video hardware characteristic

Post by TOUKO »

That doesn't have any of the features you were talking about. No scrolling, no palette animation/lighting... very convincing fake BG, but it doesn't go anywhere - it's basically just like Super Mario World. The boss isn't even that big. And didn't you say that nothing on SNES is like what you showed? I'm getting mixed messages here.
i answered to espozo about the boss in RR² .
$1295 for an Amiga 1000 in 1985
I agree, in france the amiga was good only when the 500 goes out and at more or less the same price than atari ST,but it was always way more expensive than a game console .
But when someone shows me something like this and says it's impossible,
I agree even if i tend to also use this word a bit often,but unless somebody do a similar thing, you cannot say it's possible when a machine is not designed for,but the history show us that impossible is something a bit false,or not entirely true .
For exemple, i am sure the MD cannot do agony or jim power in the same way than amiga did ,the snes can because of his 3rd BG layer,but in certain cases, the contrary is also true .
Post Reply