PingPong,
I think you underrate the V9938...
In Total Parody the V9938 updates on fly, each frame, ALL the colours in the SAT and the SPT of the first 32 sprites using byte copy from a hidden page.
Each copy command moves 2 sprite definitions -colour&shape- at time and you can choose up to 256 frames of with 3 colours per line...
All using copy commands.
If you simply want a rotating SAT like on MSX1, just use the VDP byte copy, it will be trivial and almost at zero CPU cost.

Quote:

PingPong, I think you underrate the V9938... If you simply want a rotating SAT like on MSX1, just use the VDP byte copy, it will be trivial and almost at zero CPU cost.

@ARTRAG: I know, the fact that both the sat and color sprite attributes are 128 and 512 (=128*4) allow the use of YMMM command when needed, but this use VDP time...

Time ago i've tryed a little experiment. Problem: rotate the sprite priority planes by 8 sprites at time.
Approach used:
rotating the SAT require a step of 8*4 = 32 bytes, doable with a logical command.
rotating sprite colors require a step of 8*16=128 bytes, exactly what i need for a YMMM cmd.

then the steps are.
1) move the first 128 bytes line away.
2) move (scroll) the three bottom lines up to 1 line (so you are cycling)
3) move the line on (1) to position (4).

You have cycled the sprite color table with a step of 8 sprites.

Logical cmds work in the same manner for SAT...

But you have vdp busy, and you need to wait because you have more command to send. So a little gain.

Wouldn't it just be great not to have to do this "work yer arse around a limitation" any more and instead focus on creating your game/demo which ever?

Quote:

Wouldn't it just be great not to have to do this "work yer arse around a limitation" any more and instead focus on creating your game/demo which ever?

My position is in the middle, of course. Bit here, the problem is that the VDP require to much effort in tricks to achieve things, and even with those efforts result is bad or not satisfying.

Of course with VDPX there are no problems at all on video things, even on the slow z80.

we just need to reposition the track bar from (efforts level)

90% of efforts in vdp tricks 10% for game development
to
10% of efforts in vdp tricks 90% for game development


Of course VDPX make things more simpler than needed. IMHO. But no problem

Pingpong
512 bytes for colours are a 256x4 pixel area in screen 5
128 bytes for attributes are a 256x1 pixel area in screen 5

You need two SAT's, say SAT0 and SAT1

For colours, pure rotation is to be done in 3 steps.
16 bytes are 32 pixels in a line.

I refer the coordinates as relative to the position of the edge of the boxes 256x4 and 256x1

Colors:
1) Copy (32,0)-(255,3),SAT0 to (0,0),SAT1
2) Copy (0,1)-(31,3),SAT0 to (240,0),SAT1
3) Copy (0,0)-(31,0),SAT0 to (240,3),SAT1

For attributes, a sprite takes 4 bytes, i.e. 8 pixels
We need just two steps:

1) Copy (0,0)-(7,0), SAT0 to (240,0),SAT1
2) Copy (8,0)-(255,0), SAT0 to (0,0),SAT1

swap the two SATs

Done!

Quote:

Wouldn't it just be great not to have to do this "work yer arse around a limitation" any more and instead focus on creating your game/demo which ever?

I think the reason for demos to exists is that there are limitations that you try to overcome. Sure having powerfull VDP will make new kind of demos as then the limitation is CPU, but is that any better?

About the VDP limits, no they have not yet been reached... expetially with V9958 we have barely scatched the surface, real power is yet to be discovered. With V9938 the hidden possibilitys are yet to be found from pattern modes.... For example 4motion engine was good example what kind of new visualizations we can do with these limited resources. I'm also waiting for ARTRAGs animation conversions with pallette support.

I think you're quite right about demos. Their main objective is to push the limits of hardware, displaying code skill as in "look what I accomplished given the limitations". Ofcourse, demos are about more than just that, like passing on messages and showing nice things to look at.

It's completely different for game development. There you don't want to battle limitations, there you want to create something that is visually appealing and perform well without being strained having to work your way around limitations.

Back in the days 9938 has been exploited as much as it could already. There are no "hidden" features that are still not discovered. Again I refer to what game companies accomplished back then. Another example, Microcabin's Xak, a screen 7 game. VDP pushed to its limits as the whole game is held back by VDP performance. As for 9958, it didn't add speed or convenience. Just a few more screenmodes with more colors, but no logic that leveraged it over 9938.

VDP specs are well known. From those, you can derive limitations. They can simply not be exceeded; it's hardware.

Quote:

Pingpong 512 bytes for colours are a 256x4 pixel area in screen 5 128 bytes for attributes are a 256x1 pixel area in screen 5 You need two SAT's, say SAT0 and SAT1 For colours, pure rotation is to be done in 3 steps. 16 bytes are 32 pixels in a line. I refer the coordinates as relative to the position of the edge of the boxes 256x4 and 256x1 Colors: 1) Copy (32,0)-(255,3),SAT0 to (0,0),SAT1 2) Copy (0,1)-(31,3),SAT0 to (240,0),SAT1 3) Copy (0,0)-(31,0),SAT0 to (240,3),SAT1 For attributes, a sprite takes 4 bytes, i.e. 8 pixels We need just two steps: 1) Copy (0,0)-(7,0), SAT0 to (240,0),SAT1 2) Copy (8,0)-(255,0), SAT0 to (0,0),SAT1 swap the two SATs Done!

Yes, but look better at my message: i rotate 8 things at a time.
so (1) becomes a transfer of 16*8=128 bytes, that the reason i use YMMM instead of LCMM
Of course for the 128 bytes sat i need to use logical commands, but for sprite color table i can use YMMM since my data lenght is 128 bytes at time.....

PS= a consideration, however, since the z80 had to update SAT (X,Y) to VRAM, does make sense to use the VDP? The z80 already had to write SAT.... for move objects on screen.

My view:
You need to rotate just 2 sprite at time if you use 3 colors per line.
Rotating more sprites does not improve the multiplexing but can allow lighter algorithms.

You can rotate from 2 to 7 sprites at time with just 3 copy commands, as I showed before
and 8 sprites at time with just TWO copy commands.

Again the trick is having two SATs.

Say N the number of sprites to be rotated at time, with N<8 you have

Colors:
1) Copy (32*N,0)-(255,3),SAT0 to (0,0),SAT1
2) Copy (0,1)-(32*N-1,3),SAT0 to (256-N*32,0),SAT1
3) Copy (0,0)-(32*N-1,0),SAT0 to (256-N*32,3),SAT1

swap the two SATs

If N = 8 you get:
1) Copy (0,0)-(255,0),SAT0 to (3,0),SAT1
2) Copy (0,1)-(255,3),SAT0 to (0,0),SAT1

swap the two SATs

About the SAT rotation, it is up to you if using the z80 or the VDP.
In MOAM we update the attributes at half rate but we apply the sprite multiplexing algorithm at full rate.

Quote:

If N = 8 you get: 1) Copy (0,0)-(255,0),SAT0 to (3,0),SAT1 2) Copy (0,1)-(255,3),SAT0 to (0,0),SAT1

OK, 1) and 2 can be easily converted to YMMM cmds for better performance. +/- 3.5 times fast than a logical copy.
But, of course only if i have N=8...

Quote:

Wouldn't it just be great not to have to do this "work yer arse around a limitation" any more and instead focus on creating your game/demo which ever?

In my opinion: not when you're specifically targetting a retro machine.

If one wants to have more CPU or graphical power one would have left the MSX scene in the early nineties at the latest and moved on to more capable systems. In 2008, what's attractive to an 8 bit computer with a very limited video chip in the first place if you find restrictions offensive?

Quote:

Back in the days 9938 has been exploited as much as it could already. ... Again I refer to what game companies accomplished back then.

You mention some games that are great in their own right, but they do 8px block scroll. That's not unforgivable - back in the days when I played Nemesis2 and Salamander I also took an 8px scroll for granted. But the genre of 8px block scrollers has been exhausted whereas smooth scrollers have barely seen the light of day on the MSX2 which is why I emphasize them.

Can blocky scrollers be great? Sure. But smooth scrollers can be just as great or greater. Or are you saying Space Manbow would be just as great if it used blocky scrolling? Remember - smooth scrolling has limitations and design consequences on MSX2 but there is no hardware limit preventing smooth scrolling - as there is a rock solid limit on the Spectrum preventing to use more than 2 colours per block. Spectrum can't ever look better than it did in the 80s, MSX2 can. And with the extremely limited development we have in this century, I'd say that this vastly underdeveloped area could use a bit more emphasis instead of expanding on what we already have.

It will take a lot of effort to create good smooth scrolling games (esp. in screen 5) for MSX2. But as with Spectrum conversions for MSX1: while reprogramming them with sprites and improved colour is also more challenging than a blind conversion, it's undeniable the quality makes it worthwhile in the end.

PingPong
Also when N<8 you can use YMMM, just use left to right or right to left X directions
in each of the 3 steps.
BTW with N=8 you use 2 commands only, and thus less CPU

Quote:

PingPong Also when N<8 you can use YMMM, just use left to right or right to left X directions in each of the 3 steps. BTW with N=8 you use 2 commands only, and thus less CPU

would be nice to know how many scanlines takes the commands. They are all expressed on bytes/frame, for me not so useful. the scanline timing should be considered in VBLANK, i do not run on active area...
time ago i've measured something like 11 bytes per scanline in HMMC if i remember correctly.... but i'm not sure about VBLANK or sprites enabled.

Quote:

... In my opinion: not when you're specifically targetting a retro machine. If one wants to have more CPU or graphical power one would have left the MSX scene in the early nineties at the latest and moved on to more capable systems. In 2008, what's attractive to an 8 bit computer with a very limited video chip in the first place if you find restrictions offensive?

If you looked at the earlier pages in the other thread about gfx I made the exact same note; if one wants an extremely beefed videocard, just get a PC with an 4870x2 which is what I am running. To me its mostly nostalgia and the programming model. Back in the days I loved MSX. It was a fun and flexible platform. I made a lot of hardware for it. Eprom programmers, MIDI interfaces, even my own 512KB internal memory mapper which I designed myself, using the "CAS-before-RAS" autorefresh capabilities of the used DRAMs. I have fond memories of my MSX time. The reason I work on VDPX is mostly a technical design challenge. Secondly, it is creating something that I could not back then as back in the 80s FPGAs and their capacities were simply not available to average joes. VDPX is not an attempt to leverage MSX to modern computing. Instead, it is expanson in the same retro spirit as the MSX itself. I always wanted fast smoothscrollers and good looking sprites on the MSX. The VDPX creation can just offer that. VDP chips supporting sprites is retro in itself; modern day videocards are just bitmap modes and accelerated 2D block copies. Those systems have the CPU power to back them up. It's the same for 3D acceleration. VDPX is essentially a retro expansion that brings MSX graphically up to the level of 16-bit machines back in the day where the video hardware still needed to support sprites and other features to off-load the CPU. A lot of text, but I just want you to realize the motivation and design intend of VDPX.

Quote:

...You mention some games that are great in their own right, but they do 8px block scroll. That's not unforgivable - back in the days when I played Nemesis2 and Salamander I also took an 8px scroll for granted. But the genre of 8px block scrollers has been exhausted whereas smooth scrollers have barely seen the light of day on the MSX2 which is why I emphasize them. Can blocky scrollers be great? Sure. But smooth scrollers can be just as great or greater. Or are you saying Space Manbow would be just as great if it used blocky scrolling? Remember - smooth scrolling has limitations and design consequences on MSX2 but there is no hardware limit preventing smooth scrolling - as there is a rock solid limit on the Spectrum preventing to use more than 2 colours per block. Spectrum can't ever look better than it did in the 80s, MSX2 can. And with the extremely limited development we have in this century, I'd say that this vastly underdeveloped area could use a bit more emphasis instead of expanding on what we already have. It will take a lot of effort to create good smooth scrolling games (esp. in screen 5) for MSX2. But as with Spectrum conversions for MSX1: while reprogramming them with sprites and improved colour is also more challenging than a blind conversion, it's undeniable the quality makes it worthwhile in the end.

Yes, too much effort, and too impractical and too slow to actually apply in games. The only exceptions were vertical scrollers as the VDP only supported smoothscroll in the vertical axis. And even then it was limited regarding speed. Take Aleste, when the first level begins, the level indeed scrolls insanely fast. But you know what? The videopage is not updated at all! It's the same image that just circularly scrolls. When the scrolling finally slows down, only then the background is updated with new incoming tiles. The X-axis smooth scroll was just deceptional, using the adjust registers, but the actual screen content was still an 8-pixel scroll. That brings us to Space Manbow; it was done in screen 4 to trade color density for speed. If screen-5 smoothscroll in all directions at a reasonable speed was viable on 9938 it would have been done. But it hadn't been done. For a reason.

Quote:

It will take a lot of effort to create good smooth scrolling games (esp. in screen 5) for MSX2.

Not to create a vertical one ...

I wrote several months ago a vertical scroll engine in screen 5 with 192 lines. It scrolls only a 192x192 windows, and keeps static a 64 pixels wide area on the right part of the screen (for score or information). It is achieved by using a YMMM command to copy the score/info area one pixel up each time the screen goes one pixel down. Works pretty good ... And the clock is updated too