Video Modes - RGB

[sigh]

Such game is clearly the good customer of Rasters...

= no scrollings needed as it uses fixed screens

=Animation is somewhat limited to only 2 Fighters (and the referee) so you can get big well animated softsprites.

=Hardsprites would be a bit clumbersome... I mean, this uses bigger Datas to get this in HardSprites, and those are slow to change/refresh so if many frames are used... this would be no good.

=limited to 128K cartridge too... A complete spritesheet would be far heavier and not especially fast/easy to animate.

Im in interested in these comments especially about the "Hardsprites would be a bit cumbersome...". Why would it be slow to change and refresh? Why do software sprites  operate faster for this kind of game?

would it help anybody if I published some code to demonstrate various "extra video modes" and code to convert gfx to them.

examples are:

- showing some gfx using only sprites
- generic code for loading and showing a picture
- generic code for loading and showing overscan picture
- code to do flashing pics (mode 1/mode 0) + converting code

Would be great. I'm still getting my head round these video modes.

[redbox]

Im in interested in these comments especially about the "Hardsprites would be a bit cumbersome...". Why would it be slow to change and refresh? Why do software sprites  operate faster for this kind of game?

The downside to hardware sprites is that they take up more space, and when you're copying them from RAM into the ASIC (location of Hardware Sprites) you have to copy twice as much data.  Either this or you have to unpack your data if you've packed it to take less RAM for storage and this is even more of an overhead.


The problems therefore come when you want to animate hardware sprites - you can only just animate them all within one frame.  But there are ways around this such as only animating some at a time. 


Hardware sprites do have their pros and cons and what MacDeath was saying is they might not be suited to that purpose.

[sigh]

Thanks. I had no idea about this.

So what I'm gathering is this:

1)  Pang or Shoot em up type game where the player sprites have very little animations, Hardware Sprites are a great choice (also for special effects animation such as explosions, fire and bullets.)

2) Panza/Beat em up game or football game, or anything that is heavily animated would be better off using software sprites due to the amount of animation and storage being used.

It seems like everytime I feel close to getting to grips with the video modes to generate my game ideas- something else always crops up !

[MacDeath]

That's it.

Hardsprites from the Asic do not simply read RAM or ROM for content... they need to "upload them into the ASIC... which is somewhat slow because it seems the Sprites are designed as 256 colours... so weight far more than the theorically needed 16x16xmode0 datacode... (actually like 32x16xmode0 Datas)

Clearly a flaw in design.

If they were properly implemented (=like mode0 but with redimensionnable pixels = 4 bits per pixels) they may even be twice faster to upload into ASIC.
Or if they were really 256colours, they would be simply awesome...

But this also would need 256 colours slots in the ASIC for the Sprites Palette, which is quite a lot of space into a component.




On the other hand, to move the sprites (not change the frame) is good and fast...



Amstrad PLUS lacked actually a very few things...

=overclocked video modes (=32K VRAM used... 160x200x256/320x200x16/640x200x4... like Atari ST, sort of)
So more something like 2x256colours slots for palette... (+1 for the border)

=less bugs and flawed features (DMA sound has some bugs to, sprites are unproperly done)

=More RAM and ROM (256K cartridges would have been the minimum IMO, minimum128K RAM config...256k  would be great but even 160K RAM would be quite ok...)

=More sprites !
Most other machines like MSX had 32 sprites...
ok why not 2x16 sprites, using slightly different logic.
The 16 like the one already there (minus the flaw...would then be more like Hardware tiles) and additionnal 16 which would not upload but read Datas in RAM/ROM (pointer)... and perhaps even simply use the standard Videomodes code/colours...

So yep.
A proper PLUS would have needed 2 Asics instead of one... most other computers used 2 custom chips (when they used some), often one for sound and the other for Video.

In amstrad's case, one for Video only and the other for all the rest...(ACID reading, DMAs, Memory managment, and so on...)


And having 2xAY psg could have been great to.
and 16mhz Z80...
and and and...


ok i stop this wankfest.



Actually to simply get a PCW9256 with the PLUS' Design, Video (modes, colours, sprites, scrolls) and Sound (AY + DMA) would be ok...
(and compatible with both PCW and CPC...ouch...)

[MaV]

ok i stop this wankfest.

Yeah, thanks a lot. (wipes his hands)

[arnoldemu]

Hardsprites from the Asic do not simply read RAM or ROM for content... they need to "upload them into the ASIC... which is somewhat slow because it seems the Sprites are designed as 256 colours... so weight far more than the theorically needed 16x16xmode0 datacode... (actually like 32x16xmode0 Datas)

Clearly a flaw in design.

The sprite ram is a clever idea. They didn't have the memory bandwidth to read sprites from main ram. (perhaps they could have used the time in the border area...)
So they used ram inside the ASIC which it could access fast. They used the memory bandwidth which was free in the hsync to read sound dma instructions which was clever too.

But what would have been really great, was if you could tell each sprite where in the ram to fetch it's pixels.
Then C64 like multiplexing would have been much more possible and take less cpu time.

[sigh]

That's it.

Hardsprites from the Asic do not simply read RAM or ROM for content... they need to "upload them into the ASIC... which is somewhat slow because it seems the Sprites are designed as 256 colours... so weight far more than the theorically needed 16x16xmode0 datacode... (actually like 32x16xmode0 Datas)

Clearly a flaw in design.

On the other hand, to move the sprites (not change the frame) is good and fast...

Okay. Seems  I overestimated the hardware sprites, but at least now, I have a clearer idea of it's uses.

[Axelay]

Well for the sake of the argument, comparing hardware sprites to software sprites over background...  For h/w sprites you need to copy the data, maybe unpack it, and set the XY co-ordinates and magnifications perhaps.  For s/w you need to consider working out screen addresses instead of simply plugging in XY co-ordinates, you have to save and restore the background, and allow for the memory allocated to storing it, you need to spend the time to mask your sprites against the background, and you need to either use a second 16k screen as a buffer to prevent flicker (and needing twice the save/restore buffer space) or deal with trying to minimize flicker by managing sprite update order in some way.  You also need to update every s/w sprite every frame it moves or the screen scrolls, where with the hardware sprites you can stagger sprite data update according to animation requirements.  I really don't see how software sprites over backgrounds, especially horizontally scrolling ones, could hold a candle to the plus hardware sprites, even with their difficulties?

[MacDeath]

The problem with HardSprite is that there are not a lot of them...


When i told it was a flaw, Well... to get the sprites formated as 8bpp but using only 4bpp is a flaw.

The PLUS' sprites are often compaired to C64's sprites... not a good Idea. quite different.


C64 : ok, it's fast and easy to multiplex properly... but those must stick to C64 video limitation ("modes" and palette) actually...

C64 sprites are smooth and fast... but ugly as hell... C64 palette...erk... ok a good choice of greys, lol...

Also :
= 2 (1+Transparancy) colours only if fine square pixels. (1bpp)
= 4 (3+Transparancy) colours only if blocky 2x1 pixels. (2bpp)


Good point : they are 24x21 pixels... wich is quite good yet somewhat bastardish...





So Yep, with its 16  16x16x15 sprites, Amstrad PLUS is not that bad.

Also the HardSprites are supposed to be faster if ROM operated...

That's why I always have a mixed view on those.
Better than nothing, yet frustrating...

They just miss a little something to be fully operational...

=be faster to upload into ASIC (=reduced weight in data).
=or be more numerous (32 sprites=more slots for the same amount of data = reduced weight in Datas per sprite)
=or be actually 256colours (=same as they are but 256 ink slots for Sprites).

Twice would be great... so to be really in 4bpp ...
But 8bpp would also be awesome ...

Having 32sprites in 8bpp (256colours) would have been the ultimate combomaker.

Also some stuff like flipside, reverse sprite or rotate it by 90° would have been a definitive plus.




The flaw in design was concerning the fact they use twice Bit as needed and don't use all their bits...





Anyway, I started a new topic to deal with such matter as we are talking now...
I mean we got far beyound the reachs of the original topic here...


http://www.cpcwiki.eu/forum/index.php?topic=2279.0