Was anyone else disappointed with the A1200?

[Retro1234]

If that is true and the Megadrive screen is maximum of 512x512 and thats a big if! the screen probably wraps straight round without any tricks alot easier than on the Amiga.

[vulture]

@Gilbert
I don't think sotb3 has less colours than the first tho

[roondar]

Originally Posted by Gilbert

You're acting like I am attacking the Amiga.

No, I'm trying to point out that your generalisation about what was and was not possible or seen on the machine is an exaggeration. That is all.

But for anyone who owned a 60Hz SNES or MD at the same time as an Amiga, the differences were obvious.

Comparing an NTSC machine to a PAL one is always going to skew the result. That said, I never said the A1200 was better for pushing sprites than the MD/SNES were. However, there is more to 'power' than number of objects pushed. The A1200, though it gets a lot closer than the A500, is generally worse for 2D action games than the MD/SNES. It's generally better for other types of games.

Surely Mega Tyhphoon multiplexes sprites?? Im sure you can get 128(?) hardware sprites on screen if you multiplex Amiga sprites - although only 8 per line. But in a vertical scroller this is very useful. Also it might pre-shift bitmap objects for speed which obviously uses up memory that you could store other sprites in. Would be interested to see how it does it. And of course limiting number of bitplanes for each object means less colours but more speed

Most objects in Mega Typhoon are actually bobs. Only the player and it's shots are sprites. And thanks to the Amiga sprite HW, it is indeed really easy to multiplex sprites in the way done here as multiplexing is directly supported by the hardware (meaning you don't even need special tricks to do simple multiplexing of sprites).

I'm not a megadrive programmer but you must be able to multiplex MD sprites too? The fact they haven't done it proves my point - that MD coders didn't bother optimising every cycle because they had a lot of sprites to play with already. On the Amiga you have to spend time using all sorts of tricks. A lot of Amiga games didn't even use sprites because they couldn't be bothered learn how to do even that!

The MD can multiplex sprites, but it is relatively hard to do. That said, I don't fully agree. Musha shows that the system could not display all sprites the developers wanted so they resorted to flashing certain sprites on and off. This trick was used in multiple MD games, usually for player bullets.

As for programming sprites on the Amiga, they're actually easier to use than bobs. Again, I'm not trying to say the Amiga is generally better at pushing sprites. I'm saying the notion you have to resort to complicated tricks and optimising every cycle to get a reasonable number of objects on screen is wrong (though this will, naturally, depend on what you find a reasonable number).

Musha is not a one off - Mega Typhoon is. Most schmups on Amiga don't even run 50fps. It's like saying Shadow of the Beast (which looks amazing) is an example of all Amiga arcade games - it's not because it's designed in a very specific way around the hardware with a lot of restrictions. When Relections made the sequels - they added more gameplay + freedom and couldn't keep all the fancy tech and had to reduce the colours a lot.

There are quite a few 50Hz games on the Amiga, including SHMUPS. Now, it is true that there are more non-50Hz games on the Amiga than there are 50Hz ones. I'm not denying this, though I'm fairly certain you and I might not agree as for the reasons behind that*. All I'm trying to say is that statements like 'MT is a one-off' are not true.

As for Shadow of the Beast, I'm puzzled here a bit. SOTB 2 did feature a different look and toned down the parallax, but SOTB 3 actually is very similar to SOTB 1 in terms of tricks, palette swaps, etc. It's actually a bit more interesting from a technical perspective because they keep the parallax on the floor while still allowing you to move up or down, which means they had to to some extra Copper trickery.

*) I get back to this at the end of the post

But aren't consoles character (tile) based? So you just smooth-scroll the screen a bit then redraw the whole screen (using internal map data) with hardware? That's what I always assumed. I'm too lazy to look up how it's done!

I could explain this if you want (suffice to say that you normally don't redraw the whole screen on any system unless you have no choice), but this might not be the place. My posts are usually too long as is.

Lol it's not false information.

Yes it is. You made two claims regarding multi-directional scrolling. The first was that it took years to be developed and the second was that it was really complicated to do.

Well, the first examples of multi-directional scrolling games on the Amiga are from 1987. That is not years after the Amiga's release and by good fortune just so happens to coincide neatly with the launch year of the first Amiga that was actually aimed at gamers (the A500).

As for the second point: there are two ways to do (multi-directional) scrolling. The first is indeed somewhat complicated and perhaps it took people longer to figure it out than I thought. The second method however, is much simpler and was already used in consoles (and on the Atari 8-bit). Claiming that coders couldn't cope with something they were already doing in a different form just doesn't feel correct. Case in point: I once coded a full screen scroll on the C64 for a long abandoned project. I found it way easier to get one working on the Amiga, though perhaps I just got more skilled at writing assembly in between - that is certainly possible.

Read David Jones article in Amiga Format on how he made Menace and the hardware scrolling technique he used. It took a long time to get to the technique they used in later games.

I did that ages ago but thanks for reminding me. Always liked segments like that. Anyway, I read it again and he's actually saying what I'm saying: scrolling on the Amiga is fairly easy to do with the hardware. He then shows his method, which is the easier of the two methods for scrolling. This method is rather similar to how scrolling is generally done on the NES.

Like I said Exile was one of the first that had proper 8 directional hardware scrolling. And the coder it took him ages to get it working. So you got it working in 2 days - was everyone else programming in the 1980s less intelligent than you then? I mean I know the accepted technique now only because I googled it a few years ago. I was so happy to find it out.

No, I'm not saying I'm more intelligent than coders in the 1980s. That is not what I'm trying to say at all.

I'm trying to show that there are other reasons than it being super complicated that there were few of those games about. I'll admit I've not done this in the clearest of ways, but here goes. The point is that in the mid 1980s, most games did not use multi-directional scrolling (on any platform). When these games got more and more popular, we also started seeing them on the Amiga. This did not take years and years.

The second issue here is that games on the Amiga were initially often ports from lesser systems and/or done in a rush by companies that just wanted something out of the door yesterday. It took a while for dedicated individuals such as David Jones to appear.

I don't get what you mean about blitting with hardware scrolling because you missed out steps where you remove the bobs or restore the background.

Nope, that is included

I didn't call out any Amiga game that it does worse than consoles. I was saying the A1200 could make a game to the standard of a Megadrive game. You then produced 3 games that showed a lot of objects on screen at 50fps. Every scrolling Megadrive game runs at 50fps. I mean I could probably produce 3 that don't run at 50fps...

I don't really understand your point here. You originally said "On the Amiga you have to work hard to get a full-screen game scrolling with a lot of objects/sprites at 50hz.".

I pointed out that there are a whole bunch of 50Hz games on the Amiga that do this and proceeded to give three examples that show the system is actually surprisingly capable when you do put in more effort. That I only gave three examples does not mean they're the only ones. The fact there are a fairly large number of these games about rather proves that it's clearly not as hard as some think.

The thing that makes discussing this interesting is the large number of 25Hz games on the Amiga.

In my opinion, some people mistakenly believe that all/most of the games that run at this speed do so because the system was simply incapable of better or too hard to program for. I don't agree with that, so here's what I think. On consoles, dropping the frame rate generally doesn't give you any real benefits. You may have more time to do game logic, but you're not going to be able to suddenly show twice the sprites. On the Amiga however, dropping the frame rate directly increases the number and size of objects you can show.

This means that developers were actually 'rewarded' for lowering the frame rate. Couple this with the home computer market were most systems struggled to do 50Hz games to begin with, a market where Amiga owners were (at least initially) fine with buying games that ran at 25Hz and the marketing appeal of screenshots that looked really busy and it becomes easy to see why it's such a seductive choice to make. As a bonus, it also means you can be much less efficient in how you write your code.

Add to that the slew of early ST ports and stuff from Tiertex etc and you end up with the impression the system can't do much better. But that's mostly false: there are enough examples to the contrary to show the Amiga can in fact do it just fine. Examples like Menace, which was essentially coded by a (at that point) teenager who wanted to create something really nice. To me examples like Dave Jones show it clearly was doable for someone with fairly small resources (which is in no way a dig at him, I have great respect for him and the way he released the source code for others to see).

[roondar]

Originally Posted by Retro1234

If that is true and the Megadrive screen is maximum of 512x512 and thats a big if! the screen probably wraps straight round without any tricks alot easier than on the Amiga.

https://segaretro.org/Sega_Mega_Drive/Planes
https://segaretro.org/Sega_Mega_Drive/Scrolling

Maximum square size is 512x512, you can scroll up to 1024 pixels (but only if the nametable/plane window is that big). If you want to scroll more than fits in a plane it's up to you as programmer to stream in the new tiles. Wrapping on Sega/Amiga is comparable. On one you reset the bitplane pointers, on the other you reset the plane scroll value. Both require you to set up new data if you want to see something new.

What I said is true. I'm not in this to lie, rather the opposite.

[Retro1234]

Ok the screen probably wraps around horizontal and vertically no need to do anything else no need to move your sprites very simple to scroll endlessly.

[roondar]

Originally Posted by Retro1234

Ok the screen probably wraps around horizontal and vertically no need to do anything else no need to move your sprites very simple to scroll endlessly.

If you don't need more than about two square screens (less actually) of level. Otherwise the answer is still no as the MD does not 'magic' new tiles in place.

Updating bobs/sprites on a scrolling game in the Amiga is not hard. Sprites are independent of the screen so you don't need to know where the screen is and all you do for bobs is add a single static value to the destination address. This value is needed anyway so it's no big deal.

[Retro1234]

it is a big deal, the endless scrolling will be a lot easier than the Amiga no corkscrew and all this and a lot easier for vertical scrolling plus I bet Sega developers got a sample of this code.

[Shatterhand]

The corkscrew thing on Amiga is something that always baffled me. Did they design it this way, or was it a limitation of the hardware? Why the bitmap shitfs 1 pixel when it wraps? If it didn't do that it would be a lot easier to do everything.

[Retro1234]

At a guess when Amiga Hardware scrolling was used and not just an ST port they used the method where you draw tiles in front and behind to create a clone of the screen then scroll again etc.

[roondar]

Originally Posted by Retro1234

it is a big deal, the endless scrolling will be a lot easier than the Amiga no corkscrew and all this and a lot easier for vertical scrolling plus I bet Sega developers got a sample of this code.

You need to move new data in on Sega consoles just as often as on the Amiga. The endless display does not mean you don't have the reset the scroll value or put new data in place. It's not that different.

Calling the requirement to add a single value to bob offsets a big deal genuinely baffles me.

Originally Posted by Shatterhand

The corkscrew thing on Amiga is something that always baffled me. Did they design it this way, or was it a limitation of the hardware? Why the bitmap shitfs 1 pixel when it wraps? If it didn't do that it would be a lot easier to do everything.

It's a way to optimise memory use, no more. If you don't like it, you can create an infinite scroller much like the Megadrive does it: define a bitmap twice as wide as the screen is and draw new tiles on both edges as you scroll along. When you reach the edge, simply update the pointers and you'll be scrolling along again.


This is conceptually very similar to the MD, the only difference is that the MD uses a fine scroll register and the Amiga uses a fine scroll register plus bitplane pointers.

[Galahad/FLT]

Originally Posted by Shatterhand

The corkscrew thing on Amiga is something that always baffled me. Did they design it this way, or was it a limitation of the hardware? Why the bitmap shitfs 1 pixel when it wraps? If it didn't do that it would be a lot easier to do everything.

It shifts 1 pixel to go onto the next line down.

You're essentially scrolling through memory. To scroll horizontally after using the hardware scroll, you add 2 to the bitplane pointers, so at some point, the pointers will be at the next horizontal line to be displayed. Theres no internal hardware counter that resets back to the start of the line you're on.

[Retro1234]

512 isn't even enough for 2 whole horizontal screens, I'm sorry but your blind faith and having to defend everything about the Amiga with walls and walls of text I just dont belive you to be a reliable source.Sorry

[Retro1234]

and this is how console scrolling is done not like on the Amiga The End

https://wiki.nesdev.com/w/index.php/PPU_scrolling

[roondar]

Originally Posted by Retro1234

512 isn't even enough for 2 whole horizontal screens, I'm sorry but your blind faith and having to defend everything about the Amiga with walls and walls of text I just dont belive you to be a reliable source.Sorry

If you don't believe what the Sega Retro (Mega Drive) says, well... Sorry, but that's not my problem. If you had bothered to click the links I provided, you'd have known that 512x512 is (as I said) for a square only. For pure horizontal or vertical scrolling you can do 1024x256/256x1024 instead.

As for 'blind faith'... I've repeatedly and consistently agreed with actual flaws and problems with the A1200 and the Amiga in general. I changed my mind several times when presented with credible facts more than once. In fact, on this very page I've agreed that the A1200/Amiga was limited in sprite capabilities compared to the consoles at least twice. But sure, go on pretending I show 'blind faith'.

Frankly, I simply don't care if you think I'm reliable or not. It won't change the truth value of my claims, which are easy enough to check. I even provided you with my source.

Originally Posted by Retro1234

and this is how console scrolling is done not like on the Amiga The End

https://wiki.nesdev.com/w/index.php/PPU_scrolling

I'll try to keep this brief.

That link shows something very similar in concept to the Amiga's corkscrew method. Seriously.
The main differences (apart from register use) is how you change the part of the window you show and how it's organised in memory. If you understand how to make that work, you'll understand how to make corkscrew work.

[Retro1234]

That is basically the very similar to the corkscrew but not moving down one tile and I bet that works vertically on the Mega Drive as well.

again to be honest this is just crazy and I don't care.

[roondar]

Originally Posted by Retro1234

That is basically the very similar to the corkscrew but not moving down one tile and I bet that works vertically on the Mega Drive as well.

again to be honest this is just crazy and I don't care.

Then what's the problem? Seriously, you're banging on and on about how console scrolling is so much easier and then you turn around and say 'actually, it isn't all that different'. Do note that I never said that scrolling is hard to do on consoles, just that it is similar in concept and that some of the same challenges still apply. I also already said like five times that it is indeed harder to do on the Amiga, just not 'hard'.

I seriously don't get the problem here

[NorthWay]

Originally Posted by Shatterhand

The corkscrew thing on Amiga is something that always baffled me. Did they design it this way, or was it a limitation of the hardware?

I don't think the designers thought it properly through.
Or rather, I'm guessing they expected you to brute-force stuff with the blitter for screen updates. Remember how the design goal was for 15fps cartoon like.

And the thing is, they were half-way there: The modulo registers and ddfstop could have been duplicated so you got a new ddfwrap register where the new wrap0 and wrap1 registers were added to the bitplane pointers. Just doing exactly the same thing the modulo does already.

But hey, you can at least use the copper to do it yourself with AGA!

[roondar]

Originally Posted by NorthWay

Or rather, I'm guessing they expected you to brute-force stuff with the blitter for screen updates. Remember how the design goal was for 15fps cartoon like.

I think they expected you to use the 'double screen with window' method. At least, that is what reading the HRM implies to me.

But hey, you can at least use the copper to do it yourself with AGA!

If you don't mind running in 3BPL you should be able do it under OCS as well using Dual Playfield, a sprite, the Blitter and a bit of finagling. But that, yeah that is complicated and good luck getting it right the first time.

[Shatterhand]

'double screen with window' method

What method is this?

Is it having a 2 screens large bitmap for the scrolling playfield and when you reach its edge you copy that half of the bitmap to the other half and move it back to the beginning? (EDIT: Now I read the thread more properly and saw what you're talking about, sorry!)

Looking at Blitz Basic documentation it looks like that's how they want to me to do scrolling, but not only it wastes a lot of memory, I really don't think copying a whole screen would be fast enough.

I *did* manage to achive proper horizontal scroll on Amiga with Blitz though, thanks to help from this very forum and the called corkscrew technique:

[ Show youtube player ]

I just never did anything with that engine, heh. Maybe someday I'll go back to it and do a "KUNG-FU MASTER INSIDE CAVES" game or something

But no need to use 2 windows, I just have 2 vertical columns more than the total screen width and blit the tiles as the screen moves. It was pretty fast considering the game would never scroll faster than what's shown in the video

It shifts 1 pixel to go onto the next line down.
You're essentially scrolling through memory. To scroll horizontally after using the hardware scroll, you add 2 to the bitplane pointers, so at some point, the pointers will be at the next horizontal line to be displayed. Theres no internal hardware counter that resets back to the start of the line you're on.

Thank you for your explanation. I am actually amazed I understood what you said, though I had to read it twice. Not that you didn't make it clear, its just that I obviously have some difficulty understanding how hardware works sometimes

[roondar]

Originally Posted by Shatterhand

What method is this?

Is it having a 2 screens large bitmap for the scrolling playfield and when you reach its edge you copy that half of the bitmap to the other half and move it back to the beginning? (EDIT: Now I read the thread more properly and saw what you're talking about, sorry!)

Looking at Blitz Basic documentation it looks like that's how they want to me to do scrolling, but not only it wastes a lot of memory, I really don't think copying a whole screen would be fast enough.

No, don't ever copy a whole screen in one go - that's very slow. What you do there is have a bitmap twice as wide as the visible screen and draw new tiles at both sides of the visible part of the screen (i.e. the window) as you scroll through the world. Then you simply point the window back to the start when you reach the end.

But yeah, it does use a lot of memory compared to corkscrew. It was used in plenty of games though as it's a bit easier to intuitively understand how the bitmap is layed out in memory (ironically actually programming both is fairly similar if done in Assembly). An example game that uses this method is Menace (it even had that whole tutorial plus source code in Amiga Format).

I *did* manage to achive proper horizontal scroll on Amiga with Blitz though, thanks to help from this very forum and the called corkscrew technique:

[ Show youtube player ]

I just never did anything with that engine, heh. Maybe someday I'll go back to it and do a "KUNG-FU MASTER INSIDE CAVES" game or something

But no need to use 2 windows, I just have 2 vertical columns more than the total screen width and blit the tiles as the screen moves. It was pretty fast considering the game would never scroll faster than what's shown in the video

I know all about corkscrew scrolling, I was merely pointing out you could do it in a different way if you didn't like using it