AndyC wrote: ↑Thu Mar 09, 2023 9:57 am
Not really. If you play JSW2 then play JSW, it's obvious how much more sluggish the original game is. The fact that jumps need to be frame perfect doesn't really matter because the sped up JSW2 still has the exact same frames, there is just less delay between them. If it weren't for the downgrade in colours, it would easily be the better version.
Even at 12.5fps, Jet Set Willy is an already difficult game for those who don't have thirty-odd years of muscle memory to draw upon. The average human reaction time is around 200-250ms so actually hitting an exact frame requires you to anticipate it somewhat, and running at a higher frame rate without any compensation for the timing makes it harder.
I'd think that JSW2 is still the better game for other reasons, particularly that you don't have to collect every last item and so can skip some of the more exacting parts.
Matt_B wrote: ↑Thu Mar 09, 2023 10:47 pm
Even at 12.5fps, Jet Set Willy is an already difficult game for those who don't have thirty-odd years of muscle memory to draw upon. The average human reaction time is around 200-250ms so actually hitting an exact frame requires you to anticipate it somewhat, and running at a higher frame rate without any compensation for the timing makes it harder.
Honestly, it doesn't. JSW and MM at 25fps is a lot more playable. But then "frame exact" in both of them is largely about positioning Willy on the right frame and then jumping at about the right time, more often than not. It's only some of the insane fan mod versions that typically require dodging enemies when they're on specific frames. The CPC version runs like that and I'm sure there was a hacked Speccy version that removes several of the redundant copying it does and got the frame rate up to that too.
At 25fps it feels more comfortable and it's a lot easier to get into a rhythm. I don't think you'd want it to go any faster than that, because then it would start to feel too quick - unless you could insert intermediate animation frames on everything.
I should mention that in the case of JSW2/MM I was kind of spoilt, as the CPC versions of both were indeed the Miner Willy games I played first, that was in 1985. I didn't get Speccy JSW1 until a few months later, and I hadn't even been aware that the CPC JSW I had been playing was an upgraded game as the "2" in the in-game logo isn't that easily visible and we didn't have an original.
So when I finally picked up JSW for the Speccy, I was a bit disappointed to see it had less rooms (and then there obviously was the Attic bug). At the time I didn't even notice the lower frame rate that much.
I suppose an obvious one would be Dragon's Lair. That the version that appeared on the Amiga a few years later needed six disks probably shows the size of the task. Also, it was released by Software Projects, a company that wasn't known for arcade conversions.
That none of the companies with a track record for arcade conversions (Ocean, US Gold, Activision etc.) touched it probably says a lot. Not only that but Elite tried to do a Dragon's Lair type game with Scooby Doo and look how well that went.
I feel sorry for the professional Speccy programmers from the late 80s onwards. By then, arcade games had moved on with more advanced hardware, the 16-bit home computers were able to reproduce them somewhat reasonably, and these were the games most gamers wanted.
The types of games that the Spectrum was best suited to were seen as somewhat "old hat" by this time, and the result was a lot of games that struggled on the Spectrum. I'm thinking of the games mentioned in this thread, plus maybe games like P47 Phantom Fighter, Double Dragon, U.N. Squadron. Even games that are generally well received, like Midnight Resistance (IMO).
There were exceptions, games that were developed with the Spectrum abilities in mind and were brilliant - Target Renegade etc. And of course there were still some miracles like Chase HQ that had no right to be so good.
In modern times we see brilliant Spectrum games being developed, and many of them are of a style we saw in the mid 1980s, and are all the better for it.
XTM wrote: ↑Thu Mar 09, 2023 5:52 pm
Yes, I made a generalization about most Speccy games being fairly jerky when compared to the arcade "standard" of graphics updating 50 times a second, which you very rarely saw in Speccy games, especially when scrolling was involved (one rare example for a game with scrolling would be the game "Sidewize"). The earlier Ultimate games were kinda interesting as they had smooth sprites, but they didn't seem to use the HALT command to sync things so there was some flicker. But in general you just didn't see smooth movement like this very often. I've done some demo coding in the past on the Speccy so it's not like I don't know what I'm talking about - I understand why this was impossible for most games.
Agreed! I know it's not always possible on the Spectrum, but getting the player's sprite running at 50 fps (even if the other sprites update less often) really helps give the game an "arcadey" feel with a more responsive and playable experience, in my opinion. It was something that I made a priority when writing Quadron, as it is in my next game.
Those earlier Ultimate games with their smooth movement were so impressive back in 83. How did they sync the main character's movement to maintain 50 fps without the use of HALT (or interrupts presumably) on a 16K machine?!?
Cosmium wrote: ↑Mon Mar 20, 2023 1:17 am
Those earlier Ultimate games with their smooth movement were so impressive back in 83. How did they sync the main character's movement to maintain 50 fps without the use of HALT (or interrupts presumably) on a 16K machine?!?
They didn't. They just drew sprites from the bottom up, so they wouldn't get into any beam-racing situations. Instead, you just get a single-frame twinkle when a sprite is being drawn across the beam, which isn't very noticeable.
Matt_B wrote: ↑Mon Mar 20, 2023 1:36 am
They didn't. They just drew sprites from the bottom up, so they wouldn't get into any beam-racing situations. Instead, you just get a single-frame twinkle when a sprite is being drawn across the beam, which isn't very noticeable.
One more thing is that they erase and redraw each sprite one by one, and not let's say 'erase all -> draw all'. So at worst only the currently-erased sprite would flicker a little, but not all of them at once. This falls under the general approach that can be described as 'do as little unnecessary changes as possible as you update the screen'. Variations of this are used by quite a few games on the Speccy. It's a natural way to do it with XOR-based sprite drawing, which I think is one of the reasons it is favored by many coders (e.g. Rafaelle Cecco). Jonathan Cauldwell's games erase and redraw the same sprite in its old/new positions in parallel line by line (again using XOR). Batty uses a complicated 'per-sprite buffer' method that basically does the same thing but for masked sprites vs tile background. Et c.
Matt_B wrote: ↑Mon Mar 20, 2023 1:36 am
They didn't. They just drew sprites from the bottom up, so they wouldn't get into any beam-racing situations. Instead, you just get a single-frame twinkle when a sprite is being drawn across the beam, which isn't very noticeable.
Nienn Heskil wrote: ↑Mon Mar 20, 2023 3:41 am
One more thing is that they erase and redraw each sprite one by one, and not let's say 'erase all -> draw all'. So at worst only the currently-erased sprite would flicker a little, but not all of them at once. This falls under the general approach that can be described as 'do as little unnecessary changes as possible as you update the screen'. Variations of this are used by quite a few games on the Speccy. It's a natural way to do it with XOR-based sprite drawing, which I think is one of the reasons it is favored by many coders (e.g. Rafaelle Cecco). Jonathan Cauldwell's games erase and redraw the same sprite in its old/new positions in parallel line by line (again using XOR). Batty uses a complicated 'per-sprite buffer' method that basically does the same thing but for masked sprites vs tile background. Et c.
Thanks for the responses. It's an interesting topic. I knew about the line by line xor draw method (and also use it!) but what I was really wondering about wasn't so much sprite flicker, but if anyone knew how those early Ultimate games achieved smooth movement of the player's sprite (giving the impression of being synced to the frame update) on a 16K machine without using HALT (or mode 2 interrupts, presumably) as XTM had mentioned?
For instance, if you look at the main Cookie character moving around, it appears to be pretty well synced to the frame update, moving very smoothly, as if locked to 50 fps. Is it just an illusion with some well timed delay loops giving that impression?
Cosmium wrote: ↑Mon Mar 20, 2023 11:04 pm
Thanks for the responses. It's an interesting topic. I knew about the line by line xor draw method (and also use it!) but what I was really wondering about wasn't so much sprite flicker, but if anyone knew how those early Ultimate games achieved smooth movement of the player's sprite (giving the impression of being synced to the frame update) on a 16K machine without using HALT (or mode 2 interrupts, presumably) as XTM had mentioned?
For instance, if you look at the main Cookie character moving around, it appears to be pretty well synced to the frame update, moving very smoothly, as if locked to 50 fps. Is it just an illusion with some well timed delay loops giving that impression?
I agree I think it's really interesting the number of sprite techniques programmers came up with. Just to be pedantic, Jetpac (like other Ultimate games of that era) uses OR to put sprites on screen, not XOR. And they are erased (line-by-line and bottom up as has already been mentioned) by taking the sprite’s graphic, inverting with a CPL instruction (see their code at $7742) which makes a mask they then use to cut the sprite out of the screen. This is why the static spaceships twinkle even when they’re not moving – they have to be drawn and erased constantly too otherwise they’d gradually disappear as they were eaten away as other sprites went through them. I think Commando is another (of loads I'm sure) that uses the same OR to draw and CPL/AND to erase technique. You get the same kind of shimmer when they go over other the big background graphics.
