Psycho Soldier, what a laughable sluggy peice of crud.

[ZEUSDAZ]

Well after a marathon of requested "Shit Game Time" C64 games we have a CPC one come through,...and It's one of the most god awful sluggy piles of crap I've played in a fair while, I give you the CPC arcade conversion of Psycho Soldier

SHIT GAME TIME REVIEW, PSYCHO SOLDIER:
https://www.youtube.com/watch?v=E3GjnU1q59Y

[Gryzor]

You just can't stand the smooth animation.

[AlexM]

I love your Shit Game Time series but this was even a pain to watch
Keep up the great work!

[eto]

That one has around 3-4 fps. How did they achieve that?

[ervin]

Yes you know it's really bad when you can easily count the fps!

[lmimmfn]

Knew it was going to be terrible performance wise when you can even see the redraw on the menu screen for "Press Fire To Start" , they probably spent more code redrawing that than just using different colours and switching those to black and back again every second or so.
It's a crystal ball for the actual game 

[Axelay]

That one has around 3-4 fps. How did they achieve that?

Rhetorical question?  I mean, it's mostly the usual way, it's a game on CPC coded as if for a spectrum, like most of the slowest games on CPC, with a large, slow software copied back buffer and with some very slow sprite related routines, based on the couple I looked at.

[eto]

No, that was not rhetorical, and thanks for the explanation. 

In this particular case, they must have some kind of additional "slow-down" routine, as it is constantly slow, even when there is only a single sprite on screen. 

[kawickboy]

Was the game released elsewhere than Spain? 

[ZEUSDAZ]

I love your Shit Game Time series but this was even a pain to watch
Keep up the great work!

Just remember, It's me that suffers the most
Glad you enjoy the series!

[ZEUSDAZ]

You just can't stand the smooth animation.

Of course, how did you know I was joking?!

[lmimmfn]

You just can't stand the smooth animation.

Of course, how did you know I was joking?!

I love your Shit Game Time series but this was even a pain to watch
Keep up the great work!

Just remember, It's me that suffers the most
Glad you enjoy the series!

I always enjoy your Shit Game series, keep up the great work!!!!

[Shaun M. Neary]

I actually did fire this up on my Amstrad as I'd never seen it before. Fuck me, this is horrible. I'm surprised it didn't give epileptics nationwide a fit!!

[Axelay]

No, that was not rhetorical, and thanks for the explanation.

In this particular case, they must have some kind of additional "slow-down" routine, as it is constantly slow, even when there is only a single sprite on screen.

Curiosity got the better of me (I mean, just how can you make something so slow?), and yes, it does in fact have a delay routine for the enemy sprite display routine.  When there are no sprites on the screen, it pauses for seven screen refreshes.  It allows for up to 8 sprites and does an idle loop for about 85% of a screen refresh for each sprite not present.  The sprite display routine itself is using about 35% of a screen refresh, a lot less than the delay.  That's still not good for a sprite 144 bytes in size though!  I tried reducing the delay to roughly the same time as the sprite routine and found that as sprites came on, it seemed to be slowing down, so I am just going to guess that extended delay is also allowing for other processes that come in to play with each sprite on screen. (control logic, collisions, whatever)

The other major consumer of cpu time is the software back buffer copy, which is taking around 3.5 screen refreshes.  So between just those two routines, with no enemies on screen, you've got around 10 screen refreshes already.

If you want to see the game with that delay removed, run the game in an emulator with a debugger and set three bytes starting at memory location &5598 to 0.  They should be &CD, &AB, &55 before you make them 0's.  That will start the game much 'faster' (well, noticeably less slow) but also noticeably slow down with each additional enemy appearing.

[lmimmfn]

No, that was not rhetorical, and thanks for the explanation.

In this particular case, they must have some kind of additional "slow-down" routine, as it is constantly slow, even when there is only a single sprite on screen.

Curiosity got the better of me (I mean, just how can you make something so slow?), and yes, it does in fact have a delay routine for the enemy sprite display routine.  When there are no sprites on the screen, it pauses for seven screen refreshes.  It allows for up to 8 sprites and does an idle loop for about 85% of a screen refresh for each sprite not present.  The sprite display routine itself is using about 35% of a screen refresh, a lot less than the delay.  That's still not good for a sprite 144 bytes in size though!  I tried reducing the delay to roughly the same time as the sprite routine and found that as sprites came on, it seemed to be slowing down, so I am just going to guess that extended delay is also allowing for other processes that come in to play with each sprite on screen. (control logic, collisions, whatever)

The other major consumer of cpu time is the software back buffer copy, which is taking around 3.5 screen refreshes.  So between just those two routines, with no enemies on screen, you've got around 10 screen refreshes already.

If you want to see the game with that delay removed, run the game in an emulator with a debugger and set three bytes starting at memory location &5598 to 0.  They should be &CD, &AB, &55 before you make them 0's.  That will start the game much 'faster' (well, noticeably less slow) but also noticeably slow down with each additional enemy appearing.

Well that's one way to address slowdown!!!!

[Shaun M. Neary]

To be fair, the Dro Soft version of Double Dragon plays slower than this, so it's possible to top it!

[ervin]

No, that was not rhetorical, and thanks for the explanation.

In this particular case, they must have some kind of additional "slow-down" routine, as it is constantly slow, even when there is only a single sprite on screen.

Curiosity got the better of me (I mean, just how can you make something so slow?), and yes, it does in fact have a delay routine for the enemy sprite display routine.  When there are no sprites on the screen, it pauses for seven screen refreshes.  It allows for up to 8 sprites and does an idle loop for about 85% of a screen refresh for each sprite not present.  The sprite display routine itself is using about 35% of a screen refresh, a lot less than the delay.  That's still not good for a sprite 144 bytes in size though!  I tried reducing the delay to roughly the same time as the sprite routine and found that as sprites came on, it seemed to be slowing down, so I am just going to guess that extended delay is also allowing for other processes that come in to play with each sprite on screen. (control logic, collisions, whatever)

The other major consumer of cpu time is the software back buffer copy, which is taking around 3.5 screen refreshes.  So between just those two routines, with no enemies on screen, you've got around 10 screen refreshes already.

If you want to see the game with that delay removed, run the game in an emulator with a debugger and set three bytes starting at memory location &5598 to 0.  They should be &CD, &AB, &55 before you make them 0's.  That will start the game much 'faster' (well, noticeably less slow) but also noticeably slow down with each additional enemy appearing.

Thanks for the insight Axelay, very interesting.
I can't believe it was coded in that fashion, and released in that state.

Just setting those 3 bytes to zero makes a big difference, but it's still terrible.