Is Golden Axe slower with CGA than with EGA or VGA?
If the game tries to avoid CGA snow that might be a partial explanation. Maybe some rendering just doesn't fit in the vertical blanking interval so multiple frames are needed.
To check this one would either have to disassemble the game, or try it on a CGA which exhibits snow. (Or is there an emulator that emulates CGA snow?)
wrote:And I can't remember if Golden Axe is playable with floppy disk alone, and if the floppy reading was a factor in those systems.
It's playable using the original two floppies (it'll ask you to switch disks when needed). The only oddity I remember is that the magic attack sprite data isn't loaded before a level starts, so you get an additional delay when you press Shift.
wrote:I am more intrigued by the fact that the game seems about 20x slower on 8 Mhz XTs than on a relatively modest 286.
Can happen when several routines depend on each other to execute in a timely manner - I bet it wasn't even tested on such slow machines during development. Computational complexity's a hell of a drug 😀
wrote:333 cycles seems too slow for a Turbo XT, more like the original 4.77 Mhz XT. I find the MIPS utility more useful in measuring speed in Dosbox seeing as Topbench detected elianda's AMD K5 PR133 machine as a 1.2 Ghz "slocket" Celeron.
Say what? CPU identification can be error-prone, but it's something that MIPS doesn't even try to do, so I wouldn't jump from that to any conclusions about its accuracy in the actual speed tests vs. Topbench.... regardless, MIPS measures 333 cycles as quite a bit faster than an IBM PC/XT.
(Of course, due to the nature of DOSBox there's no real way to perfectly match a real machine's speed.)
wrote:By the way, how do you select the character? I'm pressing every key...
Keypad 5 (which is also the fire button).
wrote:Is Golden Axe slower with CGA than with EGA or VGA?
If the game tries to avoid CGA snow that might be a partial explanation. Maybe some rendering just doesn't fit in the vertical blanking interval so multiple frames are needed.
To check this one would either have to disassemble the game, or try it on a CGA which exhibits snow. (Or is there an emulator that emulates CGA snow?)
All other things being the same, it's *faster* with CGA, since at 2bpp there's less data to copy to video RAM on each frame. (Of course, CGA memory is typically slower than VGA, but not by a factor of four.)
Snow only affects 80-column text mode, so it's not a factor in this case.
How does it run on a 486 then? I don't have a copy so I can't really test it out. 😜
I think a 486 would be massive overkill for this game. Any 286/386 at 16 Mhz or more should be enough for full speed.
wrote:Snow only affects 80-column text mode, so it's not a factor in this case.
I wasn't aware of that. I never experienced CGA snow myself, the XT I started programming on already had EGA graphics (fortunately switchable to full CGA compatibility).
I only noticed the snow issue because Turbo Pascal slowed down screen access to avoid snow unless I told it not to.
I wasn't really around for the CGA era, even though I've played some of the games. Could someone clarify what CGA snow is?
It only occurs in text mode AFAIK.
wrote:I wasn't really around for the CGA era, even though I've played some of the games. Could someone clarify what CGA snow is?
A particularly severe example: http://www.youtube.com/watch?v=GFUIVCsZ_F0
it happens when writing to the display buffer directly in 80-column text mode, instead of going through the BIOS functions. To avoid it you have to restrict all video memory updates to the CRT's refresh periods (like the IBM BIOS does), which of course tends to slow things down.
I believe DOSBox-X and Daum builds actually emulate CGA snow, but last time I checked it wasn't entirely "accurate", if that's a desired quality at all.
