VDPX: The Quest for High-Performance Retro Graphics

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

Por MicroTech

Champion (385)

Imagen del MicroTech

03-10-2008, 13:06

Beyond vram size upgrade, I think the key-concept of buffer descriptors (bd for short), is the possibility to queue up work requests (read vdpx commands) from cpu without havng to wait for the previous command to be terminated.

Por MagicBox

Master (198)

Imagen del MagicBox

03-10-2008, 13:09

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)

Por hap

Paragon (2040)

Imagen del hap

03-10-2008, 14:07

Now that you're working on the sprite engine, how about a linked list like on the Sega Megadrive instead of a linear attribute table?
Another cool feature, available on one of the Sega Saturn VDPs I think: being able to define delta x/y of all 4 sprite corners (basically this would mean support for zoom/rotation/flip/skew)

Por MicroTech

Champion (385)

Imagen del MicroTech

03-10-2008, 14:44

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.

Por Devcon

Resident (41)

Imagen del Devcon

03-10-2008, 14:47

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.

Por MagicBox

Master (198)

Imagen del MagicBox

03-10-2008, 18:43

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

Por MagicBox

Master (198)

Imagen del MagicBox

03-10-2008, 18:44

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 Smile First things first, and for now that's the sprite engine and soon the layers (MLT) engine Smile

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

Por flyguille

Prophet (3028)

Imagen del flyguille

03-10-2008, 20:57

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 Wink

Por MagicBox

Master (198)

Imagen del MagicBox

03-10-2008, 21:22

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 Wink

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 Wink

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

Por flyguille

Prophet (3028)

Imagen del flyguille

03-10-2008, 21:30

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?

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