Inferno style games

Página 2/7
1 | | 3 | 4 | 5 | 6 | 7

Por Grauw

Ascended (9479)

Imagen del Grauw

04-05-2014, 14:36

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 Smile.

I’d also like to point out that no-one else has made a game like Akin since 1995.

Por Grauw

Ascended (9479)

Imagen del Grauw

04-05-2014, 15:10

Ok to be fair that isn’t exactly right. Falcom uses the same type of technology and optimisations in their Ys games and Dragon Slayer IV, and they did it in 1987-1989. Ys 3 even has very impressive parallax scrolling and such, just like Akin.

Por Manuel

Ascended (17265)

Imagen del Manuel

04-05-2014, 14:56

And there's the Core Dump Promo ;-)

Por Grauw

Ascended (9479)

Imagen del Grauw

04-05-2014, 15:10

Yeah but Core Dump doesn’t count because it’s an evolution of the Akin engine Smile.

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…

Por PingPong

Prophet (3586)

Imagen del PingPong

04-05-2014, 16:28

Grauw wrote:

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)

Quote:

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! Smile

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.

Quote:

Sprites have their use

fast moving bullets or projectiles, especially msx ones.

Quote:

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.

Por Manuel

Ascended (17265)

Imagen del Manuel

04-05-2014, 16:51

What about the large boss enemies in Shrines of Enigma? Tongue

Por Grauw

Ascended (9479)

Imagen del Grauw

04-05-2014, 17:30

Well maybe I’m mincing words but I don’t think you should equate easyness with lazyness Smile. 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… :)

Por PingPong

Prophet (3586)

Imagen del PingPong

04-05-2014, 18:24

Grauw wrote:

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

Quote:

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… Smile

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.

Por Grauw

Ascended (9479)

Imagen del Grauw

04-05-2014, 21:49

PingPong wrote:
Grauw wrote:

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.

But you can’t even render those 6 distinct objects with software sprites at 60 fps…

Assuming the most optimal case of doing just a 16x16 LMMM (render sprite) and HMMM (clear sprite from back buffer) in screen 5 at 60Hz, with sprites enabled for bullets, and executing VDP commands back-to-back (not trivial)… In this scenario, based on the v9938 performance measurements every 16x16 software sprite uses 18% of the available VDP power per frame, meaning you can only render five of them each frame.

That’s a far stretch from the ten 16x16 objects on screen in this particular example in Usas. If you use hardware sprites this costs you no VDP processing power at all, and you can use the VDP commands to do other things such as opening doors, removing coins, animating the background or scrolling.

So, software sprites are good if you don’t need a stable 60 fps or don’t mind moving at 8 pixel increments, like is the case for RPGs. However for action games, hardware sprites will usually be much more suitable and give you a lot more freedom in the level designs.

You are completely free to use software sprites, as I said I like them too, but please don’t call those developers who made an informed decision not to use them lazy… I object to that :).

Por Grauw

Ascended (9479)

Imagen del Grauw

04-05-2014, 21:49

(removed this post, it wasn’t relevant for the point you were trying to make Smile.)

Página 2/7
1 | | 3 | 4 | 5 | 6 | 7