I think a screen mode of 640x480 or 520x492 (the NTSC res) at 16 colours minimum would help greatly Symbos to look better at high resolution.

Higher res could be done; however it will come at a cost of fewer sprites and fewer layers. If you were to double res in all directions, thus, 512x432, would reduce the number of sprites to 32 and number of layers to 2. (From 128 / 8).

Quote:

Quote: I would support that by providing a "Command Finished" interrupt, allowing you to create a queue yourself in MSX ram. Then you'll be in full control of your command queue size and storage format. VDPX can copy 180 bytes in the time it takes for a 3.54MHz Z80 to execute a 2-byte instruction (like LD A, 65) VDPX performance is not in doubt. I'm working on a game where each screen frame is obtained with (approx) 200 vdp commands so entering/exiting from isr for all these commands is (imho) a waste of cpu-time. Moreover system ram can be saved if bd structure is stored in vram.

I will get back on this later when the blitter is up for discussion First things first, and for now that's the sprite engine and soon the layers (MLT) engine

Although I am wondering, issueing 200 command per frame; is that a necessity because of the current VDP's structure? Perhaps what you want to achieve would be much easier to perform with VDPX, not requiring a ton of commands to begin with...

if VDPX will to support pattern mode of 8x8px blocks

y want 2 registers of 3 bit each one...

that defines the offset X & Y inside the pattern, that indicates starting rendering screen at wich XY offsets inside the pattern...

so , in that way, including in pattern-mode, we can to scroll in a 1 pix basis in every direction..... ofcourse also we needs two register to indicate at wich X & Y pattern nUMBER to start rendering, and that the NAMETABLE will be scanned CYCLICALLY so... if we define that the VDPX starts rendering on the ROW 20, when it reaches the ROW-23 is will loop to ROW 0 at nametable's scan.... that avoids to use extra VRAM for a bigger nametable. remember that the nametable must be handles in a square way.... that when it reaches the column 32 or 64 (depends the resolution) it continue rendering from colum 0 of the same row..... when it reaches the row 24 or 26 (depend of the resolution) it continue with the row 0.... and so on...

that will imply, that the cpu will upgrade only one colum/row at each frame and only when the scroll reaches "the offset pattern 0,0 "

That is the minimun work possible for the cPU in an entire all screen scrooll.


BUT.... not all games want to be full screen....

if not all the screen is used, and it has fixed thing around the game scene

will be useful, to set registers that set/resets the pattern's offset when reachs certain PIXEL XY pos in the screen. I want 4 registers that works in a horizontal basis, and 4 for vertical basis....

so, with theses lasts registers, you can do DUAL play each player with his square game-play-screne scrolleable in 1pix basis, in a pattern mode...

the rest of the screen will be rendere fixed....

so, we can call these registers like HORIZONTAL RENDERs SWITCH & VERTICAL RENDERs SWITCH, we need four of both

HRS1 having = SCREEN X coord, where this register will be fired
                     = PATTERN'S OFFSET X value for OVERRIDING when it is fired
                     = PATTERN COLUMN NUMBER value for overriding when it is fired

HRS2 the same

HRS3 the same

HRS4 the same

VRS1 having = SCREEN Y coord, where this register will be fired
                     = PATTERN'S OFFSET Y value for OVERRIDING when it is fired
                    = PATTERN ROW NUMBER for OVERRIDING when it is fired

VRS2 the same

VRS3 the same

VRS4 the same

So, thinking in two squares of two player scene... and using a frame drawed of 1 row & colum width it is possible

with 1 register you set the pixscrool of the box 1, with 1 register you set the reset of the end of the 1 player scene, allowing a fixed gfx column dividing both squares-scene.
with the third register, you set the pix scroll of the second player's scene, and with the fourdth you set the end of the second square.

the same vertically.

thinks in games like hyper sport III , or a dual ROAD FIGHTER..... jjeejej

VDPX is already designed in that way. The logical layers have a height and width of 64 patterns. For each layer there will be X/Y offset registers (in pixels) of 0 - 511. The layers will indeed always be circular so you can indeed softscroll in any direction, only having to update the incoming rows and or columns. That's all been planned for

In addition, layers will have viewport registers so you can set their actual with/hight and offset on the screen. You'd be able for instance to create a 2-player vertical split race game or shoot 'em up. Or horizantally, which ever you wish. You can also use multiple layers to implement parallax scrolling with full-screen overlap if you wanted. Another cool bean using the view-port registers would be creating some sort of a 'radar' frame that would show a map of the game field, which would scroll along. No complex coding required, only updating the radar layer and setting some registers

Yes, that's one of VDPX' main features!

okokook... I just started with the info of this thread.... I reedit my post....again

but... i have a question... there wiill be a MASK name table?... how VDPX knows wich layer to show at wich xy position? using transparency code color or what?

No problem No, there won't be a mask table. Instead, there's the transparancy color #0. Layers have a fixed order, from 0 (front) to 7 (back) and there will be a background color register for the case no layer sits under a screen X/Y.

I would love to recode YsIII for VDPX

I AM wondering, if VDPX will be able to hide automatically the sprites that exceds the borders of SQUARE-GAME_PLAY_SCENE.

if the sprites is the layer most on top, how will be possible to limit the view of sprites to a reduced square scene?... and thinking that we have TWO squares...

For sprites you can set on which layer they sit, sprites have a layer attribute. If you for example would use 2 layers, layer 0 and 1. On layer 1 you'd create the game play field. Layer 0 you'd draw borders around playfield and scoreboard (think SD snatcher) and if you then set the layer attribute of sprites to layer 1, sprites will vanish under the borders of layer 0. Just make sure that the area of layer 0 that covers the playfield is set to all transparent patterns, otherwise you won't see layer 1.

As for which sprite is shown on top, that's still determined by the sprite number, sprite 0 on top, sprite 127 on back.

Edit: I see what you mean. I may add one more bit to the SAT that tells whether sprites should be clipped by the layer they are assigned to. That way, sprites start disappearing if they go past the layer borders.

For reference, here's the SAT layout again, which is now definitive:

        7  6  5  4  3  2  1  0  |
   0 : x7 x6 x5 x4 x3 x2 x1 x0  |  x8 - x0 : X Coordinate (0 - 511)
   1 : -  -  -  -  -  -  -  x8  |  y7 - y0 : Y Coordinate (0 - 255)
   2 : y7 y6 y5 y4 y3 y2 y1 y0  |  p9 - p0 : Pattern Index (0 - 1023)
   3 : -  -  -  -  -  -  -  -   |  l2 - l0 : Layer Priority (0 - 7)
   4 : p7 p6 p5 p4 p3 p2 p1 p0  |  c2 - c0 : Collision Category (0 - 7)
   5 : -  -  -  -  -  -  p9 x8  |  en      : Enable (1 = visible, 0 = off)
   6 : -  -  -  -  -  l2 l1 l0  |  fx      : X-axis Flip (1 = flip, 0 = normal)
   7 : en c2 c1 c0 -  -  fx fy  |  fy      : Y-axis Flip (1 = flip, 0 = normal)

PERFECT!

it is possible. to start rendering on each hor line of the screen with its own scroll register, like having in a scroll register table... thinks in the ghostbuster (REAL ARCADE MACHINE) that effect when starts the game scene. and when you finishs the stage...

7 : en fx fy -  -  fy c2 c1 c0 |     : Y-axis Flip (1 = flip, 0 = normal)

Would be even better.

well i think you mean

7 : en fx fy - - c2 c1 c0 | : Y-axis Flip (1 = flip, 0 = normal)

I was thinking that you wouldn't be changing the sprite category all the time for a sprite. I mean, an enemy bullet remains an enemy bullet throughout its sprite life. The flip- and enable bits are single bits and can be turned on/off by a simple xor:

LD A, (IX+7) ; IX pointing to yer sprite
XOR #2 ;Toggle Flip X
LD (IX+7), A ; Put back

If you want to mask out the category and change it - ofcourse I can rearrange the 7th byte..

LD A, (IX+7)
AND #F0
OR <new category>
LD (IX+7), A

Ofcourse this assumes the VRAM is mapped into Z80 address space.

--- The 7th byte layout's been updated:

   7 | en -  fx fy -  c2 c1 c0 | fy      : Y-axis Flip (1 = flip, 0 = normal) 

Quote:

PERFECT! it is possible. to start rendering on each hor line of the screen with its own scroll register, like having in a scroll register table... thinks in the ghostbuster (REAL ARCADE MACHINE) that effect when starts the game scene. and when you finishs the stage...

No, I won't be adding offset registers for individual scanlines for now.