Psycho Soldier, what a laughable sluggy peice of crud.

Started by ZEUSDAZ, 01:05, 27 July 22

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

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 :picard:

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

Gryzor


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" :picard: , 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  :D
6128 for the win!!!

Axelay

Quote from: eto on 12:59, 27 July 22That 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

Quote from: AlexM on 10:35, 27 July 22I 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 :laugh:
Glad you enjoy the series!

ZEUSDAZ

Quote from: Gryzor on 10:34, 27 July 22You just can't stand the smooth animation.
Of course, how did you know I was joking?! :laugh:

lmimmfn

Quote from: ZEUSDAZ on 03:12, 28 July 22
Quote from: Gryzor on 10:34, 27 July 22You just can't stand the smooth animation.
Of course, how did you know I was joking?! :laugh:

Quote from: ZEUSDAZ on 03:11, 28 July 22
Quote from: AlexM on 10:35, 27 July 22I 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 :laugh:
Glad you enjoy the series!

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

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!!
Currently playing on: 2xCPC464, 1xCPC6128, 1x464Plus, 1x6128Plus, 2xGX4000. M4 board, ZMem 1MB and still forever playing Bruce Lee.
No cheats, snapshots or emulation. I play my games as they're intended to be played. What about you?

Axelay

Quote from: eto on 18:46, 27 July 22No, 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

Quote from: Axelay on 16:38, 28 July 22
Quote from: eto on 18:46, 27 July 22No, 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!!!!
6128 for the win!!!

Shaun M. Neary


To be fair, the Dro Soft version of Double Dragon plays slower than this, so it's possible to top it!
Currently playing on: 2xCPC464, 1xCPC6128, 1x464Plus, 1x6128Plus, 2xGX4000. M4 board, ZMem 1MB and still forever playing Bruce Lee.
No cheats, snapshots or emulation. I play my games as they're intended to be played. What about you?

ervin

Quote from: Axelay on 16:38, 28 July 22
Quote from: eto on 18:46, 27 July 22No, 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.

Powered by SMFPacks Menu Editor Mod