Have the VDP limits been reached?
Hrothgar : (Especially) The msx1 vdp is created with a good mix of *features* that prevent you to make more than exists.
- No-Line int support, so forget raster effects until you use polling (but it's heavy on CPU time) (your (4))
- No scroll support. Ah, ok, i will do dynamic redefinition of tilesets, by blitting to vram...... Umh, no, i cannot do it, due to the limited bandwidth .... + colour clash. Plus screen2 have to move 12KB of VRAM to redefine all the tiles
- Exceptional sprite support. With the !unique! (c) feature of 4 sprites / scanline very often you think about to not use sprites at all. take this example: a C64 zoomed multicolor sprite, if made to look the same on msx1 will take ALL the 4 sprites , (the c64 one is a three color sprite the msx1 is a 2 color sprite however!
)
On msx2 things are a little better, but having good scroll+animations with the limited horsepower of MSX2 VDP it's not possible.
think about it: most flickering sprite routines on msx1 rotate the sprites priority like in a circular list. While this is feasible on msx1 vdp, on msx2 one, it's hard, because of the G R E A T - M U L T I C O L O R support that forces you to rotate not only 128 bytes, but instead 640! GREAT!
Plus the vdp had the big help, that allow to know what sprite of the potentially 28 is not displayed correctly. PRATICALLY USELESS!.
The only decent is the V9958. Having scroll support allow the use of VDP for animation (SW sprites) and scroll support is by hardware. Plus you can use 8 hardware sprites ... (without boring of sprites)
With those all good things where you want to go ?
- No-Line int support, so forget raster effects until you use polling (but it's heavy on CPU time) (your (4))
- No scroll support. Ah, ok, i will do dynamic redefinition of tilesets, by blitting to vram...... Umh, no, i cannot do it, due to the limited bandwidth .... + colour clash. Plus screen2 have to move 12KB of VRAM to redefine all the tiles
- Exceptional sprite support. With the !unique! (c) feature of 4 sprites / scanline very often you think about to not use sprites at all. take this example: a C64 zoomed multicolor sprite, if made to look the same on msx1 will take ALL the 4 sprites , (the c64 one is a three color sprite the msx1 is a 2 color sprite however!
)On msx2 things are a little better, but having good scroll+animations with the limited horsepower of MSX2 VDP it's not possible.
think about it: most flickering sprite routines on msx1 rotate the sprites priority like in a circular list. While this is feasible on msx1 vdp, on msx2 one, it's hard, because of the G R E A T - M U L T I C O L O R support that forces you to rotate not only 128 bytes, but instead 640! GREAT!
Plus the vdp had the big help, that allow to know what sprite of the potentially 28 is not displayed correctly. PRATICALLY USELESS!.
The only decent is the V9958. Having scroll support allow the use of VDP for animation (SW sprites) and scroll support is by hardware. Plus you can use 8 hardware sprites ... (without boring of sprites)
With those all good things where you want to go ?
Maggoo, 3) may have been done for individual tiles, but -afaik- not with the level of detail like in that C64 game. In that game one sees two layers. In MSX games with that technique one sees 1 layer with 'rotating' tiles. I mean, they've never fooled me.., while I *did* watch that tube vid a bit like 'wtf?'
Smooth scroll in screen 5 can be done but the speed of your scrolling will be limited to 1 pixel per frame (2 if you somewhat decrease the display area). The best example of this IMO is "Total Parody" by Artrag. There are also some contraints you may have to deal with (sudden change of direction, etc). I would only use that for a game where the scroll path is pre-define, like for a nemesis type shooter.I've seen the "Total Parody" mentioned before, is it available somewhere? About the speed of the scroll: does it copy everything or only parts of the screen? Selective copying is the key part really, shouldn't that allow for much more variation in scroll speed without squeezing the whole screen to 120px? Just think about the amounts of air, bottom or repeated bricks and roofs - these don't have to be copied at all.
As for sudden change of movement: the screen shouldn't have to respond on a pixel-for-pixel basis as the player turns in the exact center of the screen; there can be margins. When considering a 32px wide center zone there should be some space to react to player movement?
3) Already done in screen 4. Check the Vscreen demo 1.0, it should be available on the MRC for download. The parralax scrolling is working like you describe.I'll check, but I guess the similarities are more on a technical level than overall visual resemblance to the game I mentioned
Possible but is it really worth it ? It's a real pain to deal with interupts on MSX1 so doing it with sprites might be possible but even more of a hassle. On MSX2 it's possibleIndeed this trick would only be useful for MSX1. And I understand the technical hurdles, but then again these seem to be taken on some other systems as well. As I've read some C64 games need to operate with their CPU and video chip in 'synched mode' throughout the game, going as far as issuing commands to the VDP on an exact xth clock cycle of a certain scanline to achieve graphical effects. It took that scene eight years to achieve that level of programming to use it for games not demos. I was just hoping something like that could be possible on MSX as well.
As for interrupt trouble: another trick that comes to mind is a cartridge-aided interrupt generator. Wasn't that used for the NES as well? As for complexity it seems a rather limited enhancement but with great possibilities, somewhat like the SCC chip. Just a thought.
As for sudden change of movement: the screen shouldn't have to respond on a pixel-for-pixel basis as the player turns in the exact center of the screen; there can be margins. When considering a 32px wide center zone there should be some space to react to player movement?
3) Already done in screen 4. Check the Vscreen demo 1.0, it should be available on the MRC for download. The parralax scrolling is working like you describe.I'll check, but I guess the similarities are more on a technical level than overall visual resemblance to the game I mentioned
Possible but is it really worth it ? It's a real pain to deal with interupts on MSX1 so doing it with sprites might be possible but even more of a hassle. On MSX2 it's possibleIndeed this trick would only be useful for MSX1. And I understand the technical hurdles, but then again these seem to be taken on some other systems as well. As I've read some C64 games need to operate with their CPU and video chip in 'synched mode' throughout the game, going as far as issuing commands to the VDP on an exact xth clock cycle of a certain scanline to achieve graphical effects. It took that scene eight years to achieve that level of programming to use it for games not demos. I was just hoping something like that could be possible on MSX as well.
As for interrupt trouble: another trick that comes to mind is a cartridge-aided interrupt generator. Wasn't that used for the NES as well? As for complexity it seems a rather limited enhancement but with great possibilities, somewhat like the SCC chip. Just a thought.
There was a developing version of total parody with 4 directions scrolling (well this was also in the public promo), parallax and borders.
Is there still a link somewhere? It sounds cool, even if it's a proof-of-concept
.
Is there still a link somewhere? It sounds cool, even if it's a proof-of-concept
.
Maggoo, 3) may have been done for individual tiles, but -afaik- not with the level of detail like in that C64 game. In that game one sees two layers. In MSX games with that technique one sees 1 layer with 'rotating' tiles. I mean, they've never fooled me.., while I *did* watch that tube vid a bit like 'wtf?'
Can be done for more than a single tile really. I have used it for blocks of 16x16 (4 tiles) in Vscreen and did tests of 64x64 (64 tiles) and it was working fine. So one could push that much further if needed. It really depends of how many tiles you want to reserve for your background. You dont want to use that many tiles for something that is just a neat visual thing.
Can be done for more than a single tile really. I have used it for blocks of 16x16 (4 tiles) in Vscreen and did tests of 64x64 (64 tiles) and it was working fine. So one could push that much further if needed. It really depends of how many tiles you want to reserve for your background. You dont want to use that many tiles for something that is just a neat visual thing.
By Hrothgar
Champion (281)
09-09-2008, 20:02