Do realise you’re talking about the single most technically impressive game that exists for MSX there… Can’t expect all other games to live up to that 
.
I’d also like to point out that no-one else has made a game like Akin since 1995.
Yeah but Core Dump doesn’t count because it’s an evolution of the Akin engine .
And, it was never completed. I would argue at least partially because the development took so long. Even with Akin as a starting point, the Core Dump work in progress blog goes from 1996 to 2000, that’s four whole years. The eventual data loss from a harddrive crash just sealed the deal.
Which brings me back to my earlier argument: if you focus all your efforts on creating the most technically impressive graphics engine and the end result is that the game never gets finished…
Additionally hardware sprites are easy to use…
That's the point. Easy -> So lazyness. not all the 8 bit have hw sprites but there are a lot of good games that use sw sprites. And not being limited by hw capabilities they look more similar to arcade ones, for example. Take as example ZX speccy ports where enemies are like the arcade (of course monochromatic)
I suppose a game like USAS could have used software sprites, but there would be a limit on how much it can show at the same time, and how flexibly it could be used. And I don’t think anyone can complain that game doesn’t look good!
USAS is the kind of game perfect for sw sprites. Not a lot of enemies on screen, not moving at fast speed. By contrast you are more limited by hw sprites. let's say you can have at most 4 multicolored enemies on screen. and even without that limit, please consider that the main charater uses 6 hw sprites and it's collegue almost 4. you quickly reach 10-20 sprites of 32, because you need to aggregate sprites and also to manage math to move them toghether.
Plus you get multicolor, but you are constrained to the OR color limit, a thing that can make every graphic man to go crazy.
Sprites have their use
fast moving bullets or projectiles, especially msx ones.
whereas in an action game hardware sprites are often a better choice because you don’t want framerate to drop when you have more than a few enemies and projectiles on screen.
on the other hand you have the ability to workaround those problems by clever programming. For example a sprite that moves on a one-color background does not need to save the background while moving. this can save time.
the problem is that msx2 bkground gfx are beautiful but sprite subsystem is not keeping up to background gfx.
What about the large boss enemies in Shrines of Enigma? 
Well maybe I’m mincing words but I don’t think you should equate easyness with lazyness . It’s just easy because it is designed and well suited for the purpose.
And when looking at Usas I think it looks great, I think it would have absolutely zero benefit from using software sprites. I was looking at a video and saw hardly any any sprite flickering. Even at places like 9:20 or 10:55 where it’s pretty much at the 8 sprites per line limit.
Also in various places there’s so much going on, e.g. if you see Cles’s happy attack at 18:10 (one of the few places where you see a bit of flickering), or the boulder at 17:14, those are some pretty big sprites… also the music note to indicate his happy mood… Those kind of details, you wouldn’t add them if you had to use software sprites I think, it’s just too expensive if you want to keep the high framerate.
p.s. I’m talking about sprites in MSX2 screen modes. The v9938 greatly increased the hardware sprite capabilities. Also maybe a matter of taste, but I think the monochrome software sprites in those speccy ports generally look horrible… :)
Even at places like 9:20 or 10:55 where it’s pretty much at the 8 sprites per line limit.
For Example, at 9.20 there are 3x4=12+6+2+2=22 sprites on screen, pretty near to the limit of 32, with only 6 distinct objects on screen plus some bullets. with sw sprites this limit is not so worrying. And you gain TOTAL freedom on pixel colors e total freedom in placement. konami did planned the movement paths to avoid critical flickering situations
p.s. I’m talking about sprites in MSX2 screen modes. The v9938 greatly increased the hardware sprite capabilities. Also maybe a matter of taste, but I think the monochrome software sprites in those speccy ports generally look horrible…
unfortunately i do not agree with you, v9938 had improved too little sprite system, and in some aspects, even made worse than msx1! If you need to implement the antiflickering code, on msx1 this comes at zero cost. you need to write always the same 128 bytes. on msx2 you are forced to write ALWAYS and extra on 512 bytes every frame.
(removed this post, it wasn’t relevant for the point you were trying to make .)
